[vlc-devel] [PATCH 2/2] picture_pool: fix Reserve() not locking/unlocking pictures

Rémi Denis-Courmont remi at remlab.net
Sat Dec 31 11:14:06 CET 2016

Le vendredi 30 décembre 2016, 23:13:21 Thomas Guillem a écrit :
> > More importantly, I cannot think of any use case for using the lock and
> > unlock
> > callbacks, that would be both practically useful for the display plugin,
> > and
> > safe/valid/well-defined, so I don't really see the point in these extra
> > intricacies.
> My work in progress OpenGL PBO branch
> https://github.com/tguillem/vlc/commit/bf7fa65ede8fb10839f70d61f707965ee43b6
> 049 will need this commit.

>From my PoV, any vout that relies on lock/unlock is broken because the 
callbacks haven't really done anything useful ever since the vout rework. 
AFAICT, the original (unsound) semantics of those callbacks were lost by then.

And I still fail to see an explanation of what they are supposed to do, how 
that's actually going to work, and why it's actually necessary.

> PBO for Pixel Buffer Object.  With that, we can do direct rendering with
> OpenGL x / OpenGLES 3 display modules. For now, perfs are worse with
> OpenGLES 3 but 30% better (for 4K) with OpenGL (still WIP).

I fail to see why.

* If you need to know when the buffer is read-only and ready for upload, cache 
invalidation, etc., you have to use the ->prepare callback.
* If you need to hold onto the buffer after display, you can use picture_Hold() 
and picture_Release() functions to defer the buffer returning to the pool.
* If you need to unmap the buffer before rendering, you simply cannot perform 
direct rendering (since software decoders and filters might need the buffer as 
reference frame during and after display).
* Likewise if you do not have enough buffers (lest a deadlock potentially 
occur). though the core should work around it automagically by turning direct 
rendering off.

And with that noted, I don't really see what (else) ->lock and ->unlock could 
do that would be useful to OpenGL, or really any video output interface.

Rémi Denis-Courmont

More information about the vlc-devel mailing list