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

Re: MediaStreamTrack disabling - effect on downstream MediaStreams?

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 27 Sep 2011 11:25:03 +0200
Message-ID: <4E81966F.9010700@alvestrand.no>
To: Adam Bergkvist <adam.bergkvist@ericsson.com>
CC: "Tommy Widenflycht (?????)" <tommyw@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 09/26/11 19:03, Adam Bergkvist wrote:
> On 19 september 2011 18:01, Harald Alvestrand wrote:
>> Just so it's clear - at the moment, I like the no-inheritance
>> model that Adam proposed better than either what's in the
>> current draft or my own proposal.
>> I haven't yet thought of an use case I could do with the
>> inheritance proposal that I couldn't also do in the
>> no-inheritance proposal, and in that case, I prefer simplicity.
>>                 Harald
> I'll try to summarize the state of this discussion.
> Proposed change 1: A MediaStream, created from an other MediaStream, should be regarded as an independent stream. Enabling or disabling a MediaStreamTrack in one stream will not affect any track in the other stream. Status: Most people seem to support this approach.
> 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.
> Is this a correct summary?
I agree with the summary, and think we should add proposed change 1 at once.

I think we can add proposed change 2 too; there are some issues here I'm 
not sure about, but we can address them in subsequent discussion.

One thing I'm not sure about in proposed change (2) is whether it has 
implications on synchronization - we have assumed that when audio and 
video come off the net with a common CNAME, and get assigned to one 
MediaStream, the streams should be played out in sync as far as possible.

When we group tracks from multiple, unsynchronized MediaStreams into a 
new MediaStream, do we assume that the framework will force some kind of 
lockstep on them, or do they just play out according to the vagaries of 
their respective jitter buffers?

At the moment, I think we can't remove MediaStreamTracks from a 
MediaStream - what there is is what the source sends, no more and no 
less. We can just fiddle with the "disabled" bits, and in the previous 
(inheriting) proposal, this provided a very roundabout way of removing a 
track (to remove a track from a stream, disable it upstream). Should we 
add explicit removal functions?

If a source adds a track, does it get added to only the MediaStream that 
was originally connected to the source? I'm assuming yes.

Received on Tuesday, 27 September 2011 09:25:42 UTC

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