This filter provides an OpenGL version of the
adjust filter. It has been developed by Vatsin Suchak (@vatsin1810) as part as his GSoC 2020, along with many other filters that will be rebased and submitted later.
# CPU filter ./vlc --dec-dev=none --video-filter=adjust --brightness=1.2 video.mp4 # OpenGL filter ./vlc --dec-dev=none --video-filter=gladjust --brightness=1.2 video.mp4
Note that even with the very same parameters, the result may not be exactly the same, because (AFAIU) the CPU filter operates on YUV planes while the OpenGL shader operates on RGB input, which it converts to HSL to properly adjust then converts back to RGB.
In this MR, the video filter is an alternate implementation of the adjust filter, with its own name:
However, from a user point of view, it could be reasonable to enable the adjust settings, whatever implementation is used. Also, the user should be able to force an implementation (either the CPU adjust or the OpenGL adjust).
How could we expose this?
If we just give the same name (
"adjust") to the filter, and a higher priority to the OpenGL version, it will not be possible to force the CPU version.
We had a similar discussion for the OpenGL blend deinterlace filter. The solution consisted in:
- passing the generic algorithm
- (optionally) passing an ordered list of implementations, by order of priority:
But here, we directly select a video filter, there is no way to request a "generic" algorithm and optionally its implementation.
Should we add a global
--prefer-opengl option? It looks a bit ad-hoc and hacky. Also, it would prevent the (theoretical) usage of one CPU filter and another OpenGL filter.
What do you think?