[vlc-devel] [PATCH 3/3] snapshot: fix copy of opaque pictures
robux4 at gmail.com
Tue Jun 6 08:48:33 CEST 2017
On Mon, Jun 5, 2017 at 8:58 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le maanantaina 5. kesäkuuta 2017, 18.54.17 EEST Thomas Guillem a écrit :
>> > > This will create issues with some hardwares.
>> > No. The picture context has always had reference counting internally. It
>> > just
>> > was never exposed to the core.
>> > In other words, a back-end without reference counting can´t use the
>> > picture
>> > context trick. And it has always been but a trick to make up for the lack
>> > of
>> > converter, filter and splitter pools.
>> Ok but why no ?
> Why what???
>> How do you prevent the vout and a filter to use the same
>> context for display/reading at the same time ?
> I don´t understand what that´s supposed to mean. The core has no means to know
> or enforce those constraints, even as things already stand without snapshot
> support. Synchronized access is a concern for the back-end to deal with, and
> it would likely cause notable performance degradation already with decoder and
> renderer running in separate threads.
For what it's worth. In Direct3D11 you can't do some operations while
another one is performing (display while the decoder is using the
texture). So there's a mutex shared between all modules handling D3D11
opaque so they don't create such issues (which can lead to crashes on
some platforms). Maybe the same trick can be used for other opaque
> If however the back-end really can only consume a picture only once at all (as
> opposed to once at a time), snapshot would require synchronous copy to CPU,
> then a copy back to GPU in a new identical picture for rendering. I would
> argue that such a back-end should never be enabled by default and is not worth
> supporting snapshot for.
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel