- From: Glenn Maynard <glenn@zewt.org>
- Date: Sat, 22 Jan 2011 05:01:26 -0500
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