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

[Baptiste Coudurier]

Michael Niedermayer wrote:
> 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
> 

Well I don't maintain audio decoders and I did not write decode_audio2.

what about that ?

amr decoder needs to be fixed also I believe, it blindly add to
*data_size for every frame, and someone reported an infinite loop on
ffmpeg-user, if you dont init *data_size to something, ffmpeg.c then
blindly adds that to next_pts and so on...

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
-------------- next part --------------
A non-text attachment was scrubbed...
Name: adpcm_fix.patch
Type: text/x-diff
Size: 528 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070202/ec236718/attachment.patch>