[FFmpeg-devel] [PATCH] libavfilter-soc: fix ffplay.c memleak

[Stefano Sabatini]

On date Sunday 2008-11-30 19:58:16 +0100, Stefano Sabatini encoded:
> On date Sunday 2008-11-30 17:53:47 +0100, Michael Niedermayer encoded:
> > On Sat, Nov 29, 2008 at 09:50:24PM +0100, Stefano Sabatini wrote:
> > > On date Wednesday 2008-11-26 12:22:36 +0100, Michael Niedermayer encoded:
> [...]
> > > > there really are 2 options
> > > > If your code works (which i doubt) you can just assume every codec uses its
> > > > input buffer and thus wont need a flag in AVCodec telling you if the codec
> > > > actually does, not to mention that this can change on a frame by frame basis
> > > > for codecs mixing raw and compressed data.
> > > 
> > > Yes the frame by frame consideration is perfectly valid 
> > 
> > > but I'm not
> > > sure about what you mean implementation-level.
> > 
> > i mean the case identical to yours, just that all codecs always set the flag
> > even if its not correct.
> > What would break?
> > 
> > The problem simply is that i dont see where you ever free the packet when the
> > flag is set. It simply leaks ...
> 
> I was thinking that there was some code which explicitely freed the
> decoded frame, which is simply not true, as the decoder seem to store
> the decoded frame in their internal buffer (as far as I
> (mis)understood it).
> 
> Then my solution was generating a memleak, since in that case the
> frame data wasn't never freed, neither by the decoder neiter by some
> application code.
> 
> So the only way to fix the problem in libavfilter-soc/ff{play,mpeg).c
> seems to me to posticipate the freeing of the packet after the decoded
> frame has been copied in the AVFilterPicRef struct.

The attached patch fixes the memleak (which I introduced fixing a crash)
occurring when a raw video decoder is used.

It does so redefining the function get_video_frame(), which won't
immediately free the data in the packet (which could be used for
example by the raw decoder to contain the frame data), but returns a
shallow copy to the packet just extracted from the input packet queue.

The packet is then freed just after the use of the corresponding frame.

[...]

Regards.
-- 
FFmpeg = Freak & Foolish Meaningless Plastic EnGraver
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-ffplay-memleak.patch
Type: text/x-diff
Size: 2429 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081204/14a92d37/attachment.patch>