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

[Santiago Jimeno]

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

> Regards,
> Mosu

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 
size.
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 
http://samples.mplayerhq.hu/Matroska/anamorphic/starwars10MB-1.mkv 
(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 
dice"

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
Then?

Regards. Santiago