[vlc-devel] [vlc-commits] vout: fix picture lock/unlock with private pool

[Rémi Denis-Courmont]

Le 2014-11-05 13:06, Thomas Guillem a écrit :
> The new vout will use a normal picture Pool without lock/unlock for
> non-dr.
> 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 
DirectX plugins.

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.

-- 
Rémi Denis-Courmont