Document timing requirements for different use cases

[chrisn]

The document should describe timing and synchronisation requirements for different kinds of events.

The Frame accurate seeking of HTML5 MediaElement discussion in w3c/media-and-entertainment#4 contains some useful detail to add. For example, in w3c/media-and-entertainment#4 (comment), @Daiz says:

even a frame or two of subtitles hanging on the screen after a scene change happens is very much notable and ugly to look at during playback.

Different kinds of events may have different synchronisation requirements, and it would be useful to categorise those, where we can. For example, maybe the banner ad, or social media feeds, and WebVMT use cases each have different timing requirements?

[chrisn]

Some discussion in https://www.w3.org/2018/02/01-me-minutes.html:

Igarashi: In terms of frame-accurate eventing, as Francois said I don't see any specific requirement. Ad insertion won't be achieved at the app level, it's more at the system or rendering level.
... Some broadcasters maybe want to synchronise web content with the media, e.g., information about a soccer player during a game.
... I see these as rarer applications. Accuracy to only about 100 ms is needed, not frame accuracy, for broadcast systems.
Giri: The W3C specs don't guarantee 100 ms accuracy, something that HbbTV complained about.
... There are other issues than UA latency that result in missing cues. Hence the MPEG work, which should take some of the uncertainty out of processig the events.
... Frame accuracy isn't critical, but 500 ms isn't good either.
Igarashi: I think 300 ms is enough in most cases.

[rjksmith]

WebVMT displays output in a separate HTML element, rather than within the media container, so latency is not particularly noticeable as the media and map displays are not generally overlaid.

It uses a keyframe approach for animation, so again latency is not particularly noticeable. A worst case scenario would be a media scene change which instantly moves to a different location and requires the map to 'jump' concurrently. However, there are other inherent delays, such as loading times for the new map tiles, that would be needed at the same time in this case, so it is only one of many factors.

The HTML5 Embedded Content document currently specifies 250ms as the maximum response time for events.