Subject: [Cellar] Does the SeekHead specification contradict itself?

From: "Sebastian G. <bastik>" <[email-masked]>
Date: Sat, 15 Oct 2016 20:06:08 +0200

I wonder about the SeekHead specification. [0]

"If a second SeekHead Element is used then the first SeekHead MUST
reference the identity and position of the second SeekHead, the second
SeekHead MUST only reference Cluster Elements and not any other
Top-Level Element, [...]"

"Whether one or two SeekHead Elements is used, the SeekHead Element(s)
MUST reference the identify and position of all Top-Level Elements
except for the first SeekHead."

I find that both contradict each other. While in the first quote is
stated that the second SeekHead MUST only reference clusters and NOT any
other Top-Level Element, the second quote says that the SeekHead
Elements MUST reference ALL Top-Level Elements.

To me that would translate to 'every SeekHead contains ALL Top-Level
Elements, beside the first SeekHead.'

Since I am confused, I assume that this could be misinterpreted and
therefore lead to faulty implementations.

(This message was only send, because David sent his message with a
question about the SeekHead, I can't answer.)

Best Regards,
Sebastian

[0]
https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/order_guidelines.md#seekhead

---

From: Dave Rice <[email-masked]>
Date: Sat, 15 Oct 2016 17:05:04 -0400

> On Oct 15, 2016, at 2:06 PM, Sebastian G. <bastik> wrote:
> 
> Elements, beside the first SeekHead.’

I think the intention was that the SeekHead Elements collectively (and not individually if more than one SeekHead is used) reference all non-first-SeekHead Top Level Elements. Does that properly resolve the contradiction? Suggested wording?

> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

---

From: "Sebastian G. <bastik>" <[email-masked]>
Date: Sun, 16 Oct 2016 10:14:14 +0200

> I think the intention was that the SeekHead Elements collectively (and not individually if more than one SeekHead is used) reference all non-first-SeekHead Top Level Elements. Does that properly re…

Well I assumed that I guessed the intention correctly, but found that I
could interpret in the way I did in my previous email.

My understanding was that it was supposed to work like follows.

There is the (initial) SeekHead Element indexing what's present in the
file so far, then changes are made to the file, e.g. chapters are added,
and any possible Void Element is too small to take the changes without
the file having to be re-written, so the initial SeekHead is updated to
point to another SeekHead written at some place where enough space is
available (in form of a Void Element) or at the end of the file. The
second SeekHead indexes what's not already indexed by the first
SeekHead, e.g. the newly added chapters.

If that is how it is actually supposed to work, then I we could try to
change the wording. The word 'collectively' seems like a good idea.

>> question about the SeekHead, I can't answer.)

(It's Dave... sorry for that.)

And we can wait until, your question about more than two SeekHeads is
resolved.

---

From: Moritz Bunkus <[email-masked]>
Date: Sun, 16 Oct 2016 10:21:14 +0200

Hey,

> SeekHead, e.g. the newly added chapters.

That is how it's supposed to work, yes.

It's not just about the case of editing a file later on, but in general
when the muxer cannot know in advance how much space it'll need and
doesn't want to rewrite the whole file.

mkvmerge can be configured to include all Cluster Elements in the
SeekHead. That requires a lot of space. What mkvmerge does is to create
the standard SeekHead near the start of the Segment containing
references to the SegmentInfo, Tracks, Chapters/Attachments/Tags (if
applicable), but not to the Clusters.

After having written all Clusters it will write a secondary SeekHead near
the end of the Segment referencing only the Clusters. Additionally it
will include a reference to the second SeekHead in the first SeekHead.

The SeekEntry Elements from both SeekHeads must be used cumutatively.

Kind regards,
mosu