This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
Also, is the change in the output after modifying the enabled state synchronous? If not, this should be specified in more details.
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: https://github.com/fluffy/webrtc-w3c/commit/6637a2b22d6326410d92e7d724ec8dca1dfdfc06 [1] file:///home/eadaber/webcom/w3c/webrtc-w3c.git/getusermedia.html#life-cycle-and-media-flow
The proposed change does clarify, thanks! How about the synchronous or asynchronous impact of changing the enabled state?
(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.
let's assume synchronous, and make the spec explicit about it; we can always revert if implementors prove this assumption wrong
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).
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?
I think there are plenty of examples of a boolean attribute queuing up a task; e.g. http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#dom-audiotrack-enabled 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.
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?
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)
Works for me :)