Status

()

defect
VERIFIED FIXED
11 years ago
9 years ago

People

(Reporter: rillian, Assigned: roc)

Tracking

({verified1.9.1})

Trunk
x86
All
Points:
---
Bug Flags:
wanted1.9.1 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(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, http://people.xiph.org/~greg/video/linux_conf_au_CELT.ogv, 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 http://people.xiph.org/~giles/2009/celt-aspect.html
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 http://www.celt-codec.org/presentations/ 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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Summary: aspect ratio no repected → Aspect ratio not correct
Whiteboard: DUPEME
Version: unspecified → Trunk

Updated

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]

Updated

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.

http://hg.mozilla.org/mozilla-central/rev/12878454c5d5
Status: NEW → RESOLVED
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

and

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

Updated

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.