[Ffmpeg-cvslog] Re: ffmpeg-cvslog Digest, Vol 20, Issue 21

[Rich Felker]

On Wed, Nov 08, 2006 at 10:51:17PM +0100, Steve Lhomme wrote:
> > From: Nico Sabbi <nicola_sabbi at fastwebnet.it>
> > indeed: in every single mmedia program I've seen so far
> > the demuxer for matroska is by far the largest and most
> > full of special cases to handle separately
> 
> Oh boy. Not again...
> 
> Let me see, Matroska handles more formats than any other format,

Blatently FALSE, it handles the fewest. Only the few that are
explicitly supported. Unless you count the nasty DShow-in-MKV
abomination. OTOH NUT supports every format _without_ special casing.
But even crappy containers support more than MKV.

> handles 
> attachment,

Bloat.

> chapters,

Not complex. This does not account for complex implementations since
implementations should just be able to ignore them if they don't
intend to use them.

> VFR,

Not complex at all. And MKV does it wrong anyway.

> compressed data,

Umm isn't all media compressed these days? Or do you mean stupid zlib
compression? The latter is pure bloat and does NOT result in space
savings compared to good design (NUT).

> subtitles,

Not complex.

> index-less 
> playback,

Even without support for indexless playback (which IIRC the MPlayer
implementation did not have at one point) MKV implementation is still
massively bloated.

> fast seeking,

Lie. Correct seeking in MKV is an unbounded operation (linear search
required) if you don't have an index and want to make sure you get the
correct subtitles, etc.

> gaps, tags, interactive playback (DVD menus), 
> seamless file linking and recently 3D/stereo files, all that with the 
> lowest overhead.

Lie, overhead is higher than NUT.

> So yes, it may take some code to achieve that.

Features in the file format do not fundamentally _require_ code unless
the code wants to make use of these features. What we talk about when
we flame MKV is the huge degree of complexity (and per-codec
special-casing!!) required to implement even the most trivial demuxer.

> It can take very little code to actually handle basic matroska files, 
> once you have the EBML layer working. (MOV and AVI hide this code in 
> riff.c in lavf).

The EBML layer itself is massive bloat, both in implementation and in
file storage.

Rich