[vlc-devel] [vlc-commits] vout: fix picture lock/unlock with private pool
remi at remlab.net
Wed Nov 5 16:16:21 CET 2014
Le 2014-11-05 13:06, Thomas Guillem a écrit :
> The new vout will use a normal picture Pool without lock/unlock for
> But, I can't find a way to not use pool->pic_unlock when using direct
> rendering: we need a way to release the picture on mediacodec/omx
> side if it's released and not displayed.
As far as I understand Android MediaCodec, the decoder decides on which buffer
gets dequeued, not the video output. The decoder should know which pictures it
references. If it did not, you would be really absolutely totally irrevocably
terminally ultimately screwed.
So the problem is to know which buffers are still queued for display, and which
buffers are free to decode further frames into. Maybe unlock works for that
purpose. All I meant is that lock/unlock does not work for what it was
supposed to... And so the vain lock/unlock callbacks should be dropped from
I have no plans to remove the callbacks. Besides, it's only lock that
interferes with my plans for tick-less decoder thread, not unlock.
> Ideally, pictures allocated by the pool have pixels allocated by vlc
> only for non-dr, non omx, non mediacodec (so, for avcodec).
As far as I know, indirect rendering has always worked that way.
Decoder and private pool pictures are allocated from the heap.
More information about the vlc-devel