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

Santiago Jimeno sjimeno at ya.com
Mon Feb 7 13:56:09 CET 2011

As for SeekHead: The maximum size of one entry is 17 bytes without CRC or 21 
bytes with CRC.
The possible entries are:
-First Cluster

I think it would be good to put First Cluster location here. This would 
provide us a complete file map and their positions and we could go to them 
without parsing whole file. We could also calculate easily the size of each 
master element.
It's not necessary to specify all cluster blocks location here. Cueing is 
for this.
Then the minimum size would be 21 x 7 = 147. But I would put padding with 
bigger size for the future (among 200-300 bytes).

As for Tags-Pictures there are three ways of placing them:  at the beginning 
of the file (ID3.2), at the end (APE, WAV) or at the middle (iTunes, Vorbis, 
WMA, Matroska).

Anyway to avoid problems (with or without padding) the best thing would be 
to make them independent of Media Data. Some Tags systems solve it dividing 
the file in two parts. Header, metadata and other information blocks in one 
file part and Media Data in the other file part.
In the case of Matroska when being at the middle, inside Segment and before 
Cluster, does these last ones being too sensitive to the variations or 
modifications before. The solution of declaring Void the modified blocks 
originates empty spaces with little utility and increases the file size. 
Moving them at the end becomes contradictory the Order Guidelines for fixing 
a definitive position that an Editor can find easily. The padding addiction 
in Tags is a possible solution (if this may be guaranteed in the future), 
but then the biggest problem for its great size is caused by Attachments 

If a program write matroska file for the first time all elements and their 
positions only depend on the author's will. But modifying or editing should 
foresee all possibilities and any other thing that multiple authors can 
imagine. This is the difficulty that I pointed out and not my limitations, 
although maybe I have them.

Then it's necessary to evaluate the three ways of Tags and Attachments 
placement and which would be more useful in function of the better container 
Placed at the beginning, it should be outside Segment, like Header's child. 
Our limit cannot be to have to rewrite the whole file. Mkvmerge specifies 
how many time takes to build file (Audio and Video) and in all cases it 
supposes more or less 1 second. This, with the modern computers, is 
perfectly acceptable even also for edition.
Placed at the end, I have already explained the possible advantages (even 
inside the segment) and writing is very easy.
Placed inside Segment and before Cluster, I have also explained the 
Placed after Cluster, it's the same that placed at the end.

Regards. Santiago

----- Original Message ----- 
From: "Steve Lhomme" <slhomme at matroska.org>
To: "Discussion about the current and future development of Matroska" 
<matroska-devel at lists.matroska.org>
Sent: Monday, February 07, 2011 8:51 AM
Subject: Re: [Matroska-devel] Hi, question about the MKV tags

> On Sat, Feb 5, 2011 at 7:39 PM, Santiago Jimeno <sjimeno at ya.com> wrote:
>>> Yes, I will change the specs to make sure it's clear that padding
>>> after SeekHead is recommended (even for things that don't even exist
>>> yet in Matroska).
>> Thank you. It would be fine to warn to authors personally.
>> I have only found problems in example files (cover_art.mkv), in those of
>> Haali (puts only 14 bytes), and mkvmerge only in 4.0.0 and 4.1.1 versions
>> (Test 1 samples)
> OK, I will first update mkclean to leave more space (right now there's
> only space for one element). And then I will make a test1 bis. I have
> a list of other features I have to put in a new test suite too.
>> Maybe it would also be necessary to specify advisable size. Mkvmerge uses
>> 4000 (maybe for including all cluster blocks).
> That's probably too much.
>> I have calculated that all master elements (included first cluster 
>> location,
>> I think it's the only one truly necessary here) will have a size 
>> something
>> smaller than 400 bytes.
> Yes. Right now mkclean leaves room for 1 link at the end. I should
> probably be safer with 3 or 4. I suppose tags at the front could do
> with a bit of padding too for easier editing without have to move it
> to the end or move all the data in the file.
> -- 
> Steve Lhomme
> Matroska association Chairman
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane: 
> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel

More information about the Matroska-devel mailing list