[MPlayer-users] Re: Free audio codec for .AVI files ?

[D Richard Felker III]

On Tue, Jan 27, 2004 at 06:58:57PM +0100, Alexander Noé wrote:
> OK, I'll only comment on statements which are obviously nonsense:
> 
> >3. OGM reportedly lacks support for variable-fps video, but I'm not
> >  sure this is true.
> 
> It could be done using one page per frame, but the overhead would be
> hilarious (about 30 bytes per frame = twice as much as AVI)

Eh? One page per frame should decrease overhead, since all the
overhead comes from the page headers... I guess I don't follow what
you're saying.

> >4. OGM wastes LOTS of space on completely useless overhead, comparable
> >   to the waste of the avi index (and unlike avi you don't even get an
> >   index in return for all that space!)
> 
> The OGM overhead is, assuming 4 kb pages, at least 0,6% (real life file
> usually have 1%), for AVI, it is 16 bytes per frame/chunk 
> (virtualdub[whatever]
> uses 24 bytes), for MKV, it is currently 13 (will be 16 for real B-frames)

For NUT it's something like 6-8.

> >5. MKV wastes a considerable amount of space (though not as much as
> >   OGM) on overhead, mainly due to the horrible "EBML" encoding and
> >   useless checksums.
> 
> The Checksum part is bullshit, unless you consider 6 bytes per cluster
> (typically 1 byte per 100 kByte if you create clusters of 512 kB) a
> considerable amount of overhead. 

So I was wrong about where the inefficiency is. It's still there if
you're wasting 13-16 bytes per frame.

> >6. MKV is incredibly overcomplicated to implement, with all sorts of
> >   "extensibility" features that are actually not useful and never
> >  will be (the same things could be done without all the bloat).
> 
> You being incapable of implementing it does not make it difficult.
> Before you write more bullshit like this, you might want to implement
> a matroska reader and writer from scratch, as I did (without libmatroska,
> libebml, lib<insert more blah here>), as Gabest did, and some more
> who did not consider it too difficult. Then you will be able to judge it....

No, I can judge it directly by the size of your code, which seems to
be about 100k. That's about 5x as big as a demuxer should be. If you
want to argue that it's not overcomplicated, write a 20k demuxer.

> >9. Both MKV and OGM lack proper framing and timestamping of individual
> >   audio packets
> 
> Valid for OGM, bullshit for MKV. For example AVI-Mux GUI can set the
> timecode scale down to micro seconds, meaning that each audio packet
> (=1 audio frame, if lacing is switched off or packets have constant
> duration, like MP<x>), can get a timestamp on micro second accuracy.
> With a sample rate of 96 kHz, this is more than enough for sample-
> accurate seeking.

This is not what I mean. Vorbis packets do NOT have constant duration,
therefore you can't seek except to explicitly timestamped packets.

Also your "microsecond resolution" is idiotic. Timestamps MUST be
given in rational time base units to be accurate. Rounding to
fixed/floating point approximations is idiotic: you reduce accuracy
and you waste space storing the timestamp.

> Before you cry about your overhead again, here are some numbers. The test
> file is muxed from 36 MP3 source files, which last about 150 mins 
> altogether,

Not interested in your stupid test cases. Try a movie.

Rich