Hi. Thanks for the advice, in the end the problem was that I used url_fclose() to close files opened with av_input_file_open().
Regards. 2009/1/6 Michael Conrad <[email protected]> > On Mon, 05 Jan 2009 06:22:45 -0500, Stas Oskin <[email protected]> > wrote: > > I've looked through the source code, and found out that av_free_packet() > > actually calls further 2 different functions depending on the context, > > destruct() and destruct_nofree(). > > In my case, where I first read the frame via av_read_frame(), the second > > one is called. After I inspected it source code, I seen there is > > actually no free operator there - the pointer simply get assigned NULL, > > which should immediately lead to a leak? > [...] > > 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? > > Well, I'm not an ffmpeg developer, but I believe in the dranger tutorial > (I think) they explain that the packet doesn't always own the data it > points to. The format demuxer code gets to decide whether it hands you > separately allocated packets or reuses the same buffer over and over. So, > the API demands that you > 1. Always call av_free_packet after using a packet and before calling > the next format-context functions > 2. Never use an old packet after calling the next format-context > function > If you want to hold onto packet data, call av_dup_packet on it. After the > call the packet is guaranteed to be dynamically allocated, and > av_free_packet will actually release memory when called on this packet. > > -- > Michael Conrad > IntelliTree Solutions llc. > 513-552-6362 > [email protected] > _______________________________________________ > libav-user mailing list > [email protected] > https://lists.mplayerhq.hu/mailman/listinfo/libav-user > _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
