[FFmpeg-devel] [PATCH] lavd/lavfi: free buffers requested for pts probing

Hendrik Leppkes h.leppkes at gmail.com
Tue Mar 12 14:29:44 CET 2013

On Tue, Mar 12, 2013 at 2:04 PM, Nicolas George
<nicolas.george at normalesup.org> wrote:
> Le duodi 22 ventôse, an CCXXI, Hendrik Leppkes a écrit :
>> ---
>> I'm not 100% sure this is the right fix, but it seems to tbe the most
>> logical (and does fix the memleaks)
>> If you request a frame from lavfi, you should free it afterwards, even if
>> the request was a peek, or does the API specify otherwise?
> This is not the "right" fix.
> The exact problem is this: with the old API, the PEEK flag would return the
> reference directly, without creating a new one. This would work because the
> reference would be guaranteed to exist until at least another call to the
> buffersink API is made; if the caller need the reference to exist for
> longer, they can always create a new one themselves.

I figured this might be the case.

> This is not possible without ugly hacks with the new API. And, as you say,
> it is more logical that way.
> The leak is caused by the compatibility layer, that implements the logic of
> the new API instead of the old one.
> The "right" fixes would be (1) make lavd/lavfi use the new API and not the
> compat layer; (2) fix the compat layer to implement the logic of the old
> API.
> (1) is easy, and I am on it as soon as I have finished this mail. (2) seems
> quite hard, and I am not sure whether it is worth the effort as AFAIK only
> lavd/lavfi uses the PEEK flag.

Fixing lavd is one thing, but can we be sure no user-code uses the
peek flag and will run into the same issue? This was my biggest
concern with the peek flag, and i was truely hoping lavd had just
forgotten to free it.
If the compat API is supposed to be reliable, it somehow needs to
cover this, but as you say, i'm not sure it'll be easy.

Considering this special case of the peek flag not incrementing the
ref wasn't documented (at least not anywhere i could find it), maybe
we can somehow wiggle out of this problem?

More information about the ffmpeg-devel mailing list