557094 - new backend no longer plays some ogg theora videos

Status: RESOLVED FIXED

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

Description

[Jan Gerber]

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

Comment 1

[John-Paul Harold]

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.

Comment 2

[Chris Pearce [:cpearce (Not reading bugmail)]]

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.

Comment 3

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Patch v1

* 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.

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

http://hg.mozilla.org/mozilla-central/rev/ae1034cd5067