GNOME Bugzilla – Bug 596326
[qtdemux] wrong display_width/display_height
Last modified: 2013-08-21 18:18:39 UTC
Created attachment 144014 [details] sample media file Attaching a file being played by Quicktime at 640x480 and recognized by GStreamer as 320x240
Created attachment 144015 [details] qtdemux mem dump
I have no idea as to why Quicktime feels it should play this 640x480. GStreamer, mplayer, vlc all play this at 320x240 and qtinfo only reports the following: Type: Quicktime 0 audio tracks. 1 video tracks. 320x240, depth 24 rate 3.015075 [600:199] constant length 30 frames compressor png . Native colormodel: 24 bpp RGB Interlace mode: None (Progressive) supported. 0 text tracks.
I suspect this is from the display matrix in the mvhd atom. In this file, it is (I think - manually parsing it from a hex dump, I haven't written code for this): [ 2 0 0 ] [ 0 2 0 ] [ 0 0 1 ] Also, even if we did parse this, we don't actually have any mechanism in gstreamer to expose an arbitrary transformation matrix to downstream.
Taking in account the scale matrix, couldn't the size of the video be updated? This is a loss of information though, the original size will be lost :/
Phil: no, you can't do that. The only place you could change the size is when you actually scale the video - in videoscale for example - and there's no way to get the information (currently) to videoscale - you can only express the _actual_ size of the video, not how you want it displayed.
(In reply to comment #5) > Phil: no, you can't do that. The only place you could change the size is when > you actually scale the video - in videoscale for example - and there's no way > to get the information (currently) to videoscale - you can only express the > _actual_ size of the video, not how you want it displayed. Well, actually you can by using the p-a-r field. But because the core is dividing the numerator and denominator by the gcd this doesn't work in this case. If p-a-r of 2/2 was allowed and possible, videoscale could do the right thing. (but that's no pixel aspect *ratio* anymore... more a pixel size)
pixel-aspect-ratio is the wrong place to attempt to put the information - even though they're related. I imagine that it's possible to have a QT file that has both pixel-aspect-ratio *and* a desired presentation transformation matrix.
Are there other formats and/or codecs that provide this kind of information (transformation matrix)? If so maybe it'd be worth some addition in the core?
Could probably do something clever with metas now, though I'm not entirely sure what the point is and if we shouldn't just WONTFIX it, or perhaps just post an element message for the application so it can take care of that if it wants to?
Dupe of Bug 679522 ?
*** This bug has been marked as a duplicate of bug 679522 ***