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

Steve Lhomme slhomme at matroska.org
Mon Feb 14 20:11:29 CET 2011


On Mon, Feb 14, 2011 at 7:00 PM, Moritz Bunkus <moritz at bunkus.org> wrote:
> On Mon, 14 Feb 2011 17:03:41 +0100, Steve Lhomme wrote:
>
>> So are we back to using double Seek Heads ? I thought this was
>> deprecated. It adds extra complexity for a fundamental part that is
>> supposed to make the file handling easier.
>
> It's almost trivial to support linked seekheads -- simply make seekhead
> parsing recursive.
>
> Also it's not the standard behaviour of mkvmerge. But mmg's chapter
> editor/track header editor and mkvpropedit will fall back to creating such
> structures if there's not enough room before the first cluster for storing
> the whole seekhead. There are only three options in such cases:
>
> 1. refuse to modify the file,
> 2. remux the whole file into a temporary one & overwrite the original one
> afterwards and
> 3. create two linked seekheads, a small one before the first cluster and a
> larger one at the back of the file.
>
> Like I said, this is the exception, not the rule.

Yes, but whether it happens 50% of the time or 0.1%, players have to
support it. And add extra code and extra test cases.

Also I think both in terms of Matroska and WebM here. At least WebM is
new and has new code in browsers (well, only in FireFox for sure). So
far they took a strict policy on anything eccentric that is forbidden.
I think the double and then triple, quadruple, etc) Seek head falls in
that category. Plus, it is very bad for progressive download, which is
how WebM works now. That's why for WebM it's strongly advised to put
the Cues at the front. Seeking is an 'expensive' operation in HTTP.

In the end I think it's better to take a level 1 element from the
front to put it on the back to get room to update the SeekHead at the
front (not the Segment Info or Track Info of course). The only case
it's not possible is when adding a Level 1 element not found at the
front and there was no room for a link to it near the Seek Head.
That's why it should be highly recommended to add enough room after
the Seek Head for a few level 1 elements. So that at least it can
contain all known Level 1 elements and a few more for future
compatibility.

>> It is valid indeed but kinda defeat the point of the Seek Head if you
>> find Level 1 elements before.
>
> The simplest algorithm that works both with seekable and with non-seekable
> files is:
>
> while (!cluster_found) {
>  read_next_level1_element
>  if (is_cluster)
>    break;
>  else if (is_seekhead && stream_is_seekable)
>    parse_seekhead_and_read_other_level1_elements;
>  else if (is_track_headers)
>    parse_track_headers;
>  else if (is_segmentinfo)
>  ...
> }
>
> if (!segmentinfo_found || !track_headers_found)
>  error;

Yes, it's very important to use the Seek Head as soon as it's found.
Even for non seekable stream. In the case of HTTP I assume a new
connection/thread has to be created to load an element not found close
enough and then synchronisation between the main reader and that
thread, if it can be avoided in the main use case, it's better.

-- 
Steve Lhomme
Matroska association Chairman



More information about the Matroska-devel mailing list