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

Alexander Noé alexander.noe at s2001.tu-chemnitz.de
Tue Jan 27 20:24:45 CET 2004

D Richard Felker III wrote:

>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.
LOL. The read the specs (you need to read OGG, because OGM doesn't have any)

The page header is 28 bytes, the size per packet is then coded. If you 
put k packets
into one page (which is typically done, unless you frames are larger 
than 4 kb), you
have 28+(about [1..2]*k) bytes per k frames.

For audio streams, it is 28+k*(packet size/255+1) bytes per page with k 

Currently, a page is about 4 kb, so that 28 bytes per 4 kB is the least 
possible overhead.

>>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 
>>uses 24 bytes), for MKV, it is currently 13 (will be 16 for real B-frames)
>For NUT it's something like 6-8.
When lacing 2 frames into one block for a CFR file, it would be the 
same, and should be less
for larger laces.

>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.
LOL. You judge the complexity of a demuxer from its size? Just using 
shorter identifiers or
moving some convenience out of the demuxer (down to a level as the 
(in)convencience of
libmatroska), it would be *seriously* smaller. But why should I? Just to 
make you happy?

Maybe look at Gabest's code. I'm sure it is smaller than mine...

>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 
>Not interested in your stupid test cases. Try a movie.
Ah, you don't like the numbers, so they are stupid. Good.

If you knew a single line of the specs, you could easily extrapolate the 
overhead for a movie
file from those numbers. Anyway, since you are too lazy to read or 
understand them, here
it is.

BTW, the test files were all around 1,5 GB, or a few hundred MBs more. 
The used versions
were more or less old, but I did not change significant stuff (causing 
significant differences
in overhead) so far.


More information about the MPlayer-users mailing list