Closed Bug 557094 Opened 15 years ago Closed 15 years ago

new backend no longer plays some ogg theora videos


(Core :: Audio/Video, defect, P2)




Tracking Status
blocking2.0 --- beta1+


(Reporter: j, Assigned: cpearce)




(Keywords: regression)


(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a4pre) Gecko/20100404 Minefield/3.7a4pre
Build Identifier: 

not sure why the video does not play, plays fine in other players
here ogginfo  videotestsrc-720x576-16-15.ogg 
Processing file "videotestsrc-720x576-16-15.ogg"...

New logical stream (#1, serial: 11f68f2c): type theora
Theora headers parsed for stream 1, information follows...
Version: 3.2.0
Vendor: Xiph.Org libTheora I 20040317 3 2 0
Width: 720
Height: 576
Total image: 720 by 576, crop offset (0, 0)
Framerate 250000000/10000000 (25.00 fps)
Pixel aspect ratio 16:15 (1.066667:1)
Frame aspect 4:3
Colourspace unspecified
Pixel format 4:2:0
Target bitrate: 0 kbps
Nominal quality setting (0-63): 16
Theora stream 1:
	Total data length: 423730 bytes
	Playback length: 0m:01.919s
	Average bitrate: 1765.541667 kb/s
Logical stream 1 ended

Reproducible: Always
for what it's worth, I've noticed that Thusnelda videos are iffy on Firefox. I have similar issues on Chrome. The same videos that give me issues in Firefox and Chrome (and other Webkit based *nix browsers), play fine in Opera 10.5. However, one small gotcha with this, I seem to have issues with Thusnelda encodes, when the videos are quite large size wise, like > 1GB, Firefox just doesn't seem to start playing. Smaller Thusnelda encoded videos, appear to play OK.

Ubuntu 10.04, AMD64, Firefox 3.6 (what comes with Ubuntu)

I can test on a minefield later on.
blocking2.0: --- → ?
For that video, the th_info.fps_numerator == 250000000 and th_info.fps_denominator == 10000000. When Firefix calculates the frame duration, it does (fps_denominator * 1000) / fps_numerator. We do that calculation in 32bit unsigned ints, and we check for overflow. The (fps_denominator * 1000) part is overflowing, and we abort the load.

We can probably get away with doing that calculation in 64bit ints, and aborting if the result is greater than UINT_MAX. We'd probably have pretty poor user experience if we calculated the frame duration as being anywhere near UINT_MAX max anyway.
Attached patch Patch v1Splinter Review
* Do FPS calculation in PRInt64, abort if result would not fit in PRUint32.
* Add test with FPS denominator/numerator pair which hit this condition.
* Add some "f" suffix to floating point constants to prevent compile warnings on Windows.
* Standardize spacing in manifest.js.
Assignee: nobody → chris
Attachment #437207 - Flags: review?(chris.double)
blocking2.0: ? → beta1+
Keywords: regression
Priority: -- → P2
Attachment #437207 - Flags: review?(chris.double) → review+
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.