W3C home > Mailing lists > Public > public-web-and-tv@w3.org > February 2019

[me-media-timed-events] Pull Request: Clarify that time marches on may run at any rate

From: François Daoust via GitHub <sysbot+gh@w3.org>
Date: Sat, 16 Feb 2019 13:02:50 +0000
To: public-web-and-tv@w3.org
Message-ID: <pull_request.opened-253641483-1550322169-sysbot+gh@w3.org>
tidoust has just submitted a new pull request for https://github.com/w3c/me-media-timed-events:

== Clarify that time marches on may run at any rate ==
The text suggested that HTML requires the time marches on steps and timeupdate events to run and get fired every 250 milliseconds at a minimum. I believe that is incorrect.

HTML does not require a specific rate to run the time marches on steps. The wording used in the time marches on step that talks about `timeupdate` events assumes that the steps run at least 4 times per second, but that is an implicit assumption which is not required anywhere AFAICT. The 250ms upper bound is a suggestion, not a requirement (and the informative note that follows the step is confusing because user agents can fire events at a slower rate in practice).

The only requirements in HTML are:
- "When the current playback position of a media element changes (e.g. due to playback or seeking), the user agent must run the time marches on steps" (see [requirement](https://html.spec.whatwg.org/multipage/media.html#playing-the-media-resource:current-playback-position-13)), which essentially requires the rate at which the time marches on steps run to match the rate at which the current playback position changes; and
- "When a media element is potentially playing [...], its current playback position must increase monotonically at the element's playbackRate units of media time per unit time of the media timeline's clock" (see [requirement](https://html.spec.whatwg.org/multipage/media.html#playing-the-media-resource:current-playback-position-9)), which sets the speed at which the current playback position increases, but not the rate at which it gets updated.

New text clarifies that the issue is that implementations are only required to run the time marches on steps when the current playback position changes, and that they are basically free to do that at any rate. On top of that, the time marches on steps allow timeupdate events to be fired only every 250ms, which makes the mechanism unsuitable for synchronized rendering. The HTML spec explicitly [discourages the use of `timeupdate` events for processing cues](https://html.spec.whatwg.org/multipage/media.html#best-practices-for-metadata-text-tracks:event-media-timeupdate)

See https://github.com/w3c/me-media-timed-events/pull/35
Received on Saturday, 16 February 2019 13:02:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:42 UTC