Re: MediaStreamTrack behaviuor

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