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

Michael Niedermayer michaelni
Fri Feb 2 03:59:20 CET 2007


Hi

On Fri, Feb 02, 2007 at 01:08:14AM +0100, Baptiste Coudurier wrote:
> 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 ?

ive no objections to you volunteering to cleanup adpcm.c its probably one
of the most messy files in svn :)

ahh and patch rejected ive fixed it i think, and this has little to do with
decode_audio2 the code was broken since it was written


> 
> 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...

ive the feeling half of the audio codecs need to be reviewed :(
and ive the feeling that ill have to do it :(((

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No evil is honorable: but death is honorable; therefore death is not evil.
-- Citium Zeno
-------------- 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/390f4ca3/attachment.pgp>



More information about the ffmpeg-devel mailing list