[Matroska-devel] Clarification on CueRelativePosition
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.
More information about the Matroska-devel