[vlc-devel] [PATCH 2/2] picture_pool: fix Reserve() not locking/unlocking pictures
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
> 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
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.
More information about the vlc-devel