[Matroska-devel] Hi, question about the MKV tags
moritz at bunkus.org
Mon Feb 14 14:24:59 CET 2011
On Monday 14 February 2011 14:09:06 Santiago Jimeno wrote:
> Then could we understand that if the padding is included inside Level
> 1 Elements it will be respected?
Not really, why should it be? Let's assume you have this layout:
Meaning the seekhead contains the void as a child. Now my application
wants to change chapters, but there's no space behind the chapters. My
application could simply remove the void from the seekhead freeing up
space before the chapters and move the chapters to the front. That's
> I think that it would be.
No. You would only rely on application developers to be lazy and to
implement void detection only on the same level.
Also I don't think there's actually a real need for padding for each and
every level 1 element. There's only one case that should always be
checked: that there's enough space in front of the first cluster for at
least a seekhead with a single entry. That seekhead can point to a
secondary seekhead (e.g. near the end of the file) that contains
pointers to all the other level 1 elements.
How much space would you pad with anyway? For chapters this is easy. Or
is it? I've seen people use chapters that occupy more than 2 KB. And
tags? Hell, they can be even longer, e.g. if you include movie
descriptions and reviews. There's simply no useful way to estimate the
amount of space needed after attachments -- because you have no clue
what any other user might want to attach later.
Leaving voids everywhere is not a proper solution.
We're coming from the tags perspective here: they should be placed at a
certain location (other elements as well). But there are practical
limitations where you can put those elements if you're not rewriting the
whole file. That's true for each and every file format. You can only
gain more flexibility in this situation by trading it for efficiency
(namely wasting a lot of space with void elements).
Therefore: don't. Use voids where they're useful, e.g. by allowing for
space for the seekhead to expand a little. Or for track header editing
applications like mmg's header editor.
> Mosu, I understand your problems and complaints about this and the
> painful thing that it is write again a code that works perfectly.
No, I don't object to the amount of work involved, I object to the
principal of leaving void elements everywhere. It doesn't gain you
anything in the general case.
> Another "aleatory" case: the file
> (VirtualDubMod) writes InfoSegment before SeekHead.
Perfectly valid. The seekhead should only be located before the first
cluster -- if a seekhead is present at all. You don't even need one in
life streaming cases as long as all other relevant level 1 elements (at
least segment info and track headers) occur before the first cluster.
Any application handling attachments and tags has to be flexible enough
to locate them wherever they are as long as they either occur before
the first cluster or they're indexed via seekheads. Therefore the
placement strategy for non-remuxes can only be a guideline -- "place
them at ... if possible, otherwise put them wherever is convenient".
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the Matroska-devel