Stas Oskin-2 wrote: > > Then I searched through the archives, and found out the following thread, > earlier this year: > http://www.mail-archive.com/[email protected]/msg00564.html > It was claimed that smart pointers are used, so am I correct that there is > an internal buffer managed by FFMPEG, which re-uses same frames to lower > the > number of re-allocations? > > There is apparently a bug in this buffer, where frames are not released? > http://article.gmane.org/gmane.comp.video.ffmpeg.libav.user/580 >
You've found my messages. I've overcome this problem. While the application was eating more and more RAM, there was no memory leak in this part, all pointers to allocated buffers stayed in the memory. My application is processing a live MPEG2 TS. The mentioned effect is caused by rolling of the timestamps over 33 bits. My understanding is that libav* functions tried to calculate new timestamps and stored some packets for exact calculation. However, when rollover occured, timestamps were dropped from near 8589934592 to 0, and the gap was too big for few packets, and libav* stored more and more. I have switched off this behavior by setting the flags: input->flags|=AVFMT_NOFILE|AVFMT_FLAG_IGNIDX; input->flags&=~AVFMT_FLAG_GENPTS; The daemon is working already for about 2 months without interruption and haven't show any memory leaks. About smart pointers. They are not for reallocation. Sorry, if this name confused someone. FFmpeg maintains the incoming packets in the list internally (see the function in the second link to gmane) and removes them on its own discretion, not on the user will. -- View this message in context: http://www.nabble.com/av_free_packet-doesn%27t-frees-memory-tp21289362p21400358.html Sent from the libav-users mailing list archive at Nabble.com. _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
