- From: Philip Jägenstedt <philipj@opera.com>
- Date: Sat, 22 Jan 2011 12:03:55 +0100
On Sat, 22 Jan 2011 11:01:26 +0100, Glenn Maynard <glenn at zewt.org> wrote:
> 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.
>
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.
--
Philip J?genstedt
Core Developer
Opera Software
Received on Saturday, 22 January 2011 03:03:55 UTC