777648 - Seeking the HTML5 video from the URL causes the video to jump to the end and not be playable anymore

Status: RESOLVED WONTFIX

(Core :: Audio/Video, defect)

Description

[Adrian Tamas (:AdrianT)]

Firefox Mobile Native 15.0b2 build 1/ Nightly 17.0a1 2012-07-25/ Aurora 16.0a2 2012-07-25 / Firefox Desktop 14.01
Device: HTC Desire (Android 2.2)/Motorola Droid Pro (Android 2.3.4)/ PC Windows 7 32bit

Steps to reproduce:
1. Go to http://people.mozilla.com/~nhirata/html_tp/big_buck_bunny_480p.webm and let the video begin to play
2. Move the video scrubber 30 sec forward

Expected results:
The video resumes from the new position

Actual results:
The scrubber jumps at the end of the video and the video can no longer be played. Reloading the tab leaves the page in a loading state for a long time. The only solution is to close the tab and reload the link in a new one. 
On Firefox Mobile the page can be reloaded in order to use the video
This is the only video I found that exhibits this behavior.

Notes:
The issue is not reproducible on the PC (Windows 7 32bit) using Google Chrome 20.0.1132.57

Comment 1

[Matthew Gregan [:kinetik]]

That file is broken, please test against a valid file.  I emailed Naoki about it in May but did not get a response.  It looks like the same file (on a different server) was used to report bug 696519.

The reason that seeking doesn't work is that we don't support seeking in WebM files without Cues--that's bug 657791.  Except this file claims it has Cues but doesn't, so it's actually just broken, and probably wouldn't be fixed by fixing bug 657791 unless we added special handling for broken files, which seems like a bad idea.

% mkvinfo -v -v big_buck_bunny_480p.webm
+ Segment, size 39857249 at 43
|+ Seek head at 55
[...]
|  + Seek ID: 0x1c 0x53 0xbb 0x6b (KaxCues) at 93
|  + Seek position: 39834097 at 100

% ls -l big_buck_bunny_480p.webm
39256064

So the Cues lie 578033 bytes beyond the end of the file.

The other reason this particular file is bad for testing is that it may give the false impression that Firefox's playback is slow.  This is because we correctly honour the frame durations and this file's frame durations increase through the video--the start of the video is 24fps, drops to 12fps at 13.5s, 8fps at 25.3s, and then 6fps at 27.4s for the rest of the video.