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

[Alexander Noé]

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)

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

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

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

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

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,
which are muxed as 36 tracks, withcues enabled. Lacing is set to 300ms
(remember that the duration of one frame is stored in the track info
for CFR streams, so that lacing CFR streams won't disrupt seek accuracy),
the cluster size is limited to 512 kB in any case, but is no longer than
30.000 timecode scale ticks (a 'hack' allows 65k, but this won't play in MPC).

Timecode scale / Overhead:
--------------------------
1,000,000 / 587,698 bytes
100,000 / 586, 369 bytes 
10,000 / 623,686 bytes
1,000 / 622,228 bytes

Concerning Timecodescale = 1000 (= micro sec accurary), there is basically
one block per cluster and stream.
As you can see, the reasonable-size-limit for the cluster size kicks in
before anything else, and for 10,000/1,000 there is one block per stream
and cluster only, thus the identical overhead.

Now lets try without lacing (which is absolutely necessary for vorbis):

Timecode scale / Overhead:
--------------------------
1,000,000 / 3,562,919 bytes
100,000 / 3,563,682 bytes 
10,000 / 3,598,998 bytes
1,000 / 3,834,525 bytes (when disabling seekhead for clusters -> 3,728,319,
when also disabling prevsize and position -> 3,667,840)


As you can see, increasing the accuracy of timestamps from milli seconds to
micro seconds in an multistream matroska audio file won't seriously increase
its overhead. If you append all tracks to one long one, it will be much more.
I can't give you any numbers, since i have not yet implemented that.

You find the mux logs here:
http://www-user.tu-chemnitz.de/~noe/Temp/AVIMux_GUI-log.zip



Alex