summaryrefslogtreecommitdiffstats
path: root/video/out/opengl/video.c
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: simplify option handlingwm42016-09-061-20/+12
| | | | | | | | | | | | | Instead of copying the options around... just don't. video.c now has full control over when options are updated. (It still gets notified from outside, but it decides when the updated options are copied: when m_config_cache_update() is called.) So there's no need for tricky stuff, and it can be simplified a bit. Also change lcms.c. We could do it like video.c, and get the options from the global config store. But it seems simpler to just provide a pointer to an option struct, which is arbitrarily mutated from the outside (from the perspective of lcms.c).
* vo_opengl: fix --icc-profile initial behaviorwm42016-09-061-0/+1
| | | | | | | | | Setting --icc-profile had no effect, until a vo_opengl option was changed at runtime. We must initialize the renderer for the initial option state too. For some reason, the ICC profile gets loaded twice. The next commit happens to fix this.
* vo_opengl: deprecate sub-options, add them as global optionswm42016-09-021-63/+100
| | | | | | | | | | | | | | | | | | | | | | | | vo_opengl sub-option were always rather annoying to handle. It seems better to make them global options instead. This is simpler and easier to use. The only disadvantage we are aware of is that it's not clear that many/all of these new global options work with vo_opengl only. --vo=opengl-hq is also deprecated. There is extensive compatibility with the old behavior. One exception is that --vo-defaults will not apply to opengl-hq (though with opengl it still works). vo-cmdline is also dysfunctional and will be removed in a following commit. These changes also affect opengl-cb. The update mechanism is still rather inefficient: it requires syncing with the VO after each option change, rather than batching updates. There's also no granularity (video.c just updates "everything", and if auto-ICC profiles are enabled, vo_opengl.c will fetch them on each update). Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
* vo_opengl: minor renderer option access refactorwm42016-09-021-0/+13
| | | | | | | | | | | | | Reduce accesses to the renderer opts in vo_opengl.c, and instead add accessors for them to video.c. I suppose gamma and maybe icc-auto could be moved to vo_opengl.c options. Also, the output colorspace could probably be adjusted to what is really used, not just the options (although it's possible that this commit changes this, due to video.c mutating its own copy of the options according to actual renderer capapbilities). But don't deal with this now.
* vo_opengl: remove pre/post/scale-shadersNiklas Haas2016-09-021-67/+3
| | | | | | | | | | Deprecated in favor of user-shaders, which are functionally equivalent but superior. (Except in the case of scaler-shader, which has no direct replacement, but it turned out to be a very unpopular feature either way - most custom scalers don't fit into the mpv kernel infrastructure and are therefore implemented as user shaders either way) Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: explicitly check for GL errors around framebuffer depth checkwm42016-08-291-0/+4
| | | | | | | | It seems like many GL implementations (including Mesa) choke on this, while others are fine. We still think that this use of the GL API is allowed by the standard (at least in the Mesa case), so to reduce confusion, explicitly check the "controversial" calls, and use an appropriate error message.
* vo_opengl: remove the 3dlut-size npot2 restrictionNiklas Haas2016-07-251-0/+2
| | | | | | | | This requires changing the pixel upload alignment because the odd sizes might not be aligned to multiples of 4. Anyway, the restriction has no real benefit and the sizes in between 32 and 64 might be worth using, so just drop it.
* vo_opengl: increase 3DLUT accuracy at lower LUT sizesNiklas Haas2016-07-251-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | This code had the exact same texture indexing bug that the original scaler code had before the introduction of the LUT_POS macro to fix it. We can re-use this same macro here, and the performance drop is virtually entirely negligible. The benefit is greatly improved LUT accuracy as the 3DLUT size decreases - in particular, the old LUT started introducing more and more black crush the lower your LUT size is (because the error was essentially an over-contrast bias, with a magnitude linearly related to the lut size). The new code improves black stability as the LUT size decreases, and only at very low values (16 and below) do black levels start noticeably getting affected (due to crude linearization of the nonlinear response curve). The default value of 3dlut-size is definitely generous enough for this to make no difference out of the box, but it also causes no performance drop at all on my machine so I see no harm in improving the logic. Furthermore, this means we could easily decrease the default 3dlut size in a future commit, perhaps even down to 64x64x64 as a default. (But more testing is warranted here)
* vo_opengl: add a tscale=linear direct implementationNiklas Haas2016-07-211-3/+10
| | | | | | | | | | This uses GLSL mix() instead of going through an indirect texture access. Easy to implement and might require less resources on some devices, since the oversample code was already essentially just a special case of this. Could be made the new default (as per issue #2685), but that should be done in a separate commit.
* vo_opengl: error out gracefully when trying to use FBOs without FBO APIwm42016-07-041-0/+5
| | | | | | | | | | | This can for example happen with vo_opengl_cb, if it is used with a GL implementation that does not supports FBOs. (mpv itself should never attempt to use FBOs if they're not available.) Without this check it would trigger an assert() in our dummy glBindFramebuffer wrapper. Suspected cause of #3308, although it's still unlikely.
* vo_opengl: move eval_szexpr to user_shaders.cNiklas Haas2016-07-031-102/+30
| | | | | | This moves some of the bulky user-shader specific logic into the file dedicated to it. Rather than expose video.c state, variable lookup is now done via a simulated closure.
* vo_opengl: generalize HDR tone mapping mechanismNiklas Haas2016-07-031-69/+61
| | | | | | | | | | | | | | | | | | | | | | | | 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-15/+15
| | | | | | | | | | | | | | | | | | 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: don't constantly resize the output FBONiklas Haas2016-07-031-1/+1
| | | | | | | | | | Commit 883d3114 seems to have (accidentally?) dropped the FBOTEX_FUZZY from the output_fbo resize, which means that current master will keep resizing and resizing the FBO as you change the window size, introducing severe memory leaking after a while. (Not sure why that would cause memory leaks, but I blame nvidia) Either way, it's bad for performance too, so it's worth fixing.
* vo_opengl: support inconsistent negative strides per planewm42016-07-031-8/+10
| | | | | | | | | | | | | | | GL generally does not support flipping the image on upload, meaning negative strides are not supported. vo_opengl handles this by flipping rendering if the stride is inverted, and gl_pbo_upload() "ignores" negative strides by uploading without flipping the image. If individual planes had strides with different signs, this broke. The flipping affected the entire image, and only the sign of the first plane was respected. This is just a crazy corner case that will never happen, but it turns out this is quite simple to support, and actually improves the code somewhat.
* vo_opengl: move PBO upload handling to shared codewm42016-07-031-71/+8
| | | | | | | | | | | | | This introduces a gl_pbo_upload_tex() function, which works almost like our gl_upload_tex() glTexSubImage2D() wrapper, except it takes a struct which caches the PBO handles. It also takes the full texture size (to make allocating an ideal buffer size easier), and a parameter to disable PBOs (so that the caller doesn't have to duplicate the gl_upload_tex() call if PBOs are disabled or unavailable). This also removes warnings and fallbacks on PBO failure. We just silently try using PBOs on every frame, and if that fails at some point, revert to normal texture uploads. Probably doesn't matter.
* vo_opengl: remove OSD bitmap packingwm42016-07-011-1/+0
| | | | It's packed in the OSD common layer already.
* vo_opengl: add output_size uniform to custom shaderMuhammad Faiz2016-06-281-0/+3
| | | | | | logically, scaler should know its input and output size Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: minor typo and coding style fixeswm42016-06-281-5/+5
|
* vo_opengl: revise the transfer curve logicNiklas Haas2016-06-281-17/+10
| | | | | | | | 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.
* vo_opengl: revise the logic for picking the default color spaceNiklas Haas2016-06-281-11/+10
| | | | | | | Too many "exceptions" these days, it's easier to just hard-code a whitelist instead of a blacklist. And besides, it only really makes sense to avoid adaptation for BT.601 specifically, since that's the one we auto-guess based on the resolution.
* vo_opengl: use image_params instead of *_src for autoconfigNiklas Haas2016-06-281-14/+17
| | | | | | | | | | | | | | | | | I'm not even sure why we ever consulted *_src to begin with, since that just describes the current image format - and not the original metadata. (And in fact, we specifically had logic to work around the impliciations this had on linear scaling) image_params is *the* authoritative source on the intended (i.e. reference) image metadata, whereas *_src may be changed by previous passes already. So only consult image_params for picking auto-generated values. Also, add some more missing "wide gamut" and "non-gamma" curves to the autoconfig blacklist. (Maybe it would make sense to move this list to csputils in the future? Or perhaps even auto-detect it based on the associated primaries)
* vo_opengl: implement the Panasonic V-Log functionNiklas Haas2016-06-281-1/+6
| | | | | | | | | | 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.
* vo_opengl: implement ARIB STD-B68 (HLG) HDR TRCNiklas Haas2016-06-281-5/+13
| | | | | | | | | | | | | | 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.
* Fix misspellingsstepshal2016-06-261-1/+1
|
* vo_opengl: add scaler name to the 'Disabling scaler' messagedirb2016-06-221-1/+2
| | | | | Print to the user the name of the scaler that gets disabled rather than just printing its number.
* vo_opengl: unmap hwdec images once rendering is donewm42016-06-201-2/+10
| | | | | Instead of keeping them for a while. While keeping the mapping was perfectly ok, nothing speaks against reducing the time they're mapped.
* vo_opengl: vdpau interop without RGB conversionwm42016-06-191-1/+49
| | | | | | | | | | | | | | | | | | | | | | Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
* vo_opengl: remove prescaling framework with superxbr prescalerBin Jin2016-06-181-68/+2
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: remove nnedi3 prescalerBin Jin2016-06-181-72/+0
|
* vo_opengl: add ability to render to an arbitrary backing framebufferwm42016-06-181-0/+7
| | | | | | | Most of the functionality already exists for the sake of vo_opengl_cb. We only have to use it. This will be used by dxinterop in the following commit.
* vo_opengl: fix framebuffer object namewm42016-06-151-3/+4
| | | | | | | | | The OpenGL 3.0+ and ES specs are quite clear on what values are accepted for the attachment object name parameter. And there's no overlap for the default framebuffer. Sigh. Probably fixes Mesa raising an error in this case and might fix #3251. Regression by the previous vo_opengl change.
* vo_opengl: use standard functions to retrieve display depthwm42016-06-141-4/+18
| | | | | | | | | | | | | Until now, we've used system-specific API (GLX, EGL, etc.) to retrieve the depth of the default framebuffer. (We equal this to display depth and use the determined depth for dithering.) We can actually retrieve this value through standard GL API, and it works everywhere (except GLES 2 of course). This simplifies everything a great deal. egl_helpers.c is empty now. But I expect that some EGL boilerplate will be moved to it, so don't remove it yet.
* vo_opengl: make size of OUTPUT available to user shadersBin Jin2016-06-121-0/+9
|
* vo_opengl: increase the size limit for cached fileBin Jin2016-06-101-1/+1
| | | | | | This is mainly for the nnedi3 user shader. With all whose NN weights hardcoded into the shader source code, the shader file could be as large as 300 kB.
* vo_opengl: make user hook passes optionalNiklas Haas2016-06-081-16/+55
| | | | | | | | | | | | | | | | User hooks can now use an extra WHEN expression to specify when the shader should be run. For example, this can be used to only run a chroma scaling shader `WHEN CHROMA.w LUMA.w <`. There's a slight semantics change to user shaders: When trying to bind a texture that does not exist, a shader will now be silently skipped (similar to when the condition is false) instead of generating an error. This allows shader stages to depend on an optional earlier stage without having to copy/paste the same condition everywhere. (In other words: there's an implicit condition on all of the bound textures existing)
* vo_opengl: avoid outputting ultra-wide-gamut by defaultNiklas Haas2016-06-071-1/+13
| | | | | | | | | | | | The default behavior of vo_opengl has pretty much always been 'show the source colors as-is, without caring to adapt it to the target device'. This decision is mostly based on the fact that if we do anything else, lots of people will complain. With the rise of content like BT.2020, however, it turns out more people complain about this content being very desaturated than people complain about this content not matching VLC - so let's just map ultra-wide gamut content back down to standard gamut by default.
* vo_opengl: also collect upload perfdata for hwdecNiklas Haas2016-06-071-0/+4
| | | | | | Instead of measuring the actual upload time, this instead measures the time needed to render + map the texture via vdpau. These numbers are still useful, since they're part of the critical path.
* vo_opengl: expose performance timers as propertiesNiklas Haas2016-06-071-0/+18
| | | | | | | | | | | This is plumbed through a new VOCTRL, VOCTRL_PERFORMANCE_DATA, and exposed as properties render-time-last, render-time-avg etc. All of these numbers are in microseconds, which gives a good precision range when just outputting them via show-text. (Lua scripts can obviously still do their own formatting etc.) Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: add time queriesNiklas Haas2016-06-071-0/+42
| | | | | | | | | | | | | | | | | | To avoid blocking the CPU, we use 8 time objects and rotate through them, only blocking until the last possible moment (before we need access to them on the next iteration through the ring buffer). I tested it out on my machine and 4 query objects were enough to guarantee block-free querying, but the extra margin shouldn't hurt. Frame render times are just output at the end of each frame, via MP_DBG. This might be improved in the future. (In particular, I want to expose these numbers as properties so that users get some more visible feedback about render times) Currently, we measure pass_render_frame and pass_draw_to_screen separately because the former might be called multiple times due to interpolation. Doing it this way gives more faithful numbers. Same goes for frame upload times.
* vo_opengl: somewhat simplify suboption handling messwm42016-06-041-64/+16
| | | | | | | | | | | | | | | Enable m_sub_options_copy() to copy nested sub-options, and also enable it to create an option struct from defaults. We can get rid of most of the crap in assign_options() now. Calling handle_scaler_opt() to get a static allocation for scaler name is still needed. It's moved to reinit_scaler(), which seems to be a better place for it. Without it, dangling pointers could be created when options are changed. (And in fact, this fixes possible dangling pointers for window.name.) In theory we could create a dynamic copy, but that seemed even more messy. Chance of regressions.
* vo_opengl: cleanup icc + runtime option changing behaviorwm42016-06-041-12/+13
| | | | | | | | | | | | | | Commit 026b75e7 actually enabled changing icc options at runtime (via vo_cmdline), but it didn't quite work. In particular, changing the icc- profile option just kept the old profile, because it was cached accordingly. As part of this, change gl_lcms.opts from a struct to a pointer to a struct. We properly copy it, instead of allowing possibly dangling strings, like it was done in a working but unclean way before. Also, reinit the whole rendering chain when the auto icc profile changes, just like it's done when icc options are changed.
* vo_opengl: minor simplification to gl_lcms_set_memory_profile()wm42016-06-041-1/+1
| | | | | | Passing the bstr thing as pointer makes no sense. Everywhere else bstr structs are passed by value because they're so small. Only when it's supposed to receive a return value they're not.
* vo_opengl: remove pointless NULL-checkwm42016-06-041-1/+1
| | | | It's never NULL.
* vo_opengl: move all icc handling from vo_opengl.c to video.cwm42016-06-031-5/+26
| | | | | | | | | | | | | | | Originally, video.c did not access any CMS things (other than lut3d being set on it), but this has changed. In practice, almost all accesses to it have moved to video.c. vo_opengl only created it, and set the auto icc profile path. Complete the move. Some things wrt. option handling are a bit fishy. (But when is this not the case.) icc-profile-auto was not tested, but the distributed human CI will take care of it.
* vo_opengl: fix giant memory leaks with icc profileswm42016-06-031-0/+2
| | | | Well this was dumb.
* vo_opengl: default hdr-tone-mapping to hableNiklas Haas2016-05-301-0/+2
| | | | | | | | | This algorithm works really well. Setting it is a much better "out-of-the-box" experience than just clipping, which will always look ugly. In other words, with this default, users of mpv will just be able to play HDR content without even realizing it's HDR (pretty much).
* vo_opengl: refactor HDR mechanismNiklas Haas2016-05-301-15/+35
| | | | | | | | | | | | | | | | | | | | Instead of doing HDR tone mapping on an ad-hoc basis inside pass_colormanage, the reference peak of an image is now part of the image params (alongside colorspace, gamma, etc.) and tone mapping is done whenever peak_src != peak_dst. To get sensible behavior when mixing HDR and SDR content and displays, target-brightness is a generic filler for "the assumed brightness of SDR content". This gets rid of the weird display_scaled hack, sets the framework for multiple HDR functions with difference reference peaks, and allows us to (in a future commit) autodetect the right source peak from the HDR metadata. (Apart from metadata, the source peak can also be controlled via vf_format. For HDR content this adjusts the overall image brightness, for SDR content it's like simulating a different exposure)
* vo_opengl: add hable tone-mapping algorithmNiklas Haas2016-05-301-0/+1
| | | | | | | | Developed by John Hable for use in Uncharted 2. Also used by Frictional Games in SOMA. Originally inspired by a filmic tone mapping algorithm created by Kodak. From http://frictionalgames.blogspot.de/2012/09/tech-feature-hdr-lightning.html
* vo_opengl: rename tone-mapping=simple to reinhardNiklas Haas2016-05-301-4/+4