[Matroska-devel] Hi, question about the MKV tags
sjimeno at ya.com
Mon Feb 14 14:09:06 CET 2011
> > Then I should also understand that the padding that continues to an
> > element
> > (as segment child) should be for later use of that element and to
> > respect
> > it.
> Hmm not really. A void element doesn't have any such semantics -- it's
> simply a placeholder where other elements can be written.
> > Is it this way the thing?. Will it be respected?
> Certainly not.
> > Because it can happen that if somebody needs to write Tags and he finds
> > a
> > big padding in Segment, for example after SeekInfo or after Tracks, he
> > writes the Tags there and annul somehow the possibility to modify the
> > element that preceded it .
> That's what mmg/mkvpropedit do already with chapters and soon with tags.
Then the possible advantage of adding padding after an element is annulled
or very reduced. Mainly for SeekHead but also for any other element.
Then could we understand that if the padding is included inside Level 1
Elements it will be respected?
I think that it would be. Since it would not be looked for to write other
elements and it is not necessary to write code to look for it.
If it is modified (rewrited) is only necessary to guide us by the element
In other words, you don't need code to look for it. You should only keep it
in mind if you rewrote the element.
This is a limitation for the admirers of the random flexibility but without
necessity of putting an authoritarian sentence in Order Guidelines.
Mosu, I understand your problems and complaints about this and the painful
thing that it is write again a code that works perfectly.
This has already happened me with the example file of AVI-Mux GUI ......that
also writes padding inside SeekHead !!.
Another "aleatory" case: the file
(VirtualDubMod) writes InfoSegment before SeekHead.
But I think what makes more complex the code is not the changes (if they are
meditated and studied) but the excessive flexibility (understanding this as
random thing according to each programmer's personal approach). Playing with
the aleatory thing is not scientific. Einstein said "God doesn't play to the
I have calculated that there are 10 possibilities of combinations for Tags
and Attachmets when are edited together (without remux).
Once this is established, it is necessary to write code for several
different placement possibilities for each one of them: before cluster,
after cluster or on free padding.
Would it be less complex to do this? - Indeed yes
More information about the Matroska-devel