[Bug 14851] <video> Add seek() function for non-exact (fast) seeking

https://www.w3.org/Bugs/Public/show_bug.cgi?id=14851

--- Comment #7 from Ian 'Hixie' Hickson <ian@hixie.ch> 2012-04-30 22:57:53 UTC ---
On Wed, 12 Jan 2011, Eric Carlson wrote:
> > I agree that precise seeking follows the principle of least surprise,
> based partly on the bugs files against the <video> element on iOS where
> this hasn't always been the behavior.

On Thu, 13 Jan 2011, 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().

On Fri, 21 Jan 2011, Michael Dale wrote:
> 
> 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.

On Fri, 21 Jan 2011, Gregory Maxwell wrote:
> 
> 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.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 30 April 2012 22:57:56 UTC