summaryrefslogtreecommitdiffstats
path: root/video/csputils.c
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: fix gray playbackwm42015-12-261-4/+3
| | | | | | Commit f24ba544 wasn't an equivalent change. (This shit needs some sort of automated tests.)
* csputils: let mpv recognise frame sequenced 3D matroska videosPaul B Mahol2015-12-181-0/+2
| | | | | | Do actually such files exist? Signed-off-by: Paul B Mahol <onemda@gmail.com>
* vo_opengl: enable brightness/contrast controls for RGBwm42015-12-121-8/+13
| | | | | | | | | Why not. Also, instead of disabling hue/saturation for RGB, just don't apply them. (They don't make sense for conversion matrixes other than YUV, but I can't be bothered to keep the fine-grained disabling of UI controls either.)
* csputils: rename "yuv2rgb" functionswm42015-12-091-4/+4
| | | | | | They're not necessarily restricted to YUV aka YCbCr. vo_direct3d.c and demux_disc.c (DVD specific code) changes untested.
* csputils, vo_opengl: remove XYZ special case in color matrix retrievalwm42015-12-091-5/+5
| | | | | This just seems unnecessary. Refactor it a bit. There should be no functional changes.
* csputils: remove obscure int_bits matrix scalingwm42015-12-091-17/+8
| | | | | | | This has no reason to be there. Put the functionality into another function instead. While we're at it, also adjust for possible accuracy issues with high bit depth YUV (matters for rendering subtitles into screenshots only).
* vo_opengl: fix issues with some obscure pixel formatswm42015-12-071-4/+24
| | | | | | | | | | | | | | | | | | | The computation of the tex_mul variable was broken in multiple ways. This variable is used e.g. by debanding for moving expansion of 10 bit fixed-point input to normalized range to another stage of processing. One obvious bug was that the rgb555 pixel format was broken. This format has component_bits=5, but obviously it's already sampled in normalized range, and does not need expansion. The tex_mul-free code path avoids this by not using the colormatrix. (The code was originally designed to work around dealing with the generally complicated pixel formats by only using the colormatrix in the YUV case.) Another possible bug was with 10 bit input. It expanded the input by bringing the [0,2^10) range to [0,1], and then treating the expanded input as 16 bit input. I didn't bother to check what this actually computed, but it's somewhat likely it was wrong anyway. Now it uses mp_get_csp_mul(), and disables expansion when computing the YUV matrix.
* video: replace vf_format outputlevels option with global optionwm42015-09-291-1/+2
| | | | | | | | | | | The vf_format suboption is replaced with --video-output-levels (a global option and property). In particular, the parameter is removed from mp_image_params. The mechanism is moved to the "video equalizer", which also handles common video output customization like brightness and contrast controls. The new code is slightly cleaner, and the top-level option is slightly more user-friendly than as vf_format sub-option.
* video: add a way to disable automatic stereo conversionwm42015-07-101-0/+1
| | | | Fixes #2111.
* csputils: improve contrast semantics for limited range outputNiklas Haas2015-04-291-5/+9
| | | | | The previous version of this logic resulted in black crush and incorrect brightness scaling when combined with limited range (TV) output.
* csputils: apply contrast equalizer in RGBwm42015-04-291-8/+3
| | | | | | | | It's weird that this basically adjusts the contrast between luma and chroma, and not blackness. This is more in line with the behavior of libswscale, the vdpau "procamp" (which mpv doesn't use), and Xv.
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* csputils: add some missing colorspacesNiklas Haas2015-04-041-8/+53
| | | | | With target-prim and target-trc it makes sense to include some common colorspaces that aren't strictly speaking used for video.
* video: cleanup stereo mode parsingwm42015-04-021-17/+16
| | | | | | | | | Use OPT_CHOICE_C() instead of the custom parser. The functionality is pretty much equivalent. (On a side note, it seems --video-stereo-mode can't be removed, because it controls whether to "reduce" stereo video to mono, which is also the default. In fact I'm not sure how this should be handled at all.)
* video: move colorspace overrides to vf_format, simplifywm42015-03-311-26/+31
| | | | | | | | | | | | | | | | | | | Remove the colorspace-related top-level options, add them to vf_format. They are rather obscure and not needed often, so it's better to get them out of the way. In particular, this gets rid of the semi-complicated logic in command.c (most of which was needed for OSD display and the direct feedback from the VO). It removes the duplicated color-related name mappings. This removes the ability to write the colormatrix and related properties. Since filters can be changed at runtime, there's no loss of functionality, except that you can't cycle automatically through the color constants anymore (but who needs to do this). This also changes the type of the mp_csp_names and related variables, so they can directly be used with OPT_CHOICE. This probably ended up a bit awkward, for the sake of not adding a new option type which would have used the previous format.
* csputils: unify names for colorspace/etc. nameswm42015-03-311-23/+23
|
* vo_opengl: refactor shader generation (part 2)Niklas Haas2015-03-121-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* Remove some FFmpeg/Libav compatibility hackswm42015-03-031-8/+0
| | | | | | All of these are now in the supported FFmpeg and Libav versions. The 3 remaining API checks are for FFmpeg-only things.
* Revert "Revert recent vo_opengl related commits"Niklas Haas2015-02-281-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | 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");
* Revert recent vo_opengl related commitswm42015-02-281-33/+0
| | | | | | | | | | | | | | | Breaks vo_opengl by default. I'm hot able to fix this myself, because I have no clue about the overcomplicated color management logic. Also, whilethis is apparently caused by commit fbacd5, the following commits all depend on it, so revert them too. This reverts the following commits: e141caa97dade07f4d7e0d6c208bcd3493e712ed 653b0dd5295453d9661f673b4ebd02c5ceacf645 729c8b3f641e633474be612e66388c131a1b5c92 fbacd5de31de964f7cd562304ab1c9b4a0d76015 Fixes #1636.
* csputils: add missing gamma supportNiklas Haas2015-02-281-0/+33
| | | | | | | | | | | We have MP_CSP_TRC defined, but it wasn't being used by practically anything. This commit adds missing conversion logic, adds it to mp_image, and moves the auto-guessing logic to where it should be, in mp_image_params_guess_csp (and out of vo_opengl). Note that this also fixes a minor bug: csp_prim was not being copied between mp_image structs if the format was not YUV in both cases, but this is wrong - the primaries are always relevant.
* csputils: add support for BT.470-MNiklas Haas2015-02-281-1/+12
| | | | | For some kind of legacy TV system, who knows? But ffmpeg supports it, and it's cheap for us to add.
* csputils, vo_opengl: remove per-component gammawm42015-02-031-4/+1
| | | | | | | | | There was some code accounting for different gamma values for R/G/B. It's inherited from an old, undocumented MPlayer feature, which was at some point disabled for convenience by myself (meaning you couldn't actually set separate gamma because it was removed from the property interface - mp_csp_copy_equalizer_values() just set them to the same value). Get rid of these meaningless leftovers.
* csputils: remove some unused functions, make some privatewm42015-02-031-62/+4
| | | | | | mp_gen_gamma_map() and mp_gen_yuv2rgb_map() were used by vo_opengl_old only. The other functions removed from csputils.h are used by csputils.c only.
* vo_opengl: handle grayscale input better, add YA16 supportwm42015-01-211-2/+2
| | | | | | | | | | Simply clamp off the U/V components in the colormatrix, instead of doing something special in the shader. Also, since YA8/YA16 gave a plane_bits value of 16/32, and a colormatrix calculation overflowed with 32, add a component_bits field to the image format descriptor, which for YA8/YA16 returns 8/16 (the wrong value had no bad consequences otherwise).
* video: Remove some stale CMS code, minor cosmeticsNiklas Haas2015-01-071-5/+1
| | | | This removes an old code path that was disabled in 016bb14.
* csputils: use M_PIwm42015-01-061-1/+1
|
* csputils: replace float[3][4] with a structwm42015-01-061-71/+53
| | | | | Not being able to use the 3x3 part of the matrix was annoying, so split it into a float[3][3] matrix and a separate float[3] constant vector.
* csputils: move image_params -> csp_params into a functionwm42015-01-061-0/+12
| | | | | | | | | Although the line count increases, this is better for making sure everything is handled consistently for all users of the mp_csp_params stuff. This also makes sure mp_csp_params is always initialized with MP_CSP_PARAMS_DEFAULTS (for consistency).
* csputils: get rid of mp_csp_detailswm42015-01-061-6/+6
| | | | It used to be central, but now it's just unneeded.
* csputils: cosmeticswm42015-01-061-137/+112
| | | | Fix some coding style issues, remove doxygen formatting.
* video: adjust some Matroska 3D formatswm42014-08-311-2/+2
| | | | | | | There is no proper and exact spec (Matroska tradition), so we probably have to rely on guessing for this. Also see issue #1045.
* csputils: adjust commentwm42014-08-301-3/+3
| | | | | Make it clear that the value is linked to the StereoMode element. You can't change this without adjusting demux_mkv.c.
* video: initial Matroska 3D supportwm42014-08-301-0/+22
| | | | | | | | | | | | | | | | | | | | | This inserts an automatic conversion filter if a Matroska file is marked as 3D (StereoMode element). The basic idea is similar to video rotation and colorspace handling: the 3D mode is added as a property to the video params. Depending on this property, a video filter can be inserted. As of this commit, extending mp_image_params is actually completely unnecessary - but the idea is that it will make it easier to integrate with VOs supporting stereo 3D mogrification. Although vo_opengl does support some stereo rendering, it didn't support the mode my sample file used, so I'll leave that part for later. Not that most mappings from Matroska mode to vf_stereo3d mode are probably wrong, and some are missing. Assuming that Matroska modes, and vf_stereo3d in modes, and out modes are all the same might be an oversimplification - we'll see. See issue #1045.
* video: add a default color space for files with no videoNiklas Haas2014-07-281-0/+3
| | | | | | | | | | | | | | | | | | Usually mp_image_params_guess_csp takes care of finding *some* default for a video channel, but files with no video (or with extremely broken configurations) end up leaving the colorspace information as MP_CSP_PRIM_AUTO, which has no associated primaries. As a result of this, color managed OSD messages could not display because they were being color managed to match the (non-existing/absurd) video channel. With this change, such non-spaces will have BT.709 primaries as far as color management and the OSD is concerned. This fixes #961. CC: @mpv-player/stable Signed-off-by: wm4 <wm4@nowhere>
* video: Include better heuristics for guessing primariesNiklas Haas2014-06-221-0/+19
| | | | | | | These consult the vertical resolution, matching against 576 for PAL and 480/486 for NTSC. The documentation has also been updated. Signed-off-by: wm4 <wm4@nowhere>
* video: Refactor rendering intent for DCP XYZ and :srgbNiklas Haas2014-06-221-55/+75
| | | | | | Notably, we now conform to SMPTE 428-1-2006 when decoding XYZ12 input, and we can support rendering intents other than colorimetric when converting between BT.709 and BT.2020, like with :srgb or :icc-profile.
* video: Better support for XYZ inputNiklas Haas2014-06-221-0/+30
| | | | | | | | | With this change, XYZ input is directly converted to the output colorspace wherever possible, and to the colorspace specified by the tags and/or --primaries option, otherwise. This commit also restructures some of the CMS code in gl_video.c to hopefully make it clearer which decision is being done where and why.
* video: Generate an accurate CMS matrix instead of hard-codingNiklas Haas2014-06-221-82/+216
| | | | | | | | | This also avoids an extra matrix multiplication when using :srgb, making that path both more efficient and also eliminating more hard-coded values. In addition, the previously hard-coded XYZ to RGB matrix will be dynamically generated.
* video: Support BT.2020 constant luminance systemNiklas Haas2014-06-221-1/+13
| | | | Signed-off-by: wm4 <wm4@nowhere>
* video: Add support for non-BT.709 primariesNiklas Haas2014-06-221-1/+83
| | | | | | | This add support for reading primary information from lavc, categorized into BT.601-525, BT.601-625, BT.709 and BT.2020; and passes it on to the vo. In vo_opengl, we always generate the 3dlut against the wider BT.2020 and transform our source into this colorspace in the shader.
* video: Add BT.2020-NCL colorspace and transfer functionNiklas Haas2014-06-221-7/+17
| | | | Source: http://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2020-0-201208-I!!PDF-E.pdf
* csputils: provide string descriptions of chroma locationswm42014-02-161-0/+6
|
* csputils: correct constness of csp name constantswm42014-02-031-3/+3
|
* video: support setting libswscale chroma positionwm42013-07-251-0/+9
|
* sd_add: add terrible hack for (xy-)vsfilter compatibilitywm42013-07-151-0/+6
| | | | | | Much has been said about this topic, we don't need to say even more. See additions to options.rst.
* csputils.h: don't recursively include libavcodec headerwm42013-06-281-9/+10
| | | | | | | | Some functions (avcol_spc_to_mp_csp() etc.) used libavcodec enum types as parameters. Remove these in order to get rid of the avcodec.h include statement. This prevents that avcodec.h is recursively included by dozens of files. Fix mp_image.c, which used the header without explicitly including avcodec.h.
* vo_opengl: handle chroma locationwm42013-06-281-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Silence some compiler warningswm42013-05-211-1/+1
| | | | None of these were actual issues.
* csputils: use AVCOL_SPC_YCOCG instead of AVCOL_SPC_YCGCO (fixes Libav build)wm42013-05-051-2/+2
| | | | | | | | This one should probably be blamed on ffmpeg. Its headers contain: #define AVCOL_SPC_YCGCO AVCOL_SPC_YCOCG Uh, ok...
* video: support YCgCo colorspacewm42013-05-041-0/+12
| | | | | | | YCgCo can be manually selected, but will also be used if the decoder reports YCgCo. To make things more fun, files are sometimes marked incorrectly, which will display such broken files incorrectly starting with this commit.
* vo_opengl: XYZ input supportwm42013-05-041-3/+23
| | | | | | | | | | | | | | | | Useful for the j2k decoder. Matrix taken from http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html (XYZ to sRGB, whitepoint D65) Gamma conversion follows what libswscale does (2.6 in, 2.2 out). If linear RGB is used internally for scaling, the gamma conversion will be undone by setting the exponent to 1. Unfortunately, the two gamma values don't compensate each others exactly (2.2 vs. 1/0.45=2.22...), so output is a little bit incorrect in sRGB or color-managed mode. But for now try hard to match libswscale output, which may or may not be correct.
* Rename directories, move files (step 1 of 2) (does not compile)wm42012-11-121-0/+391
Tis drops the silly lib prefixes, and attempts to organize the tree in a more logical way. Make the top-level directory less cluttered as well. Renames the following directories: libaf -> audio/filter libao2 -> audio/out libvo -> video/out libmpdemux -> demux Split libmpcodecs: vf* -> video/filter vd*, dec_video.* -> video/decode mp_image*, img_format*, ... -> video/ ad*, dec_audio.* -> audio/decode libaf/format.* is moved to audio/ - this is similar to how mp_image.* is located in video/. Move most top-level .c/.h files to core. (talloc.c/.h is left on top- level, because it's external.) Park some of the more annoying files in compat/. Some of these are relicts from the time mplayer used ffmpeg internals. sub/ is not split, because it's too much of a mess (subtitle code is mixed with OSD display and rendering). Maybe the organization of core is not ideal: it mixes playback core (like mplayer.c) and utility helpers (like bstr.c/h). Should the need arise, the playback core will be moved somewhere else, while core contains all helper and common code.
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-02 00:19:06 +0000