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

[Steve Lhomme]

> From: M?ns Rullg?rd <mru at inprovide.com>
>
>
> Steve Lhomme said:
> >> >>> 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 rather large size of all known matroska demuxers seems to
> >> >> contradict that statement.
> >> >
> >> > Can you give examples instead of just waving things in the air ?
> >>
> >> Sure:
> >>
> >> $ cd ~/src/tcvp/src/demuxer
> >> $ wc -l avi/*.c
> >> 1094 avi/avi.c
> >>
> >> $ wc -l matroska/*.c
> >>   285 matroska/ebml.c
> >>  1269 matroska/matroska.c
> >>  1554 total
> >>
> >> $ wc -l mpeg/mpegps.c
> >> 697 mpeg/mpegps.c
> >>
> >> $ wc -l mpeg/mpegts.c
> >> 842 mpeg/mpegts.c
> >>
> >> $ wc -l ogg/*.c
> >>    66 ogg/flac.c
> >>   603 ogg/oggread.c
> >>   162 ogg/ogm.c
> >>   111 ogg/theora.c
> >>   146 ogg/vorbis.c
> >>  1088 total
> >>
> >> $ cd ~/src/ffmpeg/libavformat
> >> $ wc -l avidec.c gxf.c matroska.c mov.c mpeg.c mpegts.c mxf.c
> >>    984 avidec.c
> >>    516 gxf.c
> >>   2720 matroska.c
> >>   1794 mov.c
> >>   1824 mpeg.c      # includes muxer
> >>   1527 mpegts.c
> >>   1078 mxf.c
> >
> > Again, you're comparing pears and apples. None of these formats allow the
> amount
> > of stuff matroska does. Either by design or by lack of standard way to do
> it.
>
> Ah, but these implementations only support the basic stuff.  The
> functionality
> of all those demuxers is more or less the same.

That's not what I say. What I say is that both AVI and WAV can contain PCM
audio. You don't go comparing the AVI and WAV demuxers just because one can do
the stuff the other does. To support PCM AVI needs more code because it can
handle more than audio. This is the idea of comparing pears and apples between
containers that can't be compared.

> From: Rich Felker <dalias at aerifal.cx>

I was expecting you to take part of this ;)

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

Almost nobody uses DShow in MKV or MOV in MKV. But VfW in MKV is used a lot.

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

zlib is just one of the possibilities. Another one introduce maybe a year ago is
simply to remove the first byte(s) of each MP3, AAC, etc frame. Since it's
always the same value. In the end the MP3 in MKV is smaller than the raw
bitstream (after a certain size of course) at very little CPU & memory cost.

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

Well, you have the opportunity to prove it.

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

Please tell me about this "per codec special casing" that everybody talked about
without any real case example.

BTW, I never mentioned NUT because nobody uses it so far. When it's ready we'll
see...

Steve