11 years ago
9 years ago


(Reporter: rillian, Assigned: roc)



Bug Flags:
wanted1.9.1 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)




(2 attachments)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.2a1pre) Gecko/20090224 Minefield/3.2a1pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.2a1pre) Gecko/20090224 Minefield/3.2a1pre

Anamorphic Ogg Theora files don't scale properly with the pixel aspect ratio embedded in the media. Visiting the above page shows a video with square pixels, which is squashed horizonally, except for the title card.

The video resource,, reports a *pixel* aspect ratio of 4:3 which with the native frame size of 384x288 should result in a 16:9 *frame* aspect ratio. Instead the frame is 4:3.

The same issue occurs when the resource is loaded directly without an enclosing html page. Correct behaviour can be see by playing the location in a media player, such as VLC or totem-gstreamer. Note that the initial title card in this video was not scaled correctly when the video was in coded, so it should look stretched horizontally during correct playback.

Reproducible: Always

Steps to Reproduce:
1. visit
2. Press play and wait while the title card is displayed

Actual Results:  
Video plays with square pixels, showing horizontal compression.

Expected Results:  
Video should play in a wider frame scaled to represent the embedded pixel aspect ratio.

The example html5 page is based on which at the moment applies additional width and height attributes to the video. In this case the video fills the specified frame when it should letterbox.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090225 Minefield/3.2a1pre ID:20090225033705
Shows this too. Have not looked into it more, but new for now.
Ever confirmed: true
OS: Mac OS X → All
Summary: aspect ratio no repected → Aspect ratio not correct
Whiteboard: DUPEME
Version: unspecified → Trunk


10 years ago
Flags: wanted1.9.1?
Should be fairly easy to fix.
Flags: wanted1.9.1? → wanted1.9.1+

Comment 3

10 years ago
confirm on 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4
I can't find a dup.
Assignee: nobody → roc
Whiteboard: DUPEME
It's not really clear what the intrinsic width and height of the video should be in the example in comment #0.

One approach would be: if the aspect ratio is >1.0, then the intrinsic height is the frame height and the intrinsic width is the aspect ratio times the frame width. If the aspect ratio <1.0 then the intrinsic width is the frame width and the intrinsic height is the frame width divided by the aspect ratio. In other words, a non-1.0 aspect ratio can only make the video bigger. How does that sound?
Posted patch fixSplinter Review
This actually turned out to be super-easy. All we have to do is compute the right intrinsic width rectangle to send to the element. nsMediaDecoder::Paint already scales the video to fill the rectangle that the caller passes in, so when the caller passes in a rectangle based on this new intrinsic width, the necessary scaling happens automatically.

Writing a reftest here would be easy, except that I'm not sure how to create a minimal Ogg file with a given pixel aspect ratio.
Attachment #378049 - Flags: review?(chris.double)
Whiteboard: [needs review]


10 years ago
Attachment #378049 - Flags: review?(chris.double) → review+

Comment 8

10 years ago
Comment on attachment 378198 [details] [diff] [review]
liboggplay changes

Can you add to README_MOZILLA mentioning the patch and pointing to this bug?
Attachment #378198 - Flags: review?(chris.double) → review+
The problem was that oggplay_get_video_aspect_ratio was failing on some videos (on all platforms) including the reftest videos, because the aspect ratio numerator and denominator are zero, so oggplay_get_video_aspect_ratio returns E_OGGPLAY_UNINITIALIZED. I guess that makes sense, but we were ignoring the return code and using the output variables uninitialized. On Mac and Linux we happened to get 0/0 which we interpreted as 1.0. On Windows we got something random.

I fixed the patch to check the return code and use 1.0 if the aspect ratio is uninitialized, and checked that in.
Closed: 10 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Whiteboard: [needs 191 landing]
verified FIXED on builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090527 Minefield/3.6a1pre ID:20090527031500


Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090527 Shiretoko/3.5pre ID:20090527031214


10 years ago
Duplicate of this bug: 496714

Comment 14

9 years ago
This bug should be reopened, it's happening again with latest trunk.

Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.3a4pre) Gecko/20100402 Minefield/3.7a4pre
(In reply to comment #14)
> This bug should be reopened, it's happening again with latest trunk.
> Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.3a4pre) Gecko/20100402
> Minefield/3.7a4pre

Filed bug 556889 for this.
You need to log in before you can comment on or make changes to this bug.