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

[Vitor Sessak]

Stefano Sabatini wrote:
> 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.

Looks fine for me.

-Vitor