On 08/29/2017 12:18 AM, Hendrik Leppkes wrote:
On Tue, Aug 29, 2017 at 12:07 AM, Jorge Ramirez
<jorge.ramirez-or...@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-or...@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]
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
