MKVtoolnix: AR fixed but MPC-HC doesn't recognize it

[flapane]

Hi,
I have fixed a wrong AR (912x600)
Display aspect ratio : 16:9
Original display aspect ratio : 3:2

It works well in VLC, but MPC still uses the wrong 3:2 AR. Do I need to change something in MPC settings? The AR flag is just set on "default".

[sneaker_ger]

mkvtoolnix only changes the container AR, there's an additional AR coded into the bitstream (I just assume you are using H.264 video - you haven't stated all the details.) In some decoders and splitters you will find an option called "use stream AR" (or similar), try unticking that.
You can also try to fiddle with bitstream AR and either
a.) let it be removed by mkvtoolnix by adding "--engage remove_bitstream_ar_info" to the command line or
b.) use this special ffmpeg build (http://forum.doom9.org/showthread.php?t=152419) to change it

[flapane]

Sorry, I'm using H.264 video
I tried option a), (and also tried to search in Halli media splitter for options, without lucky), but MPC still doesn't recognize the correct AR:
C:\Users\Flavio>"C:\Program Files (x86)\MKVtoolnix\mkvmerge.exe" -o "G:\\output.mkv" --engage remove_bitstream_ar_info "G:\\input.mkv"
mkvmerge v4.8.0 ('I Got The...') built on May 24 2011 03:12:58
'G:\\input.mkv': Using the Matroska demultiplexer.
'G:\\input.mkv' track 1: Using the MPEG-4 part 10 (VC) video output module.
The file 'G:\\output.mkv' has been opened for wrting.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 20 seconds.

[sneaker_ger]

What splitter/decoder/renderer are you using and have you tried searching for the "use stream AR" option?

[flapane]

Haali media splitter on MPC-HC, while playing the video via ffdshow rev3882/EVR.

[sneaker_ger]

Ok, "--engage remove_bitstream_ar_info" seems to be broken at the moment. I don't know how to not let ffdshow utilize stream AR info, only MPC decoder. (Maybe someone else knows?)
If you don't want to switch from ffdshow and it indeed turns out to not have that option, try an older mkvtoolnix version or use that patched ffmpeg build to remove or correct the AR info.

[sneaker_ger]

"--engage remove_bitstream_ar_info" is not broken, it just doesn't work on h264-in-mkv source files, but on raw elementary streams - my bad.

[flapane]

Thanks for the correction, I have JUST finished using the custom ffbuild, an it worked great (sar=x:y).

[hello_hello]

Seems like a good place to ask....

