W3C home > Mailing lists > Public > public-web-and-tv@w3.org > June 2018

Re: [media-and-entertainment] Frame accurate seeking of HTML5 MediaElement

From: Ingar Arntzen via GitHub <sysbot+gh@w3.org>
Date: Wed, 13 Jun 2018 16:33:33 +0000
To: public-web-and-tv@w3.org
Message-ID: <issue_comment.created-397003443-1528907612-sysbot+gh@w3.org>
@nigelmegitt These are excellent questions, thank you 👍 

> does it change the event handling model so that it no longer uses Time Marches On?

yes. the sequencer is separate from the media element (which also means that you can use it for use cases where you don't have a media element). It takes direction from a timing object, which is basically just a thin wrapper around the system clock. The sequencer uses <setTimeout()> to schedule enter/exit events at the correct time.

> What happens if the event handler for event n completes after event n+1 should begin execution?

Being run in the js environment, sequencer timeouts may be subject to delay if there are amny other activities going on (just like any appcode). The sequencer guarantees the correct ordering, and will report how much it was delayed. It something like the sequencer was implemented by browsers natively, this situation could be improved further I suppose. The sequencer itself is light-weight, and you may use multiple for different data sources or different timing objects.

> Does the timing object synchronise against the video or does it cause the video to be synchronised with it? In other words, in the case of drift, what moves to get back into alignment?

Excellent question! The model does not mandate one or the other. You may 1) continuously update the timing object from the currentTime,  or 2) you may continuously monitor and adjust currentTime to match the timing object (e.g. using variable playbackrate). 

Method 1) is fine if you only have one media element, you are doing sync only within one webpage, and you are ok with letting the media element be the master of whatever else you want to synchronize. In other scenarios you'll need method 2) 

The *timingsrc* has a *mediasync* function for method 2) and a *reversesync* function for method 1) (...I think) 

> How does the interpolating clock deal with non-linear movements along the media timeline in the video, such as pause, fast forward and rewind?

The short answer:  using *mediasync* or *reversesync* you don't have to think about that, it's all taken care of. 

Some more details:
The mediasync library creates a interpolated clock internally as an approximation on currentTime. It can distinguish the natural jitter of currentTime from hard changes by listening to events (i.e. seekTo, variable playbackrate etc.)

GitHub Notification of comment by ingararntzen
Please view or discuss this issue at https://github.com/w3c/media-and-entertainment/issues/4#issuecomment-397003443 using your GitHub account
Received on Wednesday, 13 June 2018 16:33:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 13 June 2018 16:33:41 UTC