[vlc-devel] [PATCH 08/27] opengl: load filters from command-line arguments

[Thomas Guillem]

I agree with Rémi. gl filters, vk filters or cpu filters should use one common option at the end: --filter. 

The core will need choose the good gpu filter according to the vout. Most used filters will need implementation on all API so that it always work for the user (like adjust).

But nothing prevent to have --gl-filter or --vk-filter for advanced usage.


On Mon, Jun 29, 2020, at 17:46, Alexandre Janniaux wrote:
> Hi,
> 
> On Mon, Jun 29, 2020 at 05:20:12PM +0200, Romain Vimont wrote:
> > On Mon, Jun 29, 2020 at 04:47:34PM +0300, Rémi Denis-Courmont wrote:
> > > Le torstaina 25. kesäkuuta 2020, 15.22.55 EEST Romain Vimont a écrit :
> > > > Enable OpenGL filters via the --gl-filters command-line option:
> > > >
> > > >     vlc file.mkv --gl-filters=filter1:filter2
> > >
> > > IMO, this is a bad idea at this point.
> > >
> > > That's the kind of option that people would grow to expect "just works", and
> > > then just breaks with a VLC update because the default output is no longer
> > > OpenGL. Say Vulkan.
> >
> > Indeed, I would prefer --vout='opengl{filters=filter1:filter2}' instead.
> > But currently, it seems we can't pass parameters that way for vout. I
> > could try to change it if it's acceptable.
> >
> > > In fact, it's rather bizarre to invest so much effort on a sunset technology.
> >
> > Yes, but it's not dead yet ;)
> 
> It's probably going to stay for a while still, especially
> given the investment done to have it work over other graphics
> API (collabora, khronos, gfx and cie.) and the fact that you
> currently don't have a lot of stable alternatives on the web.
> 
> It also brings a framework of tools that can lead to better
> abstraction in the core of VLC before generalizing, and working
> on this fixed a lot of different issues relative to the recent
> refactors while being usable on every other platforms, and
> other points that I details below.
> 
> >
> > > This is further aggravated by the lack of filters when passing video through
> > > from the hardware decoder to OpenGL. Users would learn the wrong habit of
> > > using --gl-filter=deinterlace,adjust instead of the normal existing filter
> > > syntax.
> >
> > This patchset is just a first step: executing OpenGL filters in the
> > vout. It's simpler because we already have the OpenGL context, and we
> > can directly draw.
> >
> > After that, with Alexandre we have WIP to execute OpenGL filters as
> > video_filter_t, and more WIP to execute deinterlace filters with
> > --deinterlace-mode=my_opengl_deinterlace_filter.
> 
> Probably typo, filter_t modules with capability video filter*.
> 
> There is no interest in having completely different syntax
> to add filters between OpenGL and usual VLC filters.
> 
> The idea of the opengl filter pipeline is that it's much easier
> to compose, write and execute than writing everything in a
> filter_t implementation, but it must, IMHO, be ran in a filter_t
> in the end, be it just to be compatible with the current filter
> pipeline.
> 
> So what we are doing in the following patchset is having
> a filter_t implementation called «opengl» initializing an
> opengl provider module, the interop, the opengl filter
> pipeline and calling the filters, to finally bake the
> rendered result in a picture_t+video context provided by
> the opengl provider module.
> 
> It completely decouples the resource providing system with
> the filtering itself, allowing to write independant platform
> specific opengl implementation without touching the code of
> filters, and allows exporting the OpenGL rendered pictures
> into a format that can be used by any display with the correct
> interops, for every platforms, and effectively allowing the
> composition between OpenGL filters and vulkan/d3d11 displays.
> 
> We could also expose each opengl filter as a vlc filter_t
> that way to directly fallback into the «automatic pipeline»
> mode provided by filter_chain, choosing the modules with the
> best score while importing/exporting from the opengl context
> each time, without real maintenance, but with a loss in
> potential optimization.
> 
> That being said, I'm not really fond of --gl-filters= either
> because it's an additional parameter and feature set. It was
> originally a way to start testing and developing the API
> without having the OpenGL implementation per system, but
> being able to override the opengl pipeline in the display
> could be exposed in a different way to the user, in particular
> for projection or VR. It should just not be exposed like a
> module parameter. I'd suggest that we keep it until the opengl
> filter_t implementation is merged though, so as to be able to
> test and review the patches correctly.
> 
> Regards,
> --
> Alexandre Janniaux
> Videolabs
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel