22259 2013-06-04 10:55:02 +0000 Disabled mediastreamtrack and state of media element 2014-04-10 07:30:51 +0000 1 1 1 Unclassified WebRTC Working Group Media Capture and Streams unspecified PC Linux RESOLVED WONTFIX P2 normal --- 1 dom public-media-capture adam.bergkvist public-media-capture oldest_to_newest 88608 0 dom 2013-06-04 10:55:02 +0000 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. 88609 1 dom 2013-06-04 11:00:41 +0000 Also, is the change in the output after modifying the enabled state synchronous? If not, this should be specified in more details. 94011 2 adam.bergkvist 2013-09-30 13:05:00 +0000 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 94087 3 dom 2013-10-01 16:11:15 +0000 The proposed change does clarify, thanks! How about the synchronous or asynchronous impact of changing the enabled state? 94166 4 adam.bergkvist 2013-10-02 10:02:45 +0000 (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. 94172 5 dom 2013-10-02 12:19:21 +0000 let's assume synchronous, and make the spec explicit about it; we can always revert if implementors prove this assumption wrong 103336 6 dom 2014-04-03 12:59:13 +0000 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). 103346 7 adam.bergkvist 2014-04-03 13:16:51 +0000 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? 103351 8 dom 2014-04-03 13:34:27 +0000 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. 103353 9 adam.bergkvist 2014-04-03 13:51:21 +0000 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? 103354 10 dom 2014-04-03 13:54:16 +0000 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) 103355 11 adam.bergkvist 2014-04-03 13:56:42 +0000 Works for me :)