- From: François Daoust via GitHub <sysbot+gh@w3.org>
- Date: Mon, 18 Jun 2018 13:27:03 +0000
- To: public-web-and-tv@w3.org
One comment on @nigelmegitt's https://github.com/w3c/media-and-entertainment/issues/4#issuecomment-397209849 and @Snarkdoof's https://github.com/w3c/media-and-entertainment/issues/4#issuecomment-397593999. There seems to be a slight confusion between the frequency at which the "time marches on" algorithm runs and the frequency at which that algorithm triggers `timeupdate` events. The "time marches on" algorithm only triggers events when needed, and `timeupdate` events once in a while. Applications willing to act on cues within a particular text track should not rely on `timeupdate` events but rather on `cuechange` events of the `TextTrack` object (or on `enter`/`exit` events of individual cues), which are fired as needed whenever the "time marches on" algorithm runs. The [HTML spec](https://html.spec.whatwg.org/#playing-the-media-resource:time-marches-on-4) requires the user agent to run the "time marches on" algorithm when the current playback position of a media element changes, and notes that this means that "these steps are run as often as possible". The spec also mandates that the ["current playback position" be increased monotonically](https://html.spec.whatwg.org/#playing-the-media-resource:current-playback-position-9) when the media element is playing. I'm not sure how to read that in terms of minimum/maximum frequency. Probably as giving full leeway to implementations. Running the algorithm at 50Hz seems doable though (and wouldn't trigger 50 events per second unless there are cues that need to switch to a different state). Implementations may optimize the algorithm as long as it produces the same visible behavior. In other words, they could use timeouts if that's more efficient than looping through cues each time. -- GitHub Notification of comment by tidoust Please view or discuss this issue at https://github.com/w3c/media-and-entertainment/issues/4#issuecomment-398053332 using your GitHub account
Received on Monday, 18 June 2018 13:27:07 UTC