summaryrefslogtreecommitdiffstats
path: root/libvo/csputils.h
Commit message (Collapse)AuthorAgeFilesLines
* video: honor the video's colormatrix and color range flagscantabile2012-08-211-0/+5
| | | | | | If either of them is not defined, the old behavior is used: - the colormatrix is guessed based on resolution. - the color range is assumed to be tv aka limited range.
* vo_gl: improve 10-bit YUV->RGB conversion accuracy slightlyUoti Urpala2012-03-091-1/+2
| | | | | | | | | | 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.
* video, options: implement better YUV->RGB conversion controlwm42011-10-161-9/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* csputils/vo_gl: rewrite YUV->RGB matrix generationUoti Urpala2011-08-291-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* cosmetics: csputils.[ch]: reindentUoti Urpala2011-08-281-21/+21
|
* vo_gl: Support 9- and 10-bit YUV input for OpenGL VOsreimar2011-07-061-0/+1
| | | | | | | | | 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
* vo_gl, csputils: dual-license under LGPL v2.1reimar2010-11-021-0/+5
| | | | | | | | | | | | 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
* Add support for adjustable TV <-> PC level conversion.reimar2010-01-161-0/+8
| | | | | | | | 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
* Slightly generalize code to generate YUV->RGB conversion table and addreimar2010-01-011-0/+1
| | | | | | | XYZ->RGB conversion as an example for that. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30163 b3059339-0415-0410-9bf9-f77b7e298cf2
* First steps to supporting different YUV->RGB conversion definitions.reimar2009-12-311-0/+10
| | | | | | | The numbers are possibly still wrong though. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30151 b3059339-0415-0410-9bf9-f77b7e298cf2
* Extract functions to generate yuv->rgb matrices and lookup tables into areimar2009-12-311-0/+45
separate file. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30150 b3059339-0415-0410-9bf9-f77b7e298cf2