[FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

Jorge Ramirez jorge.ramirez-ortiz at linaro.org
Tue Aug 29 01:07:54 EEST 2017

On 08/28/2017 11:42 PM, Hendrik Leppkes wrote:
> On Mon, Aug 28, 2017 at 11:36 PM, Jorge Ramirez
> <jorge.ramirez-ortiz at linaro.org> wrote:
>>> But manually "nesting" AVBufferRefs to make any underlying state
>>> refcounted would also work.
>> I think so, context release now looks like this (it raises an ERROR to the
>> user) but will not lock or poll.
> Thats not really what he was referring to, but to avoid the "blocking" entirely.
> Basically, what you would do is have an AVBufferRef that basically
> "holds" your v4l2 context, and every frame holds a reference on this
> AVBufferRef - and only when all frames are released, the "free"
> function on your context AVBufferRef is called, and you can then
> release all its resources - without having to block the avcodec_close
> function.

I see, thanks for the info

still, with the current v4l2 buffer design (previous thread in the 
discussion), I can't allow avcodec_close to complete - so I have to 
block or at least timeblock- when AVBuffersRefs pointing to v4l2 buffers 
have not been released by the ffmpeg user (if the user tried to access 
that memory it would result in bus errors since the mmaped addresses 
would not be valid)

> This is basically what AVHWFramesContext does, just with more frills around it.

but what about memcpies (do you know if the AVHWFramesContext framework 
copies to the hardware buffers before processing and then back to user 
buffers? because I see no alternative if the AVBufferRefs must be kept 
alive for ever...
> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

More information about the ffmpeg-devel mailing list