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

[Alexandre Janniaux]

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