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

[whatwg] HTML5 video: frame accuracy / SMPTE

From: Gregory Maxwell <gmaxwell@gmail.com>
Date: Fri, 21 Jan 2011 13:31:44 -0500
Message-ID: <AANLkTik483BVsdB1bwMpqdPo4-qOzDpWDgqojGLhbpRX@mail.gmail.com>
On Fri, Jan 21, 2011 at 1:12 PM, Michael Dale <dale at ucsc.edu> wrote:
> On 01/13/2011 01:44 AM, Philip J?genstedt wrote:
>>
>> Changing the default at this point wouldn't really hurt since not all
>> browsers are doing exact seeking anyway, right? I think that keyframe
>> seeking is more often what you want and it'd be better to let the few
>> who want frame-exact seeking jump through hoops than having everyone
>> who makes a simple seeking UI discover that seeking is a bit slow and
>> 20% of them figuring out that it can be fixed by using seek().
>>
>
> Is accurate seeking *that* much slower than keyframe seeking? I would
> discourage changing the accurate seek default. If supported at all you
> should opt into fuzzy seeking.
>
> Assuming the client can buffer fast enough for real-time playback, a
> seek to keyframe + time in the worst case would would take time offset.
> But in most cases the data to time ratio after the keyframe is much more
> sparse then the keyframe itself. So the ranged request for key + data to
> time will normally not be a lot more than keyframe + data for future
> playback for seeking to a keyframe. You can see seeking is pretty fast
> in the indexed seek firefox demos.

It's usually the decoding, not the file access that kill you.  Firefox
seeking on low resolution clips is very snappy index or not. But try a
1080p clip encoded with a 10 second maximum keyframe interval...

If your client is just capable of realtime playback then you can be
waiting as much as ten seconds for an exact seek. Even if it's 2x
realtime (a pretty reasonable multiple for 1080p) you're still taking
about 5 seconds in the worst case.

Basically, as the decoding speed approaches realtime the seeking time
approaches what you'd get by seeking to the prior keyframe and playing
up to the current point, except with the exact seeking you sit around
twiddling your thumbs while the client looks broken.

I'm personally a fan of a heuristic approach where the first seek from
a user goes to a keyframe while subsequent seeks soon after the first
are all exact.  But this is a user interface thing, and not really a
question of what the API should provide.
Received on Friday, 21 January 2011 10:31:44 UTC

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