MKV files displaying strange aspect ratios

[spicediver10191]

Hi All,

I have a long running problem with MKV playback of correct aspect ratios and I'm hoping you can help.

I primarily play my files on a PVR (Beyonwiz P1) but I've also seen the problem with some PC media players (Media Player Classic) and when converting the same MKV file to DVD with programs like DVD Flick.

THE PROBLEM:

Many of the MKV files I play display a peculiar distortion of aspect ratio, ie. 16:9 images squashed to about 14:9, or 4:3 images squashed to about 3:3.

Adjusting the AR settings on my PVR and my Panasonic 42-PX70 television never restores the correct A/R, it just creates other horizontally or vertically distorted displays of the image. The same file looks fine on a PC media player like VLC, for example, but not Media Player Classic. The video looks fine when converted to DVD with the program ConvertXtoDVD (version 3.2.0.52 or later) but not, for example, DVD Flick which preserves the problem.

This is how a 16:9 video looks:

This is how a 16:9 video SHOULD look:

This is how a 4:3 video looks:

This is how a 4:3 video SHOULD look:


ATTEMPTED FIXES:

What I'm after is a solution so I can play these MKV files properly on my PVR. I don't have a PC in my home theatre setup - I only mention PC media players for comparison.

1) Converting to .TS format with tsMuxerGUI. This fixes the video problem but is only half a solution for me because many of my sources are foriegn language and I need to view subtitles. TS files associated with an identically named subtitle file will display those subtitles but they are waaaay out of sync by 5 to 10 minutes.

2) Remuxing with MKVmergeGUI. You think this would work but...it never does for me. In fact no matter what changes I make to the h264 video stream's aspect ratio and pixel settings in MKVmerge, the newly created MKV file displays no changes to its video whatsoever.

THOUGHTS:

Given that moving the video to a .TS container fixes the problem, I'm guessing the issue has something to do with how the particular h264 video and the MKV container are communicating. Is there some user-defined variation in the h264 encoding process that can cause this prob on some displays in an MKV container?

Whatever the cause, in the past I have seen this same problem with a few DivX files too.

Any advice appreciated. I can post example file info data if that helps.

Thanks!

[jagabo]

I can post example file info data if that helps.

That's probably your best bet. But I suspect you are right, the player simply doesn't fully parse the MKV container and is assuming square pixels. This is very common.

[poisondeathray]

The aspect ratio information in .mkv's can either be at the stream level (using --sar , which is essentially the pixel aspect ratio or PAR), or at the container level (either .mkv or .mp4). Usually the container flags will override the stream level - in fact this is almost always the case, unless you have other filters activated.

The fact that VLC plays it correctly but not in MPC suggests you either have some internal or external filters either through MPC, or through directshow filters that are interfering with the aspect ratio information. For example, if you use color converter filter, this will happen. You should check your settings in MPC, and use graphstudio to see if you have any other filters in use.

You should always be able to "fix" the display aspect ratio with mkvmerge - at least in PC scenarios. Either you are doing it incorrectly, or it's the case of filters/conflicts issue.

I think jagabo is right, the other (non-PC) players probably don't parse the .mkv container correctly. If this is the case, you should use the stream level signalling instead when making your .mkv's for anamorphic encodes. (i.e. --sar x:y, but you must calcuate this depending on the frame aspect ratio (FAR). DAR = FAR x PAR). Of course, the easiest way is just to use square pixels and resize instead of anamorphic encodes, but the DAR may be off a tiny bit, taking mod16 resolutions into consideration

[spicediver10191]

I think jagabo is right, the other (non-PC) players probably don't parse the .mkv container correctly. If this is the case, you should use the stream level signalling instead when making your .mkv's for anamorphic encodes. (i.e. --sar x:y, but you must calcuate this depending on the frame aspect ratio (FAR). DAR = FAR x PAR). Of course, the easiest way is just to use square pixels and resize instead of anamorphic encodes, but the DAR may be off a tiny bit, taking mod16 resolutions into consideration

Thanks guys - I'm pretty technically challenged however, so please be patient. My head for maths is shocking.

My aim is to get these files looking right on my PVR.

I am unable to re-encode the sources from scratch, but can I make these SAR/DAR adjustments you mentioned with MKVmergeGUI? I noticed you said "--sar x:y" which looks like a MKVmerge command.

Anyway, here's file info from an offending MKV file, which may help you:

General

Complete name xxxxx
Format : Matroska
File size : 197 MiB
Duration : 23mn 55s
Overall bit rate : 1 154 Kbps
Encoded date : UTC 2006-02-20 03:58:16
Writing application : mkvmerge v1.6.5
Writing library : libebml v0.7.6 + libmatroska v0.8.0

Video

Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 8 frames
Muxing mode : Container profile=Unknown@5.1
Codec ID : V_MPEG4/ISO/AVC
Duration : 23mn 53s
Nominal bit rate : 900 Kbps
Width : 704 pixels
Height : 480 pixels
Display aspect ratio : 16/9
Frame rate : 23.976 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.111
Writing library : x264 core 44 svn-408
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=6 / brdo=1 / mixed_ref=0 / me_range=30 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / chroma_qp_offset=0 / slices=1 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=2 / wpredb=1 / bime=1 / keyint=200 / keyint_min=25 / scenecut=40 / pass=2 / bitrate=900 / ratetol=1.0 / rceq='blurCplx^(1-qComp)' / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30

-end-

[jagabo]

The point is that your player may not be paying any attention the aspect ratio flags in the MKV header. It may not even pay attention to the aspect ratio flags within the h.264 video stream. With TS files it may be getting the aspect ratio flags from the TS headers, not the h.264 stream. You may simply be out of luck with MKV.

[spicediver10191]

The point is that your player may not be paying any attention the aspect ratio flags in the MKV header. It may not even pay attention to the aspect ratio flags within the h.264 video stream. With TS files it may be getting the aspect ratio flags from the TS headers, not the h.264 stream. You may simply be out of luck with MKV.

Damn and double damn.

Looking at alternatives then....

Can you suggest how I might get external subtitles (.srt .sub) in proper sync with .a TS file? Because converting the MKV contents to TS files does solve my video problem, but I then have a subtitle sync problem where the subs are out by a long distance (5 to 10 minutes).

Thanks.

[jagabo]

You could try using a subtitle editor to adjust the timing of the subs. If they are off by a constant amount you can simply move them all forward or backward by that amount. If the timing drifts it will be a lot more work.

[spicediver10191]

You could try using a subtitle editor to adjust the timing of the subs. If they are off by a constant amount you can simply move them all forward or backward by that amount. If the timing drifts it will be a lot more work.

Thanks for the reply.

The timecodes in all the .srt and .sub files I have are actually fine.

Perhaps there's a subtitle file format that is better compatible with .TS containers...?