- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 27 Sep 2011 11:25:03 +0200
- 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. Harald
Received on Tuesday, 27 September 2011 09:25:42 UTC