[Ffmpeg-devel] [BUG] slowness and/or memory leak with adpcm_ima_qt .mov files
Fri Feb 2 00:36:50 CET 2007
On Fri, Feb 02, 2007 at 12:23:47AM +0100, Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
> > Hi
> > On Wed, Jan 31, 2007 at 04:28:12PM -0800, Allan Hsu wrote:
> >> On Jan 31, 2007, at 3:49 PM, Michael Niedermayer wrote:
> >> [...]
> >>>> I've run across what looks like a major memory leak caused by
> >>>> adpcm_ima_qt audio track decoding. ffmpeg output doesn't look out of
> >>>> the ordinary, but it is much slower than it should be (kind of slow
> >>>> on a PPC OS X machine, but *super slow* on a x86_64 linux machine).
> >>>> I've uploaded a sample to the FTP site as "shuffle-ima41.mov". Here
> >>>> is the ffmpeg output, killed because it was taking up too much
> >>>> memory:
> >>>> ./ffmpeg -i ~/Desktop/shuffle-ima41.mov -acodec pcm_s16le -vcodec
> >>>> mpeg4 -b 768k ~/Desktop/shuffle.avi
> >>> does that also happen if you dont encode the video? -vn
> >> Interesting results. The following command line does not seem to leak
> >> memory, but it doesn't ever seem to stop transcoding either:
> >> ./ffmpeg -i ~/Desktop/shuffle-ima41.mov -vn -b 768k -acodec pcm_s16le
> >> ~/Desktop/shuffle.avi
> >> I stopped ffmpeg by hitting 'q' after it had written over 1.5GB of
> >> data to shuffle.avi (the source movie is only 30 seconds long). I
> >> tried to play back this file in VLC and the audio doesn't seem to
> >> have survived. All I can hear is a periodic quiet clicking noise.
> >>> and what if you just copy the audio -acodec copy?
> >> I can't seem to find a muxer that will accept an adpcm_ima_qt stream.
> > -f null or crc, image2 should work too
> >> [...]
> >> Is there anything else I can do to help with this bug? As I mentioned
> >> in the first email, I've already uploaded my sample file to the ftp.
> > sending a patch would help alot :)
> > also valgrind might be worth a try
> > ill look at the file of course if you noone else does and or sends a patch
> Here is a fix, I suspect more decoders needs that since decode_audio2
patch rejected as it hides a serious probably exploitable bug
the decoders should check if the buffer is large enough / stop writing at
the end, not simply ignore the buffer size
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel