[FFmpeg-devel] Longevity Test Report

Benjamin Larsson banan
Wed Feb 4 12:00:53 CET 2009


Mike Melanson wrote:
> Pursuant to recent discussions, I tried decoding a full movie using 
> FFmpeg. No transcoding yet, just decoding. I used this command:
>
> ffmpeg -i <movie> -f framecrc - > /dev/null
>
> With a 100-minute AVI/MPEG-4/MP3 movie, the file decoded at a consistent 
> 1100-1200 fps on my Core 2 Duo machine (single-threaded operation) and 
> finished in 2 minutes in repeated tests. Monitoring the process via 
> 'top' shows a non-changing amount of memory usage.
>
> A 92-minute MPG/MPEG-1/MP2 movie decoded without any memory trouble.
>
> Not as much luck with a 115-minute MP4/H.264/AAC movie, though. On the 
> same machine, the decoding starts strong at over 200 fps and gradually 
> decreases. Monitoring the process via 'top' shows a steadily increasing 
> slice of the 2 GB of RAM being used. When decoding got down to about 40 
> fps, I pressed 'q' to quit, but FFmpeg never really felt like quitting 
> and I had to use harsher quit methods.
>
> When running the command prepended with 'valgrind --leak-check=full 
> --show-reachable=yes', the only problem the memory checker finds is at 
> the start of ffmpeg.c:main():
>
>      for(i=0; i<CODEC_TYPE_NB; i++){
>          avctx_opts[i]= avcodec_alloc_context2(i);
>      }
>
> I guess those contexts are never freed. But that doesn't account for any 
> major memory leaks.
>
> Oddly, I downloaded a 6-minute MOV/H.264/AAC 1080p movie 
> trailer/featurette and it decoded without any notable memory problems.
>   

My suggestion to find these kind of problems is to wrap av_malloc in a 
macro that expands av_malloc to av_leak_malloc(size,__FILE__,__LINE). 
The av_leak_malloc function should then contain a hash table to keep 
track of the malloc'ed regions and from where they come from. And to 
dump a list of the current allocated memory a function that hooks into 
some random key could be used.

A suggested use case would then be that when you find something that 
causes leaks, recompile to enable the leak detection code. Run 
ffmpeg/ffplay so the memory starts to leak, press the dump key and then 
look in the file to see all the memory allocations. There should be one 
type of allocations that is overrepresented. Look up the line and then 
fix the problem.

I know at least one ticket where this kind of tool would have helped 
alot. Or we could use memwatch.

Any comments before I try implementing this?

MvH
Benjamin Larsson






More information about the ffmpeg-devel mailing list