[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.
ah!
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