[whatwg] HTML5 video: frame accuracy / SMPTE

[Glenn Maynard]

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