Re: MediaStreamTrack disabling - effect on downstream MediaStreams?

On 09/15/11 13:57, Adam Bergkvist wrote:
> 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.
Hm - I'm not sure how that translates into pictures. Are you suggesting 
that when you clone a stream, you attach the input to the new stream 
object to the (conceptual) *input* of the cloned-from stream object 
rather than its (conceptual) output, and there being no way one 
MediaStream element can affect another MediaStream element directly?

This means that MediaStream objects can't be used to model processing 
elements, which may actually be a Good Thing. Or not; I'm off to read 
the Audio prcessing proposal again in preparation for a coordination 
meeting between the W3C Audio, DAP and WEBRTC chairs later today - I may 
form more opinions.

                Harald

Received on Thursday, 15 September 2011 12:16:46 UTC