- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Thu, 5 Jul 2012 14:12:59 +0200
- To: "Tommy Widenflycht (ᛏᚮᛘᛘᚤ)" <tommyw@google.com>
- CC: Anant Narayanan <anant@mozilla.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 2012-07-05 14:10, Adam Bergkvist wrote: > Hi > > I understand your confusing Tommy. We talked about this at the Stockholm s/confusing/confusion/ > meeting. The spec is rather inconsistent in this area. Some text hints > that it should be copies while the algorithms says references. When I > wrote the algorithm my intention was to create copies of the tracks, but > somehow that rather important detail got lost. > > We have the scenario you mention described in the (WebRTC) spec: > > "The concept of duplicating MediaStream objects as described in > [GETUSERMEDIA] is also applicable here. This feature can be used, for > instance, in a video-conferencing scenario to display the local video > from the user’s camera and microphone in a local monitor, while only > transmitting the audio to the remote peer (e.g. in response to the user > using a "video mute" feature). Combining tracks from different > MediaStream objects into a new MediaStream is useful in certain cases." > > I was going to look into this after the Stockholm meeting, but I found > ongoing work that conflicted a bit [1]. I doesn't seem like Rich is > going to propose any text so I might as well update the algorithm. > > /Adam > > [1] > http://lists.w3.org/Archives/Public/public-media-capture/2012Jun/0053.html > > On 2012-07-05 09:47, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote: >> Ahh, good! Here's the text: >> >> >> 2.2 MediaStream >> >> The |MediaStream()| constructor takes two arguments. The arguments are >> two lists with ||MediaStreamTrack| >> <http://dev.w3.org/2011/webrtc/editor/getusermedia.html#idl-def-MediaStreamTrack>| objects >> which will be used to construct the audio and video track lists of the >> new |MediaStream| object. When the constructor is invoked, the UA must >> run the following steps: >> >> 1.Let audioTracks be the constructor’s first argument. >> >> 2.Let videoTracks be the constructor’s second argument. >> >> 3.Let stream be a newly constructed |MediaStream| object. >> >> 4.Set stream’s label attribute to a newly generated value. >> >> 5.If audioTracks is not null, then run the following sub steps for >> each element track in audioTracks: >> >> 1.If track is of any other kind than "|audio|", then throw a >> |SyntaxError| exception. >> >> 2.If track has the same underlying source as another element in >> stream’s audio track list, then abort these steps. >> >> 3.Add track to stream’s audio track list. >> >> 6. If videoTracks is not null, then run the following sub steps for >> each element track in videoTracks: >> >> 1.If track is of any other kind than "|video|", then throw a >> |SyntaxError| exception. >> >> 2.If track has the same underlying source as another element in >> stream’s video track list, then abort these steps. >> >> 3.Add track to stream’s video track list. >> >> >> >> >> >> On Thu, Jul 5, 2012 at 6:12 AM, Anant Narayanan <anant@mozilla.com >> <mailto:anant@mozilla.com>> wrote: >> >> On 07/04/2012 05:35 AM, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote: >> >> I am a bit confused regarding the latest draft regarding how >> MediaStreamTracks should behave when they are part of more than one >> MediaStream. >> >> It used to be that when a MediaStream was created with a list of >> Tracks >> one created new tracks that had the same underlying data source >> as the >> input tracks. Basically one cloned the tracks. >> >> >> This is my understanding as well, if an existing track is added to a >> new MediaStream it should be duplicated even if the source is the same. >> >> >> Now the draft says that the new MediaStream should add the same >> Tracks >> to its lists. That means that the same Track can now belong to >> more than >> one MediaStream. This has an unfortunate effect that if one >> disables a >> Track, the Track gets disabled in all MediaStreams. It is no longer >> possible to have independent enabled stated, and for example >> this basic >> use case is impossible: >> >> >> Which part of the spec are you inferring this from in particular? We >> should update the text to be clearer. >> >> Thanks, >> -Anant >> >> >> >> >> -- >> Tommy Widenflycht, Senior Software Engineer >> Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden >> Org. nr. 556656-6880 >> And yes, I have to include the above in every outgoing email according >> to EU law. > > >
Received on Thursday, 5 July 2012 12:13:27 UTC