Spun off from discussion in bug 476973. While dragging the video scrubber, the controls trigger seeks while moving it around. This is good, in theory, so that you get visual feedback of the position while moving it around. It's not too bad when doing this in a file:// video. However, due to network seeking being slow and our current inability to cache pieces of video data, this basically just results in extra overhead which slows down the overall task. We should thus look at suppressing position change requests from the scrubber until mouse-up, or perhaps delay them until the position hasn't been changed for some number of (milli?)seconds.

Very important for user experience.

We will shortly have a reasonable media data cache that should make things much better. I suggest we do the following when the thumb is dragged and the mouse button is still down: -- If 'seeking' is true, don't do another seek. -- If the networkState is NETWORK_LOADED, then assume the entire resource is cached, and do a seek to the current thumb position -- (If/when bug 462959 is fixed) If the current thumb position is before the time when we started seeking, but it's in the 'played' range, then assume the data is cached and do a seek. If we implemented 'buffered' I'd use that instead of checking NETWORK_LOADED and 'played', but 'played' is much easier to implement than 'buffered'.

Chris is implementing 'buffered' in bug 462957, but I'm not sure it will make 1.9.1. I actually think we should fix this for 1.9.1 regardless of what whether bug 462957 makes it or not. I think we should just seek-on-mouseup for now, until bug 462957 is fixed.

I really really want this fixed for 1.9.1, but we shouldn't actually block the release on it.

(In reply to comment #2) > -- If 'seeking' is true, don't do another seek. Does the backend discard multiple queued seeks? EG, if user drags the thumb and causes a sequence like "currentTime = 1; currentTime = 2; currentTime = 3; currentTime = 4;" -- when the first seek (to 1) finishes, does the backend then seek to the last requested position (4), or does it attempt to process the intermediate steps too? I wonder how much effect "don't seek while seeking" is likely to actually have, since if the first seek finished while the thumb is still being dragged, another seek would be triggered immediately anyway. And we have to make sure that the final seek gets executed at some point, since that's where the user is expecting things to end up. Really, it's the first seek that's the problem, since we spend time seeking to 1 when the user quickly moves on to 4. I'm thinking a better fix would be to have the controls wait a short delay before requesting a seek. EG: var timer, seekTo; onThumbDrag(newPosition) { seekTo = newPosition; if (timer) return; timer = setTimeout("video.currentTime = seekTo", 100); } The delay needs to be short enough to allow exploratory dragging, but high enough to suppress unneeded seeks. Maybe it can take different values depending on how long a seek is predicted to take... EG, seek when the thumb lingers over a buffered position for 50ms, but don't seek to an unbuffered position unless the thumb lingers there for 500ms. Or maybe just adjust a single value based on long the last measured seek took.

(In reply to comment #5) > Does the backend discard multiple queued seeks? EG, if user drags the thumb > and causes a sequence like "currentTime = 1; currentTime = 2; currentTime = 3; > currentTime = 4;" -- when the first seek (to 1) finishes, does the backend > then seek to the last requested position (4), or does it attempt to process > the intermediate steps too? We'd discard 2 and 3. > I wonder how much effect "don't seek while seeking" is likely to actually > have, since if the first seek finished while the thumb is still being dragged, > another seek would be triggered immediately anyway. And we have to make sure > that the final seek gets executed at some point, since that's where the user > is expecting things to end up. Really, it's the first seek that's the problem, > since we spend time seeking to 1 when the user quickly moves on to 4. Yes, you're right. > I'm thinking a better fix would be to have the controls wait a short delay > before requesting a seek. EG: > > var timer, seekTo; > onThumbDrag(newPosition) { > seekTo = newPosition; > if (timer) return; > timer = setTimeout("video.currentTime = seekTo", 100); > } > > The delay needs to be short enough to allow exploratory dragging, but high > enough to suppress unneeded seeks. Maybe it can take different values > depending on how long a seek is predicted to take... EG, seek when the thumb > lingers over a buffered position for 50ms, but don't seek to an unbuffered > position unless the thumb lingers there for 500ms. Or maybe just adjust a > single value based on long the last measured seek took. That sounds like kind of a pain to tune. Now that bug 469408 has landed, we can seek almost instantly in any buffered data range. Unfortunately fixing 462957 to expose the buffered ranges is much too risky for 1.9.1. The other issue here is that currently when we seek through video, Ogg happily plays intermediate frames over the top of whatever's currently there, without applying them to the right keyframe. So intermediate seeking is pretty much broken at the moment, anyway. Then again, there's still a chance we'll be able to seek to the nearest keyframe. So I'm not really sure what to do here. Maybe we shouldn't do anything.

Not actively working at this at the moment.

Not a blocker

Should this bug still be fixed ? I've tried seeking in a HD video stream, and I had no problem at all.

I'm not seeing the slow downs mentioned in comment 0 and we should be seeking if we're not getting these slowdowns as it provides a better experience. Also, it looks like comment 9 is seconding the current lack of slow downs while dragging.