www.makemkv.com

Hi,

I use MakeMKV to rip Blurays, keeping the video, English audio, and English subtitles. Since MakeMKV marks the subtitles as a default track, I remux the MKV it produces with mkvmerge to turn the default flag off. When I play the MKV that mkvmerge spits out in VLC, I get very bad tearing and blockiness when I skip around in the file. The original MKV that MakeMKV produced plays normally when skipping around.

I emailed this information off to the mkvtoolnix author, expecting that it was a bug in mkvmerge. He checked into it and reported back that MakeMKV writes wrong frame type markers, i.e. it marks all frames in VC1 and H264 video streams as key frames, even if they aren't (my experimenting shows that MPEG2 video streams seem to have no such trouble, even after remuxing with mkvmerge).

When mkvmerge is used to remux from another MKV, it relies on the original container to provide the frame types. However, when mkvmerge is used to mux elementary streams, it analyzes the bitstream for frame types and rederives them and timecodes. So, a workaround is to use MKVExtractGUI2 to extract the video elementary stream first, then remux it along with the audio and subtitle tracks from the MKV that MakeMKV made, into a second MKV file. The resulting MKV has no problems.

I did find the following thread on the same subject, but a conclusion was never posted.

http://www.makemkv.com/forum2/viewtopic ... rame#p3192

Is this a MakeMKV bug? If not, why does MakeMKV behave this way?

Thank you.

BrownRat wrote:Since MakeMKV marks the subtitles as a default track, I remux the MKV it produces with mkvmerge to turn the default flag off.

There's no need to do that. Just open the mkv with MKVMerge GUI's header editor (File>Header Editor), and change the flag. It will take about 1 second to rewrite the header info.

Ah, thanks for this tip. I'll do that.

But it still seems like there's a problem here. I have to go through the pain of extracting the video track and then remuxing for all these MKVs I already ran through mkvmerge once, so it seems like it would be worth getting to the bottom of what the real problem is.

You could use TSMuxer to put the mkv back into a Bluray structure (if you have PGS subs, you'll need to extract those, which should be quicker than extracting the video), then run MakeMKV to re-create the mkv. Not perfect, but it may be a temporary workaround.

Already have a workaround: See paragraph three of the original post. It works for the MKVs I already ran through mkvmerge, too.

BrownRat wrote: I did find the following thread on the same subject, but a conclusion was never posted.
http://www.makemkv.com/forum2/viewtopic ... rame#p3192
Is this a MakeMKV bug? If not, why does MakeMKV behave this way?

It's an ugliness of MKV format. Unfortunately frame types are not stored in MKV file - MKVmerge stores so-called frame references and assumes that every frame without references is a key frame. The information "frame references" is extremely hard to calculate properly ( as a matter of fact it's calculated incorrectly by MKVmerge ) and is ignored by every player in the world. Only few software use this information to distinguish whether a frame is a keyframe or not.
MakeMKV doesn't put these fields and MKVmerge assumes that every frame is a keyframe.

For perian problem mentioned in other thread - I've emailed the author a code how to properly determine keyframe information for mpeg/h264/vc-1 video and he implemented it in his tool.

The proper way would be either to fix MKVmerge to read keyframe information from a bitstream; or to change MKV spec to mark a keyframe in a less ugly way ( not as a frame without "junk" references, but with a dedicated flag). Given the "open" nature of MKV format neither is likely to happen.

Mike,

... or to change MKV spec to mark a keyframe in a less ugly way ( not as a frame without "junk" references, but with a dedicated flag).

I pointed the mkvtoolnix author to your answer. His response was:

The SimpleBlock has such frame flags (not reference times) that indicate key/non-key frames. Even with reference frames: That's exactly what they were intended for... I should know, I'm one of the founders of Matroska.

http://www.matroska.org/technical/specs ... _structure

Key frame information belongs at the container level. The container level provides this information. It doesn't make sense to force a player to look into the bitstream in order to find places where it can seek to. Players usually do not KNOW the bitstream in question! They hand it over to the codec. Yet the player is the one doing the seeking. Therefore the player must be able to get key frame info from the container.

Also it's not only mkvmerge that has problem with such files, it's pretty much each and every player.

The SimpleBlock has such frame flags (not reference times) that indicate key/non-key frames.

Then it's a bug in MakeMKV that will be fixed.