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 [email protected] www.gps-laptimer.de
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
