[FFmpeg-trac] #942(swresample:new): swresample leaks memory when sampling up
FFmpeg
trac at avcodec.org
Mon Jan 30 01:20:59 CET 2012
#942: swresample leaks memory when sampling up
------------------------------------+--------------------------------------
Reporter: beafdefx | Owner: michael
Type: defect | Status: new
Priority: normal | Component: swresample
Version: git-master | Resolution:
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
------------------------------------+--------------------------------------
Comment (by beafdefx):
OK, I wrote a simple console program that just uses swresample to resample
random data and included some valgrind output in the tar.gz. The contents
of the audio input buffer isn't important, it's the memory use with
repeated calls to swr_convert that I'm concerned about.
There are two defines that you can play with to alter the way the program
executes. OUTRATE_MULTIPLIER determines the sample rate of the output in
relation to the input (input is locked at 16kHz). RESAMPLE_REPS
determines how many times swr_convert is called repeatedly. When
OUTRATE_MULTIPLIER is greater than 1, the program leaks. The bigger the
value of RESAMPLE_REPS, the more it leaks.
DO_SWR_FREE determines if swr_free is called. I leave this OFF for the
purpose of measuring memory leaking because swr_free cleans up all the
excessive memory that was used during resampling. I'm interested in
showing the excessive memory use during a long resampling session, for
example, during extended playback of a song or stream.
The included valgrind output is for 100 reps with a 2x output sample rate
mulitpler compared to 1000 reps of the same:
For 100 reps:
==45151== HEAP SUMMARY:
==45151== in use at exit: 4,294,524 bytes in 42 blocks
==45151== total heap usage: 51 allocs, 9 frees, 8,230,844 bytes
allocated
For 1000 reps:
==45133== HEAP SUMMARY:
==45133== in use at exit: 32,966,524 bytes in 42 blocks
==45133== total heap usage: 54 allocs, 12 frees, 65,478,940 bytes
allocated
This kind of excess usage doesn't make sense. Also, this excess DOES NOT
OCCUR if OUTRATE_MULITIPLER is 1 or less. I would hope that resampling
reuses existing buffers if possible, but it appears that is not the case.
Hope this helps.
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/942#comment:5>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list