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

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

From: Cullen Jennings <fluffy@cisco.com>
Date: Wed, 5 Oct 2011 12:07:33 -0600
Message-Id: <3A9F0648-D8BC-4A21-AC8E-DEBBDA984877@cisco.com>
To: public-webrtc@w3.org

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. 

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. 
Received on Wednesday, 5 October 2011 18:08:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:25 UTC