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

[whatwg] HTML5 video: frame accuracy / SMPTE

From: Glenn Maynard <glenn@zewt.org>
Date: Sat, 22 Jan 2011 05:01:26 -0500
Message-ID: <AANLkTikYchmqFo1+dRsMDiDMbZJp420rmcRHt2GOx1aN@mail.gmail.com>
On Sat, Jan 22, 2011 at 4:23 AM, Philip J?genstedt <philipj at opera.com> wrote:
>> Should there be any consistency requirements for fast seeking?
>>
>> Suppose you have a format that's high-bitrate but cheap to decode.
>> Accurately seeking is fast if the data is already buffered, but slow
>> if not, since it's limited by bandwidth and not CPU.
>>
>> An implementation might decide to snap to a keyframe if the needed
>> data isn't yet buffered, so it doesn't spend several seconds
>> downloading all of the data; but if it the data is already buffered,
>> to seek precisely.
>>
>> This could have unexpected side-effects. ?Should this be allowed? ?I'd
>> suggest that fast seeking should always be consistent with itself, at
>> least for a particular video instance.
>
> I don't think that any consideration should be given to what is already
> buffered and not, as it's always faster to seek to what's buffered so that
> would simply make it impossible to seek into the unbuffered parts. Also,
> it'd require the demuxer (which is where seeking happens) to have knowledge
> of the transport layer.

What I'm asking, though, is whether implementations should be
expressly forbidden from doing this sort of thing, by requiring that
fast seeking to a given time on the same video element always lands on
the same place.  (Aside from changes to seekable; this requirement
would be after the new playback position is clamped to seekable, not
before.)

That guarantees that:

video.seekMode = "fast";
function f() {
    video.currentTime = 10;
    setTimeout(f, 5000);
}
f();

will always seek to the same position, and never choose different
positions due to a too-clever seek algorithm allowing more precise
seeking as more data is buffered.

-- 
Glenn Maynard
Received on Saturday, 22 January 2011 02:01:26 UTC

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