RE: MediaStreamTrack disabling - effect on downstream MediaStreams?

On 2011-09-14 21:09, Harald Alvestrand wrote:
> It's entirely unclear to us (the implementors working on the Chrome
> implementation) what the purpose of this effect of disabling is, and 
> in several usages (such as temporarily turning off a track to e.g. 
> mute video or audio), it seems disruptive - since any other properties 
> such as SSRCs assigned to a MediaStreamTrack will have to be 
> re-established or re-negotiated after a disable/enable event.
>
>  From the perspective of enabling temporary muting of a track, it 
> seems like it would be better if the text had said:
>
>     When a track in a MediaStream parent is disabled, any
>     MediaStreamTrack objects corresponding to the tracks in any
>     MediaStream objects that were created from parent stop sending
>     data, although their "enabled" status does not change. If a
>     disabled track in a MediaStream parent is re-enabled, data starts
>     flowing on the downstream MediaStreamTrack objects, as long as
>     their /enabled/ attribute has the value "true".
>
> What do other people think - what would it be best if the spec said?

Hi

We think the idea with parent and child relations between MediaStream
objects, where tracks suddenly appear in child streams and other side
effects, will be confusing for web developers and doesn't really add
anything.

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

Received on Thursday, 15 September 2011 11:58:05 UTC