[FFmpeg-devel] [PATCH] lame buffer shortage
Sun Jul 22 16:23:54 CEST 2007
On Sun, Jul 22, 2007 at 02:17:29PM +0200, Gabriel Bouvigne wrote:
> Michael Niedermayer a ?crit :
> > lame is VERY broken, if it where not it would never need more then
> > the size of the largest possible packet ...
> Patches are welcome ;-)
understood but iam lazy, especially if i dont need the fixes myself ...
> Actually, if you were only allocating (2*MPA_FRAME_SIZE), then Lame will
> obviously fail in many cases.
> Your buffer size is fine for a Layer II encoder, or an Layer III encoder
> that would not use bit reservoir.
> However, when using the bit reservoir feature, you often need to encode
> several further frames before beeing able to do the actual bistream
yes, you speak about the case where future input is needed to encode the
next packet, this though has nothing to do with needing more output
> In this case, you often encounter some cases where the encoder
> is outputing more than 1 frame once it's able to do proper bitstream
lame does not do proper bitstream formating, it should just output
one packet at a time ...
every project which uses lame and which ive looked at the source has to
parse, break appart and reassemble what lame outputs
lame also seems to be the cause for the (in)famous vbr avi problem on windows
as windows tools likely did just store the lame created bitstream as is
in avi without the parse-split-rebuild step
> Regarding the patch itself, why not simply allocating the buffer size
> recommended into lame.h ?
patch welcome :)
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel