[Libav-user] Memory Leaks?

[Harald Schlangmann]

Hi,

> Also, calling av_frame_unref() is probably wrong if you haven't enabled
> reference counting.
> 
> IMO the safe way to do this is:
> 
> - require at least ffmpeg 2.1.x
> - set AVCodecContext.refcounted_frames=1 before avcodec_open2()
> - create a single AVFrame with av_frame_alloc()
> - call av_frame_unref() before passing it to the decoder
>  (you can reuse the AVFrame, as long as you unref it)
> - on program termination call av_frame_free()
> 
> Everything else is slightly or completely broken or works only on older
> FFmpeg versions. It's possible that you don't need to unref the
> frame on very new FFmpeg, but I haven't checked.

All but the “av_frame_unref() before passing it to the decoder” has been done already - including switching to reference counting. I have added an additional unref before calling decode_video2 and get a slightly different picture. Concentrating on the bigger leak (av_buffer_realloc), the number of leaks raised(!) from 6059 to 6260 and the overall bytes from 48.44 to 50.55 MB. So at least it had an impact… Btw. I tested several variations before posting here. I used both the reference counting and the old model - no significant difference here. I furthermore completely disabled audio processing and simply freed any audio package read by av_read_frame (). Here again, I saw a negative change in memory leaked. Not sure about the amount, but it grew by 50% or so. Maybe that can give an additional indication where the problem is.

To ask the other way around: is it possible the library itself has memory leaks not being discovered - even for “standard” operation? I have been almost sure it is some shortcoming from my way of using the library here. The amount leaking is probably not critical for a desktop computer with huge amounts of main memory and virtual memory management. Furthermore the standard operation is run a command from the shell and clean up the process afterwards. On an Android device (often limited to 768MB main memory even for Android 4.0 and later phones) a 200kB per second processed is a different story.

Please let me know if I can provide anything else.

Greetings Harald

-
Harald Schlangmann
Antwerpener Str. 52, 50672 Köln, Germany
+49 151 2265 4439
Harry at gps-laptimer.de
www.gps-laptimer.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4145 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20140406/98a04a77/attachment.p7s>