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

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.

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.
>
>
>
>
>