[Matroska-devel] Clarification on CueRelativePosition

wm4 nfxjfg at googlemail.com
Fri Jul 19 15:39:53 CEST 2013


On Fri, 19 Jul 2013 14:49:09 +0200
Moritz Bunkus <moritz at bunkus.org> wrote:

> Hey,
> 
> 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.

How to do that if you have to deal with broken files where the first
element after cluster is not a timecode (see below)? I'm quite sure
implementing this correctly and robustly does lead to some code
duplication, or awkward code. Thus why I can't understand why not
simply cluster by keyframe.

> > 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.

I'm just saying that with high latency seeking (even if the medium is
fast) this will not lead to ideal performance. With keyframe
clustering, that wouldn't even be an issue.

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

Which btw. doesn't help that much. There will be LOTS of video and
audio packets between that subtitle packet, and where the actual video
keyframe packet is located. You have to parse them all.

> >>   * 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).

I'm pretty sure players want to make sure they can read all files.

> > 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.

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?

> > 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...

Well, the new change _does_ require mixing seeking and parsing. Seek to
cluster header, parse, seek to the block, parse somewhat differently
from normal. (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.)

> 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
> them.
> 
> > 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.

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. I'm not
proposing changes to the file format, just different, more optimal
muxing behavior. (Optimal from a seeking perspective, even if that
increases file overhead by an insignificant amount.)

> > 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.

????????????

Again, I'm not proposing a format change.

> 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.

Well, you've also added CueRelativePosition, which does increase
overhead. So you're not opposed to adding overhead fundamentally, but
you probably think this is less overhead than the changed muxing
behavior I proposed. (At the cost of adding code to every single
Matroska demuxer which is interested in good seek performance.)

> 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
> on.

I'm sorry if I sound upset.

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

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.


More information about the Matroska-devel mailing list