W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2011

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 20 Oct 2011 10:38:54 +0200
Message-ID: <4E9FDE1E.4090701@alvestrand.no>
To: Cullen Jennings <fluffy@cisco.com>
CC: Justin Uberti <juberti@google.com>, public-webrtc@w3.org
On 10/19/11 23:57, Cullen Jennings 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.

Cullen, you know they go in different SSRCs. I don't think there's a 
definition in RTP that calls them "one source".

DTMF creates a mess; that's not at all unusual, I think.
Received on Thursday, 20 October 2011 08:39:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:22 UTC