This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22259 - Disabled mediastreamtrack and state of media element
Summary: Disabled mediastreamtrack and state of media element
Alias: None
Product: WebRTC Working Group
Classification: Unclassified
Component: Media Capture and Streams (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
QA Contact:
Depends on:
Reported: 2013-06-04 10:55 UTC by Dominique Hazael-Massieux
Modified: 2014-04-10 07:30 UTC (History)
2 users (show)

See Also:


Description Dominique Hazael-Massieux 2013-06-04 10:55:02 UTC
When a mediastreamtrack is being played in a media element and its enabled attribute is set to false, what is the impact for the media element?

I think the current intent is that the media element from its perspective is still playing, but the played content is the muted output (silence/blackness); among other things, the currentTime should still be updated, and the various relevant events (e.g. timeupdate) should be dispatched.

If so, that should be said explicitly; among other things, it doesn't seem like this is how Chrome is currently behaving.
Comment 1 Dominique Hazael-Massieux 2013-06-04 11:00:41 UTC
Also, is the change in the output after modifying the enabled state synchronous? If not, this should be specified in more details.
Comment 2 Adam Bergkvist 2013-09-30 13:05:00 UTC
General consumer behavior for muted and/or disabled tracks is described in the (MediaStreamTrack) Lify-cycle and Media Flow section [1]. To make it a bit more concrete, I've added an example (with media element) based very much on your text below.

Proposed change:

[1] file:///home/eadaber/webcom/w3c/webrtc-w3c.git/getusermedia.html#life-cycle-and-media-flow
Comment 3 Dominique Hazael-Massieux 2013-10-01 16:11:15 UTC
The proposed change does clarify, thanks!

How about the synchronous or asynchronous impact of changing the enabled state?
Comment 4 Adam Bergkvist 2013-10-02 10:02:45 UTC
(In reply to Dominique Hazael-Massieux from comment #3)
> The proposed change does clarify, thanks!
> How about the synchronous or asynchronous impact of changing the enabled
> state?

My, perhaps naive, interpretation is that it's synchronous.
Comment 5 Dominique Hazael-Massieux 2013-10-02 12:19:21 UTC
let's assume synchronous, and make the spec explicit about it; we can always revert if implementors prove this assumption wrong
Comment 6 Dominique Hazael-Massieux 2014-04-03 12:59:13 UTC
there was some follow up discussion on this: my question on synchronicity was about the effects of setting the enabled flag (black video / silent audio).

In other words, I believe the expectation is that these effects are not obtained synchronously, but rather that there is task queued to black the video and mute the audio — if so, the algorithm should be written (and the task queue be picked).
Comment 7 Adam Bergkvist 2014-04-03 13:16:51 UTC
Are you saying that there should be a task scheduled on the JS thread to do this? In that case I don't think an writable attribute is the right API for this functionality. It would be more appropriate with a request function and let the queued task update a readonly attribute when the task is carried out.

I like the simple attribute though. Couldn't we specify it to instruct the UA to make the change as soon as possible?
Comment 8 Dominique Hazael-Massieux 2014-04-03 13:34:27 UTC
I think there are plenty of examples of a boolean attribute queuing up a task; e.g.

That same links also shows that HTML5 is silent on how and when the disabled state is reflected in the media player, so maybe we don't need to say anything either. 

That said, part of why they don't need to say anything is that there is a "change" event fired on enabling/disabling a given track; I think it would be consistent to have a similar event in our case.
Comment 9 Adam Bergkvist 2014-04-03 13:51:21 UTC
I read the example you provided as there is an event queued to notify the script that something has happened, not to perform the actual "work".

Regarding doing the "work", the text says:

"On setting, it must enable the track if the new value is true, and disable it otherwise."

Can't we get away with something similar?
Comment 10 Dominique Hazael-Massieux 2014-04-03 13:54:16 UTC
I agree that the HTML5 spec is silent on when the work is done, and that we can probably be silent ourselves as a result.

(and thus close this bug)
Comment 11 Adam Bergkvist 2014-04-03 13:56:42 UTC
Works for me :)