[Matroska-devel] Clarification on CueRelativePosition

Moritz Bunkus moritz at bunkus.org
Fri Jul 19 15:51:17 CEST 2013


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

> In my experiments, I determined that the final seek position will point
> to either a SimpleBlock, or a Block. And never BlockGroup. As
> written by mkvmerge v6.2.0. Maybe I am wrong?

That's definitely wrong. It always points to either the SimpleBlock or
the BlockGroup object containing the frame/field the cue point refers
to. Read my answer and how to calculate the position in my initial reply
to Bernie's mail.

> (Unless I'm wrong and you seek to a BlockGroup not a Block. Seeking to
> a BlockGroup would lead to more reasonable code, I agree.)

Yes, you're wrong. You seek to the BlockGroup because that's what
CueRelativePosition points to.

> You don't have to change them. That is optional behavior, and
> completely transparent to the current file structure. You _can_ do it
> in order to get better seeking, but you don't _have_ to.

One muxer doing it the optimal way (from the doesn't change the job a programmer
working on a demuxer has to do one bit. He still has to accommodate for
the muxers that are not doing it that way if he wants to do the best job
a demuxer can do.

Again, "optimal" muxing from the seeking POV means a tradeoff in more
overhead. Not everyone wants that.

Matroska is definitely not the best format for low-latency seeking and
playback. But then again so aren't others (e.g. Ogg).

> I find that accusation funny, because _you_ were the one who suggested
> and implemented completely new elements to improve seeking, a much
> more intrusive change than the different muxing behavior I suggested.

Because I don't control all the muxers in this world. Only one, in

Anyway, that discussion's already done, like I said. It's in the past,
no need to discuss the pros/cons any further.

Kind regards,

More information about the Matroska-devel mailing list