[FFmpeg-devel] Memory leak using bitstream filters with shared libs

[Michael Niedermayer]

On Mon, Mar 10, 2008 at 09:53:37AM +0100, Reimar D?ffinger wrote:
> On Sun, Mar 09, 2008 at 11:00:54PM +0100, Michael Niedermayer wrote:
> > On Sun, Mar 09, 2008 at 07:50:16PM +0100, Reimar D?ffinger wrote:
> > > On Sun, Mar 09, 2008 at 12:05:33AM +0000, M?ns Rullg?rd wrote:
> > > > Baptiste discovered a rather nasty memory leak when using a bitstream
> > > > filter with shared libraries.
> > > > 
> > > > In ffmpeg.c:write_frame() the output of bitstream filters is stored in
> > > > an AVPacket, and its destruct function is set like this (line 417):
> > > > 
> > > >             new_pkt.destruct= av_destruct_packet;
> > > > 
> > > > Later on, in av_interleave_packet_per_dts(), AVPacket.destruct is
> > > > compared against av_destruct_packet, like this (utils.c:2439):
> > > > 
> > > >         if(pkt->destruct == av_destruct_packet)
> > > 
> > > This seems like a misuse of pkt->destruct to me anyway, and for a simple
> > > optimization in addition.
> > > I am still not entirely certain I understood what this does, but I think
> > > that a pkt->flag PKT_FREE_ON_DESTRUCT or some such would do.
> > 
> > ugh ....
> > No it would not do. It completely defeats the sense behind destruct() that
> > is to allow a destruct different from what av_free() does.
> 
> Huh? Of course the destruct pointer should stay, this flag would just
> indicate if the destruct function does some kind of free in the data or
> not, so that we know which way we need to use to copy etc. the AVPacket.

Whats the point of having a flag that says this destruct() does nothing,
destuct=NULL is much simpler.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080310/a161ed4b/attachment.pgp>