Is MKV a Good File Type?

[TomBrooklyn]

Is mkv a good file type?

How does it compare to mp4 and Divx?

[foxyshadis]

Divx media is just AVI with lots of (semi-standardized) hacks to add lots of interesting features, like softsubs and multiple audio. It's basically dead.
MKV doesn't need those hacks, everything is built into the format and it can hold basically every codec, and it's the basis of webm.
MP4 can only hold the most common formats (MPEG video and audio, plus dolby, DTS, LPCM and one flavor of subtitles).

MKV and MP4 are both about 1-2% smaller than DMF/AVI and 5-10% smaller than TS.

If you only use codecs supported in MP4 than it hardly matters whether if you use it or MKV, except MP4 is standardized and has slightly better device support. If you need non-MP4 codecs then you need MKV. Both are still alive and being extended as needed, both support lots of metadata, cover art, stuff like that.

[Sharc]

MKV and MP4 are both about 1-2% smaller than DMF/AVI and 5-10% smaller than TS.

This alone gives higher video quality in filesize or bitrate constrained scenarios.
Perhaps a bit off topic: Does this mean .mkv is less tolerant against bit errors (poorer error protection)?

[Video Dude]

One flaw or disadvantage of MKV is that it always makes changes to the source video stream. A demuxed video stream from MKV is never the same as the encoded stream that was initially muxed. There is no easy way to undo the changes that are made.

However, if a video stream is muxed to ts, m2ts, or mpg most muxers will not touch the original stream. The demuxed stream will be the bit by bit exact as the original.

[LoRd_MuldeR]

Perhaps a bit off topic: Does this mean .mkv is less tolerant against bit errors (poorer error protection)?

None of these container formats (MKV, MP4, TS) provides any kind of "error protection" in terms of Forward Error Correction (http://en.wikipedia.org/wiki/Forward_error_correction) on the container level! However, the TS format, which is made specifically for streaming, has no global header. Instead, it wraps all data into separate packets and each packet starts with a "sync" byte. Also, the global data is repeated periodically. This makes it possible to re-synchronize on a corrupted or incomplete TS file. At the same time, the MP4 and MKV formats, which are mainly focused on local playback, store global data exactly once, in the global header. Also, all audio/video data is stored in one big continuous chunk. This makes those files more fragile against corruptions, in theory...

[sneaker_ger]

One flaw or disadvantage of MKV is that it always makes changes to the source video stream.
This is not true.

[Sharc]

None of these container formats (MKV, MP4, TS) provides any kind of "error protection" in terms of Forward Error Correction (http://en.wikipedia.org/wiki/Forward_error_correction) on the container level! However, the TS format, which is made specifically for streaming, has no global header. Instead, it wraps all data into separate packets and each packet starts with a "sync" byte. Also, the global data is repeated periodically. This makes it possible to re-synchronize on a corrupted or incomplete TS file. At the same time, the MP4 and MKV formats, which are mainly focused on local playback, store global data exactly once, in the global header. Also, all audio/video data is stored in one big continuous chunk. This makes those files more fragile against corruptions...
Thank you for the explanations. Very instructive.

[Video Dude]

One flaw or disadvantage of MKV is that it always makes changes to the source video stream.

This is not true.

I wish it was not true.

The issue was brought up in this thread:
http://forum.doom9.org/showthread.php?t=165188

And the quote that I refer to:

Multiplexing/demultiplexing a stream through MP4/MKV will delete vital data such as IDK, delimiters, HRD, SPS, etc, necessary for blu-ray compatibility, particularly any calculations/data pertinent at the container level.

I did test it myself with x264 encoded video.

Mux with MKVToolnix, then demux. Compare the original and the demuxed stream with a hex editor. They will not be the same.

Mux the original x264 stream to m2ts with tsmuxer, then demux. The original and demuxed stream will be bit by bit exact.

[SeeMoreDigital]

And the quote that I refer to:
Multiplexing/demultiplexing a stream through MP4/MKV will delete vital data such as IDK, delimiters, HRD, SPS, etc, necessary for blu-ray compatibility, particularly any calculations/data pertinent at the container level.
Out of interest, when was that quote written and by whom?

[sneaker_ger]

And the quote that I refer to:
The quote is not true for mkvmerge. If you mux H.264 with mkvmerge it does not alter the stream in any way. Exceptions are things like stream altering options (e.g. change bitstream fps) and the removal of filling bytes.

I did test it myself with x264 encoded video.

Mux with MKVToolnix, then demux. Compare the original and the demuxed stream with a hex editor. They will not be the same.
This is only because mkvextract writes the header data from the Matroska field into the stream without checking if it's already there. Since mkvmerge does not alter the stream (see above) this results in the headers being duplicated. No information is lost.

[Reel.Deel]

And the quote that I refer to:
Multiplexing/demultiplexing a stream through MP4/MKV will delete vital data such as IDK, delimiters, HRD, SPS, etc, necessary for blu-ray compatibility, particularly any calculations/data pertinent at the container level.
Out of interest, when was that quote written and by whom?

I've seen this some time ago, it was written by PuzZLeR on 12th Oct 2011. Look at post #8 (http://forum.videohelp.com/threads/339799-Encoding-SD-video-with-H-264-to-be-100-Blu-ray-compliant?p=2113128&viewfull=1#post2113128) under MP4/MKV.

[MasterNobody]

sneaker_ger
MKVToolnix during muxing/demuxing of raw H.264 Annex B stream make such modifications:
1) removes filler and AUD NALs
2) converts all short (3-byte) start-codes to long start-codes (4-byte)
3) doubles SPS/PPS during demuxing
Any of this changes is harmful for bluray compatibility (i.e. authoring) because it breaks NAL HRD conformance which counts every bit.

