On Sun, 6 Apr 2014 12:07:49 +0200 Harald Schlangmann <[email protected]> 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 > [email protected] > www.gps-laptimer.de > _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
