[FFmpeg-devel] [PATCH] Add a CODEC_CAP_USE_INPUT_BUFFER capabilities flag

Stefano Sabatini stefano.sabatini-lala
Sun Nov 30 19:58:16 CET 2008


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.

I'll try to give it a try, if the resulting code would result too
ugly/messy then I'll consider your second proposal:

> The second choice is a CODEC_FLAG that disables this use, for this though
> id like to see at least 2-3 applications that would actually benefit from
> this as it adds some extra code into a few decoders and causes a slowdown
> if the flag is set incorrectly

Thanks, regards.
-- 
FFmpeg = Frightening and Fundamental MultiPurpose Egregious Gadget




More information about the ffmpeg-devel mailing list