2009-12-31 18:25:35 +00:00
|
|
|
/*
|
2015-04-13 07:36:54 +00:00
|
|
|
* This file is part of mpv.
|
2009-12-31 18:25:35 +00:00
|
|
|
*
|
2016-01-19 17:36:34 +00:00
|
|
|
* mpv is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
2009-12-31 18:25:35 +00:00
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2009-12-31 18:25:35 +00:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
2016-01-19 17:36:34 +00:00
|
|
|
* GNU Lesser General Public License for more details.
|
2010-06-13 10:42:32 +00:00
|
|
|
*
|
2016-01-19 17:36:34 +00:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2009-12-31 18:25:35 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef MPLAYER_CSPUTILS_H
|
|
|
|
#define MPLAYER_CSPUTILS_H
|
|
|
|
|
2012-10-27 16:01:51 +00:00
|
|
|
#include <stdbool.h>
|
2009-12-31 18:25:35 +00:00
|
|
|
#include <stdint.h>
|
|
|
|
|
2015-03-30 21:52:28 +00:00
|
|
|
#include "options/m_option.h"
|
|
|
|
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
/* NOTE: the csp and levels AUTO values are converted to specific ones
|
|
|
|
* above vf/vo level. At least vf_scale relies on all valid settings being
|
|
|
|
* nonzero at vf/vo level.
|
|
|
|
*/
|
|
|
|
|
|
|
|
enum mp_csp {
|
|
|
|
MP_CSP_AUTO,
|
2011-08-28 02:52:46 +00:00
|
|
|
MP_CSP_BT_601,
|
|
|
|
MP_CSP_BT_709,
|
|
|
|
MP_CSP_SMPTE_240M,
|
2014-03-25 17:45:08 +00:00
|
|
|
MP_CSP_BT_2020_NC,
|
2014-03-26 22:00:09 +00:00
|
|
|
MP_CSP_BT_2020_C,
|
2012-10-27 16:01:51 +00:00
|
|
|
MP_CSP_RGB,
|
2013-05-01 21:59:00 +00:00
|
|
|
MP_CSP_XYZ,
|
2013-05-02 23:37:13 +00:00
|
|
|
MP_CSP_YCGCO,
|
2011-08-28 02:52:46 +00:00
|
|
|
MP_CSP_COUNT
|
2009-12-31 19:59:58 +00:00
|
|
|
};
|
|
|
|
|
2015-03-30 21:52:28 +00:00
|
|
|
extern const struct m_opt_choice_alternatives mp_csp_names[];
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
|
|
|
|
enum mp_csp_levels {
|
|
|
|
MP_CSP_LEVELS_AUTO,
|
|
|
|
MP_CSP_LEVELS_TV,
|
|
|
|
MP_CSP_LEVELS_PC,
|
|
|
|
MP_CSP_LEVELS_COUNT,
|
|
|
|
};
|
|
|
|
|
2015-03-30 21:52:28 +00:00
|
|
|
extern const struct m_opt_choice_alternatives mp_csp_levels_names[];
|
2013-07-14 23:48:25 +00:00
|
|
|
|
2014-03-26 00:46:38 +00:00
|
|
|
enum mp_csp_prim {
|
|
|
|
MP_CSP_PRIM_AUTO,
|
|
|
|
MP_CSP_PRIM_BT_601_525,
|
|
|
|
MP_CSP_PRIM_BT_601_625,
|
|
|
|
MP_CSP_PRIM_BT_709,
|
|
|
|
MP_CSP_PRIM_BT_2020,
|
2015-02-27 20:10:09 +00:00
|
|
|
MP_CSP_PRIM_BT_470M,
|
2015-03-30 12:54:52 +00:00
|
|
|
MP_CSP_PRIM_APPLE,
|
|
|
|
MP_CSP_PRIM_ADOBE,
|
|
|
|
MP_CSP_PRIM_PRO_PHOTO,
|
|
|
|
MP_CSP_PRIM_CIE_1931,
|
2016-03-19 01:27:46 +00:00
|
|
|
MP_CSP_PRIM_DCI_P3,
|
2017-12-14 21:19:54 +00:00
|
|
|
MP_CSP_PRIM_DISPLAY_P3,
|
2016-06-26 17:57:29 +00:00
|
|
|
MP_CSP_PRIM_V_GAMUT,
|
2017-06-10 00:10:41 +00:00
|
|
|
MP_CSP_PRIM_S_GAMUT,
|
2014-03-26 00:46:38 +00:00
|
|
|
MP_CSP_PRIM_COUNT
|
|
|
|
};
|
|
|
|
|
2015-03-30 21:52:28 +00:00
|
|
|
extern const struct m_opt_choice_alternatives mp_csp_prim_names[];
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
|
2014-11-26 20:35:08 +00:00
|
|
|
enum mp_csp_trc {
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
MP_CSP_TRC_AUTO,
|
2015-01-13 23:45:31 +00:00
|
|
|
MP_CSP_TRC_BT_1886,
|
2015-01-28 17:52:33 +00:00
|
|
|
MP_CSP_TRC_SRGB,
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
MP_CSP_TRC_LINEAR,
|
2015-03-30 12:54:52 +00:00
|
|
|
MP_CSP_TRC_GAMMA18,
|
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
|
|
|
MP_CSP_TRC_GAMMA22,
|
2015-03-30 12:54:52 +00:00
|
|
|
MP_CSP_TRC_GAMMA28,
|
|
|
|
MP_CSP_TRC_PRO_PHOTO,
|
2017-06-13 15:09:02 +00:00
|
|
|
MP_CSP_TRC_PQ,
|
|
|
|
MP_CSP_TRC_HLG,
|
2016-06-26 17:28:06 +00:00
|
|
|
MP_CSP_TRC_V_LOG,
|
2017-06-10 00:05:28 +00:00
|
|
|
MP_CSP_TRC_S_LOG1,
|
2017-06-10 00:51:32 +00:00
|
|
|
MP_CSP_TRC_S_LOG2,
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
MP_CSP_TRC_COUNT
|
2014-11-26 20:35:08 +00:00
|
|
|
};
|
|
|
|
|
2015-03-30 12:54:52 +00:00
|
|
|
extern const struct m_opt_choice_alternatives mp_csp_trc_names[];
|
2014-03-26 00:46:38 +00:00
|
|
|
|
2017-06-14 18:06:56 +00:00
|
|
|
enum mp_csp_light {
|
|
|
|
MP_CSP_LIGHT_AUTO,
|
|
|
|
MP_CSP_LIGHT_DISPLAY,
|
|
|
|
MP_CSP_LIGHT_SCENE_HLG,
|
|
|
|
MP_CSP_LIGHT_SCENE_709_1886,
|
|
|
|
MP_CSP_LIGHT_SCENE_1_2,
|
|
|
|
MP_CSP_LIGHT_COUNT
|
|
|
|
};
|
|
|
|
|
|
|
|
extern const struct m_opt_choice_alternatives mp_csp_light_names[];
|
|
|
|
|
2014-03-31 22:17:07 +00:00
|
|
|
// These constants are based on the ICC specification (Table 23) and match
|
|
|
|
// up with the API of LittleCMS, which treats them as integers.
|
|
|
|
enum mp_render_intent {
|
|
|
|
MP_INTENT_PERCEPTUAL = 0,
|
|
|
|
MP_INTENT_RELATIVE_COLORIMETRIC = 1,
|
|
|
|
MP_INTENT_SATURATION = 2,
|
|
|
|
MP_INTENT_ABSOLUTE_COLORIMETRIC = 3
|
|
|
|
};
|
|
|
|
|
2014-08-30 21:54:19 +00:00
|
|
|
// The numeric values (except -1) match the Matroska StereoMode element value.
|
2014-08-30 21:24:46 +00:00
|
|
|
enum mp_stereo3d_mode {
|
|
|
|
MP_STEREO3D_INVALID = -1,
|
2014-10-29 22:14:46 +00:00
|
|
|
/* only modes explicitly referenced in the code are listed */
|
2014-08-30 21:24:46 +00:00
|
|
|
MP_STEREO3D_MONO = 0,
|
2014-10-29 22:14:46 +00:00
|
|
|
MP_STEREO3D_SBS2L = 1,
|
|
|
|
MP_STEREO3D_AB2R = 2,
|
|
|
|
MP_STEREO3D_AB2L = 3,
|
|
|
|
MP_STEREO3D_SBS2R = 11,
|
2014-08-30 21:54:19 +00:00
|
|
|
/* no explicit enum entries for most valid values */
|
2015-12-18 18:29:59 +00:00
|
|
|
MP_STEREO3D_COUNT = 15, // 14 is last valid mode
|
2014-08-30 21:24:46 +00:00
|
|
|
};
|
|
|
|
|
2015-04-02 21:54:08 +00:00
|
|
|
extern const struct m_opt_choice_alternatives mp_stereo3d_names[];
|
|
|
|
|
|
|
|
#define MP_STEREO3D_NAME(x) m_opt_choice_str(mp_stereo3d_names, x)
|
2014-08-30 21:24:46 +00:00
|
|
|
|
2014-11-12 18:30:34 +00:00
|
|
|
#define MP_STEREO3D_NAME_DEF(x, def) \
|
|
|
|
(MP_STEREO3D_NAME(x) ? MP_STEREO3D_NAME(x) : (def))
|
2014-08-30 21:24:46 +00:00
|
|
|
|
2016-06-29 07:16:13 +00:00
|
|
|
struct mp_colorspace {
|
|
|
|
enum mp_csp space;
|
|
|
|
enum mp_csp_levels levels;
|
2015-12-08 23:16:51 +00:00
|
|
|
enum mp_csp_prim primaries;
|
2016-06-29 07:16:13 +00:00
|
|
|
enum mp_csp_trc gamma;
|
2017-06-14 18:06:56 +00:00
|
|
|
enum mp_csp_light light;
|
2017-06-10 12:01:25 +00:00
|
|
|
float sig_peak; // highest relative value in signal. 0 = unknown/auto
|
2016-06-29 07:16:13 +00:00
|
|
|
};
|
|
|
|
|
2017-06-10 12:01:25 +00:00
|
|
|
// For many colorspace conversions, in particular those involving HDR, an
|
|
|
|
// implicit reference white level is needed. Since this magic constant shows up
|
|
|
|
// a lot, give it an explicit name. The value of 100 cd/m² comes from ITU-R
|
|
|
|
// documents such as ITU-R BT.2100
|
|
|
|
#define MP_REF_WHITE 100.0
|
|
|
|
|
2016-11-08 16:53:55 +00:00
|
|
|
// Replaces unknown values in the first struct by those of the second struct
|
|
|
|
void mp_colorspace_merge(struct mp_colorspace *orig, struct mp_colorspace *new);
|
|
|
|
|
2016-06-29 07:16:13 +00:00
|
|
|
struct mp_csp_params {
|
|
|
|
struct mp_colorspace color; // input colorspace
|
|
|
|
enum mp_csp_levels levels_out; // output device
|
2011-08-28 02:52:46 +00:00
|
|
|
float brightness;
|
|
|
|
float contrast;
|
|
|
|
float hue;
|
|
|
|
float saturation;
|
2015-02-03 15:52:44 +00:00
|
|
|
float gamma;
|
2015-01-21 18:29:18 +00:00
|
|
|
// discard U/V components
|
|
|
|
bool gray;
|
2012-10-25 19:23:18 +00:00
|
|
|
// texture_bits/input_bits is for rescaling fixed point input to range [0,1]
|
2012-03-08 03:25:33 +00:00
|
|
|
int texture_bits;
|
|
|
|
int input_bits;
|
2009-12-31 18:25:35 +00:00
|
|
|
};
|
|
|
|
|
2012-10-07 22:14:51 +00:00
|
|
|
#define MP_CSP_PARAMS_DEFAULTS { \
|
2016-06-29 07:16:13 +00:00
|
|
|
.color = { .space = MP_CSP_BT_601, \
|
|
|
|
.levels = MP_CSP_LEVELS_TV }, \
|
2015-01-06 14:04:29 +00:00
|
|
|
.levels_out = MP_CSP_LEVELS_PC, \
|
2012-10-07 22:14:51 +00:00
|
|
|
.brightness = 0, .contrast = 1, .hue = 0, .saturation = 1, \
|
2015-02-03 15:52:44 +00:00
|
|
|
.gamma = 1, .texture_bits = 8, .input_bits = 8}
|
2012-10-07 22:14:51 +00:00
|
|
|
|
2015-01-06 14:21:26 +00:00
|
|
|
struct mp_image_params;
|
|
|
|
void mp_csp_set_image_params(struct mp_csp_params *params,
|
|
|
|
const struct mp_image_params *imgparams);
|
|
|
|
|
2016-06-29 07:16:13 +00:00
|
|
|
bool mp_colorspace_equal(struct mp_colorspace c1, struct mp_colorspace c2);
|
|
|
|
|
vo_opengl: handle chroma location
Use the video decoder chroma location flags and render chroma locations
other than centered. Until now, we've always used the intuitive and
obvious centered chroma location, but H.264 uses something else.
FFmpeg provides a small overview in libavcodec/avcodec.h:
-----------
/**
* X X 3 4 X X are luma samples,
* 1 2 1-6 are possible chroma positions
* X X 5 6 X 0 is undefined/unknown position
*/
enum AVChromaLocation{
AVCHROMA_LOC_UNSPECIFIED = 0,
AVCHROMA_LOC_LEFT = 1, ///< mpeg2/4, h264 default
AVCHROMA_LOC_CENTER = 2, ///< mpeg1, jpeg, h263
AVCHROMA_LOC_TOPLEFT = 3, ///< DV
AVCHROMA_LOC_TOP = 4,
AVCHROMA_LOC_BOTTOMLEFT = 5,
AVCHROMA_LOC_BOTTOM = 6,
AVCHROMA_LOC_NB , ///< Not part of ABI
};
-----------
The visual difference is literally minimal, but since videophiles
apparently consider this detail as quality mark of a video renderer,
support it anyway. We don't bother with chroma locations other than
centered and left, though.
Not sure about correctness, but it's probably ok.
2013-06-08 00:15:24 +00:00
|
|
|
enum mp_chroma_location {
|
|
|
|
MP_CHROMA_AUTO,
|
|
|
|
MP_CHROMA_LEFT, // mpeg2/4, h264
|
|
|
|
MP_CHROMA_CENTER, // mpeg1, jpeg
|
2014-02-15 15:28:39 +00:00
|
|
|
MP_CHROMA_COUNT,
|
vo_opengl: handle chroma location
Use the video decoder chroma location flags and render chroma locations
other than centered. Until now, we've always used the intuitive and
obvious centered chroma location, but H.264 uses something else.
FFmpeg provides a small overview in libavcodec/avcodec.h:
-----------
/**
* X X 3 4 X X are luma samples,
* 1 2 1-6 are possible chroma positions
* X X 5 6 X 0 is undefined/unknown position
*/
enum AVChromaLocation{
AVCHROMA_LOC_UNSPECIFIED = 0,
AVCHROMA_LOC_LEFT = 1, ///< mpeg2/4, h264 default
AVCHROMA_LOC_CENTER = 2, ///< mpeg1, jpeg, h263
AVCHROMA_LOC_TOPLEFT = 3, ///< DV
AVCHROMA_LOC_TOP = 4,
AVCHROMA_LOC_BOTTOMLEFT = 5,
AVCHROMA_LOC_BOTTOM = 6,
AVCHROMA_LOC_NB , ///< Not part of ABI
};
-----------
The visual difference is literally minimal, but since videophiles
apparently consider this detail as quality mark of a video renderer,
support it anyway. We don't bother with chroma locations other than
centered and left, though.
Not sure about correctness, but it's probably ok.
2013-06-08 00:15:24 +00:00
|
|
|
};
|
|
|
|
|
2015-03-30 21:52:28 +00:00
|
|
|
extern const struct m_opt_choice_alternatives mp_chroma_names[];
|
2014-02-15 15:28:39 +00:00
|
|
|
|
video: redo video equalizer option handling
I really wouldn't care much about this, but some parts of the core code
are under HAVE_GPL, so there's some need to get rid of it. Simply turn
the video equalizer from its current fine-grained handling with vf/vo
fallbacks into global options. This makes updating them much simpler.
This removes any possibility of applying video equalizers in filters,
which affects vf_scale, and the previously removed vf_eq. Not a big
loss, since the preferred VOs have this builtin.
Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and
vo_xv. I'm not going to waste my time on these legacy VOs.
vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which
exists _only_ to trigger a redraw. This seems silly, but for now I feel
like this is less of a pain. The rest of the equalizer using code is
self-updating.
See commit 96b906a51d5 for how some video equalizer code was GPL only.
Some command line option names and ranges can probably be traced back to
a GPL only committer, but we don't consider these copyrightable.
2017-08-22 15:01:35 +00:00
|
|
|
extern const struct m_sub_options mp_csp_equalizer_conf;
|
|
|
|
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
enum mp_csp_equalizer_param {
|
|
|
|
MP_CSP_EQ_BRIGHTNESS,
|
|
|
|
MP_CSP_EQ_CONTRAST,
|
|
|
|
MP_CSP_EQ_HUE,
|
|
|
|
MP_CSP_EQ_SATURATION,
|
|
|
|
MP_CSP_EQ_GAMMA,
|
2015-09-29 19:12:26 +00:00
|
|
|
MP_CSP_EQ_OUTPUT_LEVELS,
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
MP_CSP_EQ_COUNT,
|
|
|
|
};
|
|
|
|
|
|
|
|
// Default initialization with 0 is enough, except for the capabilities field
|
video: redo video equalizer option handling
I really wouldn't care much about this, but some parts of the core code
are under HAVE_GPL, so there's some need to get rid of it. Simply turn
the video equalizer from its current fine-grained handling with vf/vo
fallbacks into global options. This makes updating them much simpler.
This removes any possibility of applying video equalizers in filters,
which affects vf_scale, and the previously removed vf_eq. Not a big
loss, since the preferred VOs have this builtin.
Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and
vo_xv. I'm not going to waste my time on these legacy VOs.
vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which
exists _only_ to trigger a redraw. This seems silly, but for now I feel
like this is less of a pain. The rest of the equalizer using code is
self-updating.
See commit 96b906a51d5 for how some video equalizer code was GPL only.
Some command line option names and ranges can probably be traced back to
a GPL only committer, but we don't consider these copyrightable.
2017-08-22 15:01:35 +00:00
|
|
|
struct mp_csp_equalizer_opts {
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
// Value for each property is in the range [-100, 100].
|
|
|
|
// 0 is default, meaning neutral or no change.
|
|
|
|
int values[MP_CSP_EQ_COUNT];
|
|
|
|
};
|
|
|
|
|
video: redo video equalizer option handling
I really wouldn't care much about this, but some parts of the core code
are under HAVE_GPL, so there's some need to get rid of it. Simply turn
the video equalizer from its current fine-grained handling with vf/vo
fallbacks into global options. This makes updating them much simpler.
This removes any possibility of applying video equalizers in filters,
which affects vf_scale, and the previously removed vf_eq. Not a big
loss, since the preferred VOs have this builtin.
Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and
vo_xv. I'm not going to waste my time on these legacy VOs.
vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which
exists _only_ to trigger a redraw. This seems silly, but for now I feel
like this is less of a pain. The rest of the equalizer using code is
self-updating.
See commit 96b906a51d5 for how some video equalizer code was GPL only.
Some command line option names and ranges can probably be traced back to
a GPL only committer, but we don't consider these copyrightable.
2017-08-22 15:01:35 +00:00
|
|
|
void mp_csp_copy_equalizer_values(struct mp_csp_params *params,
|
|
|
|
const struct mp_csp_equalizer_opts *eq);
|
|
|
|
|
|
|
|
struct mpv_global;
|
|
|
|
struct mp_csp_equalizer_state *mp_csp_equalizer_create(void *ta_parent,
|
|
|
|
struct mpv_global *global);
|
|
|
|
bool mp_csp_equalizer_state_changed(struct mp_csp_equalizer_state *state);
|
|
|
|
void mp_csp_equalizer_state_get(struct mp_csp_equalizer_state *state,
|
|
|
|
struct mp_csp_params *params);
|
|
|
|
|
2014-06-22 06:33:43 +00:00
|
|
|
struct mp_csp_col_xy {
|
|
|
|
float x, y;
|
|
|
|
};
|
|
|
|
|
2017-06-16 23:55:08 +00:00
|
|
|
static inline float mp_xy_X(struct mp_csp_col_xy xy) {
|
|
|
|
return xy.x / xy.y;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline float mp_xy_Z(struct mp_csp_col_xy xy) {
|
|
|
|
return (1 - xy.x - xy.y) / xy.y;
|
|
|
|
}
|
|
|
|
|
2014-06-22 06:33:43 +00:00
|
|
|
struct mp_csp_primaries {
|
|
|
|
struct mp_csp_col_xy red, green, blue, white;
|
|
|
|
};
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
|
2013-06-28 19:14:43 +00:00
|
|
|
enum mp_csp avcol_spc_to_mp_csp(int avcolorspace);
|
|
|
|
enum mp_csp_levels avcol_range_to_mp_csp_levels(int avrange);
|
2014-03-26 00:46:38 +00:00
|
|
|
enum mp_csp_prim avcol_pri_to_mp_csp_prim(int avpri);
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
enum mp_csp_trc avcol_trc_to_mp_csp_trc(int avtrc);
|
|
|
|
|
2013-06-28 19:14:43 +00:00
|
|
|
int mp_csp_to_avcol_spc(enum mp_csp colorspace);
|
|
|
|
int mp_csp_levels_to_avcol_range(enum mp_csp_levels range);
|
2014-03-26 00:46:38 +00:00
|
|
|
int mp_csp_prim_to_avcol_pri(enum mp_csp_prim prim);
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
int mp_csp_trc_to_avcol_trc(enum mp_csp_trc trc);
|
|
|
|
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
enum mp_csp mp_csp_guess_colorspace(int width, int height);
|
2014-04-01 22:40:36 +00:00
|
|
|
enum mp_csp_prim mp_csp_guess_primaries(int width, int height);
|
video, options: implement better YUV->RGB conversion control
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
2011-10-15 21:50:21 +00:00
|
|
|
|
2013-06-28 19:14:43 +00:00
|
|
|
enum mp_chroma_location avchroma_location_to_mp(int avloc);
|
2013-07-25 21:02:23 +00:00
|
|
|
int mp_chroma_location_to_av(enum mp_chroma_location mploc);
|
vo_opengl: handle chroma location
Use the video decoder chroma location flags and render chroma locations
other than centered. Until now, we've always used the intuitive and
obvious centered chroma location, but H.264 uses something else.
FFmpeg provides a small overview in libavcodec/avcodec.h:
-----------
/**
* X X 3 4 X X are luma samples,
* 1 2 1-6 are possible chroma positions
* X X 5 6 X 0 is undefined/unknown position
*/
enum AVChromaLocation{
AVCHROMA_LOC_UNSPECIFIED = 0,
AVCHROMA_LOC_LEFT = 1, ///< mpeg2/4, h264 default
AVCHROMA_LOC_CENTER = 2, ///< mpeg1, jpeg, h263
AVCHROMA_LOC_TOPLEFT = 3, ///< DV
AVCHROMA_LOC_TOP = 4,
AVCHROMA_LOC_BOTTOMLEFT = 5,
AVCHROMA_LOC_BOTTOM = 6,
AVCHROMA_LOC_NB , ///< Not part of ABI
};
-----------
The visual difference is literally minimal, but since videophiles
apparently consider this detail as quality mark of a video renderer,
support it anyway. We don't bother with chroma locations other than
centered and left, though.
Not sure about correctness, but it's probably ok.
2013-06-08 00:15:24 +00:00
|
|
|
void mp_get_chroma_location(enum mp_chroma_location loc, int *x, int *y);
|
|
|
|
|
2014-06-22 06:33:43 +00:00
|
|
|
struct mp_csp_primaries mp_get_csp_primaries(enum mp_csp_prim csp);
|
2017-06-10 12:01:25 +00:00
|
|
|
float mp_trc_nom_peak(enum mp_csp_trc trc);
|
2016-06-28 12:28:32 +00:00
|
|
|
bool mp_trc_is_hdr(enum mp_csp_trc trc);
|
2014-03-26 00:46:38 +00:00
|
|
|
|
2015-01-06 15:49:53 +00:00
|
|
|
/* Color conversion matrix: RGB = m * YUV + c
|
|
|
|
* m is in row-major matrix, with m[row][col], e.g.:
|
|
|
|
* [ a11 a12 a13 ] float m[3][3] = { { a11, a12, a13 },
|
|
|
|
* [ a21 a22 a23 ] { a21, a22, a23 },
|
|
|
|
* [ a31 a32 a33 ] { a31, a32, a33 } };
|
|
|
|
* This is accessed as e.g.: m[2-1][1-1] = a21
|
|
|
|
* In particular, each row contains all the coefficients for one of R, G, B,
|
|
|
|
* while each column contains all the coefficients for one of Y, U, V:
|
|
|
|
* m[r,g,b][y,u,v] = ...
|
|
|
|
* The matrix could also be viewed as group of 3 vectors, e.g. the 1st column
|
|
|
|
* is the Y vector (1, 1, 1), the 2nd is the U vector, the 3rd the V vector.
|
|
|
|
* The matrix might also be used for other conversions and colorspaces.
|
|
|
|
*/
|
|
|
|
struct mp_cmat {
|
|
|
|
float m[3][3];
|
|
|
|
float c[3];
|
|
|
|
};
|
|
|
|
|
2017-06-16 23:55:08 +00:00
|
|
|
void mp_get_rgb2xyz_matrix(struct mp_csp_primaries space, float m[3][3]);
|
2014-03-31 22:17:07 +00:00
|
|
|
void mp_get_cms_matrix(struct mp_csp_primaries src, struct mp_csp_primaries dest,
|
|
|
|
enum mp_render_intent intent, float cms_matrix[3][3]);
|
2014-03-31 02:51:47 +00:00
|
|
|
|
2015-12-07 22:41:29 +00:00
|
|
|
double mp_get_csp_mul(enum mp_csp csp, int input_bits, int texture_bits);
|
2015-12-08 23:22:12 +00:00
|
|
|
void mp_get_csp_matrix(struct mp_csp_params *params, struct mp_cmat *out);
|
2009-12-31 18:25:35 +00:00
|
|
|
|
2014-06-22 06:33:43 +00:00
|
|
|
void mp_invert_matrix3x3(float m[3][3]);
|
2015-12-08 23:22:12 +00:00
|
|
|
void mp_invert_cmat(struct mp_cmat *out, struct mp_cmat *in);
|
2015-12-08 23:08:00 +00:00
|
|
|
void mp_map_fixp_color(struct mp_cmat *matrix, int ibits, int in[3],
|
|
|
|
int obits, int out[3]);
|
2012-10-07 22:14:51 +00:00
|
|
|
|
2009-12-31 18:25:35 +00:00
|
|
|
#endif /* MPLAYER_CSPUTILS_H */
|