[sneaker_ger]

Is any Blu-Ray-encoder using 1) and 2)? In a test with x264 (Blu-Ray compatible settings), mkvmerge and eac3to the files come out bit-identical.

I don't question the part about filler bytes and headers (after all, I explicitly mentioned them in my earlier post) but are you sure about the AUD and start-code part?

[MasterNobody]

x264 use short start codes (0x000001) when output raw Annex B streams and AUDs when using --aud or --bluray-compat (which force enabling of --aud). And yes I am sure, because I tested this and compared streams in HEX editor and in stream analyzer.

[sneaker_ger]

Must be a problem of mkvextract, then.

[MasterNobody]

It is not problems of mkvextract. It is the way such format like MKV/MP4 works. All start codes are removed during muxing and replaced with NAL size instead so this short/long startcode distinction is lost permanently. AUDs are removed during muxing imho for the same reason as filler NALs. If you want better explaination than ask Mosu directly.

[sneaker_ger]

If I mux with mkvmerge and then demux with eac3to the files are bit-identical. This can either mean:
1. mkvmerge does not remove AUD
2. eac3to reconstructs AUD

If you want better explaination than ask Mosu directly.
I once did:
http://forum.doom9.org/showthread.php?p=1601751#post1601751

[MasterNobody]

2. eac3to reconstructs AUD
Probably this.

[foxyshadis]

Given that 1) and 2) are reconstructable artifacts of the stream, and 3) can be removed, who cares? That's like debating that a zipped file is no longer original. It can be recovered with eac3to, which is good enough if you know what you have to use to restore bluray compatibility, or you can petition or patch mkvmerge to fix that particular extractor, as well. Making changes that can be easily unmade doesn't seem useful for a comparison.

[MasterNobody]

Given that 1) and 2) are reconstructable artifacts of the stream
The point is that they are not exactly reconstructable. You can try to mimic x264's logic of using short/long startcodes but this would be guess not perfect reconstruction. Same for the filler.

P.S. I don't have anything against MKV. This is good format for local file playing. Simply don't use it if you want to author bluray with it latter (not a lot of people need this use case and they should know this limitation).

[Nico8583]

So do you think, if I want to add a new track (or modify a forced or default track flag) in a MKV, it's a better way to remux all streams to a new MKV or Add option from mmg.exe is equal ?

[detmek]

When you add stream using Add option you need to remux file to save that change.

[Nico8583]

Yes but is it better to remux with original streams or is it equal with already muxed streams ?

[foxyshadis]

There is no in-place add with mkv; all operations are a remux.

[Nico8583]

So if I use Add option from mmg.exe, there is a demux/remux operation in background ? And if there is a demux, some informations are lost or added twice ?
I have all original streams, I think I'll make new MKVs (with added tracks) instead of use Add option...