RepoMirrors/mpv
1
0
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2025-03-11 08:37:59 +00:00
Code Issues Releases Wiki Activity
7c5f41ff5f
mpv/video/out/opengl/video.c

2622 lines
90 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.
*
* mpv is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* 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
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with mpv. If not, see <http://www.gnu.org/licenses/>.
*
* You can alternatively redistribute this file 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.
*/
#include <assert.h>
gl_video: add some missing includes On most platforms, they are recursively included, but not all.
2013-03-30 03:01:17 +00:00
#include <math.h>
#include <stdbool.h>
#include <string.h>
#include <assert.h>
#include <libavutil/common.h>
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
#include <libavutil/lfg.h>
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: remove gl_ prefixes from files in video/out/opengl This is a bit redundant with the name of the directory itself, and not in line with existing naming conventions.
2015-08-29 02:12:56 +00:00
#include "video.h"
gl_video: add some missing includes On most platforms, they are recursively included, but not all.
2013-03-30 03:01:17 +00:00
Move compat/ and bstr/ directory contents somewhere else bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
2014-08-29 10:09:04 +00:00
#include "misc/bstr.h"
vo_opengl: fix deband sub-option handling This all has to be done manually.
2015-09-09 18:40:04 +00:00
#include "options/m_config.h"
vo_opengl: remove gl_ prefixes from files in video/out/opengl This is a bit redundant with the name of the directory itself, and not in line with existing naming conventions.
2015-08-29 02:12:56 +00:00
#include "common.h"
#include "utils.h"
#include "hwdec.h"
#include "osd.h"
vo_opengl: move shader file caching to video.c It's just about loading and cachign small files, not does not necessarily have anything to do with shaders. Move it to video.c where it's used.
2015-09-23 20:13:03 +00:00
#include "stream/stream.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_shaders.h"
vo_opengl: move gl_* files to their own subdir This is mainly just to keep things a bit more organized and separated inside the codebase.
2015-08-28 23:10:30 +00:00
#include "video/out/filter_kernels.h"
#include "video/out/aspect.h"
#include "video/out/bitmap_packer.h"
#include "video/out/dither.h"
#include "video/out/vo.h"
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
// Pixel width of 1D lookup textures.
#define LOOKUP_TEXTURE_SIZE 256
vo_opengl: rename all scale options to make more sense This emphasizes the fact that scale is used for *all* image upscaling, with cscale only serving a minor role for subsampled material.
2015-01-20 20:46:19 +00:00
// scale/cscale arguments that map directly to shader filter routines.
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
// Note that the convolution filters are not included in this list.
Add more const While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
2014-06-10 21:56:05 +00:00
static const char *const fixed_scale_filters[] = {
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
"bilinear",
"bicubic_fast",
vo_opengl: add oversample scaler This is like nearest neighbour, but the edges between pixels are linearly interpolating if needed, as if they had been (naively) oversampled.
2015-03-15 05:27:11 +00:00
"oversample",
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
"custom",
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
NULL
};
vo_opengl: add oversample support for tscale This is interesting mainly because it's essentially equivalent to the old smoothmotion algorithm. As such, it is now the default for tscale.
2015-03-15 06:11:51 +00:00
static const char *const fixed_tscale_filters[] = {
vo_opengl: reimplement tscale=oversample Closes #2102.
2015-07-11 11:55:45 +00:00
"oversample",
vo_opengl: add oversample support for tscale This is interesting mainly because it's essentially equivalent to the old smoothmotion algorithm. As such, it is now the default for tscale.
2015-03-15 06:11:51 +00:00
NULL
};
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
// must be sorted, and terminated with 0
vo_opengl: use all filter sizes possible with the shaders Not all filter sizes the shaders could handle were in the filter_sizes list. The shader can handle any multiple of 4 (the sizes 2 and 6 are special-cased to keep it simple). Add all possible filter sizes, up to 64. 64 is ridiculously high anyway. Most of the larger filter sizes are completely useless for upscaling, but help with the fancy-downscaling option. (Although it would still be more efficient to use cascaded scalers to handle downscaling better.) I considered doing something less stupid than the hardcoded array, but it seems this is still the simplest solution.
2014-12-08 16:08:26 +00:00
int filter_sizes[] =
{2, 4, 6, 8, 12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, 56, 60, 64, 0};
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 tscale_sizes[] = {2, 4, 6, 0}; // limited by TEXUNIT_VIDEO_NUM
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 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 vertex_pt {
float x, y;
};
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 vertex {
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 vertex_pt position;
vo_opengl: increase the number of video buffers Also the size is now a simple #define that can easily be changed later. This is done for smoothmotion, which might want to blend more than 4 frames at once, depending on the setting.
2015-03-13 12:42:05 +00:00
struct vertex_pt texcoord[TEXUNIT_VIDEO_NUM];
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: create abstraction for VAOs Handles stupid boilerplate OpenGL requires you to handle. It's the same code as in gl_video.c, although if no VAOs are available, the fallback code rebinds them on every draw call instead of just once.
2015-01-28 21:22:29 +00:00
static const struct gl_vao_entry vertex_vao[] = {
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
{"position", 2, GL_FLOAT, false, offsetof(struct vertex, position)},
{"texcoord0", 2, GL_FLOAT, false, offsetof(struct vertex, texcoord[0])},
{"texcoord1", 2, GL_FLOAT, false, offsetof(struct vertex, texcoord[1])},
{"texcoord2", 2, GL_FLOAT, false, offsetof(struct vertex, texcoord[2])},
{"texcoord3", 2, GL_FLOAT, false, offsetof(struct vertex, texcoord[3])},
vo_opengl: increase the number of video buffers Also the size is now a simple #define that can easily be changed later. This is done for smoothmotion, which might want to blend more than 4 frames at once, depending on the setting.
2015-03-13 12:42:05 +00:00
{"texcoord4", 2, GL_FLOAT, false, offsetof(struct vertex, texcoord[4])},
{"texcoord5", 2, GL_FLOAT, false, offsetof(struct vertex, texcoord[5])},
vo_opengl: create abstraction for VAOs Handles stupid boilerplate OpenGL requires you to handle. It's the same code as in gl_video.c, although if no VAOs are available, the fallback code rebinds them on every draw call instead of just once.
2015-01-28 21:22:29 +00:00
{0}
};
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 texplane {
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
int w, h;
gl_video: make it possible for planes to have different formats Preparation for NV12 support. Also adds support for IMGFMT_YA8.
2013-03-28 19:48:53 +00:00
GLint gl_internal_format;
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
GLenum gl_target;
gl_video: make it possible for planes to have different formats Preparation for NV12 support. Also adds support for IMGFMT_YA8.
2013-03-28 19:48:53 +00:00
GLenum gl_format;
GLenum gl_type;
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
GLuint gl_texture;
int gl_buffer;
};
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
struct video_image {
gl_video: always upload all planes When displaying YUV with alpha plane (an extremely rare special case), we didn't upload the alpha plane, because we don't do anything with it. This actually created some annoying special cases, so upload the alpha planes as well, even if they're unused.
2013-03-28 20:02:53 +00:00
struct texplane planes[4];
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
bool image_flipped;
vo_opengl: simplify screenshot code Instead of reading back the image from textures, keep a reference to the original image, and return that. The main reason this was done this way was that originally, images weren't refcounted, and would be deallocated or overwritten as soon as the VO's draw call returned. But now there isn't really a good reason for this anymore. One possibly _could_ argue that it was better because other code could reuse the image sooner (e.g. for the cache), but on the other hand, the VO runs already on a different thread, and filtering and decoding each run on other threads too, so this argument probably wouldn't hold up.
2015-01-22 17:29:37 +00:00
struct mp_image *mpi; // original input image
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +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
struct fbosurface {
struct fbotex fbotex;
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
double pts;
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
};
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
#define FBOSURFACES_MAX 10
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
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 src_tex {
GLuint gl_tex;
GLenum gl_target;
vo_opengl: don't distinguish "real" and texture size This is from times when we supported padded/non-NPOT textures. The difference is not useful anymore, and theoretical support for different sizes is most likely buggy and unmaintained. So remove it. Also remove the tex_ prefix wherever it appears.
2015-09-02 10:52:11 +00:00
int w, h;
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
struct mp_rect_f src;
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
};
vo_opengl: move shader file caching to video.c It's just about loading and cachign small files, not does not necessarily have anything to do with shaders. Move it to video.c where it's used.
2015-09-23 20:13:03 +00:00
struct cached_file {
char *path;
char *body;
};
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 {
GL *gl;
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
struct mpv_global *global;
video/out: use new mp_msg stuff for vo.c and vo_opengl The first step; also serves as example.
2013-07-31 19:44:21 +00:00
struct mp_log *log;
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 opts;
bool gl_debug;
int depth_g;
vo_opengl: don't use 10 bit video on Intel GPUs vo_opengl was originally written against OpenGL 3 core, and it seems GPUs/drivers supporting this are mostly sane. Later, it was made to work with OpenGL 2.1 too. Lately we removed the requirement for RG textures, and look, someone reported a problem with "lesser" Intel GPUs. This commit does the same in vo_opengl what was added to vo_opengl_old a long time ago. Fixes #1383.
2014-12-24 15:54:47 +00:00
int texture_16bit_depth; // actual bits available in 16 bit textures
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 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 gl_shader_cache *sc;
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
GLenum gl_target; // texture target (GL_TEXTURE_2D, ...) for video and FBOs
vo_opengl: create abstraction for VAOs Handles stupid boilerplate OpenGL requires you to handle. It's the same code as in gl_video.c, although if no VAOs are available, the fallback code rebinds them on every draw call instead of just once.
2015-01-28 21:22:29 +00:00
struct gl_vao vao;
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
video/out: change aspects of OSD handling Let the VOs draw the OSD on their own, instead of making OSD drawing a separate VO driver call. Further, let it be the VOs responsibility to request subtitles with the correct PTS. We also basically allow the VO to request OSD/subtitles at any time. OSX changes untested.
2014-06-15 18:46:57 +00:00
struct osd_state *osd_state;
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 mpgl_osd *osd;
video/out: change aspects of OSD handling Let the VOs draw the OSD on their own, instead of making OSD drawing a separate VO driver call. Further, let it be the VOs responsibility to request subtitles with the correct PTS. We also basically allow the VO to request OSD/subtitles at any time. OSX changes untested.
2014-06-15 18:46:57 +00:00
double osd_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
GLuint lut_3d_texture;
bool use_lut_3d;
GLuint dither_texture;
int dither_size;
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
struct mp_image_params real_image_params; // configured format
struct mp_image_params image_params; // texture format (mind hwdec case)
vo_opengl: fix wrong comments The previous commit was actually incorrect, and the change had absolutely no effect. The two formats are (fortunately) the same. I'm probably too tired.
2014-10-16 21:51:36 +00:00
struct mp_imgfmt_desc image_desc;
vo_opengl: some minor cleanups default_tex_params() and texture_size() are each called only once, so move inline/reimplement them at the caller. image_dw/dh were unused. texture_w/h, image_format, and component_bits were rarely used, and can be replaced. Regroup some other fields. Rename surface_num to surface_idx, because the former sounded like a count, and not an index. Move fbosurface_next() closer to its callers too. Move the DebugMessageCallback() code to gl_utils.c (also simplify it by always setting the callback, instead of only when it changes).
2015-01-29 14:50:21 +00:00
int plane_count;
int image_w, image_h;
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
gl_video: support packed YUV formats with Apple extensions This adds support for packed YUV formats (YUVY and UYVY) using the extension GL_APPLE_rgb_422. While supporting this formats on their own is not that important (considering most video is planar YUV) they are used for interoperability with IOSurfaces. Next commit will use this formats to render VDA hardware decoded frames through IOSurface and OpenGL interoperability.
2013-11-13 20:52:34 +00:00
bool is_yuv, is_rgb, is_packed_yuv;
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
bool has_alpha;
char color_swizzle[5];
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
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
struct video_image image;
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 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 fbotex chroma_merge_fbo;
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
struct fbotex chroma_deband_fbo;
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
struct fbotex indirect_fbo;
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
struct fbotex blend_subs_fbo;
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
struct fbotex unsharp_fbo;
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
struct fbosurface surfaces[FBOSURFACES_MAX];
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
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
// these are duplicated so we can keep rendering back and forth between
// them to support an unlimited number of shader passes per step
struct fbotex pre_fbo[2];
struct fbotex post_fbo[2];
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 surface_idx;
int surface_now;
vo_opengl: fix "freezes" after seeking with interpolation on When seeking to a different position, and seeking takes long, the OSD might get redrawn. This means that the VO will receive a request to redraw an old frame using whatever the previous PTS was. This breaks the interpolation logic: the old frame will be added to the queue, and then the next frames (with lower PTS if you seeked backwards) are not drawn as the logic assumes they're past frames. Fix this by using the non-interpolation code path when redrawing after a seek reset, and no "real" frame has been drawn yet. It's a recent regression caused by the redrawing code simplification. The old code simply sent a VOCTRL for redrawing the frame, and the VO had to deal with retaining the old frame on its own. This is a hack as in there's probably a better solution. Fixes #2097.
2015-07-02 11:17:20 +00:00
int frames_drawn;
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
bool is_interpolated;
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 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
// state for luma (0), luma-down(1), chroma (2) and temporal (3) scalers
struct scaler scaler[4];
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_csp_equalizer video_eq;
struct mp_rect src_rect; // displayed part of the source video
struct mp_rect dst_rect; // video rectangle on output window
struct mp_osd_res osd_rect; // OSD size/margins
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
int vp_w, vp_h;
// temporary during rendering
vo_opengl: increase the number of video buffers Also the size is now a simple #define that can easily be changed later. This is done for smoothmotion, which might want to blend more than 4 frames at once, depending on the setting.
2015-03-13 12:42:05 +00:00
struct src_tex pass_tex[TEXUNIT_VIDEO_NUM];
vo_opengl: color manage after interpolation This moves the color management code out of pass_render_main (which is now dedicated solely to up/downscaling and hence renamed pass_scale_main) and into a new function, which gets called from pass_draw_to_screen instead. This makes more sense from a logical standpoint, and also means that we interpolate in linear RGB, before color management - rather than after it, which is significantly better for color accuracy and probably also interpolation quality.
2015-03-15 21:52:34 +00:00
bool use_linear;
vo_opengl: rename use_full_range to use_normalized_range As suggested by haasn. The term "full range" makes it sound like it has to do with TV vs. PC range, which is not the case at all.
2015-05-27 15:40:58 +00:00
bool use_normalized_range;
vo_opengl: apply OSD color management
2015-03-15 23:09:36 +00:00
float user_gamma;
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: add support for custom shaders
2015-03-27 12:27:40 +00:00
int frames_uploaded;
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 frames_rendered;
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
AVLFG lfg;
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
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
// Cached because computing it can take relatively long
int last_dither_matrix_size;
float *last_dither_matrix;
vo_opengl: move shader file caching to video.c It's just about loading and cachign small files, not does not necessarily have anything to do with shaders. Move it to video.c where it's used.
2015-09-23 20:13:03 +00:00
struct cached_file files[10];
int num_files;
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
struct gl_hwdec *hwdec;
bool hwdec_active;
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 fmt_entry {
int mp_format;
GLint internal_format;
GLenum format;
GLenum type;
};
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
// Very special formats, for which OpenGL happens to have direct support
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
static const struct fmt_entry mp_to_gl_formats[] = {
video: synchronize mpv rgb pixel format names with ffmpeg names This affects packed RGB formats up to 16 bits per pixel. The old mplayer names used LSB-to-MSB order, while FFmpeg (and some other libraries) use MSB-to-LSB. Nothing should change with this commit, i.e. no bit order or endian bugs should be added or fixed. In some cases, the name stays the same, even though the byte order changes, e.g. RGB8->BGR8 and BGR8->RGB8, and this affects the user-visible names too; this might cause confusion.
2014-06-14 08:03:04 +00:00
{IMGFMT_BGR555, GL_RGBA, GL_RGBA, GL_UNSIGNED_SHORT_1_5_5_5_REV},
{IMGFMT_BGR565, GL_RGB, GL_RGB, GL_UNSIGNED_SHORT_5_6_5_REV},
{IMGFMT_RGB555, GL_RGBA, GL_BGRA, GL_UNSIGNED_SHORT_1_5_5_5_REV},
{IMGFMT_RGB565, GL_RGB, GL_RGB, GL_UNSIGNED_SHORT_5_6_5},
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
{0},
};
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
static const struct fmt_entry gl_byte_formats[] = {
{0, GL_RED, GL_RED, GL_UNSIGNED_BYTE}, // 1 x 8
{0, GL_RG, GL_RG, GL_UNSIGNED_BYTE}, // 2 x 8
{0, GL_RGB, GL_RGB, GL_UNSIGNED_BYTE}, // 3 x 8
{0, GL_RGBA, GL_RGBA, GL_UNSIGNED_BYTE}, // 4 x 8
{0, GL_R16, GL_RED, GL_UNSIGNED_SHORT}, // 1 x 16
{0, GL_RG16, GL_RG, GL_UNSIGNED_SHORT}, // 2 x 16
{0, GL_RGB16, GL_RGB, GL_UNSIGNED_SHORT}, // 3 x 16
{0, GL_RGBA16, GL_RGBA, GL_UNSIGNED_SHORT}, // 4 x 16
};
vo_opengl: GLES 3 support Tested with MESA on software emulation. Seems to work well, although the default FBO format in opengl-hq disables most interesting features. I have no idea how well it will work on real hardware (or if it does at all). Unfortunately, some features, including playback of 10 bit video, are not supported. Not sure what to do about this. GLES 2 or 1 do not work.
2014-12-17 20:48:23 +00:00
static const struct fmt_entry gl_byte_formats_gles3[] = {
{0, GL_R8, GL_RED, GL_UNSIGNED_BYTE}, // 1 x 8
{0, GL_RG8, GL_RG, GL_UNSIGNED_BYTE}, // 2 x 8
{0, GL_RGB8, GL_RGB, GL_UNSIGNED_BYTE}, // 3 x 8
{0, GL_RGBA8, GL_RGBA, GL_UNSIGNED_BYTE}, // 4 x 8
// There are no filterable texture formats that can be uploaded as
// GL_UNSIGNED_SHORT, so apparently we're out of luck.
{0, 0, 0, 0}, // 1 x 16
{0, 0, 0, 0}, // 2 x 16
{0, 0, 0, 0}, // 3 x 16
{0, 0, 0, 0}, // 4 x 16
};
vo_opengl: add GLES 2 support Rather basic support. Almost nothing works, and even if it does, it's bound to be inefficient (due to texture upload). This was tested with the nVidia desktop binary drivers, which provide GLES 2 support only. However, nVidia is not known to be very strict about OpenGL, and the driver is very new too, so the vo_opengl code will have bugs too.
2014-12-19 00:03:08 +00:00
static const struct fmt_entry gl_byte_formats_gles2[] = {
{0, GL_LUMINANCE, GL_LUMINANCE, GL_UNSIGNED_BYTE}, // 1 x 8
{0, GL_LUMINANCE_ALPHA, GL_LUMINANCE_ALPHA, GL_UNSIGNED_BYTE}, // 2 x 8
{0, GL_RGB, GL_RGB, GL_UNSIGNED_BYTE}, // 3 x 8
{0, GL_RGBA, GL_RGBA, GL_UNSIGNED_BYTE}, // 4 x 8
{0, 0, 0, 0}, // 1 x 16
{0, 0, 0, 0}, // 2 x 16
{0, 0, 0, 0}, // 3 x 16
{0, 0, 0, 0}, // 4 x 16
};
vo_opengl: remove requirement for RG textures Features not supported are disabled (although with a misleading error message).
2014-12-16 17:55:02 +00:00
static const struct fmt_entry gl_byte_formats_legacy[] = {
vo_opengl: simplify the case without texture_rg If GL_RED was not available, we used GL_ALPHA. But this is an unnecessary complication, and it's easier to use GL_LUMINANCE instead. With the latter, a texture will return the .r component set, and as long as the shader doesn't look at the other components, the shader doesn't need any changes. Some of the changes added in 0e8fbdbd are now unneeeded. Also, realign the entire gl_byte_formats_legacy table.
2014-12-18 13:46:19 +00:00
{0, GL_LUMINANCE, GL_LUMINANCE, GL_UNSIGNED_BYTE}, // 1 x 8
{0, GL_LUMINANCE_ALPHA, GL_LUMINANCE_ALPHA, GL_UNSIGNED_BYTE}, // 2 x 8
{0, GL_RGB, GL_RGB, GL_UNSIGNED_BYTE}, // 3 x 8
{0, GL_RGBA, GL_RGBA, GL_UNSIGNED_BYTE}, // 4 x 8
{0, GL_LUMINANCE16, GL_LUMINANCE, GL_UNSIGNED_SHORT},// 1 x 16
{0, GL_LUMINANCE16_ALPHA16, GL_LUMINANCE_ALPHA, GL_UNSIGNED_SHORT},// 2 x 16
{0, GL_RGB16, GL_RGB, GL_UNSIGNED_SHORT},// 3 x 16
{0, GL_RGBA16, GL_RGBA, GL_UNSIGNED_SHORT},// 4 x 16
vo_opengl: remove requirement for RG textures Features not supported are disabled (although with a misleading error message).
2014-12-16 17:55:02 +00:00
};
vo_opengl: use all filter sizes possible with the shaders Not all filter sizes the shaders could handle were in the filter_sizes list. The shader can handle any multiple of 4 (the sizes 2 and 6 are special-cased to keep it simple). Add all possible filter sizes, up to 64. 64 is ridiculously high anyway. Most of the larger filter sizes are completely useless for upscaling, but help with the fancy-downscaling option. (Although it would still be more efficient to use cascaded scalers to handle downscaling better.) I considered doing something less stupid than the hardcoded array, but it seems this is still the simplest solution.
2014-12-08 16:08:26 +00:00
static const struct fmt_entry gl_float16_formats[] = {
{0, GL_R16F, GL_RED, GL_FLOAT}, // 1 x f
{0, GL_RG16F, GL_RG, GL_FLOAT}, // 2 x f
{0, GL_RGB16F, GL_RGB, GL_FLOAT}, // 3 x f
{0, GL_RGBA16F, GL_RGBA, GL_FLOAT}, // 4 x f
};
gl_video: support packed YUV formats with Apple extensions This adds support for packed YUV formats (YUVY and UYVY) using the extension GL_APPLE_rgb_422. While supporting this formats on their own is not that important (considering most video is planar YUV) they are used for interoperability with IOSurfaces. Next commit will use this formats to render VDA hardware decoded frames through IOSurface and OpenGL interoperability.
2013-11-13 20:52:34 +00:00
static const struct fmt_entry gl_apple_formats[] = {
{IMGFMT_UYVY, GL_RGB, GL_RGB_422_APPLE, GL_UNSIGNED_SHORT_8_8_APPLE},
{IMGFMT_YUYV, GL_RGB, GL_RGB_422_APPLE, GL_UNSIGNED_SHORT_8_8_REV_APPLE},
{0}
};
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
struct packed_fmt_entry {
int fmt;
int8_t component_size;
int8_t components[4]; // source component - 0 means unmapped
};
static const struct packed_fmt_entry mp_packed_formats[] = {
vo_opengl: handle grayscale input better, add YA16 support Simply clamp off the U/V components in the colormatrix, instead of doing something special in the shader. Also, since YA8/YA16 gave a plane_bits value of 16/32, and a colormatrix calculation overflowed with 32, add a component_bits field to the image format descriptor, which for YA8/YA16 returns 8/16 (the wrong value had no bad consequences otherwise).
2015-01-21 18:29:18 +00:00
// w R G B A
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
{IMGFMT_Y8, 1, {1, 0, 0, 0}},
{IMGFMT_Y16, 2, {1, 0, 0, 0}},
{IMGFMT_YA8, 1, {1, 0, 0, 2}},
vo_opengl: handle grayscale input better, add YA16 support Simply clamp off the U/V components in the colormatrix, instead of doing something special in the shader. Also, since YA8/YA16 gave a plane_bits value of 16/32, and a colormatrix calculation overflowed with 32, add a component_bits field to the image format descriptor, which for YA8/YA16 returns 8/16 (the wrong value had no bad consequences otherwise).
2015-01-21 18:29:18 +00:00
{IMGFMT_YA16, 2, {1, 0, 0, 2}},
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
{IMGFMT_ARGB, 1, {2, 3, 4, 1}},
{IMGFMT_0RGB, 1, {2, 3, 4, 0}},
{IMGFMT_BGRA, 1, {3, 2, 1, 4}},
{IMGFMT_BGR0, 1, {3, 2, 1, 0}},
{IMGFMT_ABGR, 1, {4, 3, 2, 1}},
{IMGFMT_0BGR, 1, {4, 3, 2, 0}},
{IMGFMT_RGBA, 1, {1, 2, 3, 4}},
{IMGFMT_RGB0, 1, {1, 2, 3, 0}},
{IMGFMT_BGR24, 1, {3, 2, 1, 0}},
{IMGFMT_RGB24, 1, {1, 2, 3, 0}},
{IMGFMT_RGB48, 2, {1, 2, 3, 0}},
{IMGFMT_RGBA64, 2, {1, 2, 3, 4}},
{IMGFMT_BGRA64, 2, {3, 2, 1, 4}},
{0},
};
gl_video: make it possible for planes to have different formats Preparation for NV12 support. Also adds support for IMGFMT_YA8.
2013-03-28 19:48:53 +00:00
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
const struct gl_video_opts gl_video_opts_def = {
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
.dither_depth = -1,
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
.dither_size = 6,
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
.temporal_dither_period = 1,
vo_opengl: change default FBO format Reduces (but likely does not remove) the danger of rounding intermediate values down to 8 bit. This is important for cscale, or any other processing that might store raw YUV values in framebuffers. Fixes #1918.
2015-05-05 12:41:33 +00:00
.fbo_format = GL_RGBA16,
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
.sigmoid_center = 0.75,
.sigmoid_slope = 6.5,
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
.scaler = {
vo_opengl: add scale-wparam option This lets us tune the window parameter
2015-03-27 05:18:32 +00:00
{{"bilinear", .params={NAN, NAN}}, {.params = {NAN, NAN}}}, // scale
{{NULL, .params={NAN, NAN}}, {.params = {NAN, NAN}}}, // dscale
{{"bilinear", .params={NAN, NAN}}, {.params = {NAN, NAN}}}, // cscale
vo_opengl: reimplement tscale=oversample Closes #2102.
2015-07-11 11:55:45 +00:00
{{"oversample", .params={NAN, NAN}}, {.params = {NAN, NAN}}}, // tscale
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
},
Revert "vo_opengl: disable alpha by default" This reverts commit a33b46194c3525cb585cc78b449ec275dbfd7f83. It turns out FFmpeg really considers this a bug, and fixed it by making the decoder output the correct pixel format. Fixes #1565. Reverts the fix #1528, though it should work fine with a recent git master FFmpeg.
2015-02-06 22:23:27 +00:00
.alpha_mode = 2,
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
.background = {0, 0, 0, 255},
vo_opengl: change initialization of gamma option Make the lazy gamma initialization less weird, and make the default value of the "gamma" sub-option 1.0. This means --vo=opengl:help will list the actual default value. Also change the lower bound to 0.1 - avoids a division by zero (I don't know how shaders handle NaN, but it's probably not a good idea to give them this value).
2015-02-03 16:12:04 +00:00
.gamma = 1.0f,
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
};
m_config: refactor option defaults handling Keep track of the default values directly, instead of creating a new instance of the option struct just to get the defaults. Also get rid of the special handling of m_obj_desc.init_options. Instead, handle it purely by the option parser. Originally, I wanted to handle --vo=opengl-hq and --vo=direct3d_shaders with this (by making them aliases to the real VOs with a different preset), but since --vo =opengl-hq=help prints the wrong values (as consequence of the simplification), I'm not doing that, and instead use something different.
2013-10-24 20:20:16 +00:00
const struct gl_video_opts gl_video_opts_hq_def = {
.dither_depth = 0,
.dither_size = 6,
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
.temporal_dither_period = 1,
vo_opengl: use GL_RGBA16 FBO format for HQ GL_RGB16 is definitely not a required format, after review of the OpenGL 3.3 spec. Most HW doesn't have native support for RGB16 anyway.
2014-02-17 10:33:37 +00:00
.fbo_format = GL_RGBA16,
vo_opengl: enable fancy-downscaling for opengl-hq again I guess most problems with it have been fixed. It's still slower than necessary, though.
2014-12-08 16:09:39 +00:00
.fancy_downscaling = 1,
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
.sigmoid_center = 0.75,
.sigmoid_slope = 6.5,
.sigmoid_upscaling = 1,
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
.scaler = {
vo_opengl: add scale-wparam option This lets us tune the window parameter
2015-03-27 05:18:32 +00:00
{{"spline36", .params={NAN, NAN}}, {.params = {NAN, NAN}}}, // scale
{{"mitchell", .params={NAN, NAN}}, {.params = {NAN, NAN}}}, // dscale
{{"spline36", .params={NAN, NAN}}, {.params = {NAN, NAN}}}, // cscale
vo_opengl: make oversample the default for opengl-hq as well This was supposed to have changed back when oversample was reintroduced in 3007250. Fixes #2155.
2015-07-19 23:33:03 +00:00
{{"oversample", .params={NAN, NAN}}, {.params = {NAN, NAN}}}, // tscale
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
},
Revert "vo_opengl: disable alpha by default" This reverts commit a33b46194c3525cb585cc78b449ec275dbfd7f83. It turns out FFmpeg really considers this a bug, and fixed it by making the decoder output the correct pixel format. Fixes #1565. Reverts the fix #1528, though it should work fine with a recent git master FFmpeg.
2015-02-06 22:23:27 +00:00
.alpha_mode = 2,
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
.background = {0, 0, 0, 255},
vo_opengl: change initialization of gamma option Make the lazy gamma initialization less weird, and make the default value of the "gamma" sub-option 1.0. This means --vo=opengl:help will list the actual default value. Also change the lower bound to 0.1 - avoids a division by zero (I don't know how shaders handle NaN, but it's probably not a good idea to give them this value).
2015-02-03 16:12:04 +00:00
.gamma = 1.0f,
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
.blend_subs = 0,
vo_opengl: enable pbo by default with opengl-hq Can significantly help with very large video resolutions on nvidia drivers. It doesn't seem to have negative effects on Intel drivers either. (Although it could have on Intel drivers for older hardware.) For now, this is only for --vo=opengl-hq. Maybe --vo=opengl should use it too, but it's still meant to be the crappy, fail-safe default.
2015-09-02 11:16:34 +00:00
.pbo = 1,
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
.deband = 1,
m_config: refactor option defaults handling Keep track of the default values directly, instead of creating a new instance of the option struct just to get the defaults. Also get rid of the special handling of m_obj_desc.init_options. Instead, handle it purely by the option parser. Originally, I wanted to handle --vo=opengl-hq and --vo=direct3d_shaders with this (by making them aliases to the real VOs with a different preset), but since --vo =opengl-hq=help prints the wrong values (as consequence of the simplification), I'm not doing that, and instead use something different.
2013-10-24 20:20:16 +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
m_option: add mp_log callback to OPT_STRING_VALIDATE options And also convert a bunch of other code, especially ao_wasapi and ao_portaudio.
2013-12-21 19:03:36 +00:00
static int validate_scaler_opt(struct mp_log *log, const m_option_t *opt,
struct bstr name, struct bstr param);
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: separate kernel and window This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
static int validate_window_opt(struct mp_log *log, const m_option_t *opt,
struct bstr name, struct bstr param);
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
#define OPT_BASE_STRUCT struct gl_video_opts
vo_opengl: reduce code duplication for scaler options This simple refactor cuts down on the immense amount of overhead and duplication across all of the related scale-* options.
2015-08-29 01:24:15 +00:00
#define SCALER_OPTS(n, i) \
OPT_STRING_VALIDATE(n, scaler[i].kernel.name, 0, validate_scaler_opt), \
OPT_FLOAT(n"-param1", scaler[i].kernel.params[0], 0), \
OPT_FLOAT(n"-param2", scaler[i].kernel.params[1], 0), \
OPT_FLOAT(n"-blur", scaler[i].kernel.blur, 0), \
OPT_FLOAT(n"-wparam", scaler[i].window.params[0], 0), \
OPT_FLAG(n"-clamp", scaler[i].clamp, 0), \
OPT_FLOATRANGE(n"-radius", scaler[i].radius, 0, 0.5, 16.0), \
OPT_FLOATRANGE(n"-antiring", scaler[i].antiring, 0, 0.0, 1.0), \
OPT_STRING_VALIDATE(n"-window", scaler[i].window.name, 0, validate_window_opt)
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
const struct m_sub_options gl_video_conf = {
Add more const While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
2014-06-10 21:56:05 +00:00
.opts = (const m_option_t[]) {
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
OPT_FLAG("dumb-mode", dumb_mode, 0),
vo_opengl: change initialization of gamma option Make the lazy gamma initialization less weird, and make the default value of the "gamma" sub-option 1.0. This means --vo=opengl:help will list the actual default value. Also change the lower bound to 0.1 - avoids a division by zero (I don't know how shaders handle NaN, but it's probably not a good idea to give them this value).
2015-02-03 16:12:04 +00:00
OPT_FLOATRANGE("gamma", gamma, 0, 0.1, 2.0),
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
OPT_FLAG("gamma-auto", gamma_auto, 0),
vo_opengl: make csp options consistent with vf_format
2015-03-31 05:31:35 +00:00
OPT_CHOICE_C("target-prim", target_prim, 0, mp_csp_prim_names),
OPT_CHOICE_C("target-trc", target_trc, 0, mp_csp_trc_names),
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
OPT_FLAG("pbo", pbo, 0),
vo_opengl: reduce code duplication for scaler options This simple refactor cuts down on the immense amount of overhead and duplication across all of the related scale-* options.
2015-08-29 01:24:15 +00:00
SCALER_OPTS("scale", 0),
SCALER_OPTS("dscale", 1),
SCALER_OPTS("cscale", 2),
SCALER_OPTS("tscale", 3),
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
OPT_FLAG("scaler-resizes-only", scaler_resizes_only, 0),
vo_opengl: add support for linear scaling without CMS This introduces a new option linear-scaling, which is now implied by srgb, icc-profile and sigmoid-upscaling. Notably, this means (sigmoidized) linear upscaling is now enabled by default in opengl-hq mode. The impact should be negligible, and there has been no observation of negative side effects of sigmoidized scaling, so it feels safe to do so.
2015-02-06 02:37:21 +00:00
OPT_FLAG("linear-scaling", linear_scaling, 0),
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
OPT_FLAG("fancy-downscaling", fancy_downscaling, 0),
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
OPT_FLAG("sigmoid-upscaling", sigmoid_upscaling, 0),
OPT_FLOATRANGE("sigmoid-center", sigmoid_center, 0, 0.0, 1.0),
OPT_FLOATRANGE("sigmoid-slope", sigmoid_slope, 0, 1.0, 20.0),
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
OPT_CHOICE("fbo-format", fbo_format, 0,
({"rgb", GL_RGB},
{"rgba", GL_RGBA},
{"rgb8", GL_RGB8},
{"rgb10", GL_RGB10},
gl_video: add RGB10_A2 FBO format Maybe this can be the default in the future, but I'm not sure yet.
2013-10-23 15:46:57 +00:00
{"rgb10_a2", GL_RGB10_A2},
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
{"rgb16", GL_RGB16},
{"rgb16f", GL_RGB16F},
gl_video: add some alpha FBO formats
2013-03-28 20:44:33 +00:00
{"rgb32f", GL_RGB32F},
{"rgba12", GL_RGBA12},
{"rgba16", GL_RGBA16},
{"rgba16f", GL_RGBA16F},
{"rgba32f", GL_RGBA32F})),
gl_video: use choice option type for dither-depth suboption Replaces the numeric magic values -1 and 0 with "no" and "auto". The numeric values are still allowed for compatibility.
2013-03-28 20:39:17 +00:00
OPT_CHOICE_OR_INT("dither-depth", dither_depth, 0, -1, 16,
({"no", -1}, {"auto", 0})),
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
OPT_CHOICE("dither", dither_algo, 0,
({"fruit", 0}, {"ordered", 1}, {"no", -1})),
OPT_INTRANGE("dither-size-fruit", dither_size, 0, 2, 8),
OPT_FLAG("temporal-dither", temporal_dither, 0),
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
OPT_INTRANGE("temporal-dither-period", temporal_dither_period, 0, 1, 128),
options: handle choice -> flag fallback automatically In the past it happened quite often that flag options (yes/no) were changed to choice options (yes/no/some more). The problem with this was that while flag options don't need a parameter, this wasn't the case with choice options. A hack was introduced to compensate for this: setting M_OPT_OPTIONAL_PARAM on the option, and an empty string ("") was added as choice, so that the choice could be used like a flag. So, for example, "--mute" would set the choice "". Fix this by 1. not requiring a parameter if there's a "yes" choice, and 2. redirect an empty parameter to "yes". The effect is that a choice option with the choices ["yes", "no"] is pretty much equivalent to a flag option.
2015-02-27 17:31:24 +00:00
OPT_CHOICE("alpha", alpha_mode, 0,
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
({"no", 0},
options: handle choice -> flag fallback automatically In the past it happened quite often that flag options (yes/no) were changed to choice options (yes/no/some more). The problem with this was that while flag options don't need a parameter, this wasn't the case with choice options. A hack was introduced to compensate for this: setting M_OPT_OPTIONAL_PARAM on the option, and an empty string ("") was added as choice, so that the choice could be used like a flag. So, for example, "--mute" would set the choice "". Fix this by 1. not requiring a parameter if there's a "yes" choice, and 2. redirect an empty parameter to "yes". The effect is that a choice option with the choices ["yes", "no"] is pretty much equivalent to a flag option.
2015-02-27 17:31:24 +00:00
{"yes", 1},
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
{"blend", 2})),
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
OPT_FLAG("rectangle-textures", use_rectangle, 0),
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
OPT_COLOR("background", background, 0),
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
OPT_FLAG("interpolation", interpolation, 0),
vo_opengl: unify blend-subtitles-res and blend-subtitles
2015-04-11 17:16:34 +00:00
OPT_CHOICE("blend-subtitles", blend_subs, 0,
({"no", 0},
{"yes", 1},
{"video", 2})),
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
OPT_STRING("scale-shader", scale_shader, 0),
OPT_STRINGLIST("pre-shaders", pre_shaders, 0),
OPT_STRINGLIST("post-shaders", post_shaders, 0),
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
OPT_FLAG("deband", deband, 0),
OPT_SUBSTRUCT("deband", deband_opts, deband_conf, 0),
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
OPT_FLOAT("sharpen", unsharp, 0),
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
vo_opengl: get rid of approx-gamma and make it the default as per BT.1886 After finding out more about how video mastering is done in the real world it dawned upon me why the "hack" we figured out in #534 looks so much better. Since mastering studios have historically been using only CRTs, the practice adopted for backwards compatibility was to simulate CRT responses even on modern digital monitors, a practice so ubiquitous that the ITU-R formalized it in R-Rec BT.1886 to be precisely gamma 2.40. As such, we finally have enough proof to get rid of the option altogether and just always do that. The value 1.961 is a rounded version of my experimentally obtained approximation of the BT.709 curve, which resulted in a value of around 1.9610336. This is the closest average match to the source brightness while preserving the nonlinear response of the BT.1886 ideal monitor. For playback in dark environments, it's expected that the gamma shift should be reproduced by a user controlled setting, up to a maximum of 1.224 (2.4/1.961) for a pitch black environment. More information: https://developer.apple.com/library/mac/technotes/tn2257/_index.html
2015-01-13 23:45:31 +00:00
OPT_REMOVED("approx-gamma", "this is always enabled now"),
vo_opengl: rename all scale options to make more sense This emphasizes the fact that scale is used for *all* image upscaling, with cscale only serving a minor role for subsampled material.
2015-01-20 20:46:19 +00:00
OPT_REMOVED("cscale-down", "chroma is never downscaled"),
vo_opengl: remove scale-sep and indirect options These are now auto-detected sanely; and enabled whenever it would be a performance or quality gain (which is pretty much everything except bilinear/bilinear scaling). Perhaps notably, with the absence of scale_sep, there's no more way to use convolution filters on hardware without FBOs, but I don't think there's hardware in existence that doesn't have FBOs but is still fast enough to run the fallback (slow) 2D convolution filters, so I don't think it's a net loss.
2015-01-22 17:24:50 +00:00
OPT_REMOVED("scale-sep", "this is set automatically whenever sane"),
OPT_REMOVED("indirect", "this is set automatically whenever sane"),
vo_opengl: fix srgb replacement options OPT_REPLACED can't specify option values or multiple options. Change to OPT_REMOVED. Also, target-prim doesn't have an srgb option. BT.709 uses sRGB primaries, so use it instead.
2015-03-16 09:17:22 +00:00
OPT_REMOVED("srgb", "use target-prim=bt709:target-trc=srgb instead"),
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
OPT_REMOVED("source-shader", "use :deband to enable debanding"),
vo_opengl: rename all scale options to make more sense This emphasizes the fact that scale is used for *all* image upscaling, with cscale only serving a minor role for subsampled material.
2015-01-20 20:46:19 +00:00
OPT_REPLACED("lscale", "scale"),
OPT_REPLACED("lscale-down", "scale-down"),
OPT_REPLACED("lparam1", "scale-param1"),
OPT_REPLACED("lparam2", "scale-param2"),
OPT_REPLACED("lradius", "scale-radius"),
OPT_REPLACED("lantiring", "scale-antiring"),
OPT_REPLACED("cparam1", "cscale-param1"),
OPT_REPLACED("cparam2", "cscale-param2"),
OPT_REPLACED("cradius", "cscale-radius"),
OPT_REPLACED("cantiring", "cscale-antiring"),
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
OPT_REPLACED("smoothmotion", "interpolation"),
vo_opengl: add oversample support for tscale This is interesting mainly because it's essentially equivalent to the old smoothmotion algorithm. As such, it is now the default for tscale.
2015-03-15 06:11:51 +00:00
OPT_REPLACED("smoothmotion-threshold", "tscale-param1"),
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
OPT_REPLACED("scale-down", "dscale"),
vo_opengl: rename all scale options to make more sense This emphasizes the fact that scale is used for *all* image upscaling, with cscale only serving a minor role for subsampled material.
2015-01-20 20:46: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
{0}
},
.size = sizeof(struct gl_video_opts),
.defaults = &gl_video_opts_def,
};
static void uninit_rendering(struct gl_video *p);
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
static void uninit_scaler(struct gl_video *p, struct scaler *scaler);
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
static void check_gl_features(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
static bool init_format(int fmt, struct gl_video *init);
vo_opengl: simplify After recent changes, there is no reason why gl_video_set_image() should exist anymore. So merge it back into gl_video_upload_image().
2015-07-15 10:22:49 +00:00
static void gl_video_upload_image(struct gl_video *p, struct mp_image *mpi);
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
static void assign_options(struct gl_video_opts *dst, struct gl_video_opts *src);
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
#define GLSL(x) gl_sc_add(p->sc, #x "\n");
#define GLSLF(...) gl_sc_addf(p->sc, __VA_ARGS__)
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: remove requirement for RG textures Features not supported are disabled (although with a misleading error message).
2014-12-16 17:55:02 +00:00
static const struct fmt_entry *find_tex_format(GL *gl, int bytes_per_comp,
int n_channels)
{
assert(bytes_per_comp == 1 || bytes_per_comp == 2);
assert(n_channels >= 1 && n_channels <= 4);
vo_opengl: GLES 3 support Tested with MESA on software emulation. Seems to work well, although the default FBO format in opengl-hq disables most interesting features. I have no idea how well it will work on real hardware (or if it does at all). Unfortunately, some features, including playback of 10 bit video, are not supported. Not sure what to do about this. GLES 2 or 1 do not work.
2014-12-17 20:48:23 +00:00
const struct fmt_entry *fmts = gl_byte_formats;
vo_opengl: add GLES 2 support Rather basic support. Almost nothing works, and even if it does, it's bound to be inefficient (due to texture upload). This was tested with the nVidia desktop binary drivers, which provide GLES 2 support only. However, nVidia is not known to be very strict about OpenGL, and the driver is very new too, so the vo_opengl code will have bugs too.
2014-12-19 00:03:08 +00:00
if (gl->es >= 300) {
vo_opengl: GLES 3 support Tested with MESA on software emulation. Seems to work well, although the default FBO format in opengl-hq disables most interesting features. I have no idea how well it will work on real hardware (or if it does at all). Unfortunately, some features, including playback of 10 bit video, are not supported. Not sure what to do about this. GLES 2 or 1 do not work.
2014-12-17 20:48:23 +00:00
fmts = gl_byte_formats_gles3;
vo_opengl: add GLES 2 support Rather basic support. Almost nothing works, and even if it does, it's bound to be inefficient (due to texture upload). This was tested with the nVidia desktop binary drivers, which provide GLES 2 support only. However, nVidia is not known to be very strict about OpenGL, and the driver is very new too, so the vo_opengl code will have bugs too.
2014-12-19 00:03:08 +00:00
} else if (gl->es) {
fmts = gl_byte_formats_gles2;
vo_opengl: GLES 3 support Tested with MESA on software emulation. Seems to work well, although the default FBO format in opengl-hq disables most interesting features. I have no idea how well it will work on real hardware (or if it does at all). Unfortunately, some features, including playback of 10 bit video, are not supported. Not sure what to do about this. GLES 2 or 1 do not work.
2014-12-17 20:48:23 +00:00
} else if (!(gl->mpgl_caps & MPGL_CAP_TEX_RG)) {
fmts = gl_byte_formats_legacy;
}
vo_opengl: remove requirement for RG textures Features not supported are disabled (although with a misleading error message).
2014-12-16 17:55:02 +00:00
return &fmts[n_channels - 1 + (bytes_per_comp - 1) * 4];
}
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: move shader file caching to video.c It's just about loading and cachign small files, not does not necessarily have anything to do with shaders. Move it to video.c where it's used.
2015-09-23 20:13:03 +00:00
static const char *load_cached_file(struct gl_video *p, const char *path)
{
if (!path || !path[0])
return NULL;
for (int n = 0; n < p->num_files; n++) {
if (strcmp(p->files[n].path, path) == 0)
return p->files[n].body;
}
// not found -> load it
if (p->num_files == MP_ARRAY_SIZE(p->files)) {
// empty cache when it overflows
for (int n = 0; n < p->num_files; n++) {
talloc_free(p->files[n].path);
talloc_free(p->files[n].body);
}
p->num_files = 0;
}
struct bstr s = stream_read_file(path, p, p->global, 100000); // 100 kB
if (s.len) {
struct cached_file *new = &p->files[p->num_files++];
*new = (struct cached_file) {
.path = talloc_strdup(p, path),
.body = s.start
};
return new->body;
}
return NULL;
}
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
static void debug_check_gl(struct gl_video *p, const char *msg)
{
if (p->gl_debug)
gl_common: complete mp_msg conversion Hopefully this works on Wayland and Cocoa, which I didn't test.
2013-09-11 22:57:32 +00:00
glCheckError(p->gl, p->log, msg);
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_set_debug(struct gl_video *p, bool enable)
{
vo_opengl: make use of newer OpenGL logging API GL_ARB_debug_output provides a logging callback, which can be used to diagnose problems etc. in case the driver supports it. It's enabled only if the vo_opengl "debug" suboption is set.
2014-12-23 01:46:44 +00:00
GL *gl = p->gl;
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
p->gl_debug = enable;
vo_opengl: don't unnecessarily call glDebugMessageCallback() We still do redundant calls to it, but obviously we can avoid calling it if we don't want to set a callback at all. May or may not help with default.
2015-01-30 10:12:58 +00:00
if (p->gl->debug_context)
gl_set_debug_logger(gl, enable ? p->log : NULL);
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 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
static void gl_video_reset_surfaces(struct gl_video *p)
{
vo_opengl: correct OSD PTS when using interpolation
2015-03-25 21:40:10 +00:00
for (int i = 0; i < FBOSURFACES_MAX; i++) {
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
p->surfaces[i].pts = MP_NOPTS_VALUE;
vo_opengl: correct OSD PTS when using interpolation
2015-03-25 21:40:10 +00:00
}
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
p->surface_idx = 0;
p->surface_now = 0;
vo_opengl: fix "freezes" after seeking with interpolation on When seeking to a different position, and seeking takes long, the OSD might get redrawn. This means that the VO will receive a request to redraw an old frame using whatever the previous PTS was. This breaks the interpolation logic: the old frame will be added to the queue, and then the next frames (with lower PTS if you seeked backwards) are not drawn as the logic assumes they're past frames. Fix this by using the non-interpolation code path when redrawing after a seek reset, and no "real" frame has been drawn yet. It's a recent regression caused by the redrawing code simplification. The old code simply sent a VOCTRL for redrawing the frame, and the VO had to deal with retaining the old frame on its own. This is a hack as in there's probably a better solution. Fixes #2097.
2015-07-02 11:17:20 +00:00
p->frames_drawn = 0;
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
}
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
static inline int fbosurface_wrap(int id)
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
{
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
id = id % FBOSURFACES_MAX;
return id < 0 ? id + FBOSURFACES_MAX : id;
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
}
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
static void recreate_osd(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
mpgl_osd_destroy(p->osd);
p->osd = NULL;
if (p->osd_state) {
p->osd = mpgl_osd_init(p->gl, p->log, p->osd_state);
mpgl_osd_set_options(p->osd, p->opts.pbo);
}
vo_opengl: change initialization of gamma option Make the lazy gamma initialization less weird, and make the default value of the "gamma" sub-option 1.0. This means --vo=opengl:help will list the actual default value. Also change the lower bound to 0.1 - avoids a division by zero (I don't know how shaders handle NaN, but it's probably not a good idea to give them this value).
2015-02-03 16:12: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
static void reinit_rendering(struct gl_video *p)
{
video/out: use new mp_msg stuff for vo.c and vo_opengl The first step; also serves as example.
2013-07-31 19:44:21 +00:00
MP_VERBOSE(p, "Reinit rendering.\n");
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
debug_check_gl(p, "before scaler initialization");
uninit_rendering(p);
recreate_osd(p);
}
static void uninit_rendering(struct gl_video *p)
{
GL *gl = p->gl;
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
for (int n = 0; n < 4; n++)
uninit_scaler(p, &p->scaler[n]);
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
gl->DeleteTextures(1, &p->dither_texture);
p->dither_texture = 0;
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
vo_opengl: fix uninitialization logic The FBOs we use never actually got cleaned up anywhere, and the vimg planes were hard-coded to only clean up 3.
2015-03-13 23:32:20 +00:00
fbotex_uninit(&p->chroma_merge_fbo);
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
fbotex_uninit(&p->chroma_deband_fbo);
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
fbotex_uninit(&p->indirect_fbo);
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
fbotex_uninit(&p->blend_subs_fbo);
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
fbotex_uninit(&p->unsharp_fbo);
vo_opengl: fix uninitialization logic The FBOs we use never actually got cleaned up anywhere, and the vimg planes were hard-coded to only clean up 3.
2015-03-13 23:32:20 +00:00
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
for (int n = 0; n < 2; n++) {
fbotex_uninit(&p->pre_fbo[n]);
fbotex_uninit(&p->post_fbo[n]);
}
vo_opengl: fix uninitialization logic The FBOs we use never actually got cleaned up anywhere, and the vimg planes were hard-coded to only clean up 3.
2015-03-13 23:32:20 +00:00
for (int n = 0; n < FBOSURFACES_MAX; n++)
fbotex_uninit(&p->surfaces[n].fbotex);
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
gl_video_reset_surfaces(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
}
void gl_video_set_lut3d(struct gl_video *p, struct lut3d *lut3d)
{
GL *gl = p->gl;
vo_opengl: runtime icc profile switching The changes in vo_opengl.c are merely for adding the icc options to the set of options than can be changed with the vo_cmdline command.
2014-03-24 22:30:12 +00:00
if (!lut3d) {
if (p->use_lut_3d) {
p->use_lut_3d = false;
reinit_rendering(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
return;
vo_opengl: runtime icc profile switching The changes in vo_opengl.c are merely for adding the icc options to the set of options than can be changed with the vo_cmdline command.
2014-03-24 22:30:12 +00:00
}
vo_opengl: don't allow setting 3D LUT if unsupported The code was always uploading the 3D LUT (even of unused), as long as vo_opengl was setting a icc-profile. This could crash with GLES 2.
2014-12-23 01:48:58 +00:00
if (!(gl->mpgl_caps & MPGL_CAP_3D_TEX))
return;
vo_opengl: runtime icc profile switching The changes in vo_opengl.c are merely for adding the icc options to the set of options than can be changed with the vo_cmdline command.
2014-03-24 22:30:12 +00:00
if (!p->lut_3d_texture)
gl->GenTextures(1, &p->lut_3d_texture);
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
gl->ActiveTexture(GL_TEXTURE0 + TEXUNIT_3DLUT);
gl->BindTexture(GL_TEXTURE_3D, p->lut_3d_texture);
gl->TexImage3D(GL_TEXTURE_3D, 0, GL_RGB16, lut3d->size[0], lut3d->size[1],
lut3d->size[2], 0, GL_RGB, GL_UNSIGNED_SHORT, lut3d->data);
gl->TexParameteri(GL_TEXTURE_3D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
gl->TexParameteri(GL_TEXTURE_3D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
gl->TexParameteri(GL_TEXTURE_3D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
gl->TexParameteri(GL_TEXTURE_3D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
gl->TexParameteri(GL_TEXTURE_3D, GL_TEXTURE_WRAP_R, GL_CLAMP_TO_EDGE);
gl->ActiveTexture(GL_TEXTURE0);
p->use_lut_3d = true;
check_gl_features(p);
debug_check_gl(p, "after 3d lut creation");
vo_opengl: runtime icc profile switching The changes in vo_opengl.c are merely for adding the icc options to the set of options than can be changed with the vo_cmdline command.
2014-03-24 22:30:12 +00:00
reinit_rendering(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
}
vo_opengl: minor refactor Just making the argument order for pass_load_fbotex more consistent with finish_pass_fbo.
2015-09-05 11:33:48 +00:00
static void pass_load_fbotex(struct gl_video *p, struct fbotex *src_fbo,
int w, int h, int id)
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
{
p->pass_tex[id] = (struct src_tex){
.gl_tex = src_fbo->texture,
.gl_target = GL_TEXTURE_2D,
vo_opengl: don't distinguish "real" and texture size This is from times when we supported padded/non-NPOT textures. The difference is not useful anymore, and theoretical support for different sizes is most likely buggy and unmaintained. So remove it. Also remove the tex_ prefix wherever it appears.
2015-09-02 10:52:11 +00:00
.w = src_fbo->w,
.h = src_fbo->h,
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
.src = {0, 0, w, h},
};
}
static void pass_set_image_textures(struct gl_video *p, struct video_image *vimg,
vo_opengl: replace float array with a struct Slightly less painful, because C arrays suck.
2015-03-13 20:14:18 +00:00
struct gl_transform *chroma)
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
{
vo_opengl: replace float array with a struct Slightly less painful, because C arrays suck.
2015-03-13 20:14:18 +00:00
*chroma = (struct gl_transform){{{0}}};
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
vo_opengl: simplify screenshot code Instead of reading back the image from textures, keep a reference to the original image, and return that. The main reason this was done this way was that originally, images weren't refcounted, and would be deallocated or overwritten as soon as the VO's draw call returned. But now there isn't really a good reason for this anymore. One possibly _could_ argue that it was better because other code could reuse the image sooner (e.g. for the cache), but on the other hand, the VO runs already on a different thread, and filtering and decoding each run on other threads too, so this argument probably wouldn't hold up.
2015-01-22 17:29:37 +00:00
assert(vimg->mpi);
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 ls_w = 1.0 / (1 << p->image_desc.chroma_xs);
float ls_h = 1.0 / (1 << p->image_desc.chroma_ys);
vo_opengl: remove chroma-location suboption Terribly obscure, and vf_format can do this for all VOs.
2015-04-02 21:59:50 +00:00
if (p->image_params.chroma_location != MP_CHROMA_CENTER) {
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
int cx, cy;
vo_opengl: remove chroma-location suboption Terribly obscure, and vf_format can do this for all VOs.
2015-04-02 21:59:50 +00:00
mp_get_chroma_location(p->image_params.chroma_location, &cx, &cy);
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
// By default texture coordinates are such that chroma is centered with
// any chroma subsampling. If a specific direction is given, make it
// so that the luma and chroma sample line up exactly.
// For 4:4:4, setting chroma location should have no effect at all.
// luma sample size (in chroma coord. space)
vo_opengl: replace float array with a struct Slightly less painful, because C arrays suck.
2015-03-13 20:14:18 +00:00
chroma->t[0] = ls_w < 1 ? ls_w * -cx / 2 : 0;
chroma->t[1] = ls_h < 1 ? ls_h * -cy / 2 : 0;
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
}
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
// Make sure luma/chroma sizes are aligned.
// Example: For 4:2:0 with size 3x3, the subsampled chroma plane is 2x2
// so luma (3,3) has to align with chroma (2,2).
vo_opengl: comsetics: remove unnecessary line break
2015-09-07 19:02:16 +00:00
chroma->m[0][0] = ls_w * (float)vimg->planes[0].w / vimg->planes[1].w;
chroma->m[1][1] = ls_h * (float)vimg->planes[0].h / vimg->planes[1].h;
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
vo_opengl: increase the number of video buffers Also the size is now a simple #define that can easily be changed later. This is done for smoothmotion, which might want to blend more than 4 frames at once, depending on the setting.
2015-03-13 12:42:05 +00:00
for (int n = 0; n < p->plane_count; n++) {
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 texplane *t = &vimg->planes[n];
p->pass_tex[n] = (struct src_tex){
vo_opengl: minor cleanup to hwdec texture setting code Instead of special-casing hwdec in the place where the video textures are used, just set the textures in the image upload function. The renderer code doesn't need to know whether hwdec interop is used at all.
2015-07-26 18:13:53 +00:00
.gl_tex = vimg->planes[n].gl_texture,
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
.gl_target = t->gl_target,
vo_opengl: don't distinguish "real" and texture size This is from times when we supported padded/non-NPOT textures. The difference is not useful anymore, and theoretical support for different sizes is most likely buggy and unmaintained. So remove it. Also remove the tex_ prefix wherever it appears.
2015-09-02 10:52:11 +00:00
.w = t->w,
.h = t->h,
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
.src = {0, 0, t->w, t->h},
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
};
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
}
}
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
static void init_video(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
{
GL *gl = p->gl;
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
check_gl_features(p);
vo_opengl: redo aspects of initialization, change hwdec API Instead of checking for resolution and image format changes, always fully reinit on any parameter change. Let init_video do all required initializations, which simplifies things a little bit. Change the gl_video/hardware decoding interop API slightly, so that hwdec initialization gets the full image parameters. Also make some cosmetic changes.
2013-11-05 18:08:44 +00:00
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
init_format(p->image_params.imgfmt, p);
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
p->gl_target = p->opts.use_rectangle ? GL_TEXTURE_RECTANGLE : GL_TEXTURE_2D;
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
if (p->hwdec_active) {
if (p->hwdec->driver->reinit(p->hwdec, &p->image_params) < 0)
MP_ERR(p, "Initializing texture for hardware decoding failed.\n");
init_format(p->image_params.imgfmt, p);
vo_opengl: actually set hardware decoder mapped texture format Surfaces used by hardware decoding formats can be mapped exactly like a specific software pixel format, e.g. RGBA or NV12. p->image_params is supposed to be set to this format, but it wasn't. (How did this ever work?) Also, setting params->imgfmt in the hwdec interop drivers is pointless and redundant. (Change them to asserts, because why not.)
2015-09-24 21:48:57 +00:00
p->image_params.imgfmt = p->image_desc.id;
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
p->gl_target = p->hwdec->gl_texture_target;
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
}
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
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
mp_image_params_guess_csp(&p->image_params);
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
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
p->image_w = p->image_params.w;
p->image_h = p->image_params.h;
vo_opengl: redo aspects of initialization, change hwdec API Instead of checking for resolution and image format changes, always fully reinit on any parameter change. Let init_video do all required initializations, which simplifies things a little bit. Change the gl_video/hardware decoding interop API slightly, so that hwdec initialization gets the full image parameters. Also make some cosmetic changes.
2013-11-05 18:08:44 +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
int eq_caps = MP_CSP_EQ_CAPS_GAMMA;
video: Support BT.2020 constant luminance system Signed-off-by: wm4 <wm4@nowhere>
2014-03-26 22:00:09 +00:00
if (p->is_yuv && p->image_params.colorspace != MP_CSP_BT_2020_C)
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
eq_caps |= MP_CSP_EQ_CAPS_COLORMATRIX;
video: Better support for XYZ input With this change, XYZ input is directly converted to the output colorspace wherever possible, and to the colorspace specified by the tags and/or --primaries option, otherwise. This commit also restructures some of the CMS code in gl_video.c to hopefully make it clearer which decision is being done where and why.
2014-03-31 02:51:47 +00:00
if (p->image_desc.flags & MP_IMGFLAG_XYZ)
eq_caps |= MP_CSP_EQ_CAPS_BRIGHTNESS;
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
p->video_eq.capabilities = eq_caps;
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
av_lfg_init(&p->lfg, 1);
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
debug_check_gl(p, "before video texture creation");
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
struct video_image *vimg = &p->image;
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: slightly simplify plane size determination Setup a dummy image for the given image params, and get the plane sizes from that. Admittedly not much of a simplification, but conceptually it's simpler and less error-prone, as the image layout is guaranteed to be the same, rather than essentially duplicating the way it is determined.
2015-09-02 11:08:18 +00:00
struct mp_image layout = {0};
mp_image_set_params(&layout, &p->image_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
for (int n = 0; n < p->plane_count; n++) {
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
struct texplane *plane = &vimg->planes[n];
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
plane->gl_target = p->gl_target;
vo_opengl: slightly simplify plane size determination Setup a dummy image for the given image params, and get the plane sizes from that. Admittedly not much of a simplification, but conceptually it's simpler and less error-prone, as the image layout is guaranteed to be the same, rather than essentially duplicating the way it is determined.
2015-09-02 11:08:18 +00:00
plane->w = mp_image_plane_w(&layout, n);
plane->h = mp_image_plane_h(&layout, n);
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: some minor cleanups default_tex_params() and texture_size() are each called only once, so move inline/reimplement them at the caller. image_dw/dh were unused. texture_w/h, image_format, and component_bits were rarely used, and can be replaced. Regroup some other fields. Rename surface_num to surface_idx, because the former sounded like a count, and not an index. Move fbosurface_next() closer to its callers too. Move the DebugMessageCallback() code to gl_utils.c (also simplify it by always setting the callback, instead of only when it changes).
2015-01-29 14:50:21 +00:00
if (!p->hwdec_active) {
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
gl->ActiveTexture(GL_TEXTURE0 + n);
gl->GenTextures(1, &plane->gl_texture);
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
gl->BindTexture(p->gl_target, plane->gl_texture);
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: 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
gl->TexImage2D(p->gl_target, 0, plane->gl_internal_format,
vo_opengl: don't distinguish "real" and texture size This is from times when we supported padded/non-NPOT textures. The difference is not useful anymore, and theoretical support for different sizes is most likely buggy and unmaintained. So remove it. Also remove the tex_ prefix wherever it appears.
2015-09-02 10:52:11 +00:00
plane->w, plane->h, 0,
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
plane->gl_format, plane->gl_type, NULL);
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: some minor cleanups default_tex_params() and texture_size() are each called only once, so move inline/reimplement them at the caller. image_dw/dh were unused. texture_w/h, image_format, and component_bits were rarely used, and can be replaced. Regroup some other fields. Rename surface_num to surface_idx, because the former sounded like a count, and not an index. Move fbosurface_next() closer to its callers too. Move the DebugMessageCallback() code to gl_utils.c (also simplify it by always setting the callback, instead of only when it changes).
2015-01-29 14:50:21 +00:00
gl->TexParameteri(p->gl_target, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
gl->TexParameteri(p->gl_target, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
gl->TexParameteri(p->gl_target, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
gl->TexParameteri(p->gl_target, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
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
}
gl_video: make it possible for planes to have different formats Preparation for NV12 support. Also adds support for IMGFMT_YA8.
2013-03-28 19:48:53 +00:00
vo_opengl: don't distinguish "real" and texture size This is from times when we supported padded/non-NPOT textures. The difference is not useful anymore, and theoretical support for different sizes is most likely buggy and unmaintained. So remove it. Also remove the tex_ prefix wherever it appears.
2015-09-02 10:52:11 +00:00
MP_VERBOSE(p, "Texture for plane %d: %dx%d\n", n, plane->w, plane->h);
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
}
gl->ActiveTexture(GL_TEXTURE0);
debug_check_gl(p, "after video texture creation");
reinit_rendering(p);
}
static void uninit_video(struct gl_video *p)
{
GL *gl = p->gl;
uninit_rendering(p);
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
struct video_image *vimg = &p->image;
vo_opengl: fix uninitialization logic The FBOs we use never actually got cleaned up anywhere, and the vimg planes were hard-coded to only clean up 3.
2015-03-13 23:32:20 +00:00
for (int n = 0; n < p->plane_count; n++) {
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
struct texplane *plane = &vimg->planes[n];
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: minor cleanup to hwdec texture setting code Instead of special-casing hwdec in the place where the video textures are used, just set the textures in the image upload function. The renderer code doesn't need to know whether hwdec interop is used at all.
2015-07-26 18:13:53 +00:00
if (!p->hwdec_active)
gl->DeleteTextures(1, &plane->gl_texture);
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
plane->gl_texture = 0;
gl->DeleteBuffers(1, &plane->gl_buffer);
plane->gl_buffer = 0;
}
vo_opengl: simplify screenshot code Instead of reading back the image from textures, keep a reference to the original image, and return that. The main reason this was done this way was that originally, images weren't refcounted, and would be deallocated or overwritten as soon as the VO's draw call returned. But now there isn't really a good reason for this anymore. One possibly _could_ argue that it was better because other code could reuse the image sooner (e.g. for the cache), but on the other hand, the VO runs already on a different thread, and filtering and decoding each run on other threads too, so this argument probably wouldn't hold up.
2015-01-22 17:29:37 +00:00
mp_image_unrefp(&vimg->mpi);
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
gl_video.c: invalidate image_params in uninit_video() When the given mp_image_params does not match with that of gl_video, gl_video_config() always calls uninit_video() but calls init_video() only if valid format is given. Since uninit_video() does not change image_params of gl_video, when the same params as the previous one is given to gl_video_config() after gl_video is unitialized with invalid format, gl_video_config() never calls init_video(). To prevent this, invalidate image_params of gl_video in uninit_video().
2015-01-07 18:00:26 +00:00
// Invalidate image_params to ensure that gl_video_config() will call
// init_video() on uninitialized gl_video.
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
p->real_image_params = (struct mp_image_params){0};
p->image_params = p->real_image_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 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
static void pass_prepare_src_tex(struct gl_video *p)
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
{
GL *gl = p->gl;
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 gl_shader_cache *sc = p->sc;
vo_opengl: increase the number of video buffers Also the size is now a simple #define that can easily be changed later. This is done for smoothmotion, which might want to blend more than 4 frames at once, depending on the setting.
2015-03-13 12:42:05 +00:00
for (int n = 0; n < TEXUNIT_VIDEO_NUM; n++) {
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 src_tex *s = &p->pass_tex[n];
if (!s->gl_tex)
continue;
char texture_name[32];
char texture_size[32];
snprintf(texture_name, sizeof(texture_name), "texture%d", n);
snprintf(texture_size, sizeof(texture_size), "texture_size%d", n);
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
gl_sc_uniform_sampler(sc, texture_name, s->gl_target, n);
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
float f[2] = {1, 1};
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
if (s->gl_target != GL_TEXTURE_RECTANGLE) {
vo_opengl: don't distinguish "real" and texture size This is from times when we supported padded/non-NPOT textures. The difference is not useful anymore, and theoretical support for different sizes is most likely buggy and unmaintained. So remove it. Also remove the tex_ prefix wherever it appears.
2015-09-02 10:52:11 +00:00
f[0] = s->w;
f[1] = s->h;
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
}
gl_sc_uniform_vec2(sc, texture_size, f);
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
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
gl->ActiveTexture(GL_TEXTURE0 + n);
gl->BindTexture(s->gl_target, s->gl_tex);
}
gl->ActiveTexture(GL_TEXTURE0);
}
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
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
// flags = bits 0-1: rotate, bit 2: flip vertically
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
static void render_pass_quad(struct gl_video *p, int vp_w, int vp_h,
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
const struct mp_rect *dst, int flags)
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 vertex va[4];
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
vo_opengl: replace float array with a struct Slightly less painful, because C arrays suck.
2015-03-13 20:14:18 +00:00
struct gl_transform t;
gl_transform_ortho(&t, 0, vp_w, 0, vp_h);
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
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
float x[2] = {dst->x0, dst->x1};
float y[2] = {dst->y0, dst->y1};
vo_opengl: replace float array with a struct Slightly less painful, because C arrays suck.
2015-03-13 20:14:18 +00:00
gl_transform_vec(t, &x[0], &y[0]);
gl_transform_vec(t, &x[1], &y[1]);
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
for (int n = 0; n < 4; n++) {
struct vertex *v = &va[n];
v->position.x = x[n / 2];
v->position.y = y[n % 2];
vo_opengl: increase the number of video buffers Also the size is now a simple #define that can easily be changed later. This is done for smoothmotion, which might want to blend more than 4 frames at once, depending on the setting.
2015-03-13 12:42:05 +00:00
for (int i = 0; i < TEXUNIT_VIDEO_NUM; i++) {
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 src_tex *s = &p->pass_tex[i];
if (s->gl_tex) {
float tx[2] = {s->src.x0, s->src.x1};
float ty[2] = {s->src.y0, s->src.y1};
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
if (flags & 4)
MPSWAP(float, ty[0], ty[1]);
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
bool rect = s->gl_target == GL_TEXTURE_RECTANGLE;
vo_opengl: don't distinguish "real" and texture size This is from times when we supported padded/non-NPOT textures. The difference is not useful anymore, and theoretical support for different sizes is most likely buggy and unmaintained. So remove it. Also remove the tex_ prefix wherever it appears.
2015-09-02 10:52:11 +00:00
v->texcoord[i].x = tx[n / 2] / (rect ? 1 : s->w);
v->texcoord[i].y = ty[n % 2] / (rect ? 1 : s->h);
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
}
}
}
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
int rot = flags & 3;
while (rot--) {
static const int perm[4] = {1, 3, 0, 2};
struct vertex vb[4];
memcpy(vb, va, sizeof(vb));
for (int n = 0; n < 4; n++)
memcpy(va[n].texcoord, vb[perm[n]].texcoord,
vo_opengl: increase the number of video buffers Also the size is now a simple #define that can easily be changed later. This is done for smoothmotion, which might want to blend more than 4 frames at once, depending on the setting.
2015-03-13 12:42:05 +00:00
sizeof(struct vertex_pt[TEXUNIT_VIDEO_NUM]));
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
}
vo_opengl: move glViewport call closer to draw call
2015-03-16 19:10:48 +00:00
p->gl->Viewport(0, 0, vp_w, abs(vp_h));
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
gl_vao_draw_data(&p->vao, GL_TRIANGLE_STRIP, va, 4);
debug_check_gl(p, "after rendering");
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
}
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
// flags: see render_pass_quad
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
static void finish_pass_direct(struct gl_video *p, GLint fbo, int vp_w, int vp_h,
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
const struct mp_rect *dst, int flags)
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
{
GL *gl = p->gl;
pass_prepare_src_tex(p);
gl->BindFramebuffer(GL_FRAMEBUFFER, fbo);
gl_sc_gen_shader_and_reset(p->sc);
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
render_pass_quad(p, vp_w, vp_h, dst, flags);
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
gl->BindFramebuffer(GL_FRAMEBUFFER, 0);
memset(&p->pass_tex, 0, sizeof(p->pass_tex));
}
// dst_fbo: this will be used for rendering; possibly reallocating the whole
// FBO, if the required parameters have changed
// w, h: required FBO target dimension, and also defines the target rectangle
// used for rasterization
vo_opengl: minor fix to a comment
2015-03-13 10:53:54 +00:00
// tex: the texture unit to load the result back into
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
// flags: 0 or combination of FBOTEX_FUZZY_W/FBOTEX_FUZZY_H (setting the fuzzy
vo_opengl: minor fix to a comment
2015-03-13 10:53:54 +00:00
// flags allows the FBO to be larger than the w/h parameters)
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
static void finish_pass_fbo(struct gl_video *p, struct fbotex *dst_fbo,
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
int w, int h, int tex, int flags)
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
{
fbotex_change(dst_fbo, p->gl, p->log, w, h, p->opts.fbo_format, flags);
vo_opengl: don't distinguish "real" and texture size This is from times when we supported padded/non-NPOT textures. The difference is not useful anymore, and theoretical support for different sizes is most likely buggy and unmaintained. So remove it. Also remove the tex_ prefix wherever it appears.
2015-09-02 10:52:11 +00:00
finish_pass_direct(p, dst_fbo->fbo, dst_fbo->w, dst_fbo->h,
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
&(struct mp_rect){0, 0, w, h}, 0);
vo_opengl: minor refactor Just making the argument order for pass_load_fbotex more consistent with finish_pass_fbo.
2015-09-05 11:33:48 +00:00
pass_load_fbotex(p, dst_fbo, w, h, tex);
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
}
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
static void uninit_scaler(struct gl_video *p, struct scaler *scaler)
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
{
GL *gl = p->gl;
vo_opengl: fix uninitialization logic The FBOs we use never actually got cleaned up anywhere, and the vimg planes were hard-coded to only clean up 3.
2015-03-13 23:32:20 +00:00
fbotex_uninit(&scaler->sep_fbo);
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
gl->DeleteTextures(1, &scaler->gl_lut);
scaler->gl_lut = 0;
scaler->kernel = NULL;
scaler->initialized = false;
}
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
static void load_shader(struct gl_video *p, const char *body)
{
gl_sc_hadd(p->sc, body);
gl_sc_uniform_f(p->sc, "random", (double)av_lfg_get(&p->lfg) / UINT32_MAX);
gl_sc_uniform_f(p->sc, "frame", p->frames_uploaded);
gl_sc_uniform_vec2(p->sc, "image_size", (GLfloat[]){p->image_w, p->image_h});
}
// Applies an arbitrary number of shaders in sequence, using the given pair
// of FBOs as intermediate buffers. Returns whether any shaders were applied.
static bool apply_shaders(struct gl_video *p, char **shaders,
vo_opengl: don't distinguish "real" and texture size This is from times when we supported padded/non-NPOT textures. The difference is not useful anymore, and theoretical support for different sizes is most likely buggy and unmaintained. So remove it. Also remove the tex_ prefix wherever it appears.
2015-09-02 10:52:11 +00:00
struct fbotex textures[2], int tex_num, int w, int h)
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
{
if (!shaders)
return false;
bool success = false;
int tex = 0;
for (int n = 0; shaders[n]; n++) {
vo_opengl: move shader file caching to video.c It's just about loading and cachign small files, not does not necessarily have anything to do with shaders. Move it to video.c where it's used.
2015-09-23 20:13:03 +00:00
const char *body = load_cached_file(p, shaders[n]);
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
if (!body)
continue;
vo_opengl: don't distinguish "real" and texture size This is from times when we supported padded/non-NPOT textures. The difference is not useful anymore, and theoretical support for different sizes is most likely buggy and unmaintained. So remove it. Also remove the tex_ prefix wherever it appears.
2015-09-02 10:52:11 +00:00
finish_pass_fbo(p, &textures[tex], w, h, tex_num, 0);
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
load_shader(p, body);
GLSLF("// custom shader\n");
GLSLF("vec4 color = sample(texture%d, texcoord%d, texture_size%d);\n",
tex_num, tex_num, tex_num);
tex = (tex+1) % 2;
success = true;
}
return success;
}
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
// Semantic equality
static bool double_seq(double a, double b)
{
return (isnan(a) && isnan(b)) || a == b;
}
static bool scaler_fun_eq(struct scaler_fun a, struct scaler_fun b)
{
if ((a.name && !b.name) || (b.name && !a.name))
return false;
return ((!a.name && !b.name) || strcmp(a.name, b.name) == 0) &&
double_seq(a.params[0], b.params[0]) &&
double_seq(a.params[1], b.params[1]) &&
a.blur == b.blur;
}
static bool scaler_conf_eq(struct scaler_config a, struct scaler_config b)
{
// Note: antiring isn't compared because it doesn't affect LUT
// generation
return scaler_fun_eq(a.kernel, b.kernel) &&
scaler_fun_eq(a.window, b.window) &&
vo_opengl: add tscale-clamp option This significantly reduces the amount of noticeable flashing when using tscale kernels with negative lobes, by cutting them off completely. I'm not sure if this has any negative effects. It needs a bit of subjective testing over a period of time, so I just made it an option. Fixes #2155.
2015-08-20 19:45:58 +00:00
a.radius == b.radius &&
a.clamp == b.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
}
static void reinit_scaler(struct gl_video *p, struct scaler *scaler,
const struct scaler_config *conf,
double scale_factor,
int sizes[])
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
{
GL *gl = p->gl;
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
if (scaler_conf_eq(scaler->conf, *conf) &&
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
scaler->scale_factor == scale_factor &&
scaler->initialized)
vo_opengl: clean up rendering path Shuffle the special cases around so that it looks cleaner. The result should be equivalent to the code before.
2014-04-20 19:30:23 +00:00
return;
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
uninit_scaler(p, scaler);
vo_opengl: clean up rendering path Shuffle the special cases around so that it looks cleaner. The result should be equivalent to the code before.
2014-04-20 19:30:23 +00:00
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
scaler->conf = *conf;
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
scaler->scale_factor = scale_factor;
scaler->insufficient = false;
scaler->initialized = true;
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 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
const struct filter_kernel *t_kernel = mp_find_filter_kernel(conf->kernel.name);
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
if (!t_kernel)
return;
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 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
scaler->kernel_storage = *t_kernel;
scaler->kernel = &scaler->kernel_storage;
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 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
const char *win = conf->window.name;
vo_opengl: separate kernel and window This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
if (!win || !win[0])
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
win = t_kernel->window; // fall back to the scaler's default window
vo_opengl: separate kernel and window This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
const struct filter_window *t_window = mp_find_filter_window(win);
if (t_window)
scaler->kernel->w = *t_window;
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
for (int n = 0; n < 2; n++) {
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
if (!isnan(conf->kernel.params[n]))
scaler->kernel->f.params[n] = conf->kernel.params[n];
if (!isnan(conf->window.params[n]))
scaler->kernel->w.params[n] = conf->window.params[n];
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
}
vo_opengl: support rotation This turned out much more complicated than I thought. It's not just a matter of adjusting the texture coordinates, but you also have to consider separated scaling and panscan clipping, which make everything complicated. This actually still doesn't clip 100% correctly, but the bug is only visible when rotating (or flipping with --vf=flip), and using something like --video-pan-x/y at the same time.
2014-04-20 19:37:18 +00:00
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
if (conf->kernel.blur > 0.0)
scaler->kernel->f.blur = conf->kernel.blur;
if (conf->window.blur > 0.0)
scaler->kernel->w.blur = conf->window.blur;
vo_opengl: clean up rendering path Shuffle the special cases around so that it looks cleaner. The result should be equivalent to the code before.
2014-04-20 19:30:23 +00:00
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
if (scaler->kernel->f.resizable && conf->radius > 0.0)
scaler->kernel->f.radius = conf->radius;
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
vo_opengl: add tscale-clamp option This significantly reduces the amount of noticeable flashing when using tscale kernels with negative lobes, by cutting them off completely. I'm not sure if this has any negative effects. It needs a bit of subjective testing over a period of time, so I just made it an option. Fixes #2155.
2015-08-20 19:45:58 +00:00
scaler->kernel->clamp = conf->clamp;
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
scaler->insufficient = !mp_init_filter(scaler->kernel, sizes, scale_factor);
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
if (scaler->kernel->polar) {
scaler->gl_target = GL_TEXTURE_1D;
} else {
scaler->gl_target = GL_TEXTURE_2D;
}
int size = scaler->kernel->size;
int elems_per_pixel = 4;
if (size == 1) {
elems_per_pixel = 1;
} else if (size == 2) {
elems_per_pixel = 2;
} else if (size == 6) {
elems_per_pixel = 3;
}
int width = size / elems_per_pixel;
assert(size == width * elems_per_pixel);
const struct fmt_entry *fmt = &gl_float16_formats[elems_per_pixel - 1];
GLenum target = scaler->gl_target;
gl->ActiveTexture(GL_TEXTURE0 + TEXUNIT_SCALERS + scaler->index);
if (!scaler->gl_lut)
gl->GenTextures(1, &scaler->gl_lut);
gl->BindTexture(target, scaler->gl_lut);
float *weights = talloc_array(NULL, float, LOOKUP_TEXTURE_SIZE * size);
mp_compute_lut(scaler->kernel, LOOKUP_TEXTURE_SIZE, weights);
if (target == GL_TEXTURE_1D) {
gl->TexImage1D(target, 0, fmt->internal_format, LOOKUP_TEXTURE_SIZE,
0, fmt->format, GL_FLOAT, weights);
} else {
gl->TexImage2D(target, 0, fmt->internal_format, width, LOOKUP_TEXTURE_SIZE,
0, fmt->format, GL_FLOAT, weights);
}
talloc_free(weights);
gl->TexParameteri(target, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
gl->TexParameteri(target, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
gl->TexParameteri(target, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
if (target != GL_TEXTURE_1D)
gl->TexParameteri(target, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
gl->ActiveTexture(GL_TEXTURE0);
debug_check_gl(p, "after initializing scaler");
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: 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
// Special helper for sampling from two separated stages
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
static void pass_sample_separated(struct gl_video *p, int src_tex,
struct scaler *scaler, int w, int h,
vo_opengl: replace float array with a struct Slightly less painful, because C arrays suck.
2015-03-13 20:14:18 +00:00
struct gl_transform transform)
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
{
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
// Keep the x components untouched for the first pass
vo_opengl: sample from the right tex for separated scalers These were still hard-coded to texture0, rather than respecting src_tex like they should. A simple oversight.
2015-03-12 23:36:11 +00:00
struct mp_rect_f src_new = p->pass_tex[src_tex].src;
vo_opengl: replace float array with a struct Slightly less painful, because C arrays suck.
2015-03-13 20:14:18 +00:00
gl_transform_rect(transform, &src_new);
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
GLSLF("// pass 1\n");
vo_opengl: sample from the right tex for separated scalers These were still hard-coded to texture0, rather than respecting src_tex like they should. A simple oversight.
2015-03-12 23:36:11 +00:00
p->pass_tex[src_tex].src.y0 = src_new.y0;
p->pass_tex[src_tex].src.y1 = src_new.y1;
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
pass_sample_separated_gen(p->sc, scaler, 0, 1);
vo_opengl: sample from the right tex for separated scalers These were still hard-coded to texture0, rather than respecting src_tex like they should. A simple oversight.
2015-03-12 23:36:11 +00:00
int src_w = p->pass_tex[src_tex].src.x1 - p->pass_tex[src_tex].src.x0;
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
finish_pass_fbo(p, &scaler->sep_fbo, src_w, h, src_tex, FBOTEX_FUZZY_H);
// Restore the sample source for the second pass
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
sampler_prelude(p->sc, src_tex);
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
GLSLF("// pass 2\n");
vo_opengl: sample from the right tex for separated scalers These were still hard-coded to texture0, rather than respecting src_tex like they should. A simple oversight.
2015-03-12 23:36:11 +00:00
p->pass_tex[src_tex].src.x0 = src_new.x0;
p->pass_tex[src_tex].src.x1 = src_new.x1;
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
pass_sample_separated_gen(p->sc, scaler, 1, 0);
vo_opengl: add oversample scaler This is like nearest neighbour, but the edges between pixels are linearly interpolating if needed, as if they had been (naively) oversampled.
2015-03-15 05:27:11 +00:00
}
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
// Sample. This samples from the texture ID given by src_tex. It's hardcoded to
// use all variables and values associated with it (which includes textureN,
// texcoordN and texture_sizeN).
// The src rectangle is implicit in p->pass_tex + transform.
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
// The dst rectangle is implicit by what the caller will do next, but w and h
// must still be what is going to be used (to dimension FBOs correctly).
// This will declare "vec4 color;", which contains the scaled contents.
// The scaler unit is initialized by this function; in order to avoid cache
// thrashing, the scaler unit should usually use the same parameters.
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
static void pass_sample(struct gl_video *p, int src_tex, struct scaler *scaler,
const struct scaler_config *conf, double scale_factor,
vo_opengl: replace float array with a struct Slightly less painful, because C arrays suck.
2015-03-13 20:14:18 +00:00
int w, int h, struct gl_transform transform)
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
{
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
reinit_scaler(p, scaler, conf, scale_factor, filter_sizes);
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
sampler_prelude(p->sc, src_tex);
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
// Set up the transformation for everything other than separated scaling
if (!scaler->kernel || scaler->kernel->polar)
vo_opengl: replace float array with a struct Slightly less painful, because C arrays suck.
2015-03-13 20:14:18 +00:00
gl_transform_rect(transform, &p->pass_tex[src_tex].src);
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
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
// Dispatch the scaler. They're all wildly different.
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
const char *name = scaler->conf.kernel.name;
if (strcmp(name, "bilinear") == 0) {
vo_opengl: simplify sampler prelude This moves common re-definitions to a custom function and also shortens the names to make stuff less verbose in general.
2015-03-24 08:43:06 +00:00
GLSL(vec4 color = texture(tex, pos);)
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
} else if (strcmp(name, "bicubic_fast") == 0) {
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
pass_sample_bicubic_fast(p->sc);
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
} else if (strcmp(name, "oversample") == 0) {
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
pass_sample_oversample(p->sc, scaler, w, h);
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
} else if (strcmp(name, "custom") == 0) {
vo_opengl: move shader file caching to video.c It's just about loading and cachign small files, not does not necessarily have anything to do with shaders. Move it to video.c where it's used.
2015-09-23 20:13:03 +00:00
const char *body = load_cached_file(p, p->opts.scale_shader);
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
if (body) {
load_shader(p, body);
GLSLF("// custom scale-shader\n");
GLSL(vec4 color = sample(tex, pos, size);)
} else {
p->opts.scale_shader = NULL;
}
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
} else if (scaler->kernel && scaler->kernel->polar) {
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
pass_sample_polar(p->sc, scaler);
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
} else if (scaler->kernel) {
pass_sample_separated(p, src_tex, scaler, w, h, transform);
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
} else {
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
// Should never happen
abort();
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
}
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
// Micro-optimization: Avoid scaling unneeded channels
if (!p->has_alpha || p->opts.alpha_mode != 1)
GLSL(color.a = 1.0;)
vo_opengl: some minor cleanups default_tex_params() and texture_size() are each called only once, so move inline/reimplement them at the caller. image_dw/dh were unused. texture_w/h, image_format, and component_bits were rarely used, and can be replaced. Regroup some other fields. Rename surface_num to surface_idx, because the former sounded like a count, and not an index. Move fbosurface_next() closer to its callers too. Move the DebugMessageCallback() code to gl_utils.c (also simplify it by always setting the callback, instead of only when it changes).
2015-01-29 14:50:21 +00:00
}
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
// sample from video textures, set "color" variable to yuv value
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
static void pass_read_video(struct gl_video *p)
vo_opengl: greatly increase smoothmotion performance Instead of rendering and upscaling each video frame on every vsync, this version of the algorithm only draws them once and caches the result, so the only operation that has to run on every vsync is a cheap linear interpolation, plus CMS/dithering. On my machine, this is a huge speedup for 24 Hz content (on a 60 Hz monitor), up to 120% faster. (The speedup is not quite 250% because of the overhead that the larger FBOs and CMS provides) In terms of the implementation, this commit basically swaps interpolation and upscaling - upscaling is moved to inter_program, and interpolation is moved to the final_program. Furthermore, the main bulk of the frame rendering logic (upscaling etc.) was moved to a separete function, which is called from gl_video_interpolate_frame only if it's actually necessarily, and skipped otherwise.
2015-02-20 21:12:02 +00:00
{
vo_opengl: replace float array with a struct Slightly less painful, because C arrays suck.
2015-03-13 20:14:18 +00:00
struct gl_transform chromafix;
pass_set_image_textures(p, &p->image, &chromafix);
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
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
int in_bits = p->image_desc.component_bits,
tx_bits = (in_bits + 7) & ~7;
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
float tex_mul = ((1 << tx_bits) - 1.0) / ((1 << in_bits) - 1.0);
bool color_defined = false;
if (p->plane_count > 1) {
// Chroma processing (merging -> debanding -> scaling)
struct src_tex luma = p->pass_tex[0];
struct src_tex alpha = p->pass_tex[3];
int c_w = p->pass_tex[1].src.x1 - p->pass_tex[1].src.x0;
int c_h = p->pass_tex[1].src.y1 - p->pass_tex[1].src.y0;
const struct scaler_config *cscale = &p->opts.scaler[2];
bool merged = false;
if (p->plane_count > 2) {
// For simplicity and performance, we merge the chroma planes
// into a single texture before scaling or debanding, so the shader
// doesn't need to run multiple times.
GLSLF("// chroma merging\n");
GLSL(vec4 color = vec4(texture(texture1, texcoord1).x,
texture(texture2, texcoord2).x,
0.0, 1.0);)
// We also pull up to the full dynamic range of the texture to avoid
// heavy clipping when using low-bit-depth FBOs
GLSLF("color.xy *= %f;\n", tex_mul);
assert(c_w == p->pass_tex[2].src.x1 - p->pass_tex[2].src.x0);
assert(c_h == p->pass_tex[2].src.y1 - p->pass_tex[2].src.y0);
finish_pass_fbo(p, &p->chroma_merge_fbo, c_w, c_h, 1, 0);
p->use_normalized_range = true;
merged = true;
}
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
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
if (p->opts.deband) {
vo_opengl: fix shader compilation with debanding and OSX hwdec 2 things are being stupid here: Apple for requiring rectangle textures with their IOSurface interop for no reason, and OpenGL having a different sampler type for rectangle textures.
2015-09-10 18:53:47 +00:00
pass_sample_deband(p->sc, p->opts.deband_opts, 1, p->gl_target,
merged ? 1.0 : tex_mul, p->image_w, p->image_h,
&p->lfg);
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
GLSL(color.zw = vec2(0.0, 1.0);) // skip unused
finish_pass_fbo(p, &p->chroma_deband_fbo, c_w, c_h, 1, 0);
p->use_normalized_range = true;
}
vo_opengl: fix source-shader + XYZ input
2015-04-12 01:34:38 +00:00
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
// Sample either directly or by upscaling
if (p->image_desc.flags & MP_IMGFLAG_SUBSAMPLED) {
GLSLF("// chroma scaling\n");
pass_sample(p, 1, &p->scaler[2], cscale, 1.0,
p->image_w, p->image_h, chromafix);
GLSL(vec2 chroma = color.xy;)
color_defined = true; // pass_sample defines vec4 color
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
} else {
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
GLSL(vec2 chroma = texture(texture1, texcoord1).xy;)
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
}
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
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
p->pass_tex[0] = luma; // Restore the luma and alpha planes
p->pass_tex[3] = alpha;
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
}
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
// As an unfortunate side-effect of re-using the vec4 color constant in
// both the luma and chroma stages, vec4 color may or may not be defined
// at this point. If it's missing, define it since the code from here on
// relies on it.
if (!color_defined)
GLSL(vec4 color;)
// Sample the main (luma/RGB) plane. This is inside a sub-block to avoid
// colliding with the vec4 color that may be left over from the chroma
// stuff
GLSL(vec4 main;)
GLSLF("{\n");
if (p->opts.deband) {
vo_opengl: fix shader compilation with debanding and OSX hwdec 2 things are being stupid here: Apple for requiring rectangle textures with their IOSurface interop for no reason, and OpenGL having a different sampler type for rectangle textures.
2015-09-10 18:53:47 +00:00
pass_sample_deband(p->sc, p->opts.deband_opts, 0, p->gl_target, tex_mul,
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
p->image_w, p->image_h, &p->lfg);
p->use_normalized_range = true;
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
} else {
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
GLSL(vec4 color = texture(texture0, texcoord0);)
vo_opengl: rename use_full_range to use_normalized_range As suggested by haasn. The term "full range" makes it sound like it has to do with TV vs. PC range, which is not the case at all.
2015-05-27 15:40:58 +00:00
if (p->use_normalized_range)
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
GLSLF("color *= %f;\n", tex_mul);
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
}
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
GLSL(main = color;)
GLSLF("}\n");
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
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
// Set up the right combination of planes
GLSL(color = main;)
if (p->plane_count > 1)
GLSL(color.yz = chroma;)
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
if (p->has_alpha && p->plane_count >= 4) {
vo_opengl: apply alpha after conversion to rgb Currently this was done before conversion, which could fuck up a hypothetical YUVA stream.
2015-03-13 20:29:04 +00:00
GLSL(color.a = texture(texture3, texcoord3).r;)
vo_opengl: rename use_full_range to use_normalized_range As suggested by haasn. The term "full range" makes it sound like it has to do with TV vs. PC range, which is not the case at all.
2015-05-27 15:40:58 +00:00
if (p->use_normalized_range)
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
GLSLF("color.a *= %f;\n", tex_mul);
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
}
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
}
// yuv conversion, and any other conversions before main up/down-scaling
static void pass_convert_yuv(struct gl_video *p)
{
struct gl_shader_cache *sc = p->sc;
vo_opengl: greatly increase smoothmotion performance Instead of rendering and upscaling each video frame on every vsync, this version of the algorithm only draws them once and caches the result, so the only operation that has to run on every vsync is a cheap linear interpolation, plus CMS/dithering. On my machine, this is a huge speedup for 24 Hz content (on a 60 Hz monitor), up to 120% faster. (The speedup is not quite 250% because of the overhead that the larger FBOs and CMS provides) In terms of the implementation, this commit basically swaps interpolation and upscaling - upscaling is moved to inter_program, and interpolation is moved to the final_program. Furthermore, the main bulk of the frame rendering logic (upscaling etc.) was moved to a separete function, which is called from gl_video_interpolate_frame only if it's actually necessarily, and skipped otherwise.
2015-02-20 21:12:02 +00:00
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
struct mp_csp_params cparams = MP_CSP_PARAMS_DEFAULTS;
cparams.gray = p->is_yuv && !p->is_packed_yuv && p->plane_count == 1;
cparams.input_bits = p->image_desc.component_bits;
cparams.texture_bits = (cparams.input_bits + 7) & ~7;
mp_csp_set_image_params(&cparams, &p->image_params);
mp_csp_copy_equalizer_values(&cparams, &p->video_eq);
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
p->user_gamma = 1.0 / (cparams.gamma * p->opts.gamma);
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
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
GLSLF("// color conversion\n");
vo_opengl: greatly increase smoothmotion performance Instead of rendering and upscaling each video frame on every vsync, this version of the algorithm only draws them once and caches the result, so the only operation that has to run on every vsync is a cheap linear interpolation, plus CMS/dithering. On my machine, this is a huge speedup for 24 Hz content (on a 60 Hz monitor), up to 120% faster. (The speedup is not quite 250% because of the overhead that the larger FBOs and CMS provides) In terms of the implementation, this commit basically swaps interpolation and upscaling - upscaling is moved to inter_program, and interpolation is moved to the final_program. Furthermore, the main bulk of the frame rendering logic (upscaling etc.) was moved to a separete function, which is called from gl_video_interpolate_frame only if it's actually necessarily, and skipped otherwise.
2015-02-20 21:12:02 +00:00
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
if (p->color_swizzle[0])
GLSLF("color = color.%s;\n", p->color_swizzle);
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
// Pre-colormatrix input gamma correction
if (p->image_desc.flags & MP_IMGFLAG_XYZ) {
cparams.colorspace = MP_CSP_XYZ;
// Pre-colormatrix input gamma correction. Note that this results in
// linear light
vo_opengl: fix XYZ input gamma This seems to have been a mistranslation from the original code, which multiplied the gamma by 2.6 (*not* the color itself).
2015-03-21 06:47:42 +00:00
GLSL(color.rgb = pow(color.rgb, vec3(2.6));)
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
}
vo_opengl: greatly increase smoothmotion performance Instead of rendering and upscaling each video frame on every vsync, this version of the algorithm only draws them once and caches the result, so the only operation that has to run on every vsync is a cheap linear interpolation, plus CMS/dithering. On my machine, this is a huge speedup for 24 Hz content (on a 60 Hz monitor), up to 120% faster. (The speedup is not quite 250% because of the overhead that the larger FBOs and CMS provides) In terms of the implementation, this commit basically swaps interpolation and upscaling - upscaling is moved to inter_program, and interpolation is moved to the final_program. Furthermore, the main bulk of the frame rendering logic (upscaling etc.) was moved to a separete function, which is called from gl_video_interpolate_frame only if it's actually necessarily, and skipped otherwise.
2015-02-20 21:12:02 +00:00
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
// Something already took care of expansion
vo_opengl: rename use_full_range to use_normalized_range As suggested by haasn. The term "full range" makes it sound like it has to do with TV vs. PC range, which is not the case at all.
2015-05-27 15:40:58 +00:00
if (p->use_normalized_range)
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
cparams.input_bits = cparams.texture_bits;
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
// Conversion from Y'CbCr or other linear spaces to RGB
if (!p->is_rgb) {
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_cmat m = {{{0}}};
if (p->image_desc.flags & MP_IMGFLAG_XYZ) {
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
struct mp_csp_primaries csp = mp_get_csp_primaries(p->image_params.primaries);
mp_get_xyz2rgb_coeffs(&cparams, csp, MP_INTENT_RELATIVE_COLORIMETRIC, &m);
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
} else {
mp_get_yuv2rgb_coeffs(&cparams, &m);
}
gl_sc_uniform_mat3(sc, "colormatrix", true, &m.m[0][0]);
gl_sc_uniform_vec3(sc, "colormatrix_c", m.c);
vo_opengl: greatly increase smoothmotion performance Instead of rendering and upscaling each video frame on every vsync, this version of the algorithm only draws them once and caches the result, so the only operation that has to run on every vsync is a cheap linear interpolation, plus CMS/dithering. On my machine, this is a huge speedup for 24 Hz content (on a 60 Hz monitor), up to 120% faster. (The speedup is not quite 250% because of the overhead that the larger FBOs and CMS provides) In terms of the implementation, this commit basically swaps interpolation and upscaling - upscaling is moved to inter_program, and interpolation is moved to the final_program. Furthermore, the main bulk of the frame rendering logic (upscaling etc.) was moved to a separete function, which is called from gl_video_interpolate_frame only if it's actually necessarily, and skipped otherwise.
2015-02-20 21:12:02 +00:00
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
GLSL(color.rgb = mat3(colormatrix) * color.rgb + colormatrix_c;)
}
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
if (p->image_params.colorspace == MP_CSP_BT_2020_C) {
// Conversion for C'rcY'cC'bc via the BT.2020 CL system:
// C'bc = (B'-Y'c) / 1.9404 | C'bc <= 0
// = (B'-Y'c) / 1.5816 | C'bc > 0
//
// C'rc = (R'-Y'c) / 1.7184 | C'rc <= 0
// = (R'-Y'c) / 0.9936 | C'rc > 0
//
// as per the BT.2020 specification, table 4. This is a non-linear
// transformation because (constant) luminance receives non-equal
// contributions from the three different channels.
GLSLF("// constant luminance conversion\n");
GLSL(color.br = color.br * mix(vec2(1.5816, 0.9936),
vec2(1.9404, 1.7184),
lessThanEqual(color.br, vec2(0)))
+ color.gg;)
// Expand channels to camera-linear light. This shader currently just
// assumes everything uses the BT.2020 12-bit gamma function, since the
// difference between 10 and 12-bit is negligible for anything other
// than 12-bit content.
GLSL(color.rgb = mix(color.rgb / vec3(4.5),
pow((color.rgb + vec3(0.0993))/vec3(1.0993), vec3(1.0/0.45)),
lessThanEqual(vec3(0.08145), color.rgb));)
// Calculate the green channel from the expanded RYcB
// The BT.2020 specification says Yc = 0.2627*R + 0.6780*G + 0.0593*B
GLSL(color.g = (color.g - 0.2627*color.r - 0.0593*color.b)/0.6780;)
vo_opengl: fix incorrect wording in comment "compand" was used where the actual operation was "compress". Change to avoid confusion.
2015-03-14 02:04:23 +00:00
// Recompress to receive the R'G'B' result, same as other systems
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
GLSL(color.rgb = mix(color.rgb * vec3(4.5),
vec3(1.0993) * pow(color.rgb, vec3(0.45)) - vec3(0.0993),
lessThanEqual(vec3(0.0181), color.rgb));)
}
vo_opengl: apply alpha after conversion to rgb Currently this was done before conversion, which could fuck up a hypothetical YUVA stream.
2015-03-13 20:29:04 +00:00
if (!p->has_alpha || p->opts.alpha_mode == 0) { // none
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
GLSL(color.a = 1.0;)
vo_opengl: apply alpha after conversion to rgb Currently this was done before conversion, which could fuck up a hypothetical YUVA stream.
2015-03-13 20:29:04 +00:00
} else if (p->opts.alpha_mode == 2) { // blend
GLSL(color = vec4(color.rgb * color.a, 1.0);)
}
vo_opengl: greatly increase smoothmotion performance Instead of rendering and upscaling each video frame on every vsync, this version of the algorithm only draws them once and caches the result, so the only operation that has to run on every vsync is a cheap linear interpolation, plus CMS/dithering. On my machine, this is a huge speedup for 24 Hz content (on a 60 Hz monitor), up to 120% faster. (The speedup is not quite 250% because of the overhead that the larger FBOs and CMS provides) In terms of the implementation, this commit basically swaps interpolation and upscaling - upscaling is moved to inter_program, and interpolation is moved to the final_program. Furthermore, the main bulk of the frame rendering logic (upscaling etc.) was moved to a separete function, which is called from gl_video_interpolate_frame only if it's actually necessarily, and skipped otherwise.
2015-02-20 21:12:02 +00:00
}
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
static void get_scale_factors(struct gl_video *p, double xy[2])
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
{
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
xy[0] = (p->dst_rect.x1 - p->dst_rect.x0) /
(double)(p->src_rect.x1 - p->src_rect.x0);
xy[1] = (p->dst_rect.y1 - p->dst_rect.y0) /
(double)(p->src_rect.y1 - p->src_rect.y0);
}
vo_opengl: move video source rectangle computation to a function Needed for the following commit.
2015-09-07 19:02:49 +00:00
// Compute the cropped and rotated transformation of the video source rectangle.
// vp_w and vp_h are set to the _destination_ video size.
static void compute_src_transform(struct gl_video *p, struct gl_transform *tr,
int *vp_w, int *vp_h)
{
float sx = (p->src_rect.x1 - p->src_rect.x0) / (float)p->image_w,
sy = (p->src_rect.y1 - p->src_rect.y0) / (float)p->image_h,
ox = p->src_rect.x0,
oy = p->src_rect.y0;
struct gl_transform transform = {{{sx,0.0}, {0.0,sy}}, {ox,oy}};
int xc = 0, yc = 1;
*vp_w = p->dst_rect.x1 - p->dst_rect.x0,
*vp_h = p->dst_rect.y1 - p->dst_rect.y0;
if ((p->image_params.rotate % 180) == 90) {
MPSWAP(float, transform.m[0][xc], transform.m[0][yc]);
MPSWAP(float, transform.m[1][xc], transform.m[1][yc]);
MPSWAP(float, transform.t[0], transform.t[1]);
MPSWAP(int, xc, yc);
MPSWAP(int, *vp_w, *vp_h);
}
*tr = transform;
}
vo_opengl: color manage after interpolation This moves the color management code out of pass_render_main (which is now dedicated solely to up/downscaling and hence renamed pass_scale_main) and into a new function, which gets called from pass_draw_to_screen instead. This makes more sense from a logical standpoint, and also means that we interpolate in linear RGB, before color management - rather than after it, which is significantly better for color accuracy and probably also interpolation quality.
2015-03-15 21:52:34 +00:00
// Takes care of the main scaling and pre/post-conversions
static void pass_scale_main(struct gl_video *p)
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
{
// Figure out the main scaler.
double xy[2];
get_scale_factors(p, xy);
bool downscaling = xy[0] < 1.0 || xy[1] < 1.0;
bool upscaling = !downscaling && (xy[0] > 1.0 || xy[1] > 1.0);
double scale_factor = 1.0;
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 *scaler = &p->scaler[0];
struct scaler_config scaler_conf = p->opts.scaler[0];
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
if (p->opts.scaler_resizes_only && !downscaling && !upscaling)
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
scaler_conf.kernel.name = "bilinear";
if (downscaling && p->opts.scaler[1].kernel.name) {
scaler_conf = p->opts.scaler[1];
scaler = &p->scaler[1];
}
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
double f = MPMIN(xy[0], xy[1]);
if (p->opts.fancy_downscaling && f < 1.0 &&
fabs(xy[0] - f) < 0.01 && fabs(xy[1] - f) < 0.01)
{
scale_factor = FFMAX(1.0, 1.0 / f);
vo_opengl: greatly increase smoothmotion performance Instead of rendering and upscaling each video frame on every vsync, this version of the algorithm only draws them once and caches the result, so the only operation that has to run on every vsync is a cheap linear interpolation, plus CMS/dithering. On my machine, this is a huge speedup for 24 Hz content (on a 60 Hz monitor), up to 120% faster. (The speedup is not quite 250% because of the overhead that the larger FBOs and CMS provides) In terms of the implementation, this commit basically swaps interpolation and upscaling - upscaling is moved to inter_program, and interpolation is moved to the final_program. Furthermore, the main bulk of the frame rendering logic (upscaling etc.) was moved to a separete function, which is called from gl_video_interpolate_frame only if it's actually necessarily, and skipped otherwise.
2015-02-20 21:12:02 +00:00
}
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
// Pre-conversion, like linear light/sigmoidization
GLSLF("// scaler pre-conversion\n");
vo_opengl: require FBOs and get rid of the single-pass optimization This change makes vo_opengl slightly less compatible (ancient devices without FBOs will no longer work) and decreases performance in the simplest case (vo=opengl), in exchange for significantly reducing code complexity and making everything easier to reason about.
2015-09-05 09:39:20 +00:00
if (p->use_linear)
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
pass_linearize(p->sc, p->image_params.gamma);
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
vo_opengl: color manage after interpolation This moves the color management code out of pass_render_main (which is now dedicated solely to up/downscaling and hence renamed pass_scale_main) and into a new function, which gets called from pass_draw_to_screen instead. This makes more sense from a logical standpoint, and also means that we interpolate in linear RGB, before color management - rather than after it, which is significantly better for color accuracy and probably also interpolation quality.
2015-03-15 21:52:34 +00:00
bool use_sigmoid = p->use_linear && p->opts.sigmoid_upscaling && upscaling;
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 sig_center, sig_slope, sig_offset, sig_scale;
if (use_sigmoid) {
// Coefficients for the sigmoidal transform are taken from the
// formula here: http://www.imagemagick.org/Usage/color_mods/#sigmoidal
sig_center = p->opts.sigmoid_center;
sig_slope = p->opts.sigmoid_slope;
// This function needs to go through (0,0) and (1,1) so we compute the
// values at 1 and 0, and then scale/shift them, respectively.
sig_offset = 1.0/(1+expf(sig_slope * sig_center));
sig_scale = 1.0/(1+expf(sig_slope * (sig_center-1))) - sig_offset;
GLSLF("color.rgb = %f - log(1.0/(color.rgb * %f + %f) - 1.0)/%f;\n",
sig_center, sig_scale, sig_offset, sig_slope);
}
vo_opengl: move video source rectangle computation to a function Needed for the following commit.
2015-09-07 19:02:49 +00:00
struct gl_transform transform;
int vp_w, vp_h;
compute_src_transform(p, &transform, &vp_w, &vp_h);
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
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
GLSLF("// main scaling\n");
vo_opengl: require FBOs and get rid of the single-pass optimization This change makes vo_opengl slightly less compatible (ancient devices without FBOs will no longer work) and decreases performance in the simplest case (vo=opengl), in exchange for significantly reducing code complexity and making everything easier to reason about.
2015-09-05 09:39:20 +00:00
finish_pass_fbo(p, &p->indirect_fbo, p->image_w, p->image_h, 0, 0);
pass_sample(p, 0, scaler, &scaler_conf, scale_factor, vp_w, vp_h,
transform);
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
GLSLF("// scaler post-conversion\n");
if (use_sigmoid) {
// Inverse of the transformation above
GLSLF("color.rgb = (1.0/(1.0 + exp(%f * (%f - color.rgb))) - %f) / %f;\n",
sig_slope, sig_center, sig_offset, sig_scale);
}
vo_opengl: color manage after interpolation This moves the color management code out of pass_render_main (which is now dedicated solely to up/downscaling and hence renamed pass_scale_main) and into a new function, which gets called from pass_draw_to_screen instead. This makes more sense from a logical standpoint, and also means that we interpolate in linear RGB, before color management - rather than after it, which is significantly better for color accuracy and probably also interpolation quality.
2015-03-15 21:52:34 +00:00
}
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
vo_opengl: treat non-blended subtitles as sRGB Currently, the code just skipped CMS completely. This commit treats them as sRGB by default, instead. This also refactors much of the color management code to make it more generalized and re-usable.
2015-03-27 10:12:46 +00:00
// Adapts the colors from the given color space to the display device's native
// gamut.
static void pass_colormanage(struct gl_video *p, enum mp_csp_prim prim_src,
enum mp_csp_trc trc_src)
vo_opengl: color manage after interpolation This moves the color management code out of pass_render_main (which is now dedicated solely to up/downscaling and hence renamed pass_scale_main) and into a new function, which gets called from pass_draw_to_screen instead. This makes more sense from a logical standpoint, and also means that we interpolate in linear RGB, before color management - rather than after it, which is significantly better for color accuracy and probably also interpolation quality.
2015-03-15 21:52:34 +00:00
{
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
GLSLF("// color management\n");
enum mp_csp_trc trc_dst = p->opts.target_trc;
vo_opengl: treat non-blended subtitles as sRGB Currently, the code just skipped CMS completely. This commit treats them as sRGB by default, instead. This also refactors much of the color management code to make it more generalized and re-usable.
2015-03-27 10:12:46 +00:00
enum mp_csp_prim prim_dst = p->opts.target_prim;
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
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
if (p->use_lut_3d) {
// The 3DLUT is hard-coded against BT.2020's gamut during creation, and
// we never want to adjust its output (so treat it as linear)
prim_dst = MP_CSP_PRIM_BT_2020;
trc_dst = MP_CSP_TRC_LINEAR;
}
if (prim_dst == MP_CSP_PRIM_AUTO)
prim_dst = prim_src;
if (trc_dst == MP_CSP_TRC_AUTO) {
vo_opengl: treat non-blended subtitles as sRGB Currently, the code just skipped CMS completely. This commit treats them as sRGB by default, instead. This also refactors much of the color management code to make it more generalized and re-usable.
2015-03-27 10:12:46 +00:00
trc_dst = trc_src;
// Avoid outputting linear light at all costs
if (trc_dst == MP_CSP_TRC_LINEAR)
trc_dst = p->image_params.gamma;
if (trc_dst == MP_CSP_TRC_LINEAR)
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
trc_dst = MP_CSP_TRC_GAMMA22;
}
vo_opengl: treat non-blended subtitles as sRGB Currently, the code just skipped CMS completely. This commit treats them as sRGB by default, instead. This also refactors much of the color management code to make it more generalized and re-usable.
2015-03-27 10:12:46 +00:00
bool need_cms = prim_src != prim_dst || p->use_lut_3d;
bool need_gamma = trc_src != trc_dst || need_cms;
vo_opengl: blend-subtitles in non-linear light
2015-03-29 04:34:34 +00:00
if (need_gamma)
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
pass_linearize(p->sc, trc_src);
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
// Adapt to the right colorspace if necessary
if (prim_src != prim_dst) {
struct mp_csp_primaries csp_src = mp_get_csp_primaries(prim_src),
csp_dst = mp_get_csp_primaries(prim_dst);
float m[3][3] = {{0}};
mp_get_cms_matrix(csp_src, csp_dst, MP_INTENT_RELATIVE_COLORIMETRIC, m);
gl_sc_uniform_mat3(p->sc, "cms_matrix", true, &m[0][0]);
GLSL(color.rgb = cms_matrix * color.rgb;)
}
if (p->use_lut_3d) {
gl_sc_uniform_sampler(p->sc, "lut_3d", GL_TEXTURE_3D, TEXUNIT_3DLUT);
// For the 3DLUT we are arbitrarily using 2.4 as input gamma to reduce
// the severity of quantization errors.
GLSL(color.rgb = clamp(color.rgb, 0.0, 1.0);)
GLSL(color.rgb = pow(color.rgb, vec3(1.0/2.4));)
GLSL(color.rgb = texture3D(lut_3d, color.rgb).rgb;)
}
vo_opengl: blend-subtitles in non-linear light
2015-03-29 04:34:34 +00:00
if (need_gamma)
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
pass_delinearize(p->sc, trc_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
}
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
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
static void pass_dither(struct gl_video *p)
{
GL *gl = p->gl;
// Assume 8 bits per component if unknown.
int dst_depth = p->depth_g ? p->depth_g : 8;
if (p->opts.dither_depth > 0)
dst_depth = p->opts.dither_depth;
if (p->opts.dither_depth < 0 || p->opts.dither_algo < 0)
return;
if (!p->dither_texture) {
MP_VERBOSE(p, "Dither to %d.\n", dst_depth);
int tex_size;
void *tex_data;
GLint tex_iformat;
GLint tex_format;
GLenum tex_type;
unsigned char temp[256];
if (p->opts.dither_algo == 0) {
int sizeb = p->opts.dither_size;
int size = 1 << sizeb;
if (p->last_dither_matrix_size != size) {
p->last_dither_matrix = talloc_realloc(p, p->last_dither_matrix,
float, size * size);
mp_make_fruit_dither_matrix(p->last_dither_matrix, sizeb);
p->last_dither_matrix_size = size;
}
tex_size = size;
tex_iformat = gl_float16_formats[0].internal_format;
tex_format = gl_float16_formats[0].format;
tex_type = GL_FLOAT;
tex_data = p->last_dither_matrix;
} else {
assert(sizeof(temp) >= 8 * 8);
mp_make_ordered_dither_matrix(temp, 8);
const struct fmt_entry *fmt = find_tex_format(gl, 1, 1);
tex_size = 8;
tex_iformat = fmt->internal_format;
tex_format = fmt->format;
tex_type = fmt->type;
tex_data = temp;
}
p->dither_size = tex_size;
gl->ActiveTexture(GL_TEXTURE0 + TEXUNIT_DITHER);
gl->GenTextures(1, &p->dither_texture);
gl->BindTexture(GL_TEXTURE_2D, p->dither_texture);
gl->PixelStorei(GL_UNPACK_ALIGNMENT, 1);
gl->TexImage2D(GL_TEXTURE_2D, 0, tex_iformat, tex_size, tex_size, 0,
tex_format, tex_type, tex_data);
gl->TexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
gl->TexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
gl->TexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
gl->TexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
gl->PixelStorei(GL_UNPACK_ALIGNMENT, 4);
gl->ActiveTexture(GL_TEXTURE0);
vo_opengl: fix smoothmotion coefficient calculation, for real this time I've reworked pretty much all the logic to correspond to what the theory actually describes. With this commit, playback is wonderfully smooth on my machine.
2015-02-19 13:03:18 +00:00
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
debug_check_gl(p, "dither setup");
vo_opengl: greatly increase smoothmotion performance Instead of rendering and upscaling each video frame on every vsync, this version of the algorithm only draws them once and caches the result, so the only operation that has to run on every vsync is a cheap linear interpolation, plus CMS/dithering. On my machine, this is a huge speedup for 24 Hz content (on a 60 Hz monitor), up to 120% faster. (The speedup is not quite 250% because of the overhead that the larger FBOs and CMS provides) In terms of the implementation, this commit basically swaps interpolation and upscaling - upscaling is moved to inter_program, and interpolation is moved to the final_program. Furthermore, the main bulk of the frame rendering logic (upscaling etc.) was moved to a separete function, which is called from gl_video_interpolate_frame only if it's actually necessarily, and skipped otherwise.
2015-02-20 21:12:02 +00:00
}
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
GLSLF("// dithering\n");
// This defines how many bits are considered significant for output on
// screen. The superfluous bits will be used for rounding according to the
// dither matrix. The precision of the source implicitly decides how many
// dither patterns can be visible.
vo_opengl: reduce number of uniforms in dithering pass We now update uniforms every time, so we should try to reduce the number of uniforms to avoid performance penalties. (Originally, some caching was planned, but it looks like it would be too complicated to implement compared to the expected gains.)
2015-03-16 19:22:09 +00:00
int dither_quantization = (1 << dst_depth) - 1;
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
gl_sc_uniform_sampler(p->sc, "dither", GL_TEXTURE_2D, TEXUNIT_DITHER);
vo_opengl: reduce number of uniforms in dithering pass We now update uniforms every time, so we should try to reduce the number of uniforms to avoid performance penalties. (Originally, some caching was planned, but it looks like it would be too complicated to implement compared to the expected gains.)
2015-03-16 19:22:09 +00:00
GLSLF("vec2 dither_pos = gl_FragCoord.xy / %d;\n", p->dither_size);
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
if (p->opts.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 phase = (p->frames_rendered / p->opts.temporal_dither_period) % 8u;
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
float r = phase * (M_PI / 2); // rotate
float m = phase < 4 ? 1 : -1; // mirror
float matrix[2][2] = {{cos(r), -sin(r) },
{sin(r) * m, cos(r) * m}};
gl_sc_uniform_mat2(p->sc, "dither_trafo", true, &matrix[0][0]);
GLSL(dither_pos = dither_trafo * dither_pos;)
vo_opengl: fix smoothmotion coefficient calculation, for real this time I've reworked pretty much all the logic to correspond to what the theory actually describes. With this commit, playback is wonderfully smooth on my machine.
2015-02-19 13:03:18 +00:00
}
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
GLSL(float dither_value = texture(dither, dither_pos).r;)
vo_opengl: reduce number of uniforms in dithering pass We now update uniforms every time, so we should try to reduce the number of uniforms to avoid performance penalties. (Originally, some caching was planned, but it looks like it would be too complicated to implement compared to the expected gains.)
2015-03-16 19:22:09 +00:00
GLSLF("color = floor(color * %d + dither_value + 0.5 / (%d * %d)) / %d;\n",
dither_quantization, p->dither_size, p->dither_size,
dither_quantization);
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
}
vo_opengl: blend-subtitles in non-linear light
2015-03-29 04:34:34 +00:00
// Draws the OSD, in scene-referred colors.. If cms is true, subtitles are
// instead adapted to the display's gamut.
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
static void pass_draw_osd(struct gl_video *p, int draw_flags, double pts,
struct mp_osd_res rect, int vp_w, int vp_h, int fbo,
vo_opengl: blend-subtitles in non-linear light
2015-03-29 04:34:34 +00:00
bool cms)
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
{
mpgl_osd_generate(p->osd, rect, pts, p->image_params.stereo_out, draw_flags);
p->gl->BindFramebuffer(GL_FRAMEBUFFER, fbo);
for (int n = 0; n < MAX_OSD_PARTS; n++) {
enum sub_bitmap_format fmt = mpgl_osd_get_part_format(p->osd, n);
if (!fmt)
continue;
gl_sc_uniform_sampler(p->sc, "osdtex", GL_TEXTURE_2D, 0);
switch (fmt) {
case SUBBITMAP_RGBA: {
GLSLF("// OSD (RGBA)\n");
GLSL(vec4 color = texture(osdtex, texcoord).bgra;)
break;
}
case SUBBITMAP_LIBASS: {
GLSLF("// OSD (libass)\n");
GLSL(vec4 color =
vec4(ass_color.rgb, ass_color.a * texture(osdtex, texcoord).r);)
break;
}
default:
abort();
}
vo_opengl: blend-subtitles in non-linear light
2015-03-29 04:34:34 +00:00
// Subtitle color management, they're assumed to be sRGB by default
if (cms)
vo_opengl: treat non-blended subtitles as sRGB Currently, the code just skipped CMS completely. This commit treats them as sRGB by default, instead. This also refactors much of the color management code to make it more generalized and re-usable.
2015-03-27 10:12:46 +00:00
pass_colormanage(p, MP_CSP_PRIM_BT_709, MP_CSP_TRC_SRGB);
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
gl_sc_set_vao(p->sc, mpgl_osd_get_vao(p->osd));
gl_sc_gen_shader_and_reset(p->sc);
mpgl_osd_draw_part(p->osd, vp_w, vp_h, n);
}
gl_sc_set_vao(p->sc, &p->vao);
}
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
// Minimal rendering code path, for GLES or OpenGL 2.1 without proper FBOs.
static void pass_render_frame_dumb(struct gl_video *p, int fbo)
{
p->gl->BindFramebuffer(GL_FRAMEBUFFER, fbo);
struct gl_transform chromafix;
pass_set_image_textures(p, &p->image, &chromafix);
struct gl_transform transform;
int vp_w, vp_h;
compute_src_transform(p, &transform, &vp_w, &vp_h);
struct gl_transform tchroma = transform;
tchroma.t[0] /= 1 << p->image_desc.chroma_xs;
tchroma.t[1] /= 1 << p->image_desc.chroma_ys;
gl_transform_rect(transform, &p->pass_tex[0].src);
for (int n = 1; n < 3; n++) {
gl_transform_rect(chromafix, &p->pass_tex[n].src);
gl_transform_rect(tchroma, &p->pass_tex[n].src);
}
gl_transform_rect(transform, &p->pass_tex[3].src);
GLSL(vec4 color = texture(texture0, texcoord0);)
if (p->image_params.imgfmt == IMGFMT_NV12 ||
p->image_params.imgfmt == IMGFMT_NV21)
{
GLSL(color.gb = texture(texture1, texcoord1).RG;)
} else if (p->plane_count >= 3) {
GLSL(color.g = texture(texture1, texcoord1).r;)
GLSL(color.b = texture(texture2, texcoord2).r;)
}
if (p->plane_count >= 4)
GLSL(color.a = texture(texture3, texcoord3).r;);
p->use_normalized_range = false;
pass_convert_yuv(p);
}
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
// The main rendering function, takes care of everything up to and including
vo_opengl: cleanup frame reupload logic There are some situations when redrawing is requested, but the current frame was deleted. This could happen when switching e.g. hw decoding mid-stream. Separate uploading/drawing and fix the condition.
2015-07-17 21:21:04 +00:00
// upscaling. p->image is rendered.
static void pass_render_frame(struct gl_video *p)
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
{
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
if (p->opts.dumb_mode)
return;
vo_opengl: CMS no longer implies linear scaling They're completely orthogonal concepts, merged in the past due to convenience and ease of implementing it in the old #ifdef hell renderer. Especially after the CMS stuff was generalized by 634b4a, this was a trivial change to implement and also means color management will be much higher quality when enabled with vo=opengl (which had quantization issues in the past due to the 8 bit FBO format and upscaling), since it can be done in a single pass now.
2015-04-02 09:13:51 +00:00
p->use_linear = p->opts.linear_scaling || p->opts.sigmoid_upscaling;
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
pass_read_video(p);
pass_convert_yuv(p);
vo_opengl: add blend-subtitles-res This can be used to draw the subtitles at the video's native res, which can make them look more natural and increases performance.
2015-04-10 20:19:44 +00:00
// For subtitles
double vpts = p->image.mpi->pts;
if (vpts == MP_NOPTS_VALUE)
vpts = p->osd_pts;
vo_opengl: unify blend-subtitles-res and blend-subtitles
2015-04-11 17:16:34 +00:00
if (p->osd && p->opts.blend_subs == 2) {
vo_opengl: fix blend-subtitles-res=video & anamorphic video Since scaling the video changes the aspect ratio, we have to compensate for this when rendering subtitles.
2015-04-11 13:53:00 +00:00
double scale[2];
get_scale_factors(p, scale);
struct mp_osd_res rect = {
.w = p->image_w, .h = p->image_h,
.display_par = scale[1] / scale[0], // counter compensate scaling
};
vo_opengl: add blend-subtitles-res This can be used to draw the subtitles at the video's native res, which can make them look more natural and increases performance.
2015-04-10 20:19:44 +00:00
finish_pass_fbo(p, &p->blend_subs_fbo, p->image_w, p->image_h, 0, 0);
pass_draw_osd(p, OSD_DRAW_SUB_ONLY, vpts, rect, p->image_w, p->image_h,
p->blend_subs_fbo.fbo, false);
GLSL(vec4 color = texture(texture0, texcoord0);)
}
vo_opengl: require FBOs and get rid of the single-pass optimization This change makes vo_opengl slightly less compatible (ancient devices without FBOs will no longer work) and decreases performance in the simplest case (vo=opengl), in exchange for significantly reducing code complexity and making everything easier to reason about.
2015-09-05 09:39:20 +00:00
apply_shaders(p, p->opts.pre_shaders, &p->pre_fbo[0], 0,
p->image_w, p->image_h);
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
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
if (p->opts.unsharp != 0.0) {
finish_pass_fbo(p, &p->unsharp_fbo, p->image_w, p->image_h, 0, 0);
pass_sample_unsharp(p->sc, p->opts.unsharp);
}
vo_opengl: color manage after interpolation This moves the color management code out of pass_render_main (which is now dedicated solely to up/downscaling and hence renamed pass_scale_main) and into a new function, which gets called from pass_draw_to_screen instead. This makes more sense from a logical standpoint, and also means that we interpolate in linear RGB, before color management - rather than after it, which is significantly better for color accuracy and probably also interpolation quality.
2015-03-15 21:52:34 +00:00
pass_scale_main(p);
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
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
int vp_w = p->dst_rect.x1 - p->dst_rect.x0,
vp_h = p->dst_rect.y1 - p->dst_rect.y0;
vo_opengl: unify blend-subtitles-res and blend-subtitles
2015-04-11 17:16:34 +00:00
if (p->osd && p->opts.blend_subs == 1) {
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
// Recreate the real video size from the src/dst rects
struct mp_osd_res rect = {
.w = vp_w, .h = vp_h,
.ml = -p->src_rect.x0, .mr = p->src_rect.x1 - p->image_w,
.mt = -p->src_rect.y0, .mb = p->src_rect.y1 - p->image_h,
.display_par = 1.0,
};
// Adjust margins for scale
double scale[2];
get_scale_factors(p, scale);
rect.ml *= scale[0]; rect.mr *= scale[0];
rect.mt *= scale[1]; rect.mb *= scale[1];
vo_opengl: blend-subtitles in non-linear light
2015-03-29 04:34:34 +00:00
// We should always blend subtitles in non-linear light
if (p->use_linear)
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
pass_delinearize(p->sc, p->image_params.gamma);
vo_opengl: add FBOTEX_FUZZY alias Minor reusability factor
2015-03-25 22:06:46 +00:00
finish_pass_fbo(p, &p->blend_subs_fbo, vp_w, vp_h, 0, FBOTEX_FUZZY);
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
pass_draw_osd(p, OSD_DRAW_SUB_ONLY, vpts, rect, vp_w, vp_h,
vo_opengl: blend-subtitles in non-linear light
2015-03-29 04:34:34 +00:00
p->blend_subs_fbo.fbo, false);
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
GLSL(vec4 color = texture(texture0, texcoord0);)
vo_opengl: blend-subtitles in non-linear light
2015-03-29 04:34:34 +00:00
if (p->use_linear)
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
pass_linearize(p->sc, p->image_params.gamma);
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
}
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
apply_shaders(p, p->opts.post_shaders, &p->post_fbo[0], 0, vp_w, vp_h);
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
}
static void pass_draw_to_screen(struct gl_video *p, int fbo)
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
{
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
if (p->opts.dumb_mode)
pass_render_frame_dumb(p, fbo);
vo_opengl: treat non-blended subtitles as sRGB Currently, the code just skipped CMS completely. This commit treats them as sRGB by default, instead. This also refactors much of the color management code to make it more generalized and re-usable.
2015-03-27 10:12:46 +00:00
// Adjust the overall gamma before drawing to screen
if (p->user_gamma != 1) {
gl_sc_uniform_f(p->sc, "user_gamma", p->user_gamma);
GLSL(color.rgb = clamp(color.rgb, 0.0, 1.0);)
GLSL(color.rgb = pow(color.rgb, vec3(user_gamma));)
}
pass_colormanage(p, p->image_params.primaries,
p->use_linear ? MP_CSP_TRC_LINEAR : p->image_params.gamma);
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
pass_dither(p);
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
int flags = (p->image_params.rotate % 90 ? 0 : p->image_params.rotate / 90)
| (p->image.image_flipped ? 4 : 0);
finish_pass_direct(p, fbo, p->vp_w, p->vp_h, &p->dst_rect, flags);
}
// Draws an interpolate frame to fbo, based on the frame timing in t
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
static void gl_video_interpolate_frame(struct gl_video *p, struct vo_frame *t,
int fbo)
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
{
int vp_w = p->dst_rect.x1 - p->dst_rect.x0,
vo_opengl: add FBOTEX_FUZZY alias Minor reusability factor
2015-03-25 22:06:46 +00:00
vp_h = p->dst_rect.y1 - p->dst_rect.y0;
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
vo_opengl: fix framestepping/pausing + interpolation This is not the most theoretically perfect solution, ideally we could check to see if the frame in question has already been rendered somewhere in the queue and then avoid re-rendering it, at the cost of a few extra lines of code. But I don't think the performance trade-off is dramatic enough here.
2015-06-30 23:25:30 +00:00
// Reset the queue completely if this is a still image, to avoid any
// interpolation artifacts from surrounding frames when unpausing or
// framestepping
if (t->still)
gl_video_reset_surfaces(p);
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
// First of all, figure out if we have a frame availble at all, and draw
// it manually + reset the queue if not
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
if (p->surfaces[p->surface_now].pts == MP_NOPTS_VALUE) {
vo_opengl: cleanup frame reupload logic There are some situations when redrawing is requested, but the current frame was deleted. This could happen when switching e.g. hw decoding mid-stream. Separate uploading/drawing and fix the condition.
2015-07-17 21:21:04 +00:00
gl_video_upload_image(p, t->current);
pass_render_frame(p);
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
finish_pass_fbo(p, &p->surfaces[p->surface_now].fbotex,
Revert "vo_opengl: make the size of interpolation textures exact" This reverts commit fb8d15836695e883355c5ec6ff8463e7bbf39461. Reallocating the FBOs on every resize is very slow. It affects resizing the window, as well as changing the video size itself with e.g. panscan. Since the original change was done based on a single user complaint, but the change itself caused a lot of complaints, we decided to just revert it.
2015-07-22 21:57:09 +00:00
vp_w, vp_h, 0, FBOTEX_FUZZY);
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
p->surfaces[p->surface_now].pts = p->image.mpi->pts;
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
p->surface_idx = p->surface_now;
}
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
// Find the right frame for this instant
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
if (t->current&& t->current->pts != MP_NOPTS_VALUE) {
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
int next = fbosurface_wrap(p->surface_now + 1);
while (p->surfaces[next].pts != MP_NOPTS_VALUE &&
p->surfaces[next].pts > p->surfaces[p->surface_now].pts &&
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
p->surfaces[p->surface_now].pts < t->current->pts)
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
{
p->surface_now = next;
next = fbosurface_wrap(next + 1);
}
}
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
// Figure out the queue size. For illustration, a filter radius of 2 would
// look like this: _ A [B] C D _
// A is surface_bse, B is surface_now, C is surface_nxt and D is
// surface_end.
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 *tscale = &p->scaler[3];
reinit_scaler(p, tscale, &p->opts.scaler[3], 1, tscale_sizes);
vo_opengl: reimplement tscale=oversample Closes #2102.
2015-07-11 11:55:45 +00:00
bool oversample = strcmp(tscale->conf.kernel.name, "oversample") == 0;
vo_opengl: add oversample support for tscale This is interesting mainly because it's essentially equivalent to the old smoothmotion algorithm. As such, it is now the default for tscale.
2015-03-15 06:11:51 +00:00
int size;
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
vo_opengl: reimplement tscale=oversample Closes #2102.
2015-07-11 11:55:45 +00:00
if (oversample) {
size = 2;
} else {
assert(tscale->kernel && !tscale->kernel->polar);
size = ceil(tscale->kernel->size);
assert(size <= TEXUNIT_VIDEO_NUM);
}
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
int radius = size/2;
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 surface_now = p->surface_now;
int surface_nxt = fbosurface_wrap(surface_now + 1);
int surface_bse = fbosurface_wrap(surface_now - (radius-1));
int surface_end = fbosurface_wrap(surface_now + radius);
assert(fbosurface_wrap(surface_bse + size-1) == surface_end);
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
// Render new frames while there's room in the queue. Note that technically,
// this should be done before the step where we find the right frame, but
// it only barely matters at the very beginning of playback, and this way
// makes the code much more linear.
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 surface_dst = fbosurface_wrap(p->surface_idx+1);
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
for (int i = 0; i < t->num_frames; i++) {
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
// Avoid overwriting data we might still need
if (surface_dst == surface_bse - 1)
break;
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 mp_image *f = t->frames[i];
vo_opengl: reject future images in different formats The VO will be provided with future frames even if the format changes mid-stream. This caused a crash if these frames were actually used (i.e. interpolation mode was enabled). Fixes a crash when deinterlacing is toggled during playback, and the deinterlacer changes the stream format (as it can happen e.g. if the decoder outputs nv12, which in turn happens with hw decoding). (On a side note, future frames are always non-NULL. Also, the current frame is of course always in the correct format.)
2015-07-15 12:58:56 +00:00
if (!mp_image_params_equal(&f->params, &p->real_image_params) ||
f->pts == MP_NOPTS_VALUE)
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
continue;
if (f->pts > p->surfaces[p->surface_idx].pts) {
MP_STATS(p, "new-pts");
vo_opengl: cleanup frame reupload logic There are some situations when redrawing is requested, but the current frame was deleted. This could happen when switching e.g. hw decoding mid-stream. Separate uploading/drawing and fix the condition.
2015-07-17 21:21:04 +00:00
gl_video_upload_image(p, f);
pass_render_frame(p);
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
finish_pass_fbo(p, &p->surfaces[surface_dst].fbotex,
Revert "vo_opengl: make the size of interpolation textures exact" This reverts commit fb8d15836695e883355c5ec6ff8463e7bbf39461. Reallocating the FBOs on every resize is very slow. It affects resizing the window, as well as changing the video size itself with e.g. panscan. Since the original change was done based on a single user complaint, but the change itself caused a lot of complaints, we decided to just revert it.
2015-07-22 21:57:09 +00:00
vp_w, vp_h, 0, FBOTEX_FUZZY);
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
p->surfaces[surface_dst].pts = f->pts;
p->surface_idx = surface_dst;
surface_dst = fbosurface_wrap(surface_dst+1);
}
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
}
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
// Figure out whether the queue is "valid". A queue is invalid if the
// frames' PTS is not monotonically increasing. Anything else is invalid,
// so avoid blending incorrect data and just draw the latest frame as-is.
// Possible causes for failure of this condition include seeks, pausing,
// end of playback or start of playback.
bool valid = true;
vo_opengl: improve interpolation diagnostics This adds extra debugging output for buffer underruns, to help track down possible queueing issues. It also inverts the numberic output for tscale=oversample to make more sense, without changing the logic.
2015-03-15 22:25:01 +00:00
for (int i = surface_bse, ii; valid && i != surface_end; i = ii) {
ii = fbosurface_wrap(i+1);
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
if (p->surfaces[i].pts == MP_NOPTS_VALUE ||
p->surfaces[ii].pts == MP_NOPTS_VALUE)
{
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
valid = false;
vo_opengl: improve interpolation diagnostics This adds extra debugging output for buffer underruns, to help track down possible queueing issues. It also inverts the numberic output for tscale=oversample to make more sense, without changing the logic.
2015-03-15 22:25:01 +00:00
} else if (p->surfaces[ii].pts < p->surfaces[i].pts) {
valid = false;
MP_DBG(p, "interpolation queue underrun\n");
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
}
}
vo_opengl: correct OSD PTS when using interpolation
2015-03-25 21:40:10 +00:00
// Update OSD PTS to synchronize subtitles with the displayed frame
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
p->osd_pts = p->surfaces[surface_now].pts;
vo_opengl: correct OSD PTS when using interpolation
2015-03-25 21:40:10 +00:00
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
// Finally, draw the right mix of frames to the screen.
vo_opengl: fix framestepping/pausing + interpolation This is not the most theoretically perfect solution, ideally we could check to see if the frame in question has already been rendered somewhere in the queue and then avoid re-rendering it, at the cost of a few extra lines of code. But I don't think the performance trade-off is dramatic enough here.
2015-06-30 23:25:30 +00:00
if (!valid || t->still) {
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
// surface_now is guaranteed to be valid, so we can safely use it.
vo_opengl: minor refactor Just making the argument order for pass_load_fbotex more consistent with finish_pass_fbo.
2015-09-05 11:33:48 +00:00
pass_load_fbotex(p, &p->surfaces[surface_now].fbotex, vp_w, vp_h, 0);
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
GLSL(vec4 color = texture(texture0, texcoord0);)
p->is_interpolated = false;
} else {
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
double pts_now = p->surfaces[surface_now].pts,
pts_nxt = p->surfaces[surface_nxt].pts;
double mix = (t->vsync_offset / 1e6) / (pts_nxt - pts_now);
// The scaler code always wants the fcoord to be between 0 and 1,
// so we try to adjust by using the previous set of N frames instead
// (which requires some extra checking to make sure it's valid)
if (mix < 0.0) {
int prev = fbosurface_wrap(surface_bse - 1);
if (p->surfaces[prev].pts != MP_NOPTS_VALUE &&
p->surfaces[prev].pts < p->surfaces[surface_bse].pts)
{
mix += 1.0;
surface_bse = prev;
} else {
mix = 0.0; // at least don't blow up, this should only
// ever happen at the start of playback
}
vo_opengl: add oversample support for tscale This is interesting mainly because it's essentially equivalent to the old smoothmotion algorithm. As such, it is now the default for tscale.
2015-03-15 06:11:51 +00:00
}
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
vo_opengl: reimplement tscale=oversample Closes #2102.
2015-07-11 11:55:45 +00:00
// Blend the frames together
if (oversample) {
double vsync_dist = (t->next_vsync - t->prev_vsync)/1e6
/ (pts_nxt - pts_now),
threshold = tscale->conf.kernel.params[0];
threshold = isnan(threshold) ? 0.0 : threshold;
mix = (1 - mix) / vsync_dist;
mix = mix <= 0 + threshold ? 0 : mix;
mix = mix >= 1 - threshold ? 1 : mix;
mix = 1 - mix;
gl_sc_uniform_f(p->sc, "inter_coeff", mix);
GLSL(vec4 color = mix(texture(texture0, texcoord0),
texture(texture1, texcoord1),
inter_coeff);)
} else {
gl_sc_uniform_f(p->sc, "fcoord", mix);
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
pass_sample_separated_gen(p->sc, tscale, 0, 0);
vo_opengl: reimplement tscale=oversample Closes #2102.
2015-07-11 11:55:45 +00:00
}
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
// Load all the required frames
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
for (int i = 0; i < size; i++) {
pass_load_fbotex(p, &p->surfaces[fbosurface_wrap(surface_bse+i)].fbotex,
vo_opengl: minor refactor Just making the argument order for pass_load_fbotex more consistent with finish_pass_fbo.
2015-09-05 11:33:48 +00:00
vp_w, vp_h, i);
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
}
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
vo_opengl: add oversample support for tscale This is interesting mainly because it's essentially equivalent to the old smoothmotion algorithm. As such, it is now the default for tscale.
2015-03-15 06:11:51 +00:00
MP_STATS(p, "frame-mix");
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
MP_DBG(p, "inter frame pts: %lld, vsync: %lld, mix: %f\n",
(long long)t->pts, (long long)t->next_vsync, mix);
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
p->is_interpolated = true;
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
}
pass_draw_to_screen(p, fbo);
vo_opengl: fix "freezes" after seeking with interpolation on When seeking to a different position, and seeking takes long, the OSD might get redrawn. This means that the VO will receive a request to redraw an old frame using whatever the previous PTS was. This breaks the interpolation logic: the old frame will be added to the queue, and then the next frames (with lower PTS if you seeked backwards) are not drawn as the logic assumes they're past frames. Fix this by using the non-interpolation code path when redrawing after a seek reset, and no "real" frame has been drawn yet. It's a recent regression caused by the redrawing code simplification. The old code simply sent a VOCTRL for redrawing the frame, and the VO had to deal with retaining the old frame on its own. This is a hack as in there's probably a better solution. Fixes #2097.
2015-07-02 11:17:20 +00:00
p->frames_drawn += 1;
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
}
vo_opengl: move OSD rendering to separate function Also reindent the few lines that call into the actual renderer to remove the "draw_osd" goto.
2015-03-23 15:28:33 +00:00
// (fbo==0 makes BindFramebuffer select the screen backbuffer)
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
void gl_video_render_frame(struct gl_video *p, struct vo_frame *frame, int fbo)
vo_opengl: move OSD rendering to separate function Also reindent the few lines that call into the actual renderer to remove the "draw_osd" goto.
2015-03-23 15:28:33 +00:00
{
GL *gl = p->gl;
struct video_image *vimg = &p->image;
gl->BindFramebuffer(GL_FRAMEBUFFER, fbo);
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
bool has_frame = frame->current || vimg->mpi;
if (!has_frame || p->dst_rect.x0 > 0 || p->dst_rect.y0 > 0 ||
vo_opengl: move OSD rendering to separate function Also reindent the few lines that call into the actual renderer to remove the "draw_osd" goto.
2015-03-23 15:28:33 +00:00
p->dst_rect.x1 < p->vp_w || p->dst_rect.y1 < abs(p->vp_h))
{
struct m_color c = p->opts.background;
gl->ClearColor(c.r / 255.0, c.g / 255.0, c.b / 255.0, c.a / 255.0);
gl->Clear(GL_COLOR_BUFFER_BIT);
}
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
if (has_frame) {
gl_sc_set_vao(p->sc, &p->vao);
vo_opengl: move OSD rendering to separate function Also reindent the few lines that call into the actual renderer to remove the "draw_osd" goto.
2015-03-23 15:28:33 +00:00
vo_opengl: fix "freezes" after seeking with interpolation on When seeking to a different position, and seeking takes long, the OSD might get redrawn. This means that the VO will receive a request to redraw an old frame using whatever the previous PTS was. This breaks the interpolation logic: the old frame will be added to the queue, and then the next frames (with lower PTS if you seeked backwards) are not drawn as the logic assumes they're past frames. Fix this by using the non-interpolation code path when redrawing after a seek reset, and no "real" frame has been drawn yet. It's a recent regression caused by the redrawing code simplification. The old code simply sent a VOCTRL for redrawing the frame, and the VO had to deal with retaining the old frame on its own. This is a hack as in there's probably a better solution. Fixes #2097.
2015-07-02 11:17:20 +00:00
if (p->opts.interpolation && (p->frames_drawn || !frame->still)) {
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
gl_video_interpolate_frame(p, frame, fbo);
} else {
// Skip interpolation if there's nothing to be done
vo_opengl: cleanup frame reupload logic There are some situations when redrawing is requested, but the current frame was deleted. This could happen when switching e.g. hw decoding mid-stream. Separate uploading/drawing and fix the condition.
2015-07-17 21:21:04 +00:00
if (!frame->redraw || !vimg->mpi)
gl_video_upload_image(p, frame->current);
pass_render_frame(p);
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
pass_draw_to_screen(p, fbo);
}
vo_opengl: move OSD rendering to separate function Also reindent the few lines that call into the actual renderer to remove the "draw_osd" goto.
2015-03-23 15:28:33 +00:00
}
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
debug_check_gl(p, "after video rendering");
vo_opengl: move OSD rendering to separate function Also reindent the few lines that call into the actual renderer to remove the "draw_osd" goto.
2015-03-23 15:28:33 +00:00
gl->BindFramebuffer(GL_FRAMEBUFFER, fbo);
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
if (p->osd) {
pass_draw_osd(p, p->opts.blend_subs ? OSD_DRAW_OSD_ONLY : 0,
vo_opengl: blend-subtitles in non-linear light
2015-03-29 04:34:34 +00:00
p->osd_pts, p->osd_rect, p->vp_w, p->vp_h, fbo, true);
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
debug_check_gl(p, "after OSD rendering");
}
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
gl->UseProgram(0);
gl->BindFramebuffer(GL_FRAMEBUFFER, 0);
p->frames_rendered++;
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 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
// vp_w/vp_h is the implicit size of the target framebuffer.
// vp_h can be negative to flip the screen.
void gl_video_resize(struct gl_video *p, int vp_w, int vp_h,
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: 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
{
p->src_rect = *src;
p->dst_rect = *dst;
p->osd_rect = *osd;
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
p->vp_w = vp_w;
p->vp_h = vp_h;
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
gl_video_reset_surfaces(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
}
vo_opengl: improve robustness against PBO failure If PBO upload fails, disable PBOs and revert to the normal codepath. In theory we should retry PBO upload on failure (because OpenGL specifies that it can sporadically fail), but since it normally doesn't happen, and the fallback will work, I'm not bothering. Some restructuring is needed, since glUnmapBuffer needs to be called earlier. In fact, the old code structure didn't make too much sense, and is a leftover from MPlayer's direct rendering support, which let the decoder decode to a PBO-mapped region. This means the buffer_ptr field can be dropped. Drop buffer_size as well, since it only had 2 possible values (0 or the size required for the current config).
2015-09-02 20:45:07 +00:00
static bool unmap_image(struct gl_video *p, struct mp_image *mpi)
{
GL *gl = p->gl;
bool ok = true;
struct video_image *vimg = &p->image;
for (int n = 0; n < p->plane_count; n++) {
struct texplane *plane = &vimg->planes[n];
gl->BindBuffer(GL_PIXEL_UNPACK_BUFFER, plane->gl_buffer);
ok = gl->UnmapBuffer(GL_PIXEL_UNPACK_BUFFER) && ok;
mpi->planes[n] = NULL; // PBO offset 0
}
gl->BindBuffer(GL_PIXEL_UNPACK_BUFFER, 0);
return ok;
}
vo_opengl: rename get_image to map_image
2015-09-02 10:39:19 +00:00
static bool map_image(struct gl_video *p, struct mp_image *mpi)
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
{
GL *gl = p->gl;
if (!p->opts.pbo)
return false;
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
struct video_image *vimg = &p->image;
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
for (int n = 0; n < p->plane_count; n++) {
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
struct texplane *plane = &vimg->planes[n];
mp_image: remove redundant plane_w/h fields Seems relatively painful in this case, but they are morally wrong.
2015-04-10 18:58:26 +00:00
mpi->stride[n] = mp_image_plane_w(mpi, n) * p->image_desc.bytes[n];
vo_opengl: improve robustness against PBO failure If PBO upload fails, disable PBOs and revert to the normal codepath. In theory we should retry PBO upload on failure (because OpenGL specifies that it can sporadically fail), but since it normally doesn't happen, and the fallback will work, I'm not bothering. Some restructuring is needed, since glUnmapBuffer needs to be called earlier. In fact, the old code structure didn't make too much sense, and is a leftover from MPlayer's direct rendering support, which let the decoder decode to a PBO-mapped region. This means the buffer_ptr field can be dropped. Drop buffer_size as well, since it only had 2 possible values (0 or the size required for the current config).
2015-09-02 20:45:07 +00:00
if (!plane->gl_buffer) {
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
gl->GenBuffers(1, &plane->gl_buffer);
vo_opengl: improve robustness against PBO failure If PBO upload fails, disable PBOs and revert to the normal codepath. In theory we should retry PBO upload on failure (because OpenGL specifies that it can sporadically fail), but since it normally doesn't happen, and the fallback will work, I'm not bothering. Some restructuring is needed, since glUnmapBuffer needs to be called earlier. In fact, the old code structure didn't make too much sense, and is a leftover from MPlayer's direct rendering support, which let the decoder decode to a PBO-mapped region. This means the buffer_ptr field can be dropped. Drop buffer_size as well, since it only had 2 possible values (0 or the size required for the current config).
2015-09-02 20:45:07 +00:00
gl->BindBuffer(GL_PIXEL_UNPACK_BUFFER, plane->gl_buffer);
size_t buffer_size = mp_image_plane_h(mpi, n) * mpi->stride[n];
gl->BufferData(GL_PIXEL_UNPACK_BUFFER, buffer_size,
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
NULL, GL_DYNAMIC_DRAW);
}
vo_opengl: improve robustness against PBO failure If PBO upload fails, disable PBOs and revert to the normal codepath. In theory we should retry PBO upload on failure (because OpenGL specifies that it can sporadically fail), but since it normally doesn't happen, and the fallback will work, I'm not bothering. Some restructuring is needed, since glUnmapBuffer needs to be called earlier. In fact, the old code structure didn't make too much sense, and is a leftover from MPlayer's direct rendering support, which let the decoder decode to a PBO-mapped region. This means the buffer_ptr field can be dropped. Drop buffer_size as well, since it only had 2 possible values (0 or the size required for the current config).
2015-09-02 20:45:07 +00:00
gl->BindBuffer(GL_PIXEL_UNPACK_BUFFER, plane->gl_buffer);
mpi->planes[n] = gl->MapBuffer(GL_PIXEL_UNPACK_BUFFER, GL_WRITE_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
gl->BindBuffer(GL_PIXEL_UNPACK_BUFFER, 0);
vo_opengl: improve robustness against PBO failure If PBO upload fails, disable PBOs and revert to the normal codepath. In theory we should retry PBO upload on failure (because OpenGL specifies that it can sporadically fail), but since it normally doesn't happen, and the fallback will work, I'm not bothering. Some restructuring is needed, since glUnmapBuffer needs to be called earlier. In fact, the old code structure didn't make too much sense, and is a leftover from MPlayer's direct rendering support, which let the decoder decode to a PBO-mapped region. This means the buffer_ptr field can be dropped. Drop buffer_size as well, since it only had 2 possible values (0 or the size required for the current config).
2015-09-02 20:45:07 +00:00
if (!mpi->planes[n]) {
unmap_image(p, mpi);
return false;
}
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: simplify PBO copy Use mp_image_copy() instead of copying manually. (This function checks whether the destination is regarded writeable, which it is not, because the destination is the source image with changed pointers, so refcounting has to be removed from the destination image by resetting mpi->bufs.)
2015-09-02 10:44:46 +00:00
memset(mpi->bufs, 0, sizeof(mpi->bufs));
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
return true;
}
vo_opengl: simplify After recent changes, there is no reason why gl_video_set_image() should exist anymore. So merge it back into gl_video_upload_image().
2015-07-15 10:22:49 +00:00
static void gl_video_upload_image(struct gl_video *p, struct mp_image *mpi)
vo_opengl: do not block on wayland When not receiving frame callbacks, we should not draw anything to avoid blocking the OpenGL renderer. We do this by extending gl context api, by introducing new optional function 'is_active', that indicates whether OpenGL renderers should draw or not. This fixes issue #249.
2015-03-22 00:32:03 +00:00
{
vo_opengl: simplify After recent changes, there is no reason why gl_video_set_image() should exist anymore. So merge it back into gl_video_upload_image().
2015-07-15 10:22:49 +00:00
GL *gl = p->gl;
vo_opengl: do not block on wayland When not receiving frame callbacks, we should not draw anything to avoid blocking the OpenGL renderer. We do this by extending gl context api, by introducing new optional function 'is_active', that indicates whether OpenGL renderers should draw or not. This fixes issue #249.
2015-03-22 00:32:03 +00:00
struct video_image *vimg = &p->image;
vo_opengl: refactor wayland frame skipping Currently, the wayland backend needs extra work to avoid drawing more often than the wayland frame callback allows. (This is not ideal, but will be fixed at a later time.) Unify this with the start_frame callback added for cocoa. Some details change for the better. For example, if a frame is dropped, and a redraw is done afterwards, the actually correct frame is redrawn, instead whatever was in the textures from before the dropped frame.
2015-05-01 16:44:45 +00:00
vo_opengl: simplify After recent changes, there is no reason why gl_video_set_image() should exist anymore. So merge it back into gl_video_upload_image().
2015-07-15 10:22:49 +00:00
mpi = mp_image_new_ref(mpi);
if (!mpi)
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
abort();
vo_opengl: simplify After recent changes, there is no reason why gl_video_set_image() should exist anymore. So merge it back into gl_video_upload_image().
2015-07-15 10:22:49 +00:00
talloc_free(vimg->mpi);
vimg->mpi = mpi;
vo_opengl: refactor wayland frame skipping Currently, the wayland backend needs extra work to avoid drawing more often than the wayland frame callback allows. (This is not ideal, but will be fixed at a later time.) Unify this with the start_frame callback added for cocoa. Some details change for the better. For example, if a frame is dropped, and a redraw is done afterwards, the actually correct frame is redrawn, instead whatever was in the textures from before the dropped frame.
2015-05-01 16:44:45 +00:00
p->osd_pts = mpi->pts;
vo_opengl: simplify After recent changes, there is no reason why gl_video_set_image() should exist anymore. So merge it back into gl_video_upload_image().
2015-07-15 10:22:49 +00:00
p->frames_uploaded++;
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
vo_opengl: minor cleanup to hwdec texture setting code Instead of special-casing hwdec in the place where the video textures are used, just set the textures in the image upload function. The renderer code doesn't need to know whether hwdec interop is used at all.
2015-07-26 18:13:53 +00:00
if (p->hwdec_active) {
GLuint imgtex[4] = {0};
bool ok = p->hwdec->driver->map_image(p->hwdec, vimg->mpi, imgtex) >= 0;
for (int n = 0; n < p->plane_count; n++)
vimg->planes[n].gl_texture = ok ? imgtex[n] : -1;
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
return;
vo_opengl: minor cleanup to hwdec texture setting code Instead of special-casing hwdec in the place where the video textures are used, just set the textures in the image upload function. The renderer code doesn't need to know whether hwdec interop is used at all.
2015-07-26 18:13:53 +00:00
}
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
assert(mpi->num_planes == p->plane_count);
vo_opengl: improve robustness against PBO failure If PBO upload fails, disable PBOs and revert to the normal codepath. In theory we should retry PBO upload on failure (because OpenGL specifies that it can sporadically fail), but since it normally doesn't happen, and the fallback will work, I'm not bothering. Some restructuring is needed, since glUnmapBuffer needs to be called earlier. In fact, the old code structure didn't make too much sense, and is a leftover from MPlayer's direct rendering support, which let the decoder decode to a PBO-mapped region. This means the buffer_ptr field can be dropped. Drop buffer_size as well, since it only had 2 possible values (0 or the size required for the current config).
2015-09-02 20:45:07 +00:00
mp_image_t pbo_mpi = *mpi;
bool pbo = map_image(p, &pbo_mpi);
if (pbo) {
mp_image_copy(&pbo_mpi, mpi);
if (unmap_image(p, &pbo_mpi)) {
mpi = &pbo_mpi;
} else {
MP_FATAL(p, "Video PBO upload failed. Disabling PBOs.\n");
pbo = false;
p->opts.pbo = 0;
}
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: improve robustness against PBO failure If PBO upload fails, disable PBOs and revert to the normal codepath. In theory we should retry PBO upload on failure (because OpenGL specifies that it can sporadically fail), but since it normally doesn't happen, and the fallback will work, I'm not bothering. Some restructuring is needed, since glUnmapBuffer needs to be called earlier. In fact, the old code structure didn't make too much sense, and is a leftover from MPlayer's direct rendering support, which let the decoder decode to a PBO-mapped region. This means the buffer_ptr field can be dropped. Drop buffer_size as well, since it only had 2 possible values (0 or the size required for the current config).
2015-09-02 20:45:07 +00:00
vimg->image_flipped = mpi->stride[0] < 0;
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
for (int n = 0; n < p->plane_count; n++) {
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
struct texplane *plane = &vimg->planes[n];
vo_opengl: improve robustness against PBO failure If PBO upload fails, disable PBOs and revert to the normal codepath. In theory we should retry PBO upload on failure (because OpenGL specifies that it can sporadically fail), but since it normally doesn't happen, and the fallback will work, I'm not bothering. Some restructuring is needed, since glUnmapBuffer needs to be called earlier. In fact, the old code structure didn't make too much sense, and is a leftover from MPlayer's direct rendering support, which let the decoder decode to a PBO-mapped region. This means the buffer_ptr field can be dropped. Drop buffer_size as well, since it only had 2 possible values (0 or the size required for the current config).
2015-09-02 20:45:07 +00:00
if (pbo)
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
gl->BindBuffer(GL_PIXEL_UNPACK_BUFFER, plane->gl_buffer);
gl->ActiveTexture(GL_TEXTURE0 + n);
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
gl->BindTexture(p->gl_target, plane->gl_texture);
glUploadTex(gl, p->gl_target, plane->gl_format, plane->gl_type,
vo_opengl: improve robustness against PBO failure If PBO upload fails, disable PBOs and revert to the normal codepath. In theory we should retry PBO upload on failure (because OpenGL specifies that it can sporadically fail), but since it normally doesn't happen, and the fallback will work, I'm not bothering. Some restructuring is needed, since glUnmapBuffer needs to be called earlier. In fact, the old code structure didn't make too much sense, and is a leftover from MPlayer's direct rendering support, which let the decoder decode to a PBO-mapped region. This means the buffer_ptr field can be dropped. Drop buffer_size as well, since it only had 2 possible values (0 or the size required for the current config).
2015-09-02 20:45:07 +00:00
mpi->planes[n], mpi->stride[n], 0, 0, plane->w, plane->h, 0);
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
}
gl->ActiveTexture(GL_TEXTURE0);
vo_opengl: silence an INVALID_ENUM error with GLES2 Signed-off-by: wm4 <wm4@nowhere>
2014-12-20 16:22:36 +00:00
if (pbo)
gl->BindBuffer(GL_PIXEL_UNPACK_BUFFER, 0);
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: require FBOs and get rid of the single-pass optimization This change makes vo_opengl slightly less compatible (ancient devices without FBOs will no longer work) and decreases performance in the simplest case (vo=opengl), in exchange for significantly reducing code complexity and making everything easier to reason about.
2015-09-05 09:39:20 +00:00
static bool test_fbo(struct gl_video *p)
gl_video: add some debug code for testing texture depth This probes and prints the depth of some texture formats with the help of a FBO. By default it tests the format used for scaling, as well as the format used for dithering and the 3D LUT (if any of these are enabled). The output is visible only with -v. Some representative values are probed, and the difference of input and output value is printed as hex- float. Hex-floats are used because they make the implied precision more obvious. Originally I wanted to do some more sophisticated guessing of the implied depth/precision for more user-friendly reporting, but then I decided that printing raw data is better for debugging, especially if things go wrong. This does not try to disable any functionality and does not print any warnings if the depth is lower than what it should be.
2013-05-30 13:37:13 +00:00
{
GL *gl = p->gl;
vo_opengl: require FBOs and get rid of the single-pass optimization This change makes vo_opengl slightly less compatible (ancient devices without FBOs will no longer work) and decreases performance in the simplest case (vo=opengl), in exchange for significantly reducing code complexity and making everything easier to reason about.
2015-09-05 09:39:20 +00:00
bool success = false;
vo_opengl: test FBOs only if they're going to be used Change test_fbo() so that it checks the FBO lazily, and restructure check_gl_features() to invoke it only if we know that a FBO will be needed for a certain enabled feature. This can avoid strange error messages when using --vo=opengl and the FBO format does not work. It's also less confusing when reading the verbose log (users might think that the FBO is actually used, etc.).
2015-02-26 09:35:49 +00:00
MP_VERBOSE(p, "Testing user-set FBO format (0x%x)\n",
(unsigned)p->opts.fbo_format);
gl_video: add some debug code for testing texture depth This probes and prints the depth of some texture formats with the help of a FBO. By default it tests the format used for scaling, as well as the format used for dithering and the 3D LUT (if any of these are enabled). The output is visible only with -v. Some representative values are probed, and the difference of input and output value is printed as hex- float. Hex-floats are used because they make the implied precision more obvious. Originally I wanted to do some more sophisticated guessing of the implied depth/precision for more user-friendly reporting, but then I decided that printing raw data is better for debugging, especially if things go wrong. This does not try to disable any functionality and does not print any warnings if the depth is lower than what it should be.
2013-05-30 13:37:13 +00:00
struct fbotex fbo = {0};
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
if (fbotex_init(&fbo, p->gl, p->log, 16, 16, p->opts.fbo_format)) {
gl_video: add some debug code for testing texture depth This probes and prints the depth of some texture formats with the help of a FBO. By default it tests the format used for scaling, as well as the format used for dithering and the 3D LUT (if any of these are enabled). The output is visible only with -v. Some representative values are probed, and the difference of input and output value is printed as hex- float. Hex-floats are used because they make the implied precision more obvious. Originally I wanted to do some more sophisticated guessing of the implied depth/precision for more user-friendly reporting, but then I decided that printing raw data is better for debugging, especially if things go wrong. This does not try to disable any functionality and does not print any warnings if the depth is lower than what it should be.
2013-05-30 13:37:13 +00:00
gl->BindFramebuffer(GL_FRAMEBUFFER, fbo.fbo);
gl->BindFramebuffer(GL_FRAMEBUFFER, 0);
vo_opengl: require FBOs and get rid of the single-pass optimization This change makes vo_opengl slightly less compatible (ancient devices without FBOs will no longer work) and decreases performance in the simplest case (vo=opengl), in exchange for significantly reducing code complexity and making everything easier to reason about.
2015-09-05 09:39:20 +00:00
success = true;
gl_video: add some debug code for testing texture depth This probes and prints the depth of some texture formats with the help of a FBO. By default it tests the format used for scaling, as well as the format used for dithering and the 3D LUT (if any of these are enabled). The output is visible only with -v. Some representative values are probed, and the difference of input and output value is printed as hex- float. Hex-floats are used because they make the implied precision more obvious. Originally I wanted to do some more sophisticated guessing of the implied depth/precision for more user-friendly reporting, but then I decided that printing raw data is better for debugging, especially if things go wrong. This does not try to disable any functionality and does not print any warnings if the depth is lower than what it should be.
2013-05-30 13:37:13 +00:00
}
vo_opengl: move FBO helper to gl_utils This is somewhat messy, because fbotex_init() itself was depending on some gl_video parameters unrelated to FBO creation (like what scaler was in use - what the fuck did this check do in this function?), so this commit does a bit more than moving code around. In particular, the FBO for the separate scaling intermediate step now always uses GL_NEAREST sampling, and all FBOs are destroyed/recreated on renderer reinitialization. This also moves the function matrix_ortho2d() - trivial enough not to put it into a separate commit.
2015-01-29 13:58:26 +00:00
fbotex_uninit(&fbo);
gl_common: complete mp_msg conversion Hopefully this works on Wayland and Cocoa, which I didn't test.
2013-09-11 22:57:32 +00:00
glCheckError(gl, p->log, "FBO test");
vo_opengl: require FBOs and get rid of the single-pass optimization This change makes vo_opengl slightly less compatible (ancient devices without FBOs will no longer work) and decreases performance in the simplest case (vo=opengl), in exchange for significantly reducing code complexity and making everything easier to reason about.
2015-09-05 09:39:20 +00:00
return success;
gl_video: add some debug code for testing texture depth This probes and prints the depth of some texture formats with the help of a FBO. By default it tests the format used for scaling, as well as the format used for dithering and the 3D LUT (if any of these are enabled). The output is visible only with -v. Some representative values are probed, and the difference of input and output value is printed as hex- float. Hex-floats are used because they make the implied precision more obvious. Originally I wanted to do some more sophisticated guessing of the implied depth/precision for more user-friendly reporting, but then I decided that printing raw data is better for debugging, especially if things go wrong. This does not try to disable any functionality and does not print any warnings if the depth is lower than what it should be.
2013-05-30 13:37:13 +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
// Disable features that are not supported with the current OpenGL version.
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
static void check_gl_features(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
{
GL *gl = p->gl;
bool have_float_tex = gl->mpgl_caps & MPGL_CAP_FLOAT_TEX;
bool have_fbo = gl->mpgl_caps & MPGL_CAP_FB;
vo_opengl: clean up ewa_lanczos code This fixes compatibility with GLES 2.0 and makes the code a bit neater in general. It also properly forces indirect scaling for subsampled video regardless of the lscale setting.
2015-01-17 16:28:47 +00:00
bool have_1d_tex = gl->mpgl_caps & MPGL_CAP_1D_TEX;
vo_opengl: don't allow setting 3D LUT if unsupported The code was always uploading the 3D LUT (even of unused), as long as vo_opengl was setting a icc-profile. This could crash with GLES 2.
2014-12-23 01:48:58 +00:00
bool have_3d_tex = gl->mpgl_caps & MPGL_CAP_3D_TEX;
vo_opengl: Correct and clarify gl_check_features This updates the logic for the new, somewhat unified behavior of SRGB and 3DLUT since 34bf9be (not that it was particularly correct even that change) and checks for the presence of corresponding extensions only in the cases in which they're needed.
2014-03-05 14:01:32 +00:00
bool have_mix = gl->glsl_version >= 130;
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: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
if (gl->es && p->opts.pbo) {
p->opts.pbo = 0;
MP_WARN(p, "Disabling PBOs (GLES unsupported).\n");
}
if (p->opts.dumb_mode || gl->es || !have_fbo || !test_fbo(p)) {
if (!p->opts.dumb_mode) {
MP_WARN(p, "High bit depth FBOs unsupported. Enabling dumb mode.\n"
"Most extended features will be disabled.\n");
}
p->use_lut_3d = false;
vo_opengl: filter allowed options in dumb-mode Instead of the other way around of disabling disallowed options. This is more robust and also slightly simpler, at least conceptually. If new vo_opengl features are added, they don't need to be explicitly disabled for dumb-mode just to avoid that it accidentally breaks.
2015-09-08 20:55:01 +00:00
// Most things don't work, so whitelist all options that still work.
struct gl_video_opts new_opts = {
.gamma = p->opts.gamma,
.gamma_auto = p->opts.gamma_auto,
.pbo = p->opts.pbo,
.fbo_format = p->opts.fbo_format,
.alpha_mode = p->opts.alpha_mode,
.use_rectangle = p->opts.use_rectangle,
.background = p->opts.background,
.dither_algo = -1,
.dumb_mode = 1,
};
assign_options(&p->opts, &new_opts);
vo_opengl: fix deband sub-option handling This all has to be done manually.
2015-09-09 18:40:04 +00:00
p->opts.deband_opts = m_config_alloc_struct(NULL, &deband_conf);
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
return;
vo_opengl: require FBOs and get rid of the single-pass optimization This change makes vo_opengl slightly less compatible (ancient devices without FBOs will no longer work) and decreases performance in the simplest case (vo=opengl), in exchange for significantly reducing code complexity and making everything easier to reason about.
2015-09-05 09:39:20 +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
// Normally, we want to disable them by default if FBOs are unavailable,
// because they will be slow (not critically slow, but still slower).
// Without FP textures, we must always disable them.
vo_opengl: remove requirement for RG textures Features not supported are disabled (although with a misleading error message).
2014-12-16 17:55:02 +00:00
// I don't know if luminance alpha float textures exist, so disregard them.
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
for (int n = 0; n < 4; n++) {
const struct filter_kernel *kernel =
mp_find_filter_kernel(p->opts.scaler[n].kernel.name);
vo_opengl: test FBOs only if they're going to be used Change test_fbo() so that it checks the FBO lazily, and restructure check_gl_features() to invoke it only if we know that a FBO will be needed for a certain enabled feature. This can avoid strange error messages when using --vo=opengl and the FBO format does not work. It's also less confusing when reading the verbose log (users might think that the FBO is actually used, etc.).
2015-02-26 09:35:49 +00:00
if (kernel) {
char *reason = NULL;
if (!have_float_tex)
vo_opengl: slightly more informative message when disabling scalers
2015-07-27 21:18:19 +00:00
reason = "(float tex. missing)";
vo_opengl: test FBOs only if they're going to be used Change test_fbo() so that it checks the FBO lazily, and restructure check_gl_features() to invoke it only if we know that a FBO will be needed for a certain enabled feature. This can avoid strange error messages when using --vo=opengl and the FBO format does not work. It's also less confusing when reading the verbose log (users might think that the FBO is actually used, etc.).
2015-02-26 09:35:49 +00:00
if (!have_1d_tex && kernel->polar)
vo_opengl: slightly more informative message when disabling scalers
2015-07-27 21:18:19 +00:00
reason = "(1D tex. missing)";
vo_opengl: test FBOs only if they're going to be used Change test_fbo() so that it checks the FBO lazily, and restructure check_gl_features() to invoke it only if we know that a FBO will be needed for a certain enabled feature. This can avoid strange error messages when using --vo=opengl and the FBO format does not work. It's also less confusing when reading the verbose log (users might think that the FBO is actually used, etc.).
2015-02-26 09:35:49 +00:00
if (reason) {
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
p->opts.scaler[n].kernel.name = "bilinear";
vo_opengl: slightly more informative message when disabling scalers
2015-07-27 21:18:19 +00:00
MP_WARN(p, "Disabling scaler #%d %s.\n", n, reason);
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: add GLES 2 support Rather basic support. Almost nothing works, and even if it does, it's bound to be inefficient (due to texture upload). This was tested with the nVidia desktop binary drivers, which provide GLES 2 support only. However, nVidia is not known to be very strict about OpenGL, and the driver is very new too, so the vo_opengl code will have bugs too.
2014-12-19 00:03:08 +00:00
// GLES3 doesn't provide filtered 16 bit integer textures
// GLES2 doesn't even provide 3D textures
vo_opengl: don't allow setting 3D LUT if unsupported The code was always uploading the 3D LUT (even of unused), as long as vo_opengl was setting a icc-profile. This could crash with GLES 2.
2014-12-23 01:48:58 +00:00
if (p->use_lut_3d && !(have_3d_tex && have_float_tex)) {
vo_opengl: GLES 3 support Tested with MESA on software emulation. Seems to work well, although the default FBO format in opengl-hq disables most interesting features. I have no idea how well it will work on real hardware (or if it does at all). Unfortunately, some features, including playback of 10 bit video, are not supported. Not sure what to do about this. GLES 2 or 1 do not work.
2014-12-17 20:48:23 +00:00
p->use_lut_3d = false;
vo_opengl: slightly simplify check_gl_features() Not sure why this was so roundabout; probably to keep spam down if the user's OpenGL drivers are crap (but then just don't enable extended features), or because the "Disabling..." text was so repetitious. But there doesn't seem to be a good reason after all. Also, this could already overflow the fixed size disabled[] array. Just print the messages directly.
2015-04-11 17:24:54 +00:00
MP_WARN(p, "Disabling color management (GLES unsupported).\n");
vo_opengl: GLES 3 support Tested with MESA on software emulation. Seems to work well, although the default FBO format in opengl-hq disables most interesting features. I have no idea how well it will work on real hardware (or if it does at all). Unfortunately, some features, including playback of 10 bit video, are not supported. Not sure what to do about this. GLES 2 or 1 do not work.
2014-12-17 20:48:23 +00:00
}
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
int use_cms = p->opts.target_prim != MP_CSP_PRIM_AUTO ||
p->opts.target_trc != MP_CSP_TRC_AUTO || p->use_lut_3d;
vo_opengl: Correct and clarify gl_check_features This updates the logic for the new, somewhat unified behavior of SRGB and 3DLUT since 34bf9be (not that it was particularly correct even that change) and checks for the presence of corresponding extensions only in the cases in which they're needed.
2014-03-05 14:01:32 +00:00
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
// mix() is needed for some gamma functions
if (!have_mix && (p->opts.linear_scaling || p->opts.sigmoid_upscaling)) {
p->opts.linear_scaling = false;
p->opts.sigmoid_upscaling = false;
vo_opengl: slightly simplify check_gl_features() Not sure why this was so roundabout; probably to keep spam down if the user's OpenGL drivers are crap (but then just don't enable extended features), or because the "Disabling..." text was so repetitious. But there doesn't seem to be a good reason after all. Also, this could already overflow the fixed size disabled[] array. Just print the messages directly.
2015-04-11 17:24:54 +00:00
MP_WARN(p, "Disabling linear/sigmoid scaling (GLSL version too old).\n");
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
}
if (!have_mix && use_cms) {
p->opts.target_prim = MP_CSP_PRIM_AUTO;
p->opts.target_trc = MP_CSP_TRC_AUTO;
p->use_lut_3d = false;
vo_opengl: slightly simplify check_gl_features() Not sure why this was so roundabout; probably to keep spam down if the user's OpenGL drivers are crap (but then just don't enable extended features), or because the "Disabling..." text was so repetitious. But there doesn't seem to be a good reason after all. Also, this could already overflow the fixed size disabled[] array. Just print the messages directly.
2015-04-11 17:24:54 +00:00
MP_WARN(p, "Disabling color management (GLSL version too old).\n");
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: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
static void init_gl(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
{
GL *gl = p->gl;
debug_check_gl(p, "before init_gl");
gl->Disable(GL_DITHER);
vo_opengl: create abstraction for VAOs Handles stupid boilerplate OpenGL requires you to handle. It's the same code as in gl_video.c, although if no VAOs are available, the fallback code rebinds them on every draw call instead of just once.
2015-01-28 21:22:29 +00:00
gl_vao_init(&p->vao, gl, sizeof(struct vertex), vertex_vao);
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
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
gl_video_set_gl_state(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
vo_opengl: don't use 10 bit video on Intel GPUs vo_opengl was originally written against OpenGL 3 core, and it seems GPUs/drivers supporting this are mostly sane. Later, it was made to work with OpenGL 2.1 too. Lately we removed the requirement for RG textures, and look, someone reported a problem with "lesser" Intel GPUs. This commit does the same in vo_opengl what was added to vo_opengl_old a long time ago. Fixes #1383.
2014-12-24 15:54:47 +00:00
// Test whether we can use 10 bit. Hope that testing a single format/channel
// is good enough (instead of testing all 1-4 channels variants etc.).
const struct fmt_entry *fmt = find_tex_format(gl, 2, 1);
if (gl->GetTexLevelParameteriv && fmt->format) {
GLuint tex;
gl->GenTextures(1, &tex);
gl->BindTexture(GL_TEXTURE_2D, tex);
gl->TexImage2D(GL_TEXTURE_2D, 0, fmt->internal_format, 64, 64, 0,
fmt->format, fmt->type, NULL);
GLenum pname = 0;
switch (fmt->format) {
case GL_RED: pname = GL_TEXTURE_RED_SIZE; break;
case GL_LUMINANCE: pname = GL_TEXTURE_LUMINANCE_SIZE; break;
}
GLint param = 0;
if (pname)
gl->GetTexLevelParameteriv(GL_TEXTURE_2D, 0, pname, &param);
if (param) {
MP_VERBOSE(p, "16 bit texture depth: %d.\n", (int)param);
p->texture_16bit_depth = param;
}
vo_opengl: delete 16 bit test texture Essentially a leak, but not that bad since it's small and allocated only once.
2015-02-27 21:13:15 +00:00
gl->DeleteTextures(1, &tex);
vo_opengl: don't use 10 bit video on Intel GPUs vo_opengl was originally written against OpenGL 3 core, and it seems GPUs/drivers supporting this are mostly sane. Later, it was made to work with OpenGL 2.1 too. Lately we removed the requirement for RG textures, and look, someone reported a problem with "lesser" Intel GPUs. This commit does the same in vo_opengl what was added to vo_opengl_old a long time ago. Fixes #1383.
2014-12-24 15:54:47 +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
debug_check_gl(p, "after init_gl");
}
void gl_video_uninit(struct gl_video *p)
{
vo_opengl: make uninit idempotent
2014-12-03 21:37:39 +00:00
if (!p)
return;
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
GL *gl = p->gl;
uninit_video(p);
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
gl_sc_destroy(p->sc);
vo_opengl: create abstraction for VAOs Handles stupid boilerplate OpenGL requires you to handle. It's the same code as in gl_video.c, although if no VAOs are available, the fallback code rebinds them on every draw call instead of just once.
2015-01-28 21:22:29 +00:00
gl_vao_uninit(&p->vao);
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
gl->DeleteTextures(1, &p->lut_3d_texture);
mpgl_osd_destroy(p->osd);
vo_opengl: some minor cleanups default_tex_params() and texture_size() are each called only once, so move inline/reimplement them at the caller. image_dw/dh were unused. texture_w/h, image_format, and component_bits were rarely used, and can be replaced. Regroup some other fields. Rename surface_num to surface_idx, because the former sounded like a count, and not an index. Move fbosurface_next() closer to its callers too. Move the DebugMessageCallback() code to gl_utils.c (also simplify it by always setting the callback, instead of only when it changes).
2015-01-29 14:50:21 +00:00
gl_set_debug_logger(gl, NULL);
vo_opengl: make use of newer OpenGL logging API GL_ARB_debug_output provides a logging callback, which can be used to diagnose problems etc. in case the driver supports it. It's enabled only if the vo_opengl "debug" suboption is set.
2014-12-23 01:46:44 +00:00
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
assign_options(&p->opts, &(struct gl_video_opts){0});
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
talloc_free(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
void gl_video_set_gl_state(struct gl_video *p)
{
GL *gl = p->gl;
gl->ActiveTexture(GL_TEXTURE0);
vo_opengl: don't reset unused GL_PACK_... state
2015-01-22 17:54:05 +00:00
if (gl->mpgl_caps & MPGL_CAP_ROW_LENGTH)
vo_opengl: mess with PixelStorei state management This is needed for GLES 2 support. GLES 2 doesn't support GL_UNPACK_ROW_LENGTH, and we shouldn't even use this constant, since a GLES implementation could raise an error. So set it only if neccessary, and leave it in the default state otherwise. This also smuggles in a ES 2 fallback for glUploadTex(), and querying an extension relevant for ES 2. For the alignment state (GL_[UN]PACK_ALIGNMENT) do the same for symmetry. All 4 states (alignment/rows x pack/unpack) are now assumed to be in their initial states by default. Also redo the PixelStorei handling in the function table. I could rebase this, but look at the commit time.
2014-12-18 23:58:56 +00:00
gl->PixelStorei(GL_UNPACK_ROW_LENGTH, 0);
gl->PixelStorei(GL_UNPACK_ALIGNMENT, 4);
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
}
void gl_video_unset_gl_state(struct gl_video *p)
{
vo_opengl: create abstraction for VAOs Handles stupid boilerplate OpenGL requires you to handle. It's the same code as in gl_video.c, although if no VAOs are available, the fallback code rebinds them on every draw call instead of just once.
2015-01-28 21:22:29 +00:00
/* nop */
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_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: 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
gl_video_reset_surfaces(p);
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
}
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)
{
return p->is_interpolated;
}
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
// dest = src.<w> (always using 4 components)
vo_opengl: remove requirement for RG textures Features not supported are disabled (although with a misleading error message).
2014-12-16 17:55:02 +00:00
static void packed_fmt_swizzle(char w[5], const struct fmt_entry *texfmt,
const struct packed_fmt_entry *fmt)
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
{
vo_opengl: remove requirement for RG textures Features not supported are disabled (although with a misleading error message).
2014-12-16 17:55:02 +00:00
const char *comp = "rgba";
vo_opengl: simplify the case without texture_rg If GL_RED was not available, we used GL_ALPHA. But this is an unnecessary complication, and it's easier to use GL_LUMINANCE instead. With the latter, a texture will return the .r component set, and as long as the shader doesn't look at the other components, the shader doesn't need any changes. Some of the changes added in 0e8fbdbd are now unneeeded. Also, realign the entire gl_byte_formats_legacy table.
2014-12-18 13:46:19 +00:00
// Normally, we work with GL_RG
vo_opengl: remove requirement for RG textures Features not supported are disabled (although with a misleading error message).
2014-12-16 17:55:02 +00:00
if (texfmt && texfmt->internal_format == GL_LUMINANCE_ALPHA)
comp = "ragb";
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
for (int c = 0; c < 4; c++)
vo_opengl: remove requirement for RG textures Features not supported are disabled (although with a misleading error message).
2014-12-16 17:55:02 +00:00
w[c] = comp[MPMAX(fmt->components[c] - 1, 0)];
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
w[4] = '\0';
}
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
static bool init_format(int fmt, struct gl_video *init)
{
vo_opengl: remove requirement for RG textures Features not supported are disabled (although with a misleading error message).
2014-12-16 17:55:02 +00:00
struct GL *gl = init->gl;
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
init->hwdec_active = false;
gl_hwdec: use a imgfmt field instead of a query_format callback Now that vdpau always uses a single image format, this can be simplified.
2013-11-29 13:19:51 +00:00
if (init->hwdec && init->hwdec->driver->imgfmt == fmt) {
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
fmt = init->hwdec->converted_imgfmt;
init->hwdec_active = true;
}
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_imgfmt_desc desc = mp_imgfmt_get_desc(fmt);
if (!desc.id)
return false;
gl_video: make it possible for planes to have different formats Preparation for NV12 support. Also adds support for IMGFMT_YA8.
2013-03-28 19:48:53 +00:00
if (desc.num_planes > 4)
return false;
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
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
const struct fmt_entry *plane_format[4] = {0};
gl_video: make it possible for planes to have different formats Preparation for NV12 support. Also adds support for IMGFMT_YA8.
2013-03-28 19:48:53 +00:00
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
init->color_swizzle[0] = '\0';
init->has_alpha = false;
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
// YUV/planar formats
vo_opengl: minor simplification I think this is easier to follow.
2014-03-01 14:40:46 +00:00
if (desc.flags & MP_IMGFLAG_YUV_P) {
vo_opengl: handle grayscale input better, add YA16 support Simply clamp off the U/V components in the colormatrix, instead of doing something special in the shader. Also, since YA8/YA16 gave a plane_bits value of 16/32, and a colormatrix calculation overflowed with 32, add a component_bits field to the image format descriptor, which for YA8/YA16 returns 8/16 (the wrong value had no bad consequences otherwise).
2015-01-21 18:29:18 +00:00
int bits = desc.component_bits;
gl_video: make it possible for planes to have different formats Preparation for NV12 support. Also adds support for IMGFMT_YA8.
2013-03-28 19:48:53 +00:00
if ((desc.flags & MP_IMGFLAG_NE) && bits >= 8 && bits <= 16) {
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
init->has_alpha = desc.num_planes > 3;
vo_opengl: remove requirement for RG textures Features not supported are disabled (although with a misleading error message).
2014-12-16 17:55:02 +00:00
plane_format[0] = find_tex_format(gl, (bits + 7) / 8, 1);
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
for (int p = 1; p < desc.num_planes; p++)
plane_format[p] = plane_format[0];
vo_opengl: minor simplification I think this is easier to follow.
2014-03-01 14:40:46 +00:00
goto supported;
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
}
}
gl_video: add support for NV12 There's really no reason for this, but it feels nice being able to support a weird pixel format.
2013-03-28 20:02:41 +00:00
// YUV/half-packed
vo_opengl: minor simplification I think this is easier to follow.
2014-03-01 14:40:46 +00:00
if (fmt == IMGFMT_NV12 || fmt == IMGFMT_NV21) {
vo_opengl: remove requirement for RG textures Features not supported are disabled (although with a misleading error message).
2014-12-16 17:55:02 +00:00
if (!(init->gl->mpgl_caps & MPGL_CAP_TEX_RG))
return false;
plane_format[0] = find_tex_format(gl, 1, 1);
plane_format[1] = find_tex_format(gl, 1, 2);
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
if (fmt == IMGFMT_NV21)
snprintf(init->color_swizzle, sizeof(init->color_swizzle), "rbga");
vo_opengl: minor simplification I think this is easier to follow.
2014-03-01 14:40:46 +00:00
goto supported;
gl_video: add support for NV12 There's really no reason for this, but it feels nice being able to support a weird pixel format.
2013-03-28 20:02:41 +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
// RGB/planar
vo_opengl: minor simplification I think this is easier to follow.
2014-03-01 14:40:46 +00:00
if (fmt == IMGFMT_GBRP) {
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
snprintf(init->color_swizzle, sizeof(init->color_swizzle), "brga");
vo_opengl: remove requirement for RG textures Features not supported are disabled (although with a misleading error message).
2014-12-16 17:55:02 +00:00
plane_format[0] = find_tex_format(gl, 1, 1);
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
for (int p = 1; p < desc.num_planes; p++)
plane_format[p] = plane_format[0];
vo_opengl: minor simplification I think this is easier to follow.
2014-03-01 14:40:46 +00:00
goto supported;
gl_video: make it possible for planes to have different formats Preparation for NV12 support. Also adds support for IMGFMT_YA8.
2013-03-28 19:48:53 +00:00
}
gl_video: typo in comment
2013-06-14 20:58:21 +00:00
// XYZ (same organization as RGB packed, but requires conversion matrix)
vo_opengl: minor simplification I think this is easier to follow.
2014-03-01 14:40:46 +00:00
if (fmt == IMGFMT_XYZ12) {
vo_opengl: remove requirement for RG textures Features not supported are disabled (although with a misleading error message).
2014-12-16 17:55:02 +00:00
plane_format[0] = find_tex_format(gl, 2, 3);
vo_opengl: minor simplification I think this is easier to follow.
2014-03-01 14:40:46 +00:00
goto supported;
vo_opengl: XYZ input support Useful for the j2k decoder. Matrix taken from http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html (XYZ to sRGB, whitepoint D65) Gamma conversion follows what libswscale does (2.6 in, 2.2 out). If linear RGB is used internally for scaling, the gamma conversion will be undone by setting the exponent to 1. Unfortunately, the two gamma values don't compensate each others exactly (2.2 vs. 1/0.45=2.22...), so output is a little bit incorrect in sRGB or color-managed mode. But for now try hard to match libswscale output, which may or may not be correct.
2013-05-01 21:59:00 +00:00
}
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
// Packed RGB special formats
vo_opengl: minor simplification I think this is easier to follow.
2014-03-01 14:40:46 +00:00
for (const struct fmt_entry *e = mp_to_gl_formats; e->mp_format; e++) {
vo_opengl: GLES does not support GL_BGRA Apparently GLES 2 and 3 do not support this. (The implementations I tested with were derived from desktop OpenGL and were not overly strict with this.) This is no problem; just use GL_RGBA and mangle the channels in the shader. Also disable direct support for image formats like IMGFMT_RGB555 with GLES; at least some of them are not supported in this form, and the formats aren't important anyway.
2014-12-20 18:23:17 +00:00
if (!gl->es && e->mp_format == fmt) {
vo_opengl: minor simplification I think this is easier to follow.
2014-03-01 14:40:46 +00:00
plane_format[0] = e;
goto supported;
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +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
}
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
// Packed RGB(A) formats
vo_opengl: minor simplification I think this is easier to follow.
2014-03-01 14:40:46 +00:00
for (const struct packed_fmt_entry *e = mp_packed_formats; e->fmt; e++) {
if (e->fmt == fmt) {
int n_comp = desc.bytes[0] / e->component_size;
vo_opengl: remove requirement for RG textures Features not supported are disabled (although with a misleading error message).
2014-12-16 17:55:02 +00:00
plane_format[0] = find_tex_format(gl, e->component_size, n_comp);
packed_fmt_swizzle(init->color_swizzle, plane_format[0], e);
vo_opengl: minor simplification I think this is easier to follow.
2014-03-01 14:40:46 +00:00
init->has_alpha = e->components[3] != 0;
goto supported;
gl_video: make it possible for planes to have different formats Preparation for NV12 support. Also adds support for IMGFMT_YA8.
2013-03-28 19:48:53 +00:00
}
}
gl_video: support packed YUV formats with Apple extensions This adds support for packed YUV formats (YUVY and UYVY) using the extension GL_APPLE_rgb_422. While supporting this formats on their own is not that important (considering most video is planar YUV) they are used for interoperability with IOSurfaces. Next commit will use this formats to render VDA hardware decoded frames through IOSurface and OpenGL interoperability.
2013-11-13 20:52:34 +00:00
// Packed YUV Apple formats
if (init->gl->mpgl_caps & MPGL_CAP_APPLE_RGB_422) {
for (const struct fmt_entry *e = gl_apple_formats; e->mp_format; e++) {
if (e->mp_format == fmt) {
init->is_packed_yuv = true;
snprintf(init->color_swizzle, sizeof(init->color_swizzle),
"gbra");
plane_format[0] = e;
vo_opengl: minor simplification I think this is easier to follow.
2014-03-01 14:40:46 +00:00
goto supported;
gl_video: support packed YUV formats with Apple extensions This adds support for packed YUV formats (YUVY and UYVY) using the extension GL_APPLE_rgb_422. While supporting this formats on their own is not that important (considering most video is planar YUV) they are used for interoperability with IOSurfaces. Next commit will use this formats to render VDA hardware decoded frames through IOSurface and OpenGL interoperability.
2013-11-13 20:52:34 +00:00
}
}
}
vo_opengl: minor simplification I think this is easier to follow.
2014-03-01 14:40:46 +00:00
// Unsupported format
return false;
supported:
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
vo_opengl: add alpha output Allows playing video with alpha information on X11, as long as the video contains alpha and the window manager does compositing. See vo.rst. Whether a window can be transparent is decided by the choice of the X Visual used for window creation. Unfortunately, there's no direct way to request such a Visual through the GLX or the X API, and use of the XRender extension is required to find out whether a Visual implies a framebuffer with alpha used by XRender (see for example [1]). Instead of depending on the XRender wrapper library (which would require annoying configure checks, even though XRender is virtually always supported), use a simple heuristics to find out whether a Visual has alpha. Since getting it wrong just means an optional feature will not work as expected, we consider this ok. [1] http://stackoverflow.com/questions/4052940/how-to-make-an-opengl- rendering-context-with-transparent-background/9215724#9215724
2013-03-28 20:44:27 +00:00
// Stuff like IMGFMT_420AP10. Untested, most likely insane.
vo_opengl: some minor cleanups default_tex_params() and texture_size() are each called only once, so move inline/reimplement them at the caller. image_dw/dh were unused. texture_w/h, image_format, and component_bits were rarely used, and can be replaced. Regroup some other fields. Rename surface_num to surface_idx, because the former sounded like a count, and not an index. Move fbosurface_next() closer to its callers too. Move the DebugMessageCallback() code to gl_utils.c (also simplify it by always setting the callback, instead of only when it changes).
2015-01-29 14:50:21 +00:00
if (desc.num_planes == 4 && (desc.component_bits % 8) != 0)
vo_opengl: add alpha output Allows playing video with alpha information on X11, as long as the video contains alpha and the window manager does compositing. See vo.rst. Whether a window can be transparent is decided by the choice of the X Visual used for window creation. Unfortunately, there's no direct way to request such a Visual through the GLX or the X API, and use of the XRender extension is required to find out whether a Visual implies a framebuffer with alpha used by XRender (see for example [1]). Instead of depending on the XRender wrapper library (which would require annoying configure checks, even though XRender is virtually always supported), use a simple heuristics to find out whether a Visual has alpha. Since getting it wrong just means an optional feature will not work as expected, we consider this ok. [1] http://stackoverflow.com/questions/4052940/how-to-make-an-opengl- rendering-context-with-transparent-background/9215724#9215724
2013-03-28 20:44:27 +00:00
return false;
vo_opengl: some minor cleanups default_tex_params() and texture_size() are each called only once, so move inline/reimplement them at the caller. image_dw/dh were unused. texture_w/h, image_format, and component_bits were rarely used, and can be replaced. Regroup some other fields. Rename surface_num to surface_idx, because the former sounded like a count, and not an index. Move fbosurface_next() closer to its callers too. Move the DebugMessageCallback() code to gl_utils.c (also simplify it by always setting the callback, instead of only when it changes).
2015-01-29 14:50:21 +00:00
if (desc.component_bits > 8 && desc.component_bits < 16) {
vo_opengl: don't use 10 bit video on Intel GPUs vo_opengl was originally written against OpenGL 3 core, and it seems GPUs/drivers supporting this are mostly sane. Later, it was made to work with OpenGL 2.1 too. Lately we removed the requirement for RG textures, and look, someone reported a problem with "lesser" Intel GPUs. This commit does the same in vo_opengl what was added to vo_opengl_old a long time ago. Fixes #1383.
2014-12-24 15:54:47 +00:00
if (init->texture_16bit_depth < 16)
return false;
}
vo_opengl: GLES 3 support Tested with MESA on software emulation. Seems to work well, although the default FBO format in opengl-hq disables most interesting features. I have no idea how well it will work on real hardware (or if it does at all). Unfortunately, some features, including playback of 10 bit video, are not supported. Not sure what to do about this. GLES 2 or 1 do not work.
2014-12-17 20:48:23 +00:00
for (int p = 0; p < desc.num_planes; p++) {
if (!plane_format[p]->format)
return false;
}
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
for (int p = 0; p < desc.num_planes; p++) {
struct texplane *plane = &init->image.planes[p];
const struct fmt_entry *format = plane_format[p];
assert(format);
plane->gl_format = format->format;
plane->gl_internal_format = format->internal_format;
plane->gl_type = format->type;
}
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
init->is_yuv = desc.flags & MP_IMGFLAG_YUV;
gl_video: use GL_SRGB only if it's really RGB Use the proper RGB flag instead of !YUV. Currently, this doesn't change anything, because only RGB and YUV formats are supported.
2013-05-01 21:13:39 +00:00
init->is_rgb = desc.flags & MP_IMGFLAG_RGB;
gl_video: always upload all planes When displaying YUV with alpha plane (an extremely rare special case), we didn't upload the alpha plane, because we don't do anything with it. This actually created some annoying special cases, so upload the alpha planes as well, even if they're unused.
2013-03-28 20:02:53 +00:00
init->plane_count = desc.num_planes;
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
init->image_desc = desc;
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
return true;
}
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)
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: 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
struct gl_video tmp = *p;
return init_format(mp_format, &tmp);
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
}
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: 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: simplify screenshot code Instead of reading back the image from textures, keep a reference to the original image, and return that. The main reason this was done this way was that originally, images weren't refcounted, and would be deallocated or overwritten as soon as the VO's draw call returned. But now there isn't really a good reason for this anymore. One possibly _could_ argue that it was better because other code could reuse the image sooner (e.g. for the cache), but on the other hand, the VO runs already on a different thread, and filtering and decoding each run on other threads too, so this argument probably wouldn't hold up.
2015-01-22 17:29:37 +00:00
mp_image_unrefp(&p->image.mpi);
vo_opengl: redo aspects of initialization, change hwdec API Instead of checking for resolution and image format changes, always fully reinit on any parameter change. Let init_video do all required initializations, which simplifies things a little bit. Change the gl_video/hardware decoding interop API slightly, so that hwdec initialization gets the full image parameters. Also make some cosmetic changes.
2013-11-05 18:08:44 +00:00
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
if (!mp_image_params_equal(&p->real_image_params, params)) {
vo_opengl: redo aspects of initialization, change hwdec API Instead of checking for resolution and image format changes, always fully reinit on any parameter change. Let init_video do all required initializations, which simplifies things a little bit. Change the gl_video/hardware decoding interop API slightly, so that hwdec initialization gets the full image parameters. Also make some cosmetic changes.
2013-11-05 18:08:44 +00:00
uninit_video(p);
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
p->real_image_params = *params;
p->image_params = *params;
vo_opengl_cb: simplify reconfigure, render transparent if unconfigured I think that's expected; mpv shouldn't draw anything while no video is active. This doesn't blend transparently, though. Also document the vo_opengl_cb thing.
2014-12-09 20:36:45 +00:00
if (params->imgfmt)
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
init_video(p);
vo_opengl: redo aspects of initialization, change hwdec API Instead of checking for resolution and image format changes, always fully reinit on any parameter change. Let init_video do all required initializations, which simplifies things a little bit. Change the gl_video/hardware decoding interop API slightly, so that hwdec initialization gets the full image parameters. Also make some cosmetic changes.
2013-11-05 18:08:44 +00:00
}
vo_opengl: initialize renderer after setting size This silences the warning: video/out/gl_video.c:1091:51: runtime error: division by zero when running with clang -fsanitize=undefined. Division by zero is legal according to IEEE, but I guess clang doesn't care about standard. While triggering this warning isn't actually avoided in all cases, it's avoided in the common case and also makes people shut up about it.
2014-11-07 14:28:12 +00:00
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
gl_video_reset_surfaces(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
}
void gl_video_set_output_depth(struct gl_video *p, int r, int g, int b)
{
video/out: use new mp_msg stuff for vo.c and vo_opengl The first step; also serves as example.
2013-07-31 19:44:21 +00:00
MP_VERBOSE(p, "Display depth: R=%d, G=%d, B=%d\n", r, g, b);
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
p->depth_g = g;
}
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)
{
mpgl_osd_destroy(p->osd);
p->osd = NULL;
p->osd_state = osd;
recreate_osd(p);
}
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
struct gl_video *gl_video_init(GL *gl, 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
{
vo_opengl: cleanups after vo_opengl_old removal Don't load all the legacy functions (including ancient extensions). Slightly simplify function loader and context creation, now that legacy GL doesn't need to be handled. Remove the code for drawing OSD in legacy mode. Remove all the header hacks, which were meant for ancient OpenGL headers which didn't even support things like OpenGL 1.3. Instead, adjust the GLX check to make sure we get both OpenGL 3x and 2.1 symbols. For win32 and OSX, we assume that the user has the latest headers anyway. For wayland, we hope that things somehow go right.
2015-01-21 19:32:42 +00:00
if (gl->version < 210 && gl->es < 200) {
vo_opengl, vo_opengl_cb: check GL version in renderer vo_opengl actually checks this in the context creation code already, but it still increases robustness in case the requirements are changed later.
2014-12-22 11:49:20 +00:00
mp_err(log, "At least OpenGL 2.1 or OpenGL ES 2.0 required.\n");
return NULL;
}
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 *p = talloc_ptrtype(NULL, p);
*p = (struct gl_video) {
.gl = gl,
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
.global = g,
video/out: use new mp_msg stuff for vo.c and vo_opengl The first step; also serves as example.
2013-07-31 19:44:21 +00:00
.log = log,
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
.opts = gl_video_opts_def,
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
.gl_target = GL_TEXTURE_2D,
vo_opengl: don't use 10 bit video on Intel GPUs vo_opengl was originally written against OpenGL 3 core, and it seems GPUs/drivers supporting this are mostly sane. Later, it was made to work with OpenGL 2.1 too. Lately we removed the requirement for RG textures, and look, someone reported a problem with "lesser" Intel GPUs. This commit does the same in vo_opengl what was added to vo_opengl_old a long time ago. Fixes #1383.
2014-12-24 15:54:47 +00:00
.texture_16bit_depth = 16,
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
.scaler = {{.index = 0}, {.index = 1}, {.index = 2}, {.index = 3}},
vo_opengl: move shader file caching to video.c It's just about loading and cachign small files, not does not necessarily have anything to do with shaders. Move it to video.c where it's used.
2015-09-23 20:13:03 +00:00
.sc = gl_sc_create(gl, log),
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: make use of newer OpenGL logging API GL_ARB_debug_output provides a logging callback, which can be used to diagnose problems etc. in case the driver supports it. It's enabled only if the vo_opengl "debug" suboption is set.
2014-12-23 01:46:44 +00:00
gl_video_set_debug(p, true);
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
init_gl(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
recreate_osd(p);
return p;
}
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
// Get static string for scaler shader. If "tscale" is set to true, the
// scaler must be a separable convolution filter.
static const char *handle_scaler_opt(const char *name, bool tscale)
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: make "mitchell" the hq default filter for downscaling Seems like several people agree that it's a good filter for downscaling. Setting this option by default may also prevent people from accidentally using an unsuitable filter for downscaling by setting "scale" and without being aware of the impliciations (maybe). On the other hand, this change is not strictly backwards compatible for the same reasons. Also, allow disabling this option with scale-down="" (before this, not setting it was the only way to do this - not possible anymore if it's set by default). This is what the change in handle_scaler_opt() does.
2015-01-26 01:03:44 +00:00
if (name && name[0]) {
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
const struct filter_kernel *kernel = mp_find_filter_kernel(name);
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
if (kernel && (!tscale || !kernel->polar))
vo_opengl: separate kernel and window This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
return kernel->f.name;
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: add oversample support for tscale This is interesting mainly because it's essentially equivalent to the old smoothmotion algorithm. As such, it is now the default for tscale.
2015-03-15 06:11:51 +00:00
for (const char *const *filter = tscale ? fixed_tscale_filters
: fixed_scale_filters;
*filter; filter++) {
if (strcmp(*filter, name) == 0)
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
return *filter;
}
}
return NULL;
}
vo_opengl: fix dangling pointers with vo_cmdline gl_video_set_options() does not acquire ownership of the opts parameter or its contents. In case of vo_cmdline, opts will point to temporary memory. This memory will be free'd at a later point, and p->opts will point to free'd memory on the next reinitialization. The fix is pretty ugly, but it's a quick bug fix. This can probably be removed once VO sub-options are exposed as properties. Fixes #2035.
2015-06-09 20:30:32 +00:00
static char **dup_str_array(void *parent, char **src)
{
if (!src)
return NULL;
char **res = talloc_new(parent);
int num = 0;
for (int n = 0; src && src[n]; n++)
MP_TARRAY_APPEND(res, res, num, talloc_strdup(res, src[n]));
MP_TARRAY_APPEND(res, res, num, NULL);
return res;
}
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
static void assign_options(struct gl_video_opts *dst, struct gl_video_opts *src)
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: 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
talloc_free(dst->source_shader);
talloc_free(dst->scale_shader);
talloc_free(dst->pre_shaders);
talloc_free(dst->post_shaders);
vo_opengl: fix deband sub-option handling This all has to be done manually.
2015-09-09 18:40:04 +00:00
talloc_free(dst->deband_opts);
vo_opengl: fix dangling pointers with vo_cmdline gl_video_set_options() does not acquire ownership of the opts parameter or its contents. In case of vo_cmdline, opts will point to temporary memory. This memory will be free'd at a later point, and p->opts will point to free'd memory on the next reinitialization. The fix is pretty ugly, but it's a quick bug fix. This can probably be removed once VO sub-options are exposed as properties. Fixes #2035.
2015-06-09 20:30:32 +00:00
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
*dst = *src;
vo_opengl: fix dangling pointers with vo_cmdline gl_video_set_options() does not acquire ownership of the opts parameter or its contents. In case of vo_cmdline, opts will point to temporary memory. This memory will be free'd at a later point, and p->opts will point to free'd memory on the next reinitialization. The fix is pretty ugly, but it's a quick bug fix. This can probably be removed once VO sub-options are exposed as properties. Fixes #2035.
2015-06-09 20:30:32 +00:00
vo_opengl: fix deband sub-option handling This all has to be done manually.
2015-09-09 18:40:04 +00:00
if (src->deband_opts)
dst->deband_opts = m_sub_options_copy(NULL, &deband_conf, src->deband_opts);
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
for (int n = 0; n < 4; n++) {
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
dst->scaler[n].kernel.name =
(char *)handle_scaler_opt(dst->scaler[n].kernel.name, n == 3);
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: 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
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
dst->source_shader = talloc_strdup(NULL, dst->source_shader);
dst->scale_shader = talloc_strdup(NULL, dst->scale_shader);
dst->pre_shaders = dup_str_array(NULL, dst->pre_shaders);
dst->post_shaders = dup_str_array(NULL, dst->post_shaders);
}
// Set the options, and possibly update the filter chain too.
// Note: assumes all options are valid and verified by the option parser.
void gl_video_set_options(struct gl_video *p, struct gl_video_opts *opts)
{
assign_options(&p->opts, opts);
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
check_gl_features(p);
uninit_rendering(p);
}
void gl_video_configure_queue(struct gl_video *p, struct vo *vo)
{
vo: minor simplification for queue size handling Instead of calling it "future frames" and adding or subtracting 1 from it, always call it "requested frames". This simplifies it a bit. MPContext.next_frames had 2 added to it; this was mainly to ensure a minimum size of 2. Drop it and assume VO_MAX_REQ_FRAMES is at least 2; together with the other changes, this can be the exact size of the array.
2015-07-20 19:12:46 +00:00
int queue_size = 1;
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
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
// Figure out an adequate size for the interpolation queue. The larger
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
// the radius, the earlier we need to queue frames.
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
if (p->opts.interpolation) {
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
const struct filter_kernel *kernel =
mp_find_filter_kernel(p->opts.scaler[3].kernel.name);
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
if (kernel) {
vo_opengl: separate kernel and window This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
double radius = kernel->f.radius;
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
radius = radius > 0 ? radius : p->opts.scaler[3].radius;
vo: minor simplification for queue size handling Instead of calling it "future frames" and adding or subtracting 1 from it, always call it "requested frames". This simplifies it a bit. MPContext.next_frames had 2 added to it; this was mainly to ensure a minimum size of 2. Drop it and assume VO_MAX_REQ_FRAMES is at least 2; together with the other changes, this can be the exact size of the array.
2015-07-20 19:12:46 +00:00
queue_size += 1 + ceil(radius);
vo_opengl: reimplement tscale=oversample Closes #2102.
2015-07-11 11:55:45 +00:00
} else {
// Oversample case
vo: minor simplification for queue size handling Instead of calling it "future frames" and adding or subtracting 1 from it, always call it "requested frames". This simplifies it a bit. MPContext.next_frames had 2 added to it; this was mainly to ensure a minimum size of 2. Drop it and assume VO_MAX_REQ_FRAMES is at least 2; together with the other changes, this can be the exact size of the array.
2015-07-20 19:12:46 +00:00
queue_size += 2;
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
}
}
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
vo_set_queue_params(vo, 0, p->opts.interpolation, queue_size);
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_cb: implement equalizer controls This makes vo_opengl_cb respond to controls like "gamma" and "brightness". The commit includes an awkward refactor for vo_opengl to make it easier for vo_opengl_cb. One problem is a logical race condition. The set of supported controls depends on the pixelformat, which in turn is set by reconfig(). But the actual reconfig() call (on the renderer) happens asynchronously on the renderer thread. At the time it happens, the player most likely already tried to set some controls for command line options (see init_vo() in video.c). So setting this command line options will fail most of the time, though it could randomly succeed. This can't be fixed directly, because the player can't wait on the renderer thread, because the renderer thread might already wait on the player.
2015-01-06 16:34:29 +00:00
struct mp_csp_equalizer *gl_video_eq_ptr(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
{
vo_opengl_cb: implement equalizer controls This makes vo_opengl_cb respond to controls like "gamma" and "brightness". The commit includes an awkward refactor for vo_opengl to make it easier for vo_opengl_cb. One problem is a logical race condition. The set of supported controls depends on the pixelformat, which in turn is set by reconfig(). But the actual reconfig() call (on the renderer) happens asynchronously on the renderer thread. At the time it happens, the player most likely already tried to set some controls for command line options (see init_vo() in video.c). So setting this command line options will fail most of the time, though it could randomly succeed. This can't be fixed directly, because the player can't wait on the renderer thread, because the renderer thread might already wait on the player.
2015-01-06 16:34:29 +00:00
return &p->video_eq;
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_cb: implement equalizer controls This makes vo_opengl_cb respond to controls like "gamma" and "brightness". The commit includes an awkward refactor for vo_opengl to make it easier for vo_opengl_cb. One problem is a logical race condition. The set of supported controls depends on the pixelformat, which in turn is set by reconfig(). But the actual reconfig() call (on the renderer) happens asynchronously on the renderer thread. At the time it happens, the player most likely already tried to set some controls for command line options (see init_vo() in video.c). So setting this command line options will fail most of the time, though it could randomly succeed. This can't be fixed directly, because the player can't wait on the renderer thread, because the renderer thread might already wait on the player.
2015-01-06 16:34:29 +00:00
// Call when the mp_csp_equalizer returned by gl_video_eq_ptr() was changed.
void gl_video_eq_update(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
{
}
m_option: add mp_log callback to OPT_STRING_VALIDATE options And also convert a bunch of other code, especially ao_wasapi and ao_portaudio.
2013-12-21 19:03:36 +00:00
static int validate_scaler_opt(struct mp_log *log, const m_option_t *opt,
struct bstr name, struct bstr param)
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: improve terminal messages with lscale suboption errors Make it more apparent what the hell the user did wrong.
2015-01-22 18:58:22 +00:00
char s[20] = {0};
int r = 1;
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
bool tscale = bstr_equals0(name, "tscale");
vo_opengl: some option changes Doing "mpv --vo=opengl:lscale=help" now lists possible scalers and exits. The "backend" suboption behaves similar. Make the "stereo" suboption a choice, instead of using magic integer values.
2013-07-22 00:14:15 +00:00
if (bstr_equals0(param, "help")) {
vo_opengl: improve terminal messages with lscale suboption errors Make it more apparent what the hell the user did wrong.
2015-01-22 18:58:22 +00:00
r = M_OPT_EXIT - 1;
} else {
snprintf(s, sizeof(s), "%.*s", BSTR_P(param));
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
if (!handle_scaler_opt(s, tscale))
vo_opengl: improve terminal messages with lscale suboption errors Make it more apparent what the hell the user did wrong.
2015-01-22 18:58:22 +00:00
r = M_OPT_INVALID;
}
if (r < 1) {
m_option: add mp_log callback to OPT_STRING_VALIDATE options And also convert a bunch of other code, especially ao_wasapi and ao_portaudio.
2013-12-21 19:03:36 +00:00
mp_info(log, "Available scalers:\n");
vo_opengl: add oversample support for tscale This is interesting mainly because it's essentially equivalent to the old smoothmotion algorithm. As such, it is now the default for tscale.
2015-03-15 06:11:51 +00:00
for (const char *const *filter = tscale ? fixed_tscale_filters
: fixed_scale_filters;
*filter; filter++) {
mp_info(log, " %s\n", *filter);
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
}
vo_opengl: separate kernel and window This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
for (int n = 0; mp_filter_kernels[n].f.name; n++) {
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
if (!tscale || !mp_filter_kernels[n].polar)
vo_opengl: separate kernel and window This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
mp_info(log, " %s\n", mp_filter_kernels[n].f.name);
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
}
vo_opengl: improve terminal messages with lscale suboption errors Make it more apparent what the hell the user did wrong.
2015-01-22 18:58:22 +00:00
if (s[0])
mp_fatal(log, "No scaler named '%s' found!\n", s);
vo_opengl: some option changes Doing "mpv --vo=opengl:lscale=help" now lists possible scalers and exits. The "backend" suboption behaves similar. Make the "stereo" suboption a choice, instead of using magic integer values.
2013-07-22 00:14:15 +00:00
}
vo_opengl: improve terminal messages with lscale suboption errors Make it more apparent what the hell the user did wrong.
2015-01-22 18:58:22 +00:00
return r;
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
}
add a way to resize window contents without VO resize gl_video_resize_redraw() simply resizes and redraws (but without invoking swapGlBuffers()). The VO is not involved in any way, so this can simply be called from inside the mpgl lock from any thread. Requires a minor refactor of the GL OSD code in order to redraw without an OSD object.
2013-03-15 19:17:33 +00:00
vo_opengl: separate kernel and window This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
static int validate_window_opt(struct mp_log *log, const m_option_t *opt,
struct bstr name, struct bstr param)
{
char s[20] = {0};
int r = 1;
if (bstr_equals0(param, "help")) {
r = M_OPT_EXIT - 1;
} else {
snprintf(s, sizeof(s), "%.*s", BSTR_P(param));
const struct filter_window *window = mp_find_filter_window(s);
if (!window)
r = M_OPT_INVALID;
}
if (r < 1) {
mp_info(log, "Available windows:\n");
for (int n = 0; mp_filter_windows[n].name; n++)
mp_info(log, " %s\n", mp_filter_windows[n].name);
if (s[0])
mp_fatal(log, "No window named '%s' found!\n", s);
}
return r;
}
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)
{
assert(lmax > lmin);
float num = (rmax - rmin) * (log10(lux) - log10(lmin));
float den = log10(lmax) - log10(lmin);
float result = num / den + rmin;
// clamp the result
float max = MPMAX(rmax, rmin);
float min = MPMIN(rmax, rmin);
return MPMAX(MPMIN(result, max), min);
}
void gl_video_set_ambient_lux(struct gl_video *p, int lux)
{
if (p->opts.gamma_auto) {
float gamma = gl_video_scale_ambient_lux(16.0, 64.0, 2.40, 1.961, lux);
vo_opengl: increase ambient light changes log level info is a quite too annoying. increase it to verbose.
2015-03-04 19:18:14 +00:00
MP_VERBOSE(p, "ambient light changed: %dlux (gamma: %f)\n", lux, gamma);
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
p->opts.gamma = MPMIN(1.0, 1.961 / gamma);
gl_video_eq_update(p);
}
}
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
void gl_video_set_hwdec(struct gl_video *p, struct gl_hwdec *hwdec)
{
p->hwdec = hwdec;
vo_opengl: simplify screenshot code Instead of reading back the image from textures, keep a reference to the original image, and return that. The main reason this was done this way was that originally, images weren't refcounted, and would be deallocated or overwritten as soon as the VO's draw call returned. But now there isn't really a good reason for this anymore. One possibly _could_ argue that it was better because other code could reuse the image sooner (e.g. for the cache), but on the other hand, the VO runs already on a different thread, and filtering and decoding each run on other threads too, so this argument probably wouldn't hold up.
2015-01-22 17:29:37 +00:00
mp_image_unrefp(&p->image.mpi);
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
}
Reference in New Issue Copy Permalink