Found while working on the videocontrol scrubber (bug 462113), with the patches for bug 464376 and bug 469446 applied... Dragging the scrubber to a new position sets video.currentTime. That works (although it's slow), but doing so also seems to trigger a (partial?) download of the video again. The video starts firing progress events, at about the same rate as when it's initially downloaded. This will happen after the video has been fully loaded, so it's definitely not just downloading unbuffered data.

Which part is the bug? the re-download or the firing events again? It seems to me that we might throw away the beginning of a video before we hit the end and actually do need to re-download the beginning...

I think the basic problem is that it's downloading again, even for small seeks adjacent to the currently playing position. The progress events are probably ok if a re-download is expected, although I'm not sure what the spec has to say about it. I guess I mainly mention them because they're the most obvious symptom.

We throw away data as soon as we've displayed/played it. So any seek backwards will redownload. A seek forwards into data we've already got buffered will not cause a redownload. A seek forwards into an area we've not buffered will cause a redownload. Maybe a better approach for the bug is an enhancement to improve the buffering/caching of the resource to minimize re-downloads and improve seeking. This is something we've been discussing.

(In reply to comment #3) > A seek forwards into data we've already got buffered will not > cause a redownload. I'm seeing redownloads for both forwards and backwards seeks, after the video has fully loaded.

> I'm seeing redownloads for both forwards and backwards seeks, > after the video has fully loaded. Sorry, I meant the underlying seeks performed by the ogg libraries. A seek request forward in time from the user will often cause a seek backwards as the ogg libraries 'divide and conquer' through the resource to find the correct seek location. So in practice seeks will always cause a redownload unless extremely lucky that the ogg libraries guess the location immediately and it's already buffered.

I don't think we can really block on this. Ogg seeking is not very good and the caching required to work around that will be quite elaborate and difficult to get right.

To be clear, is this an Ogg decoder problem or our cache problem? Seems like seeking within data already cached is something the cache should support (maybe it's tricky, I'm not familiar with the code). This results in a really poor experience when changing the playback position, especially compared to other online video players like YouTube. Seeking within a local file:// video is significantly faster, though still not quite snappy.

Necko doesn't support caching of byte-range requests. We'd have to layer our own caching on top of Necko (or do major Necko surgery). It's doable, but difficult, and we have a lot of other important bugs that need to be fixed for 3.1. I guess the fact that Ogg seek operations are really slow is actually different from this bug, but it compounds the bad user experience.

Fair enough. The video controls should work correctly, if slowly, as-is.

So is it expected that on http://www.double.co.nz/video_test/test5.html any seek would take 20+ seconds?

See https://bugzilla.mozilla.org/show_bug.cgi?id=469408#c4

I'd like to point out that most other "online video" implementations (Flash and Windows Media at least) just download the whole thing to a temporary file when seeking is allowed. The file is kept around in some temporary folder until the video is dismissed. Additionally, the download is backed up by the regular browser cache, but doesn't rely on it during playback. This seems the most sane solution to me. For streaming stuff, there's no temp file but there's no seeking either. Aditionally, Flash has it so that optionally you can seek beyond the loaded point. This trashes all the already downloaded data and starts a new download at the exact required offset. In order for this to work, the video file has to have a header where all the possible seek times and byte offsets are stored. So the file has to support it, and the server has to support byte range requests. Otherwise, it just keeps buffering until it reaches the requested position. I think doing a binary search over the network is ill advised.

This is an opportunity to be better than Flash and not throw away downloaded video before seeking into the future. It makes sense to cache the entire video at least while the page is open.

This was fixed by the media cache work.