Re: Track Definition - Was: Re: MediaStreamTrack disabling - effect on downstream MediaStreams?

On Wed, Oct 19, 2011 at 5:57 PM, Cullen Jennings <fluffy@cisco.com> wrote:

>
> On Oct 5, 2011, at 16:44 , Justin Uberti wrote:
>
> >
> >
> > On Wed, Oct 5, 2011 at 2:07 PM, Cullen Jennings <fluffy@cisco.com>
> wrote:
> >
> > On Sep 26, 2011, at 11:03 AM, Adam Bergkvist wrote:
> >
> > >
> > > Proposed change 2: The MediaStream constructor should take a list of
> MediaStreamTracks, which makes it possible to combine tracks from several
> streams into a new MediaStream (see older mails for use case). Status: Some
> support, some think it may be more powerful than what we need. No real
> objections.
> >
> > I'm not sure we agree what a track is and without a clear answer to that,
> I find it hard to have a position on this. If other think it is clear what a
> track is, perhaps I just need it explained to me.
> >
> > I will propose what I think a track should be ... I think it should be
> the smallest unit stream which can not be further subdivide in it's on the
> wire representation. So effectively this means I think it should represent
> the media flowing in or out of a single codec. So if you you have an audio
> codec that codes the stereo as one set of data and uses joint coding - they
> I view that as one track. But if you you separately encode the right and
> left by passing them through two different codecs and one could be decoded
> without the other, then I would view that as two tracks. Similarly by this
> definition, if you were sending a DTMF and G.711 media, that would be two
> tracks. I'm not sure if there is widespread agreement on this or not but if
> people think tracks are something different than this, it would be great to
> hear what they should be.
> >
> > My understanding is slightly different; I'm looking at a track as an RTP
> source. The main difference from your definition is that I would not see
> DTMF and G.711 as separate media. If DTMF is sent out-of-band using
> telephone-event, or in-band using G.711, that distinction shouldn't be
> evident to the higher layers. Similarly, if a client chooses to switch
> codecs in mid-stream, that wouldn't create a new track IMO. If stereo is
> sent as "left mic source" + "right mic source" with the same CNAME, that
> would result in two tracks in a single MediaStream. But if stereo was sent
> as a single "stereo mic source" with stereo coding, that would be a single
> track.
> >
>
> ok - just trying to get my head around all this.  So would a video and
> audio from the same camera be one track ? It seems like they are the same
> RTP source.
>

If they could be coded as a single interleaved format, I suppose they could
be the same source. In practice, such a camera will generate two independent
streams, with separate codecs, and will result in two different RTP sources
(and hence tracks).


>
>
> > In short, I see that a track indicates a single media source with a
> single clock and a single identifier (SSRC) that allows clear identification
> of which packets belong to which track.
> >
> > I don't know if this is a good definition or not but really what it gets
> down to is I'm a bit unclear on what all these things are.
> >
> >
> >
> >
> >
>
>