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

[Jorge Ramirez]

On 08/29/2017 12:18 AM, Hendrik Leppkes wrote:
> On Tue, Aug 29, 2017 at 12:07 AM, Jorge Ramirez
> <jorge.ramirez-ortiz at linaro.org> wrote:
>> 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)
>
> The entire point here is that avcodec_close would basically not close
> much (only things that can be free'ed without consequences) as long as
> buffers are still referenced, and the actual closing of hardware
> resources would happen in the free callback fired once all AVBufferRef
> are unused.


ok will try to delegate closing the hardware and doing any operations 
that might invalidate any of the buffers that are on the fly to the last 
reference being released (avcodec_close will probably not be doing much 
then)

>
>>
>>> 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...
> Most hardware formats cannot be accessed by "software" without some
> sort of conversion, thats where those memcpys come in - they download
> the frame from special gpu memory to ordinary memory so they can be
> further processed by any ordinary code.
> This is handy for plugging hardware decoding into any old workflow
> that already exists.
>
> However, it is not required - you can have a fully optimized path and
> keep everything in gpu memory at all times, assuming all components in
> between support any special access requirements imposed by the gpu.

ok. makes sense. thanks a lot Hendrik.


>
> - Hendrik

[apologies, it seems I took the thread out of the ML when I initally 
replied. bringing it back]