2009-12-31 18:25:35 +00:00
|
|
|
/*
|
|
|
|
* This file is part of MPlayer.
|
|
|
|
*
|
|
|
|
* MPlayer 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.
|
|
|
|
*
|
|
|
|
* MPlayer 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 MPlayer; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
2010-06-13 10:42:32 +00:00
|
|
|
*
|
|
|
|
* 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.
|
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>
|
|
|
|
|
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
|
|
|
};
|
|
|
|
|
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
|
|
|
// Any enum mp_csp value is a valid index (except MP_CSP_COUNT)
|
2014-02-03 20:58:51 +00:00
|
|
|
extern const char *const mp_csp_names[MP_CSP_COUNT];
|
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,
|
|
|
|
};
|
|
|
|
|
2013-07-14 23:48:25 +00:00
|
|
|
// Any enum mp_csp_levels value is a valid index (except MP_CSP_LEVELS_COUNT)
|
2014-02-03 20:58:51 +00:00
|
|
|
extern const char *const mp_csp_levels_names[MP_CSP_LEVELS_COUNT];
|
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,
|
|
|
|
MP_CSP_PRIM_COUNT
|
|
|
|
};
|
|
|
|
|
|
|
|
// Any enum mp_csp_prim value is a valid index (except MP_CSP_PRIM_COUNT)
|
|
|
|
extern const char *const mp_csp_prim_names[MP_CSP_PRIM_COUNT];
|
|
|
|
|
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 */
|
2014-08-30 21:24:46 +00:00
|
|
|
MP_STEREO3D_COUNT = 13, // 12 is last valid mode
|
|
|
|
};
|
|
|
|
|
|
|
|
extern const char *const mp_stereo3d_names[MP_STEREO3D_COUNT];
|
|
|
|
|
|
|
|
#define MP_STEREO3D_NAME(x) \
|
|
|
|
((x) >= 0 && (x) < MP_STEREO3D_COUNT ? (char *)mp_stereo3d_names[(x)] : NULL)
|
|
|
|
|
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
|
|
|
struct mp_csp_details {
|
|
|
|
enum mp_csp format;
|
|
|
|
enum mp_csp_levels levels_in; // encoded video
|
|
|
|
enum mp_csp_levels levels_out; // output device
|
2010-01-16 19:59:31 +00:00
|
|
|
};
|
|
|
|
|
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
|
|
|
// initializer for struct mp_csp_details that contains reasonable defaults
|
|
|
|
#define MP_CSP_DETAILS_DEFAULTS {MP_CSP_BT_601, MP_CSP_LEVELS_TV, MP_CSP_LEVELS_PC}
|
|
|
|
|
2009-12-31 18:25:35 +00:00
|
|
|
struct mp_csp_params {
|
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
|
|
|
struct mp_csp_details colorspace;
|
2011-08-28 02:52:46 +00:00
|
|
|
float brightness;
|
|
|
|
float contrast;
|
|
|
|
float hue;
|
|
|
|
float saturation;
|
|
|
|
float rgamma;
|
|
|
|
float ggamma;
|
|
|
|
float bgamma;
|
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;
|
2012-10-25 19:23:18 +00:00
|
|
|
// for scaling integer input and output (if 0, assume range [0,1])
|
|
|
|
int int_bits_in;
|
|
|
|
int int_bits_out;
|
2009-12-31 18:25:35 +00:00
|
|
|
};
|
|
|
|
|
2012-10-07 22:14:51 +00:00
|
|
|
#define MP_CSP_PARAMS_DEFAULTS { \
|
|
|
|
.colorspace = MP_CSP_DETAILS_DEFAULTS, \
|
|
|
|
.brightness = 0, .contrast = 1, .hue = 0, .saturation = 1, \
|
|
|
|
.rgamma = 1, .ggamma = 1, .bgamma = 1, \
|
|
|
|
.texture_bits = 8, .input_bits = 8}
|
|
|
|
|
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
|
|
|
};
|
|
|
|
|
2014-02-15 15:28:39 +00:00
|
|
|
extern const char *const mp_chroma_names[MP_CHROMA_COUNT];
|
|
|
|
|
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,
|
|
|
|
MP_CSP_EQ_COUNT,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define MP_CSP_EQ_CAPS_COLORMATRIX \
|
|
|
|
( (1 << MP_CSP_EQ_BRIGHTNESS) \
|
|
|
|
| (1 << MP_CSP_EQ_CONTRAST) \
|
|
|
|
| (1 << MP_CSP_EQ_HUE) \
|
|
|
|
| (1 << MP_CSP_EQ_SATURATION) )
|
|
|
|
|
|
|
|
#define MP_CSP_EQ_CAPS_GAMMA (1 << MP_CSP_EQ_GAMMA)
|
2014-03-31 02:51:47 +00:00
|
|
|
#define MP_CSP_EQ_CAPS_BRIGHTNESS (1 << MP_CSP_EQ_BRIGHTNESS)
|
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
|
|
|
|
2014-02-03 20:58:51 +00:00
|
|
|
extern const char *const mp_csp_equalizer_names[MP_CSP_EQ_COUNT];
|
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
|
|
|
|
|
|
|
// Default initialization with 0 is enough, except for the capabilities field
|
|
|
|
struct mp_csp_equalizer {
|
|
|
|
// Bit field of capabilities. For example (1 << MP_CSP_EQ_HUE) means hue
|
|
|
|
// support is available.
|
|
|
|
int capabilities;
|
|
|
|
// Value for each property is in the range [-100, 100].
|
|
|
|
// 0 is default, meaning neutral or no change.
|
|
|
|
int values[MP_CSP_EQ_COUNT];
|
|
|
|
};
|
|
|
|
|
2014-06-22 06:33:43 +00:00
|
|
|
struct mp_csp_col_xy {
|
|
|
|
float x, y;
|
|
|
|
};
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
void mp_csp_copy_equalizer_values(struct mp_csp_params *params,
|
|
|
|
const struct mp_csp_equalizer *eq);
|
|
|
|
|
|
|
|
int mp_csp_equalizer_set(struct mp_csp_equalizer *eq, const char *property,
|
|
|
|
int value);
|
|
|
|
|
|
|
|
int mp_csp_equalizer_get(struct mp_csp_equalizer *eq, const char *property,
|
|
|
|
int *out_value);
|
|
|
|
|
2013-06-28 19:14:43 +00:00
|
|
|
enum mp_csp avcol_spc_to_mp_csp(int avcolorspace);
|
2012-08-20 21:03:59 +00:00
|
|
|
|
2013-06-28 19:14:43 +00:00
|
|
|
enum mp_csp_levels avcol_range_to_mp_csp_levels(int avrange);
|
2012-08-20 21:03:59 +00:00
|
|
|
|
2014-03-26 00:46:38 +00:00
|
|
|
enum mp_csp_prim avcol_pri_to_mp_csp_prim(int avpri);
|
|
|
|
|
2013-06-28 19:14:43 +00:00
|
|
|
int mp_csp_to_avcol_spc(enum mp_csp colorspace);
|
2012-09-14 15:51:26 +00:00
|
|
|
|
2013-06-28 19:14:43 +00:00
|
|
|
int mp_csp_levels_to_avcol_range(enum mp_csp_levels range);
|
2012-09-14 15:51:26 +00:00
|
|
|
|
2014-03-26 00:46:38 +00:00
|
|
|
int mp_csp_prim_to_avcol_pri(enum mp_csp_prim prim);
|
|
|
|
|
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);
|
|
|
|
|
2009-12-31 18:25:35 +00:00
|
|
|
void mp_gen_gamma_map(unsigned char *map, int size, float gamma);
|
|
|
|
#define ROW_R 0
|
|
|
|
#define ROW_G 1
|
|
|
|
#define ROW_B 2
|
|
|
|
#define COL_Y 0
|
|
|
|
#define COL_U 1
|
|
|
|
#define COL_V 2
|
|
|
|
#define COL_C 3
|
2014-06-22 06:33:43 +00:00
|
|
|
struct mp_csp_primaries mp_get_csp_primaries(enum mp_csp_prim csp);
|
2014-03-26 00:46:38 +00:00
|
|
|
|
2014-03-31 22:17:07 +00:00
|
|
|
void mp_apply_chromatic_adaptation(struct mp_csp_col_xy src, struct mp_csp_col_xy dest, float m[3][3]);
|
|
|
|
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-06-22 06:33:43 +00:00
|
|
|
void mp_get_rgb2xyz_matrix(struct mp_csp_primaries space, float m[3][3]);
|
2014-03-31 02:51:47 +00:00
|
|
|
|
2014-03-31 22:17:07 +00:00
|
|
|
void mp_get_xyz2rgb_coeffs(struct mp_csp_params *params, struct mp_csp_primaries prim,
|
|
|
|
enum mp_render_intent intent, float xyz2rgb[3][4]);
|
2009-12-31 18:25:35 +00:00
|
|
|
void mp_get_yuv2rgb_coeffs(struct mp_csp_params *params, float yuv2rgb[3][4]);
|
|
|
|
void mp_gen_yuv2rgb_map(struct mp_csp_params *params, uint8_t *map, int size);
|
|
|
|
|
2014-06-22 06:33:43 +00:00
|
|
|
void mp_mul_matrix3x3(float a[3][3], float b[3][3]);
|
|
|
|
void mp_invert_matrix3x3(float m[3][3]);
|
2012-10-24 17:11:42 +00:00
|
|
|
void mp_invert_yuv2rgb(float out[3][4], float in[3][4]);
|
2012-10-25 19:23:18 +00:00
|
|
|
void mp_map_int_color(float matrix[3][4], int clip_bits, int c[3]);
|
2012-10-07 22:14:51 +00:00
|
|
|
|
2009-12-31 18:25:35 +00:00
|
|
|
#endif /* MPLAYER_CSPUTILS_H */
|