Closed Bug 557094 Opened 10 years ago Closed 10 years ago
new backend no longer plays some ogg theora videos
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.
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.
* 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+
Priority: -- → P2
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.