View Single Post
Old 15th March 2010, 18:51   #1479  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
Summarizing Foofaraw's question:

Quote:
Originally Posted by Foofaraw
A.mkv -> (mkvmerge) -> B.mkv is different from A.mkv -> (mkvcleaver) -> elemental_streams.h264/.ac3/.mp3 -> (mkvmerge) -> B.mkv
mkvmerge has different paths for the same content depending on where they come from. You guessed as much from the evidence. There are several reasons for this, amongst them are:

1. It tries to re-use as much information as possible as can be retrieved from the source container. If you have a h.264 track inside a Matroska file then you have a lot more meta-information about it that you do when it is stored outside of a container as an elementary stream. Information that is reused includes but is not limited to the timestamps, track parameters like display width/height, track name, language etc etc.

2. What is not so obvious is that mkvmerge also reuses the framing. If you have a raw track type like MP3, AC3, AAC or h.264 elementary streams then mkvmerge has to determine how many bytes of the track to put into each Matroska block (also called 'frame' sometimes even though a Matroska block does not necessarily contain exactly one 'frame' in the way people think of frames). This process is usually called framing and has to be done by any raw -> container converter. If a track is stored inside a Matroska file then mkvmerge sometimes skips this process and takes the input file's framing -- one Matroska block in, one Matroska block out.

3. Another important thing to remember is that raw tracks outside of a Matroska file are not simply the concatenation of all the contents of all Matroska blocks. This is the case for some very simple track types (e.g. MP3, AC3, AAC, DTS) but for most others it isn't, especially for video track types like h.264. Elementary streams often contain special framing markers (think of '00 00 01' prefixes for MPEG-1/2 or '00 00 00 01' for h.264). Also some parts of the stream are not put into Matroska blocks but into the CodecPrivate element (e.g. SPS/PPS NALUs in h.264 tracks). The CodecPrivate almost always has some special kind of storage format that is always different than how that information is stored in an elementary stream. mkvextract and mkvmerge convert this data from one form into the other and back again. In the case of direct mkv -> mkv conversion the CodecPrivate element is kept as-is.

4. There are muxers out there that create invalid Matroska files. For example there are files with the CodecID V_MPEG4/ISO/AVC (h.264 video) that contain the elementary stream 1:1 including the '00 00 00 01' prefixes in each Matroska block. They also don't have a CodecPrivate element but store the SPS/PPS NALUs inside the first Matroska block. This not only violates the specs it is also incompatible with most playback software out there. So mkvmerge has yet another processing path for such tracks.

There are more cases, but I guess you get the drift. It is not possible to switch this behavior in mkvmerge -- it is hard coded for each and every combination of track type and source file format (and even for the same tuple "container & track format" there may be different paths as 4. illustrates).
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline