Last modified: 2013-07-30 10:26:02 UTC
Last left over of bug 16149 Upstream issuer reported at https://trac.xiph.org/ticket/1666
Testing real quick on Mac OS X 10.6.7 with XiphQT 0.1.9 just installed (the latest release shown, from June '09). Forcing the QuickTime viewer in Safari seems to show the video at http://commons.wikimedia.org/wiki/File:Aljazeeraasset-GAZAATTACKD29128D540.ogv in the correct aspect ratio (16:9). Running it through 'Native browser support' (<video> tag) shows it incorrectly at 720x576 -- this will be using the same Quicktime components for decoding, but through a different interface at the browser level. Since 'native' support is the default, that seems to be what's coming up wrong... but it may be a bug in Safari's video implementation rather than the XiphQT stuff itself judging by the Quicktime plugin sizing it correctly.
That page hadn't been purged yet btw. You are right it seems the <video> pipeline is not adapting to non-square pixels, but that the QT <object> is.
Created attachment 8494 [details] Test html with different inclusion methods of the video
Created attachment 8495 [details] Screenshot of the video tag rendering
Created attachment 8496 [details] Screenshot of the object tag with width rendering
Created attachment 8497 [details] Screenshot of object rendering without width setting
Further investigation with #webkit IRC people: <video> and the Snow Leopard player open videos in quicktimes "Clean aperture"-mode, unlike older QTP versions and the old QT object plugin that open videos in "classic" mode. For "Clean aperture" mode to work icw non-square pixel video formats, plugins such as the XiphQT plugin need to implement the pasp atom or PixelAspectRatioImageDescriptionExtension.
Assigning this one to MDale.
mdale: This report has been in ASSIGNED status for more than one year and you are set as its assignee. In case that you are not actively working on a fix, please reset the bug status to NEW/UNCONFIRMED. In case you do not plan to work on a fix in the near future: Please also edit the "Assigned To" field by clicking "Reset Assignee to default", in order to not prevent potential contributors from working on a fix. Thanks for your help! [assigned>=1y]
The OggHandler extension is not under active development anymore. It is unlikely that there will be any further active development. OggHandler has been superseded by TimedMediaHandler: http://www.mediawiki.org/wiki/Extension:TimedMediaHandler Please use TimedMediaHandler instead. Closing this report as WONTFIX as part of Bugzilla Housekeeping. Please feel free to reopen this bug report in the future if either anyone takes the responsibility for active development of OggHandler again; or move this bug report from the "OggHandler" to the "TimedMediaHandler" component in Bugzilla if the same problem still happens when using TimedMediaHandler. Thanks.
