[Matroska-devel] Hi, question about the MKV tags

Moritz Bunkus moritz at bunkus.org
Sat Feb 12 10:56:41 CET 2011


 Hey,

 On Sat, 12 Feb 2011 10:22:22 +0100, Steve Lhomme wrote:

> mkclean puts the Void inside the SeekHead element. In the end the
> result is almost the same.

 Not really. The code in mmg/mkvpropedit that can place chapters, tags 
 or whatever level 1 element in existing files only looks for void 
 elements at the first level -- meaning if they're children of the 
 segment. It does not consider void elements inside level 1 elements e.g. 
 in seekheads. It will also not remove voids in a seekhead or reduce its 
 sizes.

 Putting the void into the seekhead certainly allows for storing more 
 seekentries in the seekhead with the proper code. However, it makes such 
 code a lot more complex than it already is. If you don't know how 
 complex all the situations can get then I suggest you take a look at 
 http://www.bunkus.org/cgi-bin/gitweb.cgi?p=mkvtoolnix.git;a=blob;f=src/common/kax_analyzer.cpp;h=e76bea635280f962e0651f25860562777827f2e4;hb=HEAD

 That file is actually documented properly and therefore worth a read if 
 one is implementing something similar, and if we're discussing where to 
 put void elements.

> The only difference is that then the
> SeekHead already has the right amount of bytes in the header for its
> total side. The downside is that adding new elements at the level 1
> would mean editing the SeekHead header to grab some octets from it so
> they can be used around it.

 That downside is what I'm talking about as well. Let's not make this 
 code more complicated that it already is. There's a reason why there are 
 few tools to handle the Matroska file structure that way instead of 
 relying on other tools to simply remux the whole file, and putting void 
 inside level 1 elements only adds to that complexity.

> This is the intention of Alexander Noe (author of AVI-Mux GUI) to put
> elements in random position when possible. So that readers don't
> assume fixed positions. This is to ensure better long term
> compatibility.

 I agree with Alex on this. Even though mkvmerge doesn't do it to the 
 extent that AVI-Mux GUI does mkvmerge often does things that annoy 
 existing readers while staying 100% spec compliant -- e.g. make header 
 removal the default or use SimpleBlocks by default. mkvmerge switching 
 to them caused almost the same outcry about "incompatible files" that 
 activating header removal compression did.

 Regards,
 mosu




More information about the Matroska-devel mailing list