Modify the YUV->RGB conversion matrix to take into account the
difference between the same color value being x/255 in a 8-bit texture
and x*256/65535 in a 16-bit texture (actually things are stored as
x*4/65535 for 10-bit color, but that can be ignored here). This 0.4 %
difference in the shader float value could make shades of gray in
10-bit (or generally more than 8 bit) YUV produce RGB values with
green slightly higher than red/blue.
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.
Rewrite the csputils.c code generating a conversion matrix for
YUV->RGB conversions (currently used by vo_gl only). Functional
differences:
- The separate "mplayer default" colorspace is removed, and BT.601 is
used instead (the default colorspace was in fact BT.601; see below).
- The old code was missing chroma scaling. As a result the "mplayer
default" colorspace actually mapped to BT.601, and everything else
was buggy (I guess the other colorspaces were added with particular
coefficient semantics, without understanding that the original
"default colorspace" was actually BT.601 and why its coefficients
differed from the added version).
- The old code had a bug in the equalizer hue equations.
- The old code assumed that for specifying whether input and output
were limited-range or full-range YUV or RGB it would make sense to
specify "no conversion" meaning full-range YUV to full-range RGB or
limited-range YUV to limited-range RGB. This isn't true; limited-
range YUV has different ranges for luma and chroma (16-235
vs 16-240) which means you have to scale chroma for limited->limited
conversions. The new code assumes limited->limited conversions for
the levelconv parameter 2. It'd probably make sense to change the
API later to specify the ranges of input and output separately.
- The undocumented EBU and XYZ colorspaces are removed. I doubt any
videos use these. Also the EBU colorspace looks like it'd expect
a different input range - at least no input would map to full RGB
red as it was.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33502 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix clear/border color of chroma texture for 9- and 10-bit formats.
Avoids pink borders for those formats.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33504 b3059339-0415-0410-9bf9-f77b7e298cf2
Dual-license gl_common and vo_gl under the LGPL v2.1 or later as
an alternative to the GPL license.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31375 b3059339-0415-0410-9bf9-f77b7e298cf2
Allow LGPL for csputils as well, they were previously part of gl_common
and are still an important part of it.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31376 b3059339-0415-0410-9bf9-f77b7e298cf2
This could also be done by modifying contrast and brightness, but
this seems a bit more flexible and easier to use.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30335 b3059339-0415-0410-9bf9-f77b7e298cf2
