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

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

From: Njaal Borch <njaal.borch@gmail.com>
Date: Wed, 13 Jun 2018 21:00:12 +0200
Message-ID: <CAOc996t9+DrLf1kgQaCU--BdoincY6_rbMQpv1m=ad11c7AK1w@mail.gmail.com>
To: Ingar Arntzen via GitHub <sysbot+gh@w3.org>
Cc: public-web-and-tv@w3.org
Just a small comment about the sync we are achieving: we always have to
correct an error with media playback, as media elements do not compensate
for the buffering time. In other words, "play from X" is interpreted as
"play from X whenever you are ready". As X is a moving target in our model,
the player is always late.

We compensate by learning how slow a media element is (the next skip is
much more accurate), and we use variable playback rate for fine adjustments
and keeping in sync even if there is drift in playback (many devices have
proven to play back at a slightly wrong pace).

Native support for timing objects would fix all of these issues, and will
at the same time enable excellent methods for synchronizing anything from
sub titles to synchronized web animations.

On Wed, Jun 13, 2018, 19:10 Ingar Arntzen via GitHub <sysbot+gh@w3.org>

> @chrisn
> > Presumably, frame accurate time reporting would help with synchronised
> media playback across multiple devices, particularly where different
> browser engines are involved, each with a different pipeline delay. But,
> you say you're already achieving sub-frame rate sync in your library, based
> on currentTime, so maybe not?
> So, while the results are pretty good, there is no way to ensure that they
> are always that good (or thay they will stay this good), unless these
> issues on the agenda through standardization work.
> There are a number of ways to improve/simplify sync.
> - as you say, exposing accurate information on downstream delays, frame
> count, media offset is always a good thing.
> - currentTime values are also not timestamped, which means that you dont
> really know when it was sampled internally.
> - The jitter of currentTime is terrible.
> - Good sync depends on an interpolated clock. I guess this would also make
> it easier to convert back and forth between media offset and frame numbers.
> - there are also improvements *seekTo* and *playbackrate* which would
> improve things considerably
> --
> GitHub Notification of comment by ingararntzen
> Please view or discuss this issue at
> https://github.com/w3c/media-and-entertainment/issues/4#issuecomment-397014061
> using your GitHub account
Received on Wednesday, 13 June 2018 19:04:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 13 June 2018 19:04:18 UTC