Last modified: 2011-05-15 09:56:04 UTC
Video formats frequently allow specifying non-square pixels; for instance NTSC DVDs at 720x480 may have either "tall" pixels (for classic 4:3 screen) or "wide" pixels (for a 16:9 widescreen picture). Currently we don't take this into account and assume pixels will be square; as a result, a video with non-square pixels will appear displayed squished or stretched. The raw pixel size should probably be scaled to a "display" pixel size; thumbnails can be generated at that size and the player widgets can be stretched at that aspect ratio. (QuickTime appears to properly scale the picture to its proper aspect ratio within the plugin window, but Cortado just stretches the video to fit whatever size you specified. Haven't tested Firefox 3.1 video element yet.) I've made a 720x480 widescreen version of the fundraising PSA video, which I'll upload somewhere shortly as an example.
Some related discussion at http://commons.wikimedia.org/wiki/Commons:Village_pump#Cortado_Java_Applet
(In reply to comment #1) > Some related discussion at > http://commons.wikimedia.org/wiki/Commons:Village_pump#Cortado_Java_Applet > Please use permalinks. http://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=18173542#Cortado_Java_Applet
Looks like I totally forgot to upload the test video, but I've linked to one of the Al-Jazeera videos described in the discussion above which demonstrates the problem: http://commons.wikimedia.org/wiki/File:Aljazeeraasset-GAZAATTACKD29128D540.ogv This is a 16:9 PAL video; 720x576 pixel source should display stretched to 1024x576. Note that the file has correct metadata; VLC displays it at the proper aspect ratio.
Cortado itself has been correct since r48131. This issue now appears limited to the ffmpeg generated thumbnails.
Is there no possibility to fix the aspect ratio of the generated thumbnails? I am not a programmer, but there are at least 2 ways to get the proper properties of the media files: 1) the command "ffmpeg -i xxx.ogg" returns it as an error code. 2) use mediainfo (open source) to get the aspect ratio By using this information, the correct resizing with ffmpeg is not a problem..
Wikimedia no longer uses ffmpeg for thumbnail generation. oggThumb can correctly handle pixel aspect, so I think all that needs to be fixed up is the ogghandler side.
Thank you for your friendly information. Searching for "oggThumb" i found this (http://dev.streamnik.de/75.htm): -s Picture output size. The thumbnail is created in the size given as <width>x<height>. If you want to include the thumbnails into your webpage and you need to have a fixed width but dynamic height, you can set the dynamic axis to 0. So the aspect ratio of the video frame is kept. This is the same for setting width or height to 0. Example: -s 0x100 So I think it will not be so difficult to fix this bug. Thumbnails with wrong aspect ratio in a Wikipedia page look really strange (and my camera produces videos in anamorphic 16:9). Last of all: sorry for my poor English...
Note: XiphQT doesn't seem to support square pixels either.
(In reply to comment #8) > Note: XiphQT doesn't seem to support square pixels either. Reported as: https://trac.xiph.org/ticket/1666
Fixed non-square pixels for OggHandler in r65927.
Thanks and 2 questions: when will it be available in the standard software used by commons/wikipedia and what must be done to fix the ratio in the thumbnails of existing videos?
The answer to the first question is not my calle. It likely will be in 1.17 and 1.16 has not even been released yet, so probably a few more months at the very least. Note that this does not fix the size of the thumbnails. The thumbnails are generated by ffmpeg or oggThumb, which both should work now (if you download the thumbnail you should be able to verify). This fixes how the thumbs are displayed by MediaWiki in the HTML and at most it requires an action=purge of the imagedescription page.
OK, I will wait and carry on produce anamorphic clips for wikipedia... Thanks again!
Thanks, now thumbnails are working correct. However a new minor bug is introduced now: the resolution of the files is wrong interpreted in the description of the files (example: http://commons.wikimedia.org/wiki/File:Meligethes_aeneus_720x576.og . The resolution of 720x576 is displayed as 1,024×576 pixels.)
That depends on your definition of correct. The actual display size is 1024x576 pixels. The storage size is different indeed, but that is not something that we care about at the front end. Closing this and moving the xiphQT issue to a new separate bug 28732.
