[Ffmpeg-devel] [BUG] slowness and/or memory leak with adpcm_ima_qt .mov files

[Michael Niedermayer]

Hi

On Fri, Feb 02, 2007 at 12:23:47AM +0100, Baptiste Coudurier wrote:
> Hi
> 
> 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
> introduction.

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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070202/adbf2a69/attachment.pgp>