[Libav-user] Memory Leaks?

[wm4]

On Sun, 6 Apr 2014 12:07:49 +0200
Harald Schlangmann <harry at gps-laptimer.de> wrote:

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

That seems unlikely. Minor memory leaks can and do happen, but I think
such a big one would be quickly discovered.

Does it happen when using the ffmpeg command line utility or ffplay to
perform similar operations as your code?

You could try to pinpoint the cause by disabling most of your code, and
uncommenting ffmpeg API calls stepwise until it leaks.

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