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

Re: MediaStreamTrack disabling - effect on downstream MediaStreams?

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Mon, 19 Sep 2011 16:17:42 +0200
Message-ID: <4E774F06.3000709@ericsson.com>
To: public-webrtc@w3.org
On 2011-09-16 16:52, Harald Alvestrand wrote:
> On 09/15/2011 08:12 PM, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote:
>> Your suggestion seems very powerful but possibly more powerful than
>> needed. What kind of use cases do you have in mind for this? I
>> personally like the clear relationship between parent and child.
> to me, wearing my WG chair hat, it seems that we have 2 proposals for
> conceptual models on the table:
>
> - MediaStreams are groups of tracks, each of which comes from a source.
> If you create a MediaStream from another MediaStream, you get tracks
> that come from the same source (so carry the same content), but bear no
> relationship to the original MediaStream's tracks.

Wearing my contributor hat (and as my desk is only a few meters from 
Adam's, the value of my vote may be limited in this case) I cast my vote 
on the model above. To me it seems simpler because there are no 
dependencies while being flexible.

>
> - MediaStreams are groups of tracks, each of which comes from either a
> source or a track within another MediaStream. If you create a
> MediaStream from another MediaStream, you get tracks that come from that
> MediaStream (the "parent"), so depend on the state of that MediaStream
> and its tracks for whether or not there is data flowing.
>
> To illustrate, the task "take an incoming MediaStream with 2 video
> tracks and display them separately" that we discussed earlier would become:
>
> First version:
>
>       myFirstVideo = stream
>       mySecondVideo = new MediaStream(myFirstVideo)  // both tracks present
>       myFirstVideo.videoTracks.select(1)
>       oneVideoObject.setSource(myFirstVideo.getUrl())  // Showing first
> track
>       mySecondVideo.videoTracks.select(2)
>       anotherVideoObject.setSource(mySecondVideo.getUrl())  // Showing
> second track
>
> No matter what you do to myFirstVideo, mySecondVideo will not be affected.
>
> Second version:
>
>       myMultiVideoStream = stream
>       myFirstVideo = new MediaStream(myMultiVideoStream)
>       myFirstVideo.videoTracks.select(1)
>       oneVideoObject.setSource(myFirstVideo.getUrl())  // Showing first
> track
>       mySecondVideo = new MediaStream(myMultiVideoStream)
>       mySecondVideo.videoTracks.select(2)
>       anotherVideoObject.setSource(mySecondVideo.getUrl())  // Showing
> second track
>
> If one disables tracks in myMultiVideoStream, or deletes the objects,
> data will no longer flow to myFirstVideo and mySecondVideo.
>
> The issue of what disabling a stream does seems less fundamental than
> this difference.
> Opinions?
>
>                     Harald
>
>
>> /Tommy
>>
>>
>> On Thu, Sep 15, 2011 at 04:57, Adam Bergkvist
>> <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>> wrote:
>>
>>
>>     It would be more flexible and easier for developers to grasp if a new
>>     MediaStream, constructed from another MediaStream, would have tracks
>>     that are independent from its "parent" (even though they map to the
>>     same underlying audio and/or video sources). The new MediaStream would
>>     also get its own label.
>>
>>     For example, the MediaStream forking functionality was added to
>>     support
>>     the use case where you want to stop sending video without
>>     disabling the
>>     video in your local self-view. If you then instead would like to
>>     disable
>>     the local self-view without stop sending video you would have to
>>     create
>>     yet another "child" for the local self-view, rather than just
>>     using the
>>     "parent".
>>
>>     The way we would like to achieve this is to let the MediaStream
>>     constructor take an array of MediaStreamTrack objects.
>>
>>     // streamB will contain copies of all tracks from streamA
>>     var streamB = new MediaStream(streamA.tracks);
>>
>>     // the below statements are all true
>>     streamB.label != streamA.label;
>>     streamB.tracks[0] !== streamA.tracks[0];
>>     streamB.tracks[0].kind == streamA.tracks[0].kind;
>>     streamB.tracks[0].label == streamA.tracks[0].label;
>>
>>     // streamC will contain copies of a subset of the tracks in streamA
>>     var streamC = new MediaStream([streamA.tracks[0], streamA.tracks[2]]);
>>
>>     // combinedStream will contain copies of the first tracks in
>>     localStream
>>     // and remoteStream (the audio tracks)
>>     var combinedStream =
>>        new MediaStream([localStream.tracks[0], remoteStream.tracks[0]]);
>>     // record the conversation
>>     var recorder = combinedStream.record();
>>
>>     BR
>>     Adam
>>
>>
>>
>>
>> --
>> 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 Monday, 19 September 2011 14:18:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:25 UTC