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

Steve Lhomme slhomme at matroska.org
Sat Feb 12 10:35:31 CET 2011

On Mon, Feb 7, 2011 at 1:56 PM, Santiago Jimeno <sjimeno at ya.com> wrote:
> As for SeekHead: The maximum size of one entry is 17 bytes without CRC or 21
> bytes with CRC.
> The possible entries are:
> -SegmentInfo
> -Track
> -Chapters
> -Attachments
> -Tags
> -Cueing
> -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.

That's a good idea

> 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).

Yes, you never know if someday there won't be more level 1 elements.

> 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

No, this is not good. Matroska tags not only describes the whole
content, but it can describe chapters, tracks and attachments. So it
has to be at the same level as those, ie inside the segment. A Segment
is an "integral" entity, it should not look outside for data about it.
Plus when segments are chained you would not know if the tag applies
to the one before or after. (chained segments are really a pain to
edit tags too)

I am planning to add a new Level 0 element to reference segments. But
I don't think tags fit in there.

> 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
> (Pictures).

The ordering guidelines does take in consideration the case of editing
tags in case it needs to be moved at the end.

Steve Lhomme
Matroska association Chairman

More information about the Matroska-devel mailing list