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

RE: MediaStreamTrack disabling - effect on downstream MediaStreams?

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Mon, 19 Sep 2011 17:06:53 +0200
To: Harald Alvestrand <harald@alvestrand.no>
CC: "\"Tommy Widenflycht (?????)\"" <tommyw@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <A1249B08688639468D1CB181445EE79D31BEA06F8A@ESESSCMS0355.eemea.ericsson.se>
On 19 september 2011 16:19, Harald Alvestrand wrote:
>> Since your tracks can have different states in the parent and the
>> child, it's clearly separate MediaStreamTrack instances, but they are
>> still related somehow. It seems from your example that tracks in
>> forked streams have a tri-state, "not set" (ask parent), "enabled",
>> and "disabled", is that correct? This would make it possible to build
>> tree structures of MediaStreamTracks where you would have to traverse
>> the tree to find the enable/disable state of a track.
> I don't think it's a tri-state, you only have to ask parent
> if it's enabled.
> 
> If this were C++, I would claim that enabled() has to be an
> accessor, not an exposed variable, since it does a
> computation to return its value. Not sure how this is
> normally done in Javascript.
> 
> Since the value of "enabled" doesn't depend on just what
> "enabled" is set to, this statement:
> 
>     mediastream2.tracks[0].enabled = mediastream2.tracks[0].enabled
> 
> might cause a change of state. That's confusing.
> 

You're right, you can solve it by asking the parent track (all the way to the original track) if the current track is enabled. The enabled value would only be true if all parent tracks are enabled. A consequence of that would be:

var mediaStream2 = new MediaStream(mediaStream1);

mediaStream1.tracks[0].enabled = false;
// mediaStream1.tracks[0].enabled == false

mediaStream2.tracks[0].enabled = true;
// mediaStream2.tracks[0].enabled == false

BR
Adam
Received on Monday, 19 September 2011 15:07:19 UTC

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