[vlc-devel] [PATCH 05/14] filter: allow the owner not to provide a buffer callback

Rémi Denis-Courmont remi at remlab.net
Wed Sep 18 18:11:23 CEST 2019


Le keskiviikkona 18. syyskuuta 2019, 15.17.25 EEST Steve Lhomme a écrit :
> Hi,
> 
> On 2019-09-18 13:32, Rémi Denis-Courmont wrote:
> > Hmm well yeah... in other words, it's not easy or at least not obvious in
> > the general case.
> > 
> > Also how does should an OpenGL shader-based filter if the decoder device
> > is, say, NVdec, and the video context is X11?
> There is no X11 video context. I'm not sure if you're talking about the
> windowing part of the display module. The windowing part doesn't deal
> with any of that. So let's assume you're talking about the XCB display
> module.
> 
> XCB can only handle CPU based chromas. When it's opened it tells which
> chroma it's going to use. This is how it works now. The core will adapt
> whatever video format+video context is last in the decoder+filters
> pipeline. This is the job of the osys->converters chain in the display
> module.
> 
> If the last format+context in the pipeline is NVDEC then a NVDEC GPU>CPU
> filter is used by osys->converters.

That is basically what VLC 2.0.x/2.1.x did (with other APIs). And it is often 
slower than decoding in software.

NVDEC is supposed to be provide surfaces to another API, either for rendering 
(GL, VK, DX), re-encoding (NVENC) or analysis (AI or whatever) on the GPU.
Also VA-API has very limited filtering capabilities of its own - should be used 
with VK or GL.

And that's exactly why I don't think that we have a design for hardware 
filters.

-- 
Реми Дёни-Курмон
http://www.remlab.net/





More information about the vlc-devel mailing list