Env: * Linux 64bit * nvidia with nouveau driver * No Flash player Reproduction: 1. Go to YouTube <http://www.youtube.com/watch?v=gdnO1QZJ--M> 2. Wait for the video to load and start to play 3. Wait for the light grey bar showing prebuffering to move head about 25% (but not full) 4a. Change the video position to a position ahead of the current, but within light grey pre-buffered area 4b. Change the video position back to see a part again that you missed 5. Wait until the video prebuffered entirely (no more dark grey in position bar, only red and light grey) 6a. Same as step 4a. 6b. Same as step 4b. Actual result: Step 4a and b: The playback stops for considerable time, often 5-10 seconds, often more Step 6a and 6b: The playback continues instantly on the chosen new position. Expected result: Step 4a and b: The playback continues instantly on the chosen new position, assuming it's already been played or pre-buffered. I.e. step 4a and 4b should match step 6a and 6b. Importance: This makes it practically impossible to repeat a short section of a video where you didn't understand a word or want to see a picture frame again.

The first time Gecko seeks in WebM, it must load the media's index. The WebM muxing guidelines recommend placing the index at the start of the file to avoid scattered loads to retrieve the index, but YouTube places the index at the end of the file which requires an additional HTTP transaction to fetch (for the first seek only). This might be the delay you're seeing if this only happens for the first seek, but 5-10 seconds sounds excessive (what bandwidth and latency do you have to YouTube?). If you're seeing the delay each time you seek, it sounds like something else is going on. I can't reproduce this as described with the linked video. There's a bug filed to avoid requiring the index for already cached portions of the file: bug 575140/bug 657791. It might be worth checking if YouTube uses the fastSeek API (when available); the bug to implement that is bug 778077. There's also a bug covering potential optimizations in WebM seeking (bug 754525), but I don't think you're hitting the edge case that would benefit from that fix.

> YouTube places the index at the end of the file Ah, duh. However, I would think that while an index is surely great for seeking, it is possible to seek without index. mplayer can seek just fine with MPEG2 TS (transport stream, no index) over HTTP, and quite accurately in fact. It's measuring stream bitrate and then calculating. The accuracy of course depends on variable bit rate vs fixed bit rate, but even with vbr, you can make a guess. MPEG TS doesn't even have an index, and as we see in the youtube example, we can't rely on the presence of an index. Like in mplayer, I would think that there needs to be a fallback mechanism based on bitrate, in case there is no index available. I guess that would be a new bug, though. > which requires an additional HTTP transaction to fetch (for the first seek only). > This might be the delay you're seeing if this only happens for the first seek, > but 5-10 seconds sounds excessive In fact, it's 22s. I just tried again, and that HTTP fetch doesn't seem to happen at all. If I do step 4a above, I have to wait 22 seconds until it resumes playing, which is exactly when the whole stream is prebuffered (dark grey bar keep bar turned completely light grey). This leads credibility to your theory of the index being at the end. Not only that, but when I seek, even the prebuffering stops for a good while, about 5-10s. That seems to me like the HTTP Range: doesn't work. I'm using privoxy <http://www.privoxy.org/>. When I use another profile without privoxy, it works as expected. So, it seems that the proxy is breaking HTTP Range:. Surely, that's primarily the fault of the proxy. I wonder how many other proxies are affected, though, and their users getting really bad youtube experience without knowing it. I installed privoxy myself, and funny enough in fact myself wrote a video server based on HTTP Range:, and I didn't realize the connection.

Mass closing do to inactivity. Feel free to re-open if still needed.