STR: 1) Download the video located here: http://people.mozilla.org/~jwein/project-video.webmvp8.webm 2) Open the file locally in Firefox and begin playing 3) Open the file locally in VLC and begin playing 4) Compare seeking in VLC to Firefox I'm not sure why we are slower, but when we move to a new seek point we sit there and stall for a while (~6 seconds) before we resume playing whereas VLC takes ~2 seconds to resume playing. We also *appear* slower due to our greying of the video when we seek, but I think wouldn't be as noticeable if we were a little snappier.

Firefox seeks precisely to the frame specified by the time in currentTime. VLC and many media players don't do this, last time I checked. When seeking via the built-in controls, this accuracy obviously isn't necessary. We could introduce a additional method of seeking that seeks to an approximate location rather than a specific frame. I thought there was a bug about this already, but I can't find it now. There's some discussion over in https://www.w3.org/Bugs/Public/show_bug.cgi?id=14851 about introducing an API for seeking to an approximate location. The other issue is that the Cues (index) in this particular file are spaced very far apart (which has happened because the key frames are spaced the same way). In fact, for the entire nine and a half minute file there are only 23 keyframes (and therefore Cue entries, some over two minutes apart). Since we seek frame accurately, with such badly spaced keyframes/cues we might be forced to decode ~3600 frames before reaching the one we're looking for.

Having said that, if I seek VLC to a point between two badly spaced keyframes, it still lands pretty close to the right location and takes less than a second. Seeking to the same location in Firefox takes fifteen(!) seconds, with one CPU pinned the entire time. I doubt VLC's raw VP8 decoding is a factor of 15 faster than ours, so there's something else going wrong here.

(In reply to Matthew Gregan [:kinetik] from comment #1) > same way). In fact, for the entire nine and a half minute file there are > only 23 keyframes (and therefore Cue entries, some over two minutes apart). The good news is that rillian got a patch accepted to lower the default max keyframe interval in libvpx from essentially infinite to 5 seconds, so hopefully files like this should become rarer in the future.

| + SimpleBlock (key, track number 1, 1 frame(s), timecode 286.767s = 00:04:46.767) at 12199990 | + SimpleBlock (key, track number 1, 1 frame(s), timecode 424.100s = 00:07:04.100) at 18083143 Seeking to 276.767 and 424.100 is instantaneous. Seeking to 424.000 takes 26-27 seconds. In VLC it takes less than a second. Of interest, Firefox uses one core the entire time the seek is in progress, whereas VLC appears to use 3-4 cores. Multithreaded VP8 decoding might explain part of this, but there's still a large factor unaccounted for. (In reply to Timothy B. Terriberry (:derf) from comment #3) > The good news is that rillian got a patch accepted to lower the default max > keyframe interval in libvpx from essentially infinite to 5 seconds, so > hopefully files like this should become rarer in the future. That's great news!

A quick profiling run reveals we're blowing 35-40% of the time on colour conversion and copying decoded frames around. That seems avoidable. A quick hack in VideoData::Create to avoid calling SetData at all brings the seek time down from 21s to 7s on this machine (suggesting that we're blowing more like 66% of the time in colour conversion/copying). After that, profiling shows almost all the time is spent decoding in libvpx.

And a build of VLC (2.1) from git on this machine takes around 7 seconds to seek (it doesn't appear to be using multithreaded decoding like my VLC 2.0 build on Windows does).

Is this still reproducible in Firefox 46?

I can't reproduce this anymore on Firefox 49 (2016-05-02).