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

[Rémi Denis-Courmont]

Le 2014-11-03 15:32, Thomas Guillem a écrit :
> This commit doesn't allow direct rendering decoder with private pool. 
> Is it wanted ?

Yes.

vmem assumes (as per the LibVLC documentation) that a picture gets 
unlocked before it gets displayed. Direct3D wants it that way too. Indeed, I 
believe the original purpose of the lock and unlock callback was to provide a 
memory barrier between CPU and GPU access to the picture buffer.

As far as I can tell, those semantics are fundamentally incompatible with  
direct rendering, at least in a safe manner. The decoder and/or the de-
interlacing filter may need to retain references to pictures after they are 
displayed, which would prevent unlocking the pictures before displaying them.

Not that the lock() callback is _not_ really meant to _allocate_ the picture 
buffer. It´s meant to make the buffer writable by the CPU. In principles, the 
buffers are allocated by the pool() callback. If the video output does not 
invalidate pictures, the buffers can even be allocated in the activation 
callback, enabling falling back to another plugin in case of OOM.


Repeating myself, but to keep a picture from being reused by the decoder, the 
video output display plugin should delay calling picture_Release(), until the 
buffer is ready for reuse. There is really not much point providing lock & 
unlock callbacks for opaque hardware surfaces, since they are never visible to 
the CPU.

That said, it is questionable why the lock & unlock callbacks exist at all. 
The plugin could just as well unlock the picture in prepare() and lock it at 
the end of display().

-- 
Rémi Denis-Courmont