[Matroska-devel] Hi, question about the MKV tags
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:
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
It's not necessary to specify all cluster blocks location here. Cueing is
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,
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.
----- 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
>> I think it's the only one truly necessary here) will have a size
>> 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
> Read Matroska-Devel on GMane:
More information about the Matroska-devel