W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2011

[whatwg] HTML5 video: frame accuracy / SMPTE

From: Robert O'Callahan <robert@ocallahan.org>
Date: Mon, 24 Jan 2011 14:36:15 +1300
Message-ID: <AANLkTim_JBnYO4OTqv0NVOudo9k36KdxaqeQn54AToYu@mail.gmail.com>
On Sun, Jan 23, 2011 at 12:03 AM, Philip J?genstedt <philipj at opera.com>wrote:

> Ah, thanks for clarifying. It might be a bit odd for the spec to forbid
> being too clever, but I think that in practice always seeking to the same
> point is much easier, so that's what would be implemented. It would indeed
> be bad if one browser always managed to seek one frame ahead even when using
> fast seeking, and another always seeks to a nearby keyframe/key unit/index
> point/whatever.
>

Interop problems are going to arise with approximate seeking no matter what
we do, which is why it shouldn't be the default.

You don't want seekApproximate(T) to always land on the same T'. For
example, if a player wants to "seek forward approximately N seconds" via
seekApproximate(currentTime + N), but the approximation to currentTime + N
is fixed to be some T' less than or equal to currentTime, that would be
broken.

I would say that seekApproximate(T) should be specified to aim as close as
possible to T while being "fast", but the only guarantee is that it seeks
somewhere after currentTime if T > currentTime, or somewhere before
currentTime if T < currentTime.

Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]
Received on Sunday, 23 January 2011 17:36:15 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:29 UTC