summaryrefslogtreecommitdiffstats
path: root/video/csputils.h
Commit message (Collapse)AuthorAgeFilesLines
* csputils: replace more primitives with pl_Kacper Michajłow2024-01-221-55/+2
| | | | | We can go deeper, but need to stop somewhere to not reimplement vo_gpu using libplacebo...
* csputils: replace mp_chroma_location with pl_chroma_locationKacper Michajłow2024-01-221-13/+1
|
* csputils: replace mp_alpha_type with pl_alpha_modeKacper Michajłow2024-01-221-8/+1
|
* csputils: replace mp_colorspace with pl_color_spaceKacper Michajłow2024-01-221-106/+16
|
* ALL: use pl_hdr_metadata and nuke sig_peakKacper Michajłow2023-11-051-1/+0
| | | | | | | | This commit replaces all uses of sig_peak and maps all HDR metadata. Form notable changes mixed usage of maxCLL and max_luma is resolved and not always max_luma is used which makes vo_gpu and vo_gpu_next behave the same way.
* csputils: add pl_hdr_metadata to mp_colorspace and deprecate sig_peakKacper Michajłow2023-11-051-1/+2
| | | | | Note this commit does not change all uses of sig-peak, this is for future refactoring.
* csputils: change mp_hdr_metadata to pl_hdr_metadataKacper Michajłow2023-11-051-18/+2
|
* csputils: add mp_hdr_metadataKacper Michajłow2023-08-291-0/+18
|
* video: add missing libplacebo colorspace enumsLeo Izen2023-03-051-0/+4
| | | | | Add some missing libplacebo primaries and transfer enums to mpv's enum constant tables, and update the functions that convert between the two.
* csputils: add MP_CSP_TRC_ST428 as defined in ST 428-1Kacper Michajłow2023-03-021-0/+1
|
* video: make csp option definitions privateThomas Weißschuh2023-02-241-20/+0
|
* video: make csp equalizer params floatThomas Weißschuh2023-02-241-4/+4
| | | | | | This allows more precise adjustments. Fixes #11316
* csputils: add MP_CHROMA_TOPLEFTNiklas Haas2020-12-021-0/+1
| | | | | | | | | This is commonly used by UHD/HDR sources, and mpv hilariously ignores it up until now, just blindly mapping it to MP_CHROMA_AUTO without even so much as a warning message. It would be justified to add all the other chroma locations as well, but I'm lazy and just wanted to quickly fix this bug.
* vo_gpu: reinterpret SDR white levels based on ITU-R BT.2408Niklas Haas2020-06-151-3/+5
| | | | | | | | | | | | This standard says we should use a value of 203 nits instead of 100 for mapping between SDR and HDR. Code copied from https://code.videolan.org/videolan/libplacebo/-/commit/9d9164773 In particular, that commit also includes a test case to make sure the implementation doesn't break roundtrips. Relevant to #4248 and #7357.
* csputils: add function for getting uint/float transformationwm42020-05-091-0/+2
| | | | | | | | | | | | | | This provides a way to convert YUV in fixed point (or pseudo-fixed point; probably best to say "uint") to float, or rather coefficients to perform such a conversion. Things like colorspace conversion is out of scope, so this is simple and strictly per-component. This is somewhat similar to mp_get_csp_mul(), but includes proper color range expansion and correct chroma centering. The old function even seems to have a bug, and assumes something about shifted range for full range YCbCr, which is wrong. vo_gpu should probably use the new function eventually.
* vo_gpu: fix green shit with float yuv inputwm42020-05-091-0/+2
| | | | | | | | | | | | This was incorrect at least because the colorspace matrix attempted to center chroma at (conceptually) 0.5, instead of 0. Also, it tried to apply the fixed point shift logic for component sizes > 8 bit. There is no float yuv format in mpv/ffmpeg yet, but see next commit, which enables zimg to output it. I'm assuming zimg defines this format such that luma is in range [0,1] and chroma in range [-0.5,0.5], with the levels flag being ignored. This is consistent with H264/5 Annex E (I think...), and it sort of seems to look right, so that's it.
* video: add alpha type metadatawm42020-04-241-0/+8
| | | | | | | | | This is mostly for testing. It adds passing through the metadata through the video chain. The metadata can be manipulated with vf_format. Support for zimg alpha conversion (if built with zimg after it gained alpha support) is implemented. Support premultiplied input in vo_gpu. Some things still seem to be buggy.
* video: add pure gamma TRC curves for 2.0, 2.4 and 2.6.Wessel Dankers2019-09-271-0/+3
|
* csputils: Add support for Display P3 primariesVittorio Giovara2017-12-141-0/+1
|
* video: redo video equalizer option handlingwm42017-08-221-23/+13
| | | | | | | | | | | | | | | | | | | | | | | 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.
* vo_opengl: implement sony s-log2 trcNiklas Haas2017-06-181-0/+1
| | | | | | | | Apparently this is virtually identical to Panasonic's V-Log, but using the constants from S-Log1 and an extra scaling coefficient to make the S-Log1 curve less limited. Whatever floats their NIH boat, I guess. Source: https://pro.sony.com/bbsccms/assets/files/micro/dmpc/training/S-Log2_Technical_PaperV1_0.pdf
* vo_opengl: implement sony s-log1 trcNiklas Haas2017-06-181-0/+1
| | | | | | | | Source: https://pro.sony.com/bbsccms/assets/files/mkt/cinema/solutions/slog_manual.pdf Not 100% confident in the implementation since the values from the spec seem to be very subtly off (~1%), but it should be close enough for practical purposes.
* csputils: implement sony s-gamutNiklas Haas2017-06-181-0/+1
| | | | The S-Log "matching" colorspace
* vo_opengl: tone map in linear XYZ instead of RGBNiklas Haas2017-06-181-0/+9
| | | | | | | | | | | | | This preserves channel balance better and helps reduce discoloration due to nonlinear tone mapping. I wasn't sure whether to stuff this inside pass_color_manage or pass_tone_map but decided for the former because adding the extra mp_csp_prim would have made the signature of the latter longer than 80col, and also because the `mp_get_cms_matrix` below it basically does the same thing anyway, so it doesn't look that out of place. Also why is this justification longer than the actual description of the algorithm and what it's good for?
* vo_opengl: implement support for OOTFs and non-display referred contentNiklas Haas2017-06-181-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces (yet another..) mp_colorspace members, an enum `light` (for lack of a better name) which basically tells us whether we're dealing with scene-referred or display-referred light, but also a bit more metadata (in which way is the scene-referred light expected to be mapped to the display?). The addition of this parameter accomplishes two goals: 1. Allows us to actually support HLG more-or-less correctly[1] 2. Allows people playing back direct “camera” content (e.g. v-log or s-log2) to treat it as scene-referred instead of display-referred [1] Even better would be to use the display-referred OOTF instead of the idealized OOTF, but this would require either native HLG support in LittleCMS (unlikely) or more communication between lcms.c and video_shaders.c than I'm remotely comfortable with That being said, in principle we could switch our usage of the BT.1886 EOTF to the BT.709 OETF instead and treat BT.709 content as being scene-referred under application of the 709+1886 OOTF; which moves that particular conversion from the 3dlut to the shader code; but also allows a) users like UliZappe to turn it off and b) supporting the full HLG OOTF in the same framework. But I think I prefer things as they are right now.
* csputils: rename HDR curvesNiklas Haas2017-06-181-2/+2
| | | | | | | | | | st2084 and std-b67 are really weird names for PQ and HLG, which is what everybody else (including e.g. the ITU-R) calls them. Follow their example. I decided against naming them bt2020-pq and bt2020-hlg because it's not necessary in this case. The standard name is only used for the other colorspaces etc. because those literally have no other names.
* video: refactor HDR implementationNiklas Haas2017-06-181-3/+8
| | | | | | | | | | | | | | | List of changes: 1. Kill nom_peak, since it's a pointless non-field that stores nothing of value and is _always_ derived from ref_white anyway. 2. Kill ref_white/--target-brightness, because the only case it really existed for (PQ) actually doesn't need to be this general: According to ITU-R BT.2100, PQ *always* assumes a reference monitor with a white point of 100 cd/m². 3. Improve documentation and comments surrounding this stuff. 4. Clean up some of the code in general. Move stuff where it belongs.
* demux: expose demuxer colorimetry metadata to playerNiklas Haas2016-11-081-0/+3
| | | | | | Implementation-wise, the values from the demuxer/codec header are merged with the values from the decoder such that the former are used only where the latter are unknown (0/auto).
* vo_opengl: generalize HDR tone mapping mechanismNiklas Haas2016-07-031-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | This involves multiple changes: 1. Brightness metadata is split into nominal peak and signal peak. For a quick and dirty explanation: nominal peak is the brightest value that your color space can represent (i.e. the brightness of an encoded 1.0), and signal peak is the brightest value that actually occurs in the video (i.e. the brightest thing that's displayed). 2. vo_opengl uses a new decision logic to figure out the right nom_peak and sig_peak for all situations. It also does a better job of picking the right target gamut/colorspace to use for the OSD. (Which still is and still should be treated as sRGB). This change in logic also fixes #3293 en passant. 3. Since it was growing rapidly, the logic for auto-guessing / inferring the right colorimetry configuration (in pass_colormanage) was split from the logic for actually performing the adaptation (now pass_color_map). Right now, the new logic doesn't do a whole lot since HDR metadata is still ignored (but not for long).
* mp_image: split colorimetry metadata into its own structNiklas Haas2016-07-031-7/+14
| | | | | | | | | | | | | | | | | | This has two reasons: 1. I tend to add new fields to this metadata, and every time I've done so I've consistently forgotten to update all of the dozens of places in which this colorimetry metadata might end up getting used. While most usages don't really care about most of the metadata, sometimes the intend was simply to “copy” the colorimetry metadata from one struct to another. With this being inside a substruct, those lines of code can now simply read a.color = b.color without having to care about added or removed fields. 2. It makes the type definitions nicer for upcoming refactors. In going through all of the usages, I also expanded a few where I felt that omitting the “young” fields was a bug.
* vo_opengl: revise the transfer curve logicNiklas Haas2016-06-281-0/+2
| | | | | | | | Instead of hard-coding a big list, move some of the functionality to csputils. Affects both the auto-guess blacklist and the peak estimation. Also update the comments.
* csputils: adjust whitespaceNiklas Haas2016-06-281-9/+0
| | | | | All these blank lines felt sort of weird, especially since the functions were semantically related.
* vo_opengl: implement the Panasonic V-Log functionNiklas Haas2016-06-281-0/+1
| | | | | | | | | | User request and not that hard. Closes #3157. Note that FFmpeg doesn't support this and there's no signalling in HEVC etc., so the only way users can access it is by using vf_format manually. Mind: This encoding uses full range values, not TV range.
* csputils: add Panasonic V-Gamut primariesNiklas Haas2016-06-281-0/+1
| | | | | | | This is actually not entirely trivial since it involves negative Yxy coordinates, so the CMM has to be capable of full floating point operation. Fortunately, LittleCMS is, so we can just blindly implement it.
* vo_opengl: implement ARIB STD-B68 (HLG) HDR TRCNiklas Haas2016-06-281-0/+1
| | | | | | | | | | | | | | This HDR function is unique in that it's still display-referred, it just allows for values above the reference peak (super-highlights). The official standard doesn't actually document this very well, but the nominal peak turns out to be exactly 12.0 - so we normalize to this value internally in mpv. (This lets us preserve the property that the textures are encoded in the range [0,1], preventing clipping and making the best use of an integer texture's range) This was grouped together with SMPTE ST2084 when checking libavutil compatibility since they were added in the same release window, in a similar timeframe.
* vo_opengl: implement HDR (SMPTE ST2084)Niklas Haas2016-05-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently, this relies on the user manually entering their display brightness (since we have no way to detect this at runtime or from ICC metadata). The default value of 250 was picked by looking at ~10 reviews on tftcentral.co.uk and realizing they all come with around 250 cd/m^2 out of the box. (In addition, ITU-R Rec. BT.2022 supports this) Since there is no metadata in FFmpeg to indicate usage of this TRC, the only way to actually play HDR content currently is to set ``--vf=format=gamma=st2084``. (It could be guessed based on SEI, but this is not implemented yet) Incidentally, since SEI is ignored, it's currently assumed that all content is scaled to 10,000 cd/m^2 (and hard-clipped where out of range). I don't see this assumption changing much, though. As an unfortunate consequence of the fact that we don't know the display brightness, mixed with the fact that LittleCMS' parametric tone curves are not flexible enough to support PQ, we have to build the 3DLUT against gamma 2.2 if it's used. This might be a good thing, though, consdering the PQ source space is probably not fantastic for interpolation either way. Partially addresses #2572.
* csputils: add DCI-P3 colorspaceNiklas Haas2016-03-191-0/+1
| | | | | | This colorspace has been historically used as a calibration target for most digital projectors and sees some involvement in the UltraHD standards, so it's a useful addition to mpv.
* Change GPL/LGPL dual-licensed files to LGPLwm42016-01-191-12/+7
| | | | | | | | | | | Do this to make the license situation less confusing. This change should be of no consequence, since LGPL is compatible with GPL anyway, and making it LGPL-only does not restrict the use with GPL code. Additionally, the wording implies that this is allowed, and that we can just remove the GPL part.
* csputils: update MP_STEREO3D_COUNTPaul B Mahol2015-12-191-1/+1
| | | | | | | | | | This actually alows to playback alternating videos with mpv. Tested with actual file found in wild remuxed to mkv and changed props with following command: mkvpropedit /tmp/o.mkv --edit track:1 -s stereo-mode=13 Signed-off-by: Paul B Mahol <onemda@gmail.com>
* csputils: rename "yuv2rgb" functionswm42015-12-091-2/+2
| | | | | | 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-3/+2
| | | | | This just seems unnecessary. Refactor it a bit. There should be no functional changes.
* csputils: remove obscure int_bits matrix scalingwm42015-12-091-4/+2
| | | | | | | 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-0/+2
| | | | | | | | | | | | | | | | | | | 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/+3
| | | | | | | | | | | 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.
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* csputils: add some missing colorspacesNiklas Haas2015-04-041-2/+8
| | | | | 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-3/+3
| | | | | | | | | 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-7/+6
| | | | | | | | | | | | | | | | | | | 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.
* vo_opengl: refactor shader generation (part 2)Niklas Haas2015-03-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* Revert "Revert recent vo_opengl related commits"Niklas Haas2015-02-281-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | 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-12/+4
| | | | | | | | | | | | | | | 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.
* vd_lavc: respect lavc's color_trc fieldNiklas Haas2015-02-281-0/+2
| | | | | We now actually use the TRC tagging information lavc provides us with, instead of always manually guessing.
* csputils: add missing gamma supportNiklas Haas2015-02-281-4/+10
| | | | | | | | | | | We have MP_CSP_TRC defined, but it wasn't being used by practica