[Matroska-devel] Clarification on CueRelativePosition

Moritz Bunkus moritz at bunkus.org
Fri Jul 19 14:49:09 CEST 2013


On Fri, Jul 19, 2013 at 2:32 PM, wm4 <nfxjfg at googlemail.com> wrote:

> Now this must be duplicated in the seek code. This is not good. It
> leads to hard to maintain code.

Refactor into a common function. Hot hard to do at all.

> Even worse: it requires two seeks: first to the cluster header, then to
> the Block element.

That's always been the case with Matroska. The difference between
earlier is that now you actually have a chance to jump directly to the
second place instead of having to read the whole cluster up until the
point you're trying to seek to.

This is especially useful when you want to display subtitles that
overlap the desired seek point.

>>   * Read first child element (almost always the cluster timecode)
> Almost always? You said the spec requires it to be the timecode.

True, but there may be broken files out there. A player can chose to
accommodate such non-compliant files (it doesn't have to, of course).

> You also have to enter the BlockGroup parsing code somehow, which makes
> for more awkward code.

No, you don't.

Sorry, but you have some rather big misconceptions about how Matroska's
been working for over ten years now. This structure is not up to debate.

> Also, you forgot something. The parser code does not know how long this
> child element is.


The block group's total length is stored right after its ID before any
of its children starts, so I don't understand your point.

> For example, the BlockGroup can contain an arbitrary
> number of other elements after the Block,

Theoretically? Yes. Show me one file for this is true. The same can be
said for MP4 files, btw, they follow a very similar scheme of
tree-structured "tag/length/value" elements. So please stop talking
about theoretical impossibilities here. If there's a problematic file
then show it.

> So it's in general not clear at all when the parser should stop
> reading BlockGroup elements.


Seems like you're mixing up seeking & parsing code in your mind...

The seek code doesn't have to read the block group at all. It is
finished as soon as it has positioned on the start of the block group,
and the normal demux code can resume its work.

Yes, I've implemented a demuxer in the past (mplayer's first Matroska
demuxer back in 2002, long since relaced by other implementations).

> And you know what's the best about this? You don't have to change any
> software that demuxes Matroska.

You don't have to do that now either. Using those fields is completely
optional for a demuxer. Any demuxer can chose to ignore them -- or use

> Everyone can benefit from it. It keeps the code of Matroska readers
> simple, making software more robust.

Nowhere in the specs does it say that muxers HAVE to start a cluster on
a key frame. We cannot change those semantics ten years after they've
been put into place. So stop this line of thought, please.

> seeking. OK, but clusters would still be relatively small, and thus
> seeking fast.

Sure, clusters would be minimal: only one block group each. Anyway, a
completely theoretical assumption.

Please stop arguing about the format, it's leading you nowhere. It won't
be changed in the way you propose because that would not have been
backwards compatible at all: it would have declared the vast majority of
existing files to be invalid.

Also Matroska's goals are not simply allowing arbitrary amounts of
overhead to be inserted here and there. Yes, the additional overhead may
be small for this particular feature, but if we allowed that with each
and every new feature we'd get quite the growth in file size.

If you're that upset with Matroska (that's the feeling I get reading
your mail) then I suggest you chose another object of interest to work

Anyway, I'm really not interested in an extended discussion about
Matroska's seeking would have been better if X or Y or Z.

Kind regards,

More information about the Matroska-devel mailing list