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

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

From: François Daoust via GitHub <sysbot+gh@w3.org>
Date: Tue, 19 Feb 2019 10:35:38 +0000
To: public-web-and-tv@w3.org
Message-ID: <pull_request.closed-253641483-1550572537-sysbot+gh@w3.org>
tidoust has just closed tidoust's pull request 35 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)


<!--
    This comment and the below content is programatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/tidoust/me-media-timed-events/pull/35.html" title="Last updated on Feb 16, 2019, 1:02 PM UTC (607602a)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/me-media-timed-events/35/f5a1428...tidoust:607602a.html" title="Last updated on Feb 16, 2019, 1:02 PM UTC (607602a)">Diff</a>

See https://github.com/w3c/me-media-timed-events/pull/35
Received on Tuesday, 19 February 2019 10:35:39 UTC

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