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)
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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
