Re: MediaStreamTrack behaviuor

Hi

I understand your confusing Tommy. We talked about this at the Stockholm 
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:11:24 UTC