Still no perfect Matroska splitter

[Pulstar]

Neither LAV or MPC's internal splitters can properly handle DAR set in the Matroska container (via MKVtoolnix), only Haali abides by it. Haali is no longer being maintained, so is this issue going to be resolved eventually? LAV's bugtraker dismissed it altogether.

[the_weirdo]

Don't know about MPC-HC's internal splitters, but I think LAV Splitter sends the container AR properly to video decoder. How to handle that information is the duty of video decoder. I remuxed a 848x480 H.264 to MKV with MKVToolnix, set "Display width/height" to 1000x100, and tested with MPC-HC's internal decoders (both DXVA mode and software mode), LAV Video Decoder (with "Use Stream Aspect Ration" option set to Auto mode) and they all handle the container AR signal from LAV Splitter properly. Only ffdshow-tryout's video decoder ignores it. Still, I'm not sure about other video formats.

EDIT: My fault. I did the test again with two MKVs (H.264 and MPEG-4 ASP) in GraphStudioNext, splitter: LAV Splitter, renderer: EVR. With MKV/H.264, MPC-HC's internal decoders, LAV Video Decoder, DiAVC H.264 decoder (x64), ffdshow-tryout (using libavcodec), all of them display AR correctly. With MKV/MPEG-4 ASP, only ffdshow-tryout (libavcodec) fail, Xvid decoder also use wrong AR if option Aspect Ratio set to Auto (MPEG-4 first), if Auto (external first) is selected then it decode with right AR.

[nevcairiel]

Indeed, LAV sends the container AR to the decoder. Its then the decoders job to either use that, or use the video streams AR. If you use LAV Splitter + LAV Video Decoder (in their respective default config), it should use the Matroska container AR if you set it.

[hello_hello]

I just tried remuxing a couple of MKVs with a 4:3 aspect ratio as 16:9. I tried MPC-HC's internal splitter and the Haali Splitter, ffdshow and MPC-HC's internal decoder and couldn't get the remuxed MKVs to display as anything other than 16:9 (I didn't change ffdshow decoders).

Using MPC-HC's "View/Video Frame" menu, is "Keep Aspect Ratio" checked? Without it checked the video either uses the aspect ratio written to the video stream, or it assumes square pixels. I didn't get motivated enough to work out which.

[Keiyakusha]

Speaking of. I'm not sure I understand why matroska container AR is so important? If stream for some reason have wrong AR means its a broken stream. Just fix it, why complain about splitters and decoders?

[nevcairiel]

Many people don't think about it when encoding, so they don't specify the AR when encoding, and instead specify it when muxing.
It seems like a valid way to do things, even though compat with software and hardware players will suffer.

[Pulstar]

Yes I admit I'm guilty of that.. Mostly it's Youtube vids that I remux into MKV's to correct their AR's without having to re-encode them.

[SamKook]

You say there's no perfect matroska splitter, but what's wrong with haali? The fact that it's not maintained anymore isn't a problem right now as long as it still works as intended.

[Pat357]

You say there's no perfect matroska splitter, but what's wrong with haali? The fact that it's not maintained anymore isn't a problem right now as long as it still works as intended.

As a matter fact Haali splitter is still maintained, just maybe not by original author.
Corecodec (from Coreavc) promised that they will release an updated version together with the next Coreavc update.
(however, whenever that will be is unknown to man-kind)

[the_weirdo]

You say there's no perfect matroska splitter, but what's wrong with haali? The fact that it's not maintained anymore isn't a problem right now as long as it still works as intended.

IMHO, in this world nothing is perfect.

I'd have switched to LAV Splitter for MKV ages ago if it had supported some Matroska features that I need, such as editions, ordered chapters, segment linking. Haali's MKV Splitter still works fine but it contains some annoying bugs, for example it causes player crash when random seek or change audio tracks with some files, doesn't recognize "application/vnd.ms-opentype" and "application/x-font-ttf" embedded fonts...

CoreCodec promised (http://forum.doom9.org/showthread.php?p=1553520#post1553520) that they will fix those bugs for the next CoreAVC 3.1 release, but after more than 8 months, we still don't know when it'll be released. Maybe we'll have to wait for... ever!