GNOME Bugzilla – Bug 323332
mpeg2dec sets wrong aspect ratio for 16:9 dvds
Last modified: 2008-10-04 21:45:06 UTC
trying to decode mpeg2-ntsc with 16:9 aspect ratio(non square pixels) mpeg2dec sets a par of 128:81 "pixel-aspect-ratio", GST_TYPE_FRACTION, mpeg2dec->pixel_width, mpeg2dec->pixel_height, this is wrong since that way one ends up with a frame aspect ratio of 2.370 32:27 would be the right pixel aspect ratio in this case. this bug renders apps like thoggen useles for a common user.
do you have a sample file we could test this with ?
sample provided off bugzilla, write me if you need a sample.
The current display aspect ratio is of 720 / 480 * 128 / 81 = 64 / 27. So it's exactly two times bigger than the good DAR. The pixel aspect ratio is 'filled' in by the mpeg2dec library and then copied over by the plugin in the handle_sequence() function. The values returned by mpeg2dec are: width, height: 720, 480 picture-width,height: 720, 480 display-width,height: 540, 480 pixel-width,height: 128, 81 Something which might be of interest, is that mpeg2dec is saying that the sequence is PAL and not NTSC.
This is a bug in libmpeg2. Because this is video from a pan-and-scan DVD, it has a 720x480 video, with an intended 16:9 display ratio, and also in the MPEG data (in the sequence_display_extension) is information telling the decoder to crop to 540x480 pixels. 720x480->16:9 display implies (16*480)/(9*720) = 1.185 pixel-aspect-ratio (or 32/27) as we want. libmpeg2 is computing the pixel-aspect-ratio from the CROPPED window, however (which it should not). A 540x480 window stretched to 16:9 implies (16*480)/(9*540) = 128/81 pixel-aspect-ratio. We could work around this in mpeg2dec by checking whether the picture-size matches the display-size, but the correct fix should be done in libmpeg2
Created attachment 57270 [details] [review] Patch fixing libmpeg2 This is patch for libmpeg2 to fix this issue. I am trying to push this patch to libmpeg2 developers. Does anybody here know some them?
Well, the problem seems to be far more complicated. See http://sourceforge.net/mailarchive/forum.php?thread_id=9460940&forum_id=729
Yep, ok - I agree with the interpretation of the mpeg spec in the email thread (I missed that clause previously). In terms of DVD vobs, I guess the problem is that Pan & Scan is an optional output mode, and is the only time that the sequence display extension is used. As mentioned in the thread, DVDs do have access to other information about the display mode, but this is only (I think?) stored in the .ifo files, not in the .vobs. I can't see any way to automatically adapt libmpeg2 or mpeg2dec for these streams and still have it work for ones that match the MPEG spec.
This is bad. From all I know, it seems that such specs-violating mpeg streams are quite common and that the authoritative information should be taken from the .ifo file. (BTW: mplayer ignores PAR from mpeg2dec completely) Now, the question is how to solve this. I see two possibilities: - create a dvdmpeg2dec that will try guess the correct PAR knowing that the given stream is from DVD. But I do not know how to handle this by autopluggers (put dvdstream=true to caps?) - propagate the information from .ifo file to mpeg2dec somehow. Probably using application event - but this assumes that the source is dvdsrc.
It may be possible to detect NAV streams in the mpeg demuxer for MPEG-2 streams and add an extra parameter in the caps that the mpeg2dec can use to know when to override the encoded PAR from the stream.
What means "NAV stream"? It would be good to have the problem solved without using .ifo files.
VOB mpeg2 streams have NAV and DSI packets inside one of the private streams. This is at the mpeg demuxer level, so it would need to pass the information down to the mpeg decoder via caps.
Michal are you still looking into this issue?
We have solved this issue by overriding the aspect ratio using the value from the .ifo file. There is a patch that adds DAR parameter to mpeg2dec plugin. But I have not posted it anywhere since this solution needs some application interaction (namely reading DAR prom .ifo and setting it to the mpeg2dec plugin)
So is anything still to be done here? Maybe mpeg2dec should prefer pixel aspect ratios given via caps over then ones it finds in the mpeg stream? And then we teach the demuxer (or dvdsrc?) to put it into the caps if possible?
It makes more sense for the (mythical) dvdbin element to fix up the p-a-r coming out of mpeg2dec.
thaytan, does resindvd fix up p-a-r in this way?
Yep, it does - in the rsnparsetter element that sits after the video decoder.
OK, then this is fixed.