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

Alexander Noé alexander.noe at s2001.tu-chemnitz.de
Tue Jan 27 21:38:47 CET 2004


D Richard Felker III wrote:

>I know it's a way of packing together data from different frames. The
>name suggests that the packing is done out-of-order
>
Not out-of-order in matroska. You mean something like delay lines in the 
CIRC encoder
of CDs.

>Sorry, I have better things to do than read nasty C++.
>
Like reading some matroska specs?

>resolving the laces (= hide their existence for something using that 
>class) causes a neglectible
>amount of extra code, compared to the size of the AVI or matroska 
>parsers, or even writers.
>  
>
>
>AVI parsing is totally trivial without seeking. And seeking is easy
>too in proper VBR files. AVI demuxing only gets complicated when you
>want to support files written by horribly broken programs that don't
>even interleave audio, or interleave it incorrectly.
>  
>
Only writing SRT and SSA subtitles to AVI, read them back and allow to join
subtitle streams inside AVIs (including embedded SSA streams with styles
incompatible to each other, requiring some more attention) is taking 40 
kB of
C++ code in avi-mux gui.
And you call that 'easy'? Ah, ups, i forgot, you did not yet code an AVI 
class
that could read and write subtitles from and to AVIs....

>This isn't very helpful, since timestamps only take 1 byte if done
>correctly. Of course you use stupid 1/10**n based timestamps rather
>than a real time base, so your timestamps are very big.
>  
>
2 Bytes per block, not more than 5 bytes per cluster. Assuming one 
hundred blocks per
cluster, the average is 2,05 bytes per block. For CFR audio, you can 
easily put 50 frames
into one lace, and use those 2,05 bytes for the timecode the first of 
those 50 frames starts at.
This is less than 1 byte per frame, isn't it. Only vorbis would not work 
that way.
Even with small laces (lets say 100ms with mp3), it is less than 1 byte 
per frame.

>
>Wait, how can you even play the file if there are no timestamps on the
>individual frames and the file is VFR? This makes no sense. 
>
It is assumed to be gapless if a timecode is  'missing'?

>There must
>be some way to get the timestamps... For audio you get durations in
>samples by decoding, so that works, but with video, the codec normally
>cannot tell you the correct frame duration.
>  
>
For CFR, the codec does not need to tell anything, and for VFR video, 
lacing is not recommended.

>
>By the way, why does Matroska invent its own silly names for things
>which already have nice established names? Just to confuse critics so
>you can insult them when they try to explain how bad Matroska is?
>  
>
Again wrong. It uses the same silly names as Xiph does.

>This is extracted from your previous mail:....
>  
>
Ah, you mean the lines i inserted...




Alex





More information about the MPlayer-users mailing list