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

Rich Felker dalias
Thu Nov 9 18:27:30 CET 2006


On Thu, Nov 09, 2006 at 05:45:41PM +0100, Steve Lhomme wrote:
> > 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.

Your logic here is invalid. An AVI demuxer that only supports PCM
audio and no video is just as simple as a WAV demuxer. In fact WAV is
basically identical to audio-only AVI...

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

OK, whatever, same deal.

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

CPU cost is very low for mp3 but very high in worst-case (high
bitrate) due to the additional memcpy. In any case, this feature need
not add significant implementation complexity.

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

RTFS the MKV demuxer in MPlayer or lavf...

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

NUT was mostly irrelevant to my arguments. As I said before all other
containers have simpler implementation than MKV (by 2-3 times, at
least) and many support all or most of the same features.

Rich





More information about the ffmpeg-cvslog mailing list