[vlc-devel] [vlc-commits] vout: fix picture lock/unlock with private pool
Rémi Denis-Courmont
remi at remlab.net
Mon Nov 3 17:37:49 CET 2014
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
More information about the vlc-devel
mailing list