RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity
mpv/video/out/gpu/video.h

235 lines
6.2 KiB
C
Raw Normal View History

vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
/*
* This file is part of mpv.
*
vo_opengl: video.h: fix license This is a mistake coming from commit 6ef06aa1: it accidentally changed the license from GPL/LGPL dual to GPL only.
2016-01-07 09:48:04 +00:00
* mpv is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
*
* mpv is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
vo_opengl: video.h: fix license This is a mistake coming from commit 6ef06aa1: it accidentally changed the license from GPL/LGPL dual to GPL only.
2016-01-07 09:48:04 +00:00
* GNU Lesser General Public License for more details.
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
*
vo_opengl: video.h: fix license This is a mistake coming from commit 6ef06aa1: it accidentally changed the license from GPL/LGPL dual to GPL only.
2016-01-07 09:48:04 +00:00
* You should have received a copy of the GNU Lesser General Public
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
*/
vo_opengl: video.h: fix license This is a mistake coming from commit 6ef06aa1: it accidentally changed the license from GPL/LGPL dual to GPL only.
2016-01-07 09:48:04 +00:00
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
#ifndef MP_GL_VIDEO_H
#define MP_GL_VIDEO_H
#include <stdbool.h>
vo_opengl: make background color configurable This mainly affects the black bars that are drawn if the window and video aspect ratios mismatch.
2014-12-09 20:34:01 +00:00
#include "options/m_option.h"
Rename sub.c/.h to osd.c/.h This was way too misleading. osd.c merely calls the subtitle renderers, instead of actually dealing with subtitles.
2013-11-24 11:58:06 +00:00
#include "sub/osd.h"
vo_opengl: move self-contained shader routines to a separate file This is mostly to cut down somewhat on the amount of code bloat in video.c by moving out helper functions (including scaler kernels and color management routines) to a separate file. It would certainly be possible to move out more functions (eg. dithering or CMS code) with some extra effort/refactoring, but this is a start. Signed-off-by: wm4 <wm4@nowhere>
2015-09-05 12:03:00 +00:00
#include "utils.h"
vo_opengl: generate 3DLUT against source and use full BT.1886 This commit refactors the 3DLUT loading mechanism to build the 3DLUT against the original source characteristics of the file. This allows us, among other things, to use a real BT.1886 profile for the source. This also allows us to actually use perceptual mappings. Finally, this reduces errors on standard gamut displays (where the previous 3DLUT target of BT.2020 was unreasonably wide). This also improves the overall accuracy of the 3DLUT due to eliminating rounding errors where possible, and allows for more accurate use of LUT-based ICC profiles. The current code is somewhat more ugly than necessary, because the idea was to implement this commit in a working state first, and then maybe refactor the profile loading mechanism in a later commit. Fixes #2815.
2016-02-13 14:33:00 +00:00
#include "lcms.h"
vo_opengl: split utils.c/h Actually GL-specific parts go into gl_utils.c/h, the shader cache (gl_sc*) into shader_cache.c/h. No semantic changes of any kind, except that the VAO helper is made public again as part of gl_utils.c (all while the goal for gl_utils.c itself is to be included by GL-specific code).
2017-08-04 17:09:46 +00:00
#include "shader_cache.h"
vo_opengl: remove some indirect GL header inclusions from core renderer
2017-08-10 19:36:57 +00:00
#include "video/csputils.h"
vo_opengl: move self-contained shader routines to a separate file This is mostly to cut down somewhat on the amount of code bloat in video.c by moving out helper functions (including scaler kernels and color management routines) to a separate file. It would certainly be possible to move out more functions (eg. dithering or CMS code) with some extra effort/refactoring, but this is a start. Signed-off-by: wm4 <wm4@nowhere>
2015-09-05 12:03:00 +00:00
#include "video/out/filter_kernels.h"
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
struct scaler_fun {
char *name;
float params[2];
float blur;
filter_kernels: add ability to taper kernels/windows This allows us to define the tukey window (and other tapered windows). Also add a missing option definition for `wblur` while we're at it, to make testing out window-related stuff easier.
2016-10-26 14:32:57 +00:00
float taper;
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
};
struct scaler_config {
struct scaler_fun kernel;
struct scaler_fun window;
float radius;
float antiring;
filter_kernels: add radius cutoff functionality This allows filter functions to be prematurely cut off once their contributions start becoming insignificant. This effectively prevents wasted GPU time sampling from parts of the function that are essentially reduced to zero by the window function, providing anywhere from a 10% to 20% speedup. (5700μs -> 4700μs for me)
2017-07-03 09:23:48 +00:00
float cutoff;
vo_opengl: generalize --scale-clamp etc. This can help fight ringing without completely killing it, thus providing a middle-ground between ringing and aliasing.
2017-07-12 17:08:58 +00:00
float clamp;
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
};
vo_opengl: move self-contained shader routines to a separate file This is mostly to cut down somewhat on the amount of code bloat in video.c by moving out helper functions (including scaler kernels and color management routines) to a separate file. It would certainly be possible to move out more functions (eg. dithering or CMS code) with some extra effort/refactoring, but this is a start. Signed-off-by: wm4 <wm4@nowhere>
2015-09-05 12:03:00 +00:00
struct scaler {
int index;
struct scaler_config conf;
double scale_factor;
bool initialized;
struct filter_kernel *kernel;
vo_opengl: manage scaler LUT textures via ra Also fix the RA_CAP_ bitmask nonsense.
2017-07-29 18:15:59 +00:00
struct ra_tex *lut;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct ra_tex *sep_fbo;
vo_opengl: move self-contained shader routines to a separate file This is mostly to cut down somewhat on the amount of code bloat in video.c by moving out helper functions (including scaler kernels and color management routines) to a separate file. It would certainly be possible to move out more functions (eg. dithering or CMS code) with some extra effort/refactoring, but this is a start. Signed-off-by: wm4 <wm4@nowhere>
2015-09-05 12:03:00 +00:00
bool insufficient;
vo_opengl: Fix minor LUT sampling error Define a macro to correct the coordinate for lookup texture. Cache the corrected coordinate for 1D filter and use mix() to minimize the performance impact.
2015-12-05 18:54:25 +00:00
int lut_size;
vo_opengl: move self-contained shader routines to a separate file This is mostly to cut down somewhat on the amount of code bloat in video.c by moving out helper functions (including scaler kernels and color management routines) to a separate file. It would certainly be possible to move out more functions (eg. dithering or CMS code) with some extra effort/refactoring, but this is a start. Signed-off-by: wm4 <wm4@nowhere>
2015-09-05 12:03:00 +00:00
// kernel points here
struct filter_kernel kernel_storage;
};
vo_opengl: add macros for scaler units There was no real point in hard-coding these all over the place, especially since the order was sort of arbitrary and confusing.
2016-03-05 08:42:57 +00:00
enum scaler_unit {
SCALER_SCALE, // luma/video
SCALER_DSCALE, // luma-video downscaling
SCALER_CSCALE, // chroma upscaling
SCALER_TSCALE, // temporal scaling (interpolation)
SCALER_COUNT
};
vo_opengl: use enums for choice options internally This is much more readable than hard-coding magic IDs all over the file, and removes the need for all the explanatory comments that were a direct result of this.
2016-05-15 22:14:02 +00:00
enum dither_algo {
DITHER_NONE = 0,
DITHER_FRUIT,
DITHER_ORDERED,
vo_gpu: implement error diffusion for dithering This is a straightforward parallel implementation of error diffusion algorithms in compute shader. Basically we use single work group with maximal possible size to process the whole image. After a shift mapping we are able to process all pixels column by column. A large ring buffer are allocated in shared memory to speed things up. However the size of required shared memory depends linearly on the height of video window (or screen height in fullscreen mode). In case there is no enough shared memory, it will fallback to `--dither=fruit`. The maximal allowed work group size is hardcoded as 1024. Ideally we could query `GL_MAX_COMPUTE_WORK_GROUP_INVOCATIONS`. But for whatever reason, it seems most high end card from nvidia and amd support only the minimal required value, so I guess we can stick to it for now.
2019-03-16 11:19:51 +00:00
DITHER_ERROR_DIFFUSION,
vo_opengl: use enums for choice options internally This is much more readable than hard-coding magic IDs all over the file, and removes the need for all the explanatory comments that were a direct result of this.
2016-05-15 22:14:02 +00:00
};
enum alpha_mode {
ALPHA_NO = 0,
ALPHA_YES,
ALPHA_BLEND,
ALPHA_BLEND_TILES,
};
enum blend_subs_mode {
BLEND_SUBS_NO = 0,
BLEND_SUBS_YES,
BLEND_SUBS_VIDEO,
};
vo_opengl: implement more HDR tonemapping algorithms This is now a configurable option, with tunable parameters. I got inspiration for these algorithms off wikipedia. "simple" seems to work pretty well, but not well enough to make it a reasonable default. Some other notable candidates: - Local functions (e.g. based on local contrast or gradient) - Clamp with soft knee (linear up to a point) - Mapping in CIE L*Ch. Map L smoothly, clamp C and h. - Color appearance models These will have to be implemented some other time. Note that the parameter "peak_src" to pass_tone_map should, in principle, be auto-detected from the SEI information of the source file where available. This will also have to be implemented in a later commit.
2016-05-16 00:44:30 +00:00
enum tone_mapping {
vo_gpu_next: update for new tone mapping options This was significantly refactored upstream. Switch to new APIs and add new tone mapping curves and options. cf. https://code.videolan.org/videolan/libplacebo/-/merge_requests/212
2022-01-03 02:56:36 +00:00
TONE_MAPPING_AUTO,
vo_opengl: implement more HDR tonemapping algorithms This is now a configurable option, with tunable parameters. I got inspiration for these algorithms off wikipedia. "simple" seems to work pretty well, but not well enough to make it a reasonable default. Some other notable candidates: - Local functions (e.g. based on local contrast or gradient) - Clamp with soft knee (linear up to a point) - Mapping in CIE L*Ch. Map L smoothly, clamp C and h. - Color appearance models These will have to be implemented some other time. Note that the parameter "peak_src" to pass_tone_map should, in principle, be auto-detected from the SEI information of the source file where available. This will also have to be implemented in a later commit.
2016-05-16 00:44:30 +00:00
TONE_MAPPING_CLIP,
vo_opengl: add new HDR tone mapping algorithm I call it `mobius` because apparently the form f(x) = (cx+a)/(dx+b) is called a Möbius transform, which is the algorithm this is based on. In the extremes it becomes `reinhard` (param=0.0 and `clip` (param=1.0), smoothly transitioning between the two depending on the parameter. This is a useful tone mapping algorithm since the tunable mobius transform allows the user to decide the trade-off between color accuracy and detail preservation on a continuous scale. The default of 0.3 is already far more accurate than `reinhard` while also being reasonably good at preserving highlights, without suffering from the overall brightness drop and color distortion of `hable`. For these reasons, make this the new default. Also expand and improve the documentation for these tone mapping functions.
2017-06-09 07:16:06 +00:00
TONE_MAPPING_MOBIUS,
vo_opengl: rename tone-mapping=simple to reinhard This is the canonical name for the algorithm. I simply didn't know it before.
2016-05-30 10:30:23 +00:00
TONE_MAPPING_REINHARD,
vo_opengl: add hable tone-mapping algorithm Developed by John Hable for use in Uncharted 2. Also used by Frictional Games in SOMA. Originally inspired by a filmic tone mapping algorithm created by Kodak. From http://frictionalgames.blogspot.de/2012/09/tech-feature-hdr-lightning.html
2016-05-30 10:48:01 +00:00
TONE_MAPPING_HABLE,
vo_opengl: implement more HDR tonemapping algorithms This is now a configurable option, with tunable parameters. I got inspiration for these algorithms off wikipedia. "simple" seems to work pretty well, but not well enough to make it a reasonable default. Some other notable candidates: - Local functions (e.g. based on local contrast or gradient) - Clamp with soft knee (linear up to a point) - Mapping in CIE L*Ch. Map L smoothly, clamp C and h. - Color appearance models These will have to be implemented some other time. Note that the parameter "peak_src" to pass_tone_map should, in principle, be auto-detected from the SEI information of the source file where available. This will also have to be implemented in a later commit.
2016-05-16 00:44:30 +00:00
TONE_MAPPING_GAMMA,
TONE_MAPPING_LINEAR,
vo_gpu_next: update for new tone mapping options This was significantly refactored upstream. Switch to new APIs and add new tone mapping curves and options. cf. https://code.videolan.org/videolan/libplacebo/-/merge_requests/212
2022-01-03 02:56:36 +00:00
TONE_MAPPING_SPLINE,
vo_gpu: add BT.2390 tone-mapping Implementation copy/pasted from: https://code.videolan.org/videolan/libplacebo/-/commit/f793fc0480f This brings mpv's tone mapping more in line with industry standard practices, for a hopefully more consistent result across the board. Note that we ignore the black point adjustment of the tone mapping entirely. In theory we could revisit this, if we ever make black point compensation part of the mpv rendering pipeline.
2020-05-29 19:39:05 +00:00
TONE_MAPPING_BT_2390,
vo_gpu_next: update for new tone mapping options This was significantly refactored upstream. Switch to new APIs and add new tone mapping curves and options. cf. https://code.videolan.org/videolan/libplacebo/-/merge_requests/212
2022-01-03 02:56:36 +00:00
TONE_MAPPING_BT_2446A,
vo_opengl: implement more HDR tonemapping algorithms This is now a configurable option, with tunable parameters. I got inspiration for these algorithms off wikipedia. "simple" seems to work pretty well, but not well enough to make it a reasonable default. Some other notable candidates: - Local functions (e.g. based on local contrast or gradient) - Clamp with soft knee (linear up to a point) - Mapping in CIE L*Ch. Map L smoothly, clamp C and h. - Color appearance models These will have to be implemented some other time. Note that the parameter "peak_src" to pass_tone_map should, in principle, be auto-detected from the SEI information of the source file where available. This will also have to be implemented in a later commit.
2016-05-16 00:44:30 +00:00
};
vo_gpu: add --tone-mapping-mode This merges the old desaturation control options into a single enumeration, with the goal of both simplifying how these options work and also making this list more extensible (including, notably, new options only supported by vo_gpu_next). For the hybrid option, I decided to port the (slightly tweaked) values from libplacebo's pre-refactor defaults, rather than the old values we had in mpv, to more visually match the look of the vo_gpu_next hybrid.
2022-01-04 00:50:00 +00:00
enum tone_mapping_mode {
TONE_MAP_MODE_AUTO,
TONE_MAP_MODE_RGB,
TONE_MAP_MODE_MAX,
TONE_MAP_MODE_HYBRID,
TONE_MAP_MODE_LUMA,
};
vo_gpu: add --gamut-mapping-mode Merge --gamut-clipping and --gamut-warning into a single option, --gamut-mapping-mode, better corresponding to the new vo_gpu_next APIs and allowing us to easily extend this option as new modes are added in the future.
2022-01-03 03:31:50 +00:00
enum gamut_mode {
GAMUT_AUTO,
GAMUT_CLIP,
GAMUT_WARN,
GAMUT_DESATURATE,
GAMUT_DARKEN,
};
vo_gpu: improve tone mapping desaturation Instead of desaturating towards luma, we desaturate towards the per-channel tone mapped version. This essentially proves a smooth roll-off towards the "hollywood"-style (non-chromatic) tone mapping algorithm, which works better for bright content, while continuing to use the "linear" style (chromatic) tone mapping algorithm for primarily in-gamut content. We also split up the desaturation algorithm into strength and exponent, which allows users to use less aggressive desaturation settings without affecting the overall curve.
2018-12-27 17:34:19 +00:00
struct gl_tone_map_opts {
int curve;
float curve_param;
vo_gpu: allow boosting dark scenes when tone mapping In theory our "eye adaptation" algorithm works in both ways, both darkening bright scenes and brightening dark scenes. But I've always just prevented the latter with a hard clamp, since I wanted to avoid blowing up dark scenes into looking funny (and full of noise). But allowing a tiny bit of over-exposure might be a good thing. I won't change the default just yet (better let users test), but a moderate value of 1.2 might be better than the current 1.0 limit. Needs testing especially on dark scenes.
2019-01-02 02:03:38 +00:00
float max_boost;
vo_gpu_next: update for new tone mapping options This was significantly refactored upstream. Switch to new APIs and add new tone mapping curves and options. cf. https://code.videolan.org/videolan/libplacebo/-/merge_requests/212
2022-01-03 02:56:36 +00:00
int inverse;
float crosstalk;
vo_gpu: add --tone-mapping-mode This merges the old desaturation control options into a single enumeration, with the goal of both simplifying how these options work and also making this list more extensible (including, notably, new options only supported by vo_gpu_next). For the hybrid option, I decided to port the (slightly tweaked) values from libplacebo's pre-refactor defaults, rather than the old values we had in mpv, to more visually match the look of the vo_gpu_next hybrid.
2022-01-04 00:50:00 +00:00
int mode;
vo_gpu: improve tone mapping desaturation Instead of desaturating towards luma, we desaturate towards the per-channel tone mapped version. This essentially proves a smooth roll-off towards the "hollywood"-style (non-chromatic) tone mapping algorithm, which works better for bright content, while continuing to use the "linear" style (chromatic) tone mapping algorithm for primarily in-gamut content. We also split up the desaturation algorithm into strength and exponent, which allows users to use less aggressive desaturation settings without affecting the overall curve.
2018-12-27 17:34:19 +00:00
int compute_peak;
vo_gpu: redesign peak detection algorithm The previous approach of using an FIR with tunable hard threshold for scene changes had several problems: - the FIR involved annoying hard-coded buffer sizes, high VRAM usage, and the FIR sum was prone to numerical overflow which limited the number of frames we could average over. We also totally redesign the scene change detection. - the hard scene change detection was prone to both false positives and false negatives, each with their own (annoying) issues. Scrap this entirely and switch to a dual approach of using a simple single-pole IIR low pass filter to smooth out noise, while using a softer scene change curve (with tunable low and high thresholds), based on `smoothstep`. The IIR filter is extremely simple in its implementation and has an arbitrarily user-tunable cutoff frequency, while the smoothstep-based scene change curve provides a good, tunable tradeoff between adaptation speed and stability - without exhibiting either of the traditional issues associated with the hard cutoff. Another way to think about the new options is that the "low threshold" provides a margin of error within which we don't care about small fluctuations in the scene (which will therefore be smoothed out by the IIR filter).
2019-01-01 06:30:00 +00:00
float decay_rate;
vo_gpu: use dB units for scene change detection Rather than the linear cd/m^2 units, these (relative) logarithmic units lend themselves much better to actually detecting scene changes, especially since the scene averaging was changed to also work logarithmically.
2019-01-04 15:46:38 +00:00
float scene_threshold_low;
float scene_threshold_high;
vo_gpu: add --gamut-mapping-mode Merge --gamut-clipping and --gamut-warning into a single option, --gamut-mapping-mode, better corresponding to the new vo_gpu_next APIs and allowing us to easily extend this option as new modes are added in the future.
2022-01-03 03:31:50 +00:00
int gamut_mode;
vo_gpu: improve tone mapping desaturation Instead of desaturating towards luma, we desaturate towards the per-channel tone mapped version. This essentially proves a smooth roll-off towards the "hollywood"-style (non-chromatic) tone mapping algorithm, which works better for bright content, while continuing to use the "linear" style (chromatic) tone mapping algorithm for primarily in-gamut content. We also split up the desaturation algorithm into strength and exponent, which allows users to use less aggressive desaturation settings without affecting the overall curve.
2018-12-27 17:34:19 +00:00
};
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
struct gl_video_opts {
vo_opengl: move gl_video_opts copying code to separate function Sigh... Hopefully this code will be completely unnecessary one day, as it's only needed due to the sub-option parser craziness. Move dumb_mode to the top of the struct, so the C universal initializer doesn't cause warnings with all those broken compilers.
2015-09-08 20:46:36 +00:00
int dumb_mode;
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
struct scaler_config scaler[4];
vo_opengl: make LOOKUP_TEXTURE_SIZE configurable
2015-12-05 19:14:23 +00:00
int scaler_lut_size;
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
float gamma;
int gamma_auto;
int target_prim;
int target_trc;
vo_gpu: introduce --target-peak This solves a number of problems simultaneously: 1. When outputting HLG, this allows tuning the OOTF based on the display characteristics. 2. When outputting PQ or other HDR curves, this allows soft-limiting the output brightness using the tone mapping algorithm. 3. When outputting SDR, this allows HDR-in-SDR style output, by controlling the output brightness directly. Closes #5521
2018-02-14 15:10:51 +00:00
int target_peak;
vo_gpu: improve tone mapping desaturation Instead of desaturating towards luma, we desaturate towards the per-channel tone mapped version. This essentially proves a smooth roll-off towards the "hollywood"-style (non-chromatic) tone mapping algorithm, which works better for bright content, while continuing to use the "linear" style (chromatic) tone mapping algorithm for primarily in-gamut content. We also split up the desaturation algorithm into strength and exponent, which allows users to use less aggressive desaturation settings without affecting the overall curve.
2018-12-27 17:34:19 +00:00
struct gl_tone_map_opts tone_map;
vo_opengl: rename fancy-downscaling to correct-downscaling The old name was stupid. Very stupid.
2015-11-07 16:49:14 +00:00
int correct_downscaling;
vo_gpu: split --linear-scaling into two separate options Since linear downscaling makes sense to handle independently from linear/sigmoid upscaling, we split this option up. Now, linear-downscaling is its own option that only controls linearization when downscaling and nothing more. Likewise, linear-upscaling / sigmoid-upscaling are two mutually exclusive options (the latter overriding the former) that apply only to upscaling and no longer implicitly enable linear light downscaling as well. The old behavior was very confusing, as evidenced by issues such as #6213. The current behavior should make much more sense, and only minimally breaks backwards compatibility (since using linear-scaling directly was very uncommon - most users got this for free as part of gpu-hq and relied only on that). Closes #6213.
2018-10-17 09:23:16 +00:00
int linear_downscaling;
int linear_upscaling;
video: Add sigmoidal upscaling to avoid ringing artifacts This avoids issues when upscaling directly in linear light, and is the recommended way to upscale images according to imagemagick. The default slope of 6.5 offers a reasonable compromise between ringing artifacts eliminated and ringing artifacts introduced by sigmoid-upscaling. Same goes for the default center of 0.75.
2015-01-06 09:47:26 +00:00
int sigmoid_upscaling;
float sigmoid_center;
float sigmoid_slope;
gl_video: add scaler-resizes-only sub-option This option disables the scaler set with lscale if the video image is not resized.
2013-05-25 21:47:55 +00:00
int scaler_resizes_only;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
int pbo;
int dither_depth;
gl_video: improve dithering Use a different algorithm to generate the dithering matrix. This looks much better than the previous ordered dither matrix with its cross-hatch artifacts. The matrix generation algorithm as well as its implementation was contributed by Wessel Dankers aka Fruit. The code in dither.c is his implementation, reformatted and with static global variables removed by me. The new matrix is uploaded as float texture - before this commit, it was a normal integer fixed point matrix. This means dithering will be disabled on systems without float textures. The size of the dithering matrix can be configured, as the matrix is generated at runtime. The generation of the matrix can take rather long, and is already unacceptable with size 8. The default is at 6, which takes about 100 ms on a Core2 Duo system with dither.c compiled at -O2, which I consider just about acceptable. The old ordered dithering is still available and can be selected by putting the dither=ordered sub-option. The ordered dither matrix generation code was moved to dither.c. This function was originally written by Uoti Urpala.
2013-05-25 23:48:39 +00:00
int dither_algo;
int dither_size;
int temporal_dither;
vo_opengl: add temporal-dither-period option This was requested multiple times by users, and it's not hard to implement and/or maintain.
2015-07-20 17:09:22 +00:00
int temporal_dither_period;
vo_gpu: implement error diffusion for dithering This is a straightforward parallel implementation of error diffusion algorithms in compute shader. Basically we use single work group with maximal possible size to process the whole image. After a shift mapping we are able to process all pixels column by column. A large ring buffer are allocated in shared memory to speed things up. However the size of required shared memory depends linearly on the height of video window (or screen height in fullscreen mode). In case there is no enough shared memory, it will fallback to `--dither=fruit`. The maximal allowed work group size is hardcoded as 1024. Ideally we could query `GL_MAX_COMPUTE_WORK_GROUP_INVOCATIONS`. But for whatever reason, it seems most high end card from nvidia and amd support only the minimal required value, so I guess we can stick to it for now.
2019-03-16 11:19:51 +00:00
char *error_diffusion;
vo_opengl: make fbotex helper use ra Further work removing GL dependencies from the actual video renderer, and moving them into ra backends. Use of glInvalidateFramebuffer() falls away. I'd like to keep this, but it's better to readd it once shader runs are in ra.
2017-08-04 11:48:37 +00:00
char *fbo_format;
vo_opengl: blend alpha components by default Improves display of images and video with alpha channel, especially if the transparent regions contain (supposed to be invisible) garbage color values.
2013-09-19 14:55:56 +00:00
int alpha_mode;
vo_opengl: add support for rectangle textures This allows vo_opengl to use GL_TEXTURE_RECTANGLE textures, either by enabling it with the 'rectangle-textures' sub-option, or by having a hwdec backend force it. By default it's off. The _only_ reason we're adding this is because VDA can export rectangle textures only.
2013-12-01 22:39:13 +00:00
int use_rectangle;
vo_opengl: make background color configurable This mainly affects the black bars that are drawn if the window and video aspect ratios mismatch.
2014-12-09 20:34:01 +00:00
struct m_color background;
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
int interpolation;
vo_opengl: replace tscale-interpolates-only with interpolation-threshold The previous approach was too naive, and can e.g. ruin playback if scheduling switches e.g. between 1 and 2 vsync per frame.
2016-01-27 20:07:17 +00:00
float interpolation_threshold;
vo_opengl: draw subtitles directly onto the video This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
2015-03-23 01:42:19 +00:00
int blend_subs;
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
char **user_shaders;
vo_opengl: implement debanding (and remove source-shader) The removal of source-shader is a side effect, since this effectively replaces it - and the video-reading code has been significantly restructured to make more sense and be more readable. This means users no longer have to constantly download and maintain a separate deband.glsl installation alongside mpv, which was the only real use case for source-shader that we found either way.
2015-09-05 15:39:27 +00:00
int deband;
struct deband_opts *deband_opts;
vo_opengl: remove sharpen scalers, add sharpen sub-option This turns the old scalers (inherited from MPlayer) into a pre- processing step (after color conversion and before scaling). The code for the "sharpen5" scaler is reused for this. The main reason MPlayer implemented this as scalers was perhaps because FBOs were too expensive, and making it a scaler allowed to implement this in 1 pass. But unsharp masking is not really a scaler, and I would guess the result is more like combining bilinear scaling and unsharp masking.
2015-09-23 20:43:27 +00:00
float unsharp;
vo_opengl: add debugging options for testing with padded textures
2016-10-01 10:01:57 +00:00
int tex_pad_x, tex_pad_y;
vo_opengl: move all icc handling from vo_opengl.c to video.c Originally, video.c did not access any CMS things (other than lut3d being set on it), but this has changed. In practice, almost all accesses to it have moved to video.c. vo_opengl only created it, and set the auto icc profile path. Complete the move. Some things wrt. option handling are a bit fishy. (But when is this not the case.) icc-profile-auto was not tested, but the distributed human CI will take care of it.
2016-06-03 18:35:17 +00:00
struct mp_icc_opts *icc_opts;
vo_opengl: disable glFlush() by default, and add an option to enable it It seems this can cause issues with certain platforms, so better to disable it by default. The original reason for this isn't overly justified, and display-sync mode should get rid of the need for it anyway. The new option is meant for testing, and will probably be removed if nobody comes up and reports that enabling the option actually improves anything.
2016-10-05 10:18:44 +00:00
int early_flush;
vo_opengl: add option for caching shaders on disk Mostly because of ANGLE (sadly). The implementation became unpleasantly big, but at least it's relatively self-contained. I'm not sure to what degree shaders from different drivers are compatible as in whether a driver would randomly misbehave if it's fed a binary created by another driver. The useless binayFormat parameter won't help it, as they can probably easily clash. As usual, OpenGL is pretty shit here.
2017-04-08 14:38:56 +00:00
char *shader_cache_dir;
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
char *hwdec_interop;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
};
extern const struct m_sub_options gl_video_conf;
struct gl_video;
vo: change internal API for drawing frames draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
2015-07-01 17:24:28 +00:00
struct vo_frame;
vo_gpu: make screenshots use the GL renderer Using the GL renderer for color conversion will make sure screenshots will use the same conversion as normal video rendering. It can do this for all types of screenshots. The logic when to write 16 bit PNGs changes. To approximate the old behavior, we decide by looking whether the source video format has more than 8 bits per component. We apply this logic even for window screenshots. Also, 16 bit PNGs now always include an unused alpha channel. The reason is that FFmpeg has RGB48 and RGBA64 formats, but no RGB064. RGB48 is 3 bytes and usually not supported by GPUs for rendering, so we have to use RGBA64, which forces an alpha channel. Will break for users who use --target-trc and similar options. I considered creating a new gl_video context, but it could double GPU memory use, so I didn't. This uses FBOs instead of glGetTexImage(), because that increases the chance it could work on GLES (e.g. ANGLE). Untested. No support for the Vulkan and D3D11 backends yet. Fixes #5498. Also fixes #5240, because the code for reading back is not used with the new code path.
2018-02-07 19:18:36 +00:00
struct voctrl_screenshot;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_gpu: add internal ability to skip osd/subs for rendering Needed for the following commit.
2018-02-08 00:55:31 +00:00
enum {
RENDER_FRAME_SUBS = 1 << 0,
vf_gpu: render subtitles Pretty annoying affair. The vo_gpu code could of course not trigger rendering from filters yet, so it needed to be extended. Also, this uses some icky stuff made for vf_sub (and this was the reason I marked vf_sub as deprecated), so everything is terrible.
2019-11-30 17:09:31 +00:00
RENDER_FRAME_OSD = 1 << 1,
RENDER_FRAME_VF_SUBS = 1 << 2,
vo_gpu: add internal ability to skip osd/subs for rendering Needed for the following commit.
2018-02-08 00:55:31 +00:00
RENDER_FRAME_DEF = RENDER_FRAME_SUBS | RENDER_FRAME_OSD,
};
vo_opengl: further GL API use separation Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
2017-08-07 17:14:18 +00:00
struct gl_video *gl_video_init(struct ra *ra, struct mp_log *log,
struct mpv_global *g);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
void gl_video_uninit(struct gl_video *p);
vo_opengl_cb: don't render OSD while VO is not created Unlike other VOs, this rendered OSD even while no VO was created (because the renderer lives as long as the API user wants). Change this, and refactor the code so that the OSD object is accessible only while the VO is created. (There is a short time where the OSD can still be accessed even after VO destruction - this is not a race condition, though it's inelegant and unfortunately unavoidable.)
2015-03-23 15:32:59 +00:00
void gl_video_set_osd_source(struct gl_video *p, struct osd_state *osd);
vo_opengl: add infrastructure for hardware decoding OpenGL interop Most hardware decoding APIs provide some OpenGL interop. This allows using vo_opengl, without having to read the video data back from GPU. This requires adding a backend for each hardware decoding API. (Each backend is an entry in gl_hwdec_vaglx[].) The backends expose video data as a set of OpenGL textures. Add infrastructure to support this. The next commit will add support for VA-API.
2013-11-03 23:00:18 +00:00
bool gl_video_check_format(struct gl_video *p, int mp_format);
video: add a new method to configure filters and VOs The filter chain and the video ouputs have config() functions. They are strictly limited to transfering the video size and format. Other parameters (like color levels) have to be transferred separately. Improve upon this by introducing a separate set of reconfig() functions, which use mp_image_params to carry format parameters. This struct contains all image format related parameters from config(), plus additional parameters such as colorspace. Change vf_rotate to use it, as well as vo_opengl. vf_rotate is just an example/test case, but vo_opengl will need it later. The intention is also to get rid of VOCTRL_SET_YUV_COLORSPACE. This information is now handed to the VOs via reconfig(). The getter, VOCTRL_GET_YUV_COLORSPACE, will still be needed though.
2013-06-07 23:35:44 +00:00
void gl_video_config(struct gl_video *p, struct mp_image_params *params);
vo_opengl: further GL API use separation Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
2017-08-07 17:14:18 +00:00
void gl_video_render_frame(struct gl_video *p, struct vo_frame *frame,
vo_gpu: add internal ability to skip osd/subs for rendering Needed for the following commit.
2018-02-08 00:55:31 +00:00
struct ra_fbo fbo, int flags);
vo_opengl: further GL API use separation Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
2017-08-07 17:14:18 +00:00
void gl_video_resize(struct gl_video *p,
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
struct mp_rect *src, struct mp_rect *dst,
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
struct mp_osd_res *osd);
vo_opengl: further GL API use separation Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
2017-08-07 17:14:18 +00:00
void gl_video_set_fb_depth(struct gl_video *p, int fb_depth);
vo_opengl: refactor vo performance subsystem This replaces `vo-performance` by `vo-passes`, bringing with it a number of changes and improvements: 1. mpv users can now introspect the vo_opengl passes, which is something that has been requested multiple times. 2. performance data is now measured per-pass, which helps both development and debugging. 3. since adding more passes is cheap, we can now report information for more passes (e.g. the blit pass, and the osd pass). Note: we also switch to nanosecond scale, to be able to measure these passes better. 4. `--user-shaders` authors can now describe their own passes, helping users both identify which user shaders are active at any given time as well as helping shader authors identify performance issues. 5. the timing data per pass is now exported as a full list of samples, so projects like Argon-/mpv-stats can immediately read out all of the samples and render a graph without having to manually poll this option constantly. Due to gl_timer's design being complicated (directly reading performance data would block, so we delay the actual read-back until the next _start command), it's vital not to conflate different passes that might be doing different things from one frame to another. To accomplish this, the actual timers are stored as part of the gl_shader_cache's sc_entry, which makes them unique for that exact shader. Starting and stopping the time measurement is easy to unify with the gl_sc architecture, because the existing API already relies on a "generate, render, reset" flow, so we can just put timer_start and timer_stop in sc_generate and sc_reset, respectively. The ugliest thing about this code is that due to the need to keep pass information relatively stable in between frames, we need to distinguish between "new" and "redrawn" frames, which bloats the code somewhat and also feels hacky and vo_opengl-specific. (But then again, this entire thing is vo_opengl-specific)
2017-06-29 15:00:06 +00:00
void gl_video_perfdata(struct gl_video *p, struct voctrl_performance_data *out);
rpi: fix build Runtime untested, because I get this: [vo/rpi] Could not get DISPMANX objects. This happened even when building older git versions, and on a RPI image that hasn't changed in the recent years. I don't know how to make this POS work again, so I guess if there's a bug in the new code, it will remain broken.
2017-08-11 11:02:13 +00:00
void gl_video_set_clear_color(struct gl_video *p, struct m_color color);
vo_rpi: fix operation Commit 697c4389a9e6 worked "almost". I couldn't test it at the time.
2017-08-15 17:12:39 +00:00
void gl_video_set_osd_pts(struct gl_video *p, double pts);
rpi: fix build Runtime untested, because I get this: [vo/rpi] Could not get DISPMANX objects. This happened even when building older git versions, and on a RPI image that hasn't changed in the recent years. I don't know how to make this POS work again, so I guess if there's a bug in the new code, it will remain broken.
2017-08-11 11:02:13 +00:00
bool gl_video_check_osd_change(struct gl_video *p, struct mp_osd_res *osd,
double pts);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_gpu: make screenshots use the GL renderer Using the GL renderer for color conversion will make sure screenshots will use the same conversion as normal video rendering. It can do this for all types of screenshots. The logic when to write 16 bit PNGs changes. To approximate the old behavior, we decide by looking whether the source video format has more than 8 bits per component. We apply this logic even for window screenshots. Also, 16 bit PNGs now always include an unused alpha channel. The reason is that FFmpeg has RGB48 and RGBA64 formats, but no RGB064. RGB48 is 3 bytes and usually not supported by GPUs for rendering, so we have to use RGBA64, which forces an alpha channel. Will break for users who use --target-trc and similar options. I considered creating a new gl_video context, but it could double GPU memory use, so I didn't. This uses FBOs instead of glGetTexImage(), because that increases the chance it could work on GLES (e.g. ANGLE). Untested. No support for the Vulkan and D3D11 backends yet. Fixes #5498. Also fixes #5240, because the code for reading back is not used with the new code path.
2018-02-07 19:18:36 +00:00
void gl_video_screenshot(struct gl_video *p, struct vo_frame *frame,
struct voctrl_screenshot *args);
vo_opengl: add gamma-auto option This automatically sets the gamma option depending on lighting conditions measured from the computer's ambient light sensor. sRGB – arguably the “sibling” to BT.709 for still images – has a reference viewing environment defined in its specification (IEC 61966-2-1:1999, see http://www.color.org/chardata/rgb/srgb.xalter). According to this data, the assumed ambient illuminance is 64 lux. This is the illuminance where the gamma that results from ICC color management is correct. On the other hand, BT.1886 formalizes that the gamma level for dim environments to be 2.40, and Apple resources (WWDC12: 2012 Session 523: Best practices for color management) define the BT.1886 dim at 16 lux. So the logic we apply is: * >= 64lux -> 1.961 gamma * =< 16lux -> 2.400 gamma * 16lux < x < 64lux -> logaritmic rescale of lux to gamma. The human perception of illuminance roughly follows a logaritmic scale of lux [1]. [1]: https://msdn.microsoft.com/en-us/library/windows/desktop/dd319008%28v=vs.85%29.aspx
2015-02-07 12:54:18 +00:00
float gl_video_scale_ambient_lux(float lmin, float lmax,
float rmin, float rmax, float lux);
void gl_video_set_ambient_lux(struct gl_video *p, int lux);
vo_opengl: move all icc handling from vo_opengl.c to video.c Originally, video.c did not access any CMS things (other than lut3d being set on it), but this has changed. In practice, almost all accesses to it have moved to video.c. vo_opengl only created it, and set the auto icc profile path. Complete the move. Some things wrt. option handling are a bit fishy. (But when is this not the case.) icc-profile-auto was not tested, but the distributed human CI will take care of it.
2016-06-03 18:35:17 +00:00
void gl_video_set_icc_profile(struct gl_video *p, bstr icc_data);
bool gl_video_icc_auto_enabled(struct gl_video *p);
vo_opengl: minor renderer option access refactor Reduce accesses to the renderer opts in vo_opengl.c, and instead add accessors for them to video.c. I suppose gamma and maybe icc-auto could be moved to vo_opengl.c options. Also, the output colorspace could probably be adjusted to what is really used, not just the options (although it's possible that this commit changes this, due to video.c mutating its own copy of the options according to actual renderer capapbilities). But don't deal with this now.
2016-09-02 12:50:03 +00:00
bool gl_video_gamma_auto_enabled(struct gl_video *p);
struct mp_colorspace gl_video_get_output_colorspace(struct gl_video *p);
vo_opengl: add gamma-auto option This automatically sets the gamma option depending on lighting conditions measured from the computer's ambient light sensor. sRGB – arguably the “sibling” to BT.709 for still images – has a reference viewing environment defined in its specification (IEC 61966-2-1:1999, see http://www.color.org/chardata/rgb/srgb.xalter). According to this data, the assumed ambient illuminance is 64 lux. This is the illuminance where the gamma that results from ICC color management is correct. On the other hand, BT.1886 formalizes that the gamma level for dim environments to be 2.40, and Apple resources (WWDC12: 2012 Session 523: Best practices for color management) define the BT.1886 dim at 16 lux. So the logic we apply is: * >= 64lux -> 1.961 gamma * =< 16lux -> 2.400 gamma * 16lux < x < 64lux -> logaritmic rescale of lux to gamma. The human perception of illuminance roughly follows a logaritmic scale of lux [1]. [1]: https://msdn.microsoft.com/en-us/library/windows/desktop/dd319008%28v=vs.85%29.aspx
2015-02-07 12:54:18 +00:00
vo_opengl: add smoothmotion frame blending SmoothMotion is a way to time and blend frames made popular by MadVR. It's intended behaviour is to remove stuttering caused by mismatches between the display refresh rate and the video fps, while preserving the video's original artistic qualities (no soap opera effect). It's supposed to make 24fps video playback on 60hz monitors as close as possible to a 24hz monitor. Instead of drawing a frame once once it's pts has passed the vsync time, we redraw at the display refresh rate, and if we detect the vsync is between two frames we interpolated them (depending on their position relative to the vsync). We actually interpolate as few frames as possible to avoid a blur effect as much as possible. For example, if we were to play back a 1fps video on a 60hz monitor, we would blend at most on 1 vsync for each frame (while the other 59 vsyncs would be rendered as is). Frame interpolation is always done before scaling and in linear light when possible (an ICC profile is used, or :srgb is used).
2014-11-23 19:06:05 +00:00
void gl_video_reset(struct gl_video *p);
vo_opengl: redraw when pausing while showing an interpolated frame If smoothmotion is enabled, and the screen shows an interpolated frame the moment you pause, redraw a non-interpolated frame.
2015-02-04 22:37:38 +00:00
bool gl_video_showing_interpolated_frame(struct gl_video *p);
client API: expose OpenGL renderer This adds API to libmpv that lets host applications use the mpv opengl renderer. This is a more flexible (and possibly more portable) option to foreign window embedding (via --wid). This assumes that methods like context sharing and multithreaded OpenGL rendering are infeasible, and that a way is needed to integrate it with an application that uses a single thread to render everything. Add an example that does this with QtQuick/qml. The example is relatively lazy, but still shows how relatively simple the integration is. The FBO indirection could probably be avoided, but would require more work (and would probably lead to worse QtQuick integration, because it would have to ignore transformations like rotation). Because this makes mpv directly use the host application's OpenGL context, there is no platform specific code involved in mpv, except for hw decoding interop. main.qml is derived from some Qt example. The following things are still missing: - a way to do better video timing - expose GL renderer options, allow changing them at runtime - support for color equalizer controls - support for screenshots
2014-12-09 16:47:02 +00:00
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
struct mp_hwdec_devices;
vo_gpu: move hwdec loading code to common helper So I can reuse it in vo_gpu_next without having to reinvent the wheel. In theory, a lot of the stuff could be made more private inside the hwdec code itself, but for the time being I don't care about refactoring this code, merely sharing it.
2022-02-27 20:07:58 +00:00
void gl_video_init_hwdecs(struct gl_video *p, struct mp_hwdec_devices *devs,
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
bool load_all_by_default);
vo_gpu[_next]: hwdec: fix logging regression when probing When I introduced the concept of lazy loading of hwdecs by img format, I did not propagate the probing flag correctly, leading to the new normal loading path not runnng with probing set, meaning that any errors would show up, creating unnecessary noise. This change fixes this regression.
2022-03-20 19:31:38 +00:00
struct hwdec_imgfmt_request;
vo_gpu: hwdec: load hwdec interops on-demand by default Historically, we have treated hwdec interop loading as a completely separate step from loading the hwdecs themselves. Some hwdecs need an interop, and some don't, and users generally configure the exact hwdec they want, so interops that aren't relevant for that hwdec shouldn't be loaded to save time and avoid warning/error spam. The basic approach here is to recognise that interops are tied to hwdecs by imgfmt. The hwdec outputs some format, and an interop is needed to get that format to the vo without read back. So, when we try to load an hwdec, instead of just blindly loading all interops as we do today, let's pass the imgfmt in and only load interops that work for that format. If more than one interop is available for the format, the existing logic (whatever it is) will continue to be used to pick one. We also have one callsite in filters where we seem to pre-emptively load all the interops. It's probably possible to trace down a specific format but for now I'm just letting it keep loading all of them; it's no worse than before. You may notice there is no documentation update - and that's because the current docs say that when the interop mode is `auto`, the interop is loaded on demand. So reality now reflects the docs. How nice.
2022-02-06 22:18:59 +00:00
void gl_video_load_hwdecs_for_img_fmt(struct gl_video *p, struct mp_hwdec_devices *devs,
vo_gpu[_next]: hwdec: fix logging regression when probing When I introduced the concept of lazy loading of hwdecs by img format, I did not propagate the probing flag correctly, leading to the new normal loading path not runnng with probing set, meaning that any errors would show up, creating unnecessary noise. This change fixes this regression.
2022-03-20 19:31:38 +00:00
struct hwdec_imgfmt_request *params);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: refactor queue configuration Just avoid some code duplication. Also, gl_video_set_options() having a queue size output parameter is weird at best. While I don't appreciate that this commit suddenly requires gl_video.c to deal with vo.c directly in a special case, it's simply the best place to put this function.
2015-07-16 20:43:40 +00:00
struct vo;
void gl_video_configure_queue(struct gl_video *p, struct vo *vo);
vo_opengl: remove DR image layouting code to renderer No reason to have it in a higher level.
2017-08-14 17:57:44 +00:00
struct mp_image *gl_video_get_image(struct gl_video *p, int imgfmt, int w, int h,
int stride_align);
vo_opengl: add direct rendering support Can be enabled via --vd-lavc-dr=yes. See manpage additions for what it does. This reminds of the MPlayer -dr flag, but the implementation is completely different. It's the same basic concept: letting the decoder render into a GPU buffer to avoid a copy. Unlike MPlayer, this doesn't try to go through filters (libavfilter doesn't support this anyway). Unless a filter can work in-place, DR will be silently disabled. MPlayer had very complex semantics about buffer types and management (which apparently nobody ever understood) and weird restrictions that mostly limited it to mpeg2 style codecs. The mpv code does not do any of this, and just lets the decoder allocate an arbitrary number of untyped images. (No MPlayer code was used.) Parts of the code based on work by atomnuker (starting point for the generic code) and haasn (some GL definitions, some basic PBO code, and correct fencing).
2017-07-23 07:41:51 +00:00
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
#endif