What's the distinction between "display aspect ratio" and "original display aspect ratio".
For instance I was looking at a few DVD encodes after discovering using the Haali splitter causes some anamorphic encodes to display with the wrong aspect ratio (MPC's internal MKV filter woks fine) and I'm trying to understand why some of the values present aren't always the same.

If I encode a 16:9 DVD for example and end up with a 2.40 encode, what would normally be written as the DAR and Original DAR values? Would they both be 2.40 or would they be 16:9 and 2.40 respectively etc?

I've found a few DVD encodes with dimensions of 720x576 with a DAR of 5:4 (which would assume square pixels) and an Original DAR of 16:9, and they display properly using MPC-HC's internal MKV filter but not when using the Haali splitter (5:4)....

If I'm going to go through all these DVD encodes and remux the ones which don't always display correctly I'd like to make sure I understand the distinction between DAR and Original DAR and what the values should be.

[sneaker_ger]

The DAR is calculated by the Matroska track elements "DisplayWidth" and "DisplayHeight". The "Original DAR" is calculated from the SAR stored within the H.264 bitstream (This doesn't necessarily depend on whether the source, like a DVD, was anmorphic, but only on the SAR set during the encode, for example "--SAR 5:4" as an x264 parameter). Ideally both the container and video stream information match, so that the video is scaled correctly on all players, regardless of whether they use the h.264 or the Matroska info.

[hello_hello]

Could someone explain this one?
A DVD encode, dimensions 704x416. MPC-HC reports the file as having a 2.40 aspect ratio, Media Info says DAR 1.692, Original DAR 2.40, ffdshow thinks it's 1.692 and when I open it with MKVMerge GUI it thinks the display dimensions are 704x416 (1.69). It always displays correctly (even using Haali) at 2.40.

After I remux it while setting the aspect ratio to 2.40, everyone then seems to agree the aspect ratio is 2.40 and Media Info reports both DAR and Original DAR are 2.40.

Should DAR and Original DAR always be the same (assuming the aspect ratio hasn't been altered after encoding)?

[hello_hello]

The DAR is calculated by the Matroska track elements "DisplayWidth" and "DisplayHeight". The "Original DAR" is calculated from the SAR stored within the H.264 bitstream (This doesn't necessarily depend on whether the source, like a DVD, was anmorphic, but only on the SAR set during the encode, for example "--SAR 5:4" as an x264 parameter). Ideally both the container and video stream information match, so that the video is scaled correctly on all players, regardless of whether they use the h.264 or the Matroska info.

Cheers.
So I guess I'll be going through my DVD encodes to make sure they match. If the DAR has been set at 5:4 for a 720x576 DVD encode, and I used MeGUI for the encode, would it be safe to assume some version of MeGUI was at some stage writing incorrect DAR values when muxing?

Actually thinking about it, I remuxed some of those encodes with the custom version of ffmpeg to fix the colorimetry info... maybe that's where things went wrong. I'm pretty sure I didn't touch the aspect ratio information in the process, maybe i should have.
I'll have to try to dig out some old discs and the original, pre- remuxed versions to see if I can work out where things went wrong. If I've got to re-mux them all again, I just might have a cry....

[hello_hello]

Ahhhh.... I worked out how to fix the problem with the minimum of fuss..... no remuxing required. Probably wouldn't work for the OP as in my case it's the DAR value which is the wrong one, so I've got the opposite problem).

Using MKVMergeGUI's header editor, if I open an MKV, navigate to the "Video Display Width" and "Video display height" elements, change them to the aspect ratio ffdshow displays when playing the video while using it's internal MKV splitter (currently they seem to be set to pixel resolution), then select save, the problem is fixed. The "Original Display Aspect Ratio" field is no longer present (according to Media Info) and the DAR field is now correct (it contains the value which the original DAR field had before it was removed, which is the correct DAR). They even display correctly when using Haali.

Not a fast process, but at least it saves remuxing.

[sneaker_ger]

While this works in practice, I urge people to not simply remove these fields. The Matroska specs will in this case mandate that DisplayWidth=PixelWidth and DisplayHeight=PixelHeight (If DisplayUnit=0, which is its default value), which is equal to SAR=1:1. A spec compliant player would then scale incorrectly. I would rather encourage you to calculate the correct values for DisplayWidth and DisplayHeight.
In your case it should be DisplayWidth= 704 pixels * 2.4 = 998 pixels, and DisplayHeight = 416 pixels

[hello_hello]

Sorry sneaker_ger,
I edited my last post to correct what I was doing once I realised deleting the fields entirely didn't always fix the problem. Obviously too late for you to catch it before you posted.

I found a few of the original encodes (before they were remuxed) and looked at the DisplayWidth & DisplayHeight fields. I assumed they would be literal fields containing the desired display dimensions, but it seems they can also take a display aspect ratio. For instance one 688x416 anamorphic encode had the values for those fields as 167 and 71 respectively. Sometimes the values were literal, but mostly they were aspect ratio values.

So that's generally the way I went about fixing them. Opening each video with MPC-HC (internal splitter) while using ffdshow to decode, I could use ffdshow's on screen display to show the correct aspect ratio. In the example above, ffdshow still displayed the DAR as 167/71 even though the incorrectly remuxed file's DAR was 1.692 according to MediaInfo (I refrained from trying to think about that too much) so I used ffdshow's OSD aspect ratio for the DisplayWidth & DisplayHeight fields. Once I resaved the headers, in most cases the Original Aspect Ratio value was no longer displayed by MediaInfo, just leaving me with the correct DAR. If the Original DAR field was still present, it at least then agreed with the DAR field and both were correct.

The above seems to have solved my problem, especially with one of my standalone players. Cheers.