summaryrefslogtreecommitdiffstats
path: root/video/out/gl_video.c
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: treat non-blended subtitles as sRGBNiklas Haas2015-03-271-32/+44
| | | | | | | | Currently, the code just skipped CMS completely. This commit treats them as sRGB by default, instead. This also refactors much of the color management code to make it more generalized and re-usable.
* vo_opengl: add FBOTEX_FUZZY aliasNiklas Haas2015-03-261-6/+4
| | | | Minor reusability factor
* vo_opengl: simplify sampler preludeNiklas Haas2015-03-261-46/+44
| | | | | This moves common re-definitions to a custom function and also shortens the names to make stuff less verbose in general.
* vo_opengl: reset surfaces on equalizer updatesNiklas Haas2015-03-261-0/+1
| | | | | This makes the VO more responsive to equalizer changes (eg. brightness) when interpolation is used.
* vo_opengl: draw subtitles directly onto the videoNiklas Haas2015-03-261-57/+85
| | | | | | | | | | | | | | | | This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: set cscale=spline36 as default for opengl-hqNiklas Haas2015-03-251-1/+1
| | | | | | | Bilinear scaling is not a suitable default for something named "hq"; the whole reason this was done in the past was because cscale used to be obscenely slow. This is no longer the case, with cscale being nearly free.
* vo_opengl: correct OSD PTS when using interpolationNiklas Haas2015-03-251-1/+22
|
* vo_opengl: do not block on waylandJari Vetoniemi2015-03-231-0/+7
| | | | | | | | | When not receiving frame callbacks, we should not draw anything to avoid blocking the OpenGL renderer. We do this by extending gl context api, by introducing new optional function 'is_active', that indicates whether OpenGL renderers should draw or not. This fixes issue #249.
* vo_opengl: fix XYZ input gammaNiklas Haas2015-03-231-1/+1
| | | | | This seems to have been a mistranslation from the original code, which multiplied the gamma by 2.6 (*not* the color itself).
* vo_opengl: remove dead assignmentwm42015-03-231-3/+3
|
* vo_opengl_cb: don't render OSD while VO is not createdwm42015-03-231-7/+17
| | | | | | | | | | | Unlike other VOs, this rendered OSD even while no VO was created (because the renderer lives as long as the API user wants). Change this, and refactor the code so that the OSD object is accessible only while the VO is created. (There is a short time where the OSD can still be accessed even after VO destruction - this is not a race condition, though it's inelegant and unfortunately unavoidable.)
* vo_opengl: move OSD rendering to separate functionwm42015-03-231-39/+41
| | | | | Also reindent the few lines that call into the actual renderer to remove the "draw_osd" goto.
* vo_opengl: fix video equalizer gamma controlswm42015-03-221-1/+4
| | | | It was ignored.
* vo_opengl: fix background color optionwm42015-03-211-7/+5
| | | | | | gl_video_set_options() didn't update it, so the default value set on initialization was used. Fix by always setting the clear color before the clear command; it's slightly easier to follow too.
* vo_opengl: fix bicubic_fast scalerwm42015-03-211-1/+1
|
* video: uninline memcpy_pic functionswm42015-03-201-1/+0
| | | | | | | | | There's literally no reason why these functions have to be inline (they might be performance critical, but then the function call overhead isn't going to matter at all). Uninline them and move them to mp_image.c. Drop the header file and fix all uses of it.
* vo_opengl: reduce number of uniforms in dithering passwm42015-03-161-8/+5
| | | | | | | We now update uniforms every time, so we should try to reduce the number of uniforms to avoid performance penalties. (Originally, some caching was planned, but it looks like it would be too complicated to implement compared to the expected gains.)
* vo_opengl: move glViewport call closer to draw callwm42015-03-161-2/+1
|
* vo_opengl: fix srgb replacement optionsJames Ross-Gowan2015-03-161-1/+1
| | | | | | OPT_REPLACED can't specify option values or multiple options. Change to OPT_REMOVED. Also, target-prim doesn't have an srgb option. BT.709 uses sRGB primaries, so use it instead.
* vo_opengl: fix incorrectly drawn OSD in idle modewm42015-03-161-2/+2
| | | | | | Trade one bug for another, I don't even care anymore. Fixes #1691.
* vo_opengl: apply OSD color managementNiklas Haas2015-03-161-24/+39
|
* vo_opengl: improve queue size heuristicNiklas Haas2015-03-161-1/+1
| | | | | | | | The default scaling was a slight bit too low, which could cause buffer underruns in some cases. This should improve the result when using tscale filters other than oversample. The oversample case should be unaffected.
* vo_opengl: improve interpolation diagnosticsNiklas Haas2015-03-161-6/+9
| | | | | | This adds extra debugging output for buffer underruns, to help track down possible queueing issues. It also inverts the numberic output for tscale=oversample to make more sense, without changing the logic.
* vo_opengl: color manage after interpolationNiklas Haas2015-03-161-13/+18
| | | | | | | | | | | | This moves the color management code out of pass_render_main (which is now dedicated solely to up/downscaling and hence renamed pass_scale_main) and into a new function, which gets called from pass_draw_to_screen instead. This makes more sense from a logical standpoint, and also means that we interpolate in linear RGB, before color management - rather than after it, which is significantly better for color accuracy and probably also interpolation quality.
* vo_opengl: add oversample support for tscaleNiklas Haas2015-03-151-24/+45
| | | | | This is interesting mainly because it's essentially equivalent to the old smoothmotion algorithm. As such, it is now the default for tscale.
* vo_opengl: add oversample scalerNiklas Haas2015-03-151-0/+38
| | | | | | This is like nearest neighbour, but the edges between pixels are linearly interpolating if needed, as if they had been (naively) oversampled.
* vo_opengl: refactor smoothmotion -> interpolationNiklas Haas2015-03-151-76/+145
| | | | | | | | | | | | | This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
* vo_opengl: increase the number of video buffersNiklas Haas2015-03-151-12/+16
| | | | | | Also the size is now a simple #define that can easily be changed later. This is done for smoothmotion, which might want to blend more than 4 frames at once, depending on the setting.
* vo_opengl: remove hwdec unmap_image callbackwm42015-03-141-3/+0
| | | | Not needed anymore; see previous commit.
* vo_opengl: only clamp when necessaryNiklas Haas2015-03-141-2/+2
| | | | | This essentially makes it so that every gamma function that crops up somewhere has a corresponding clamp in front of it.
* vo_opengl: fix incorrect wording in commentNiklas Haas2015-03-141-1/+1
| | | | | "compand" was used where the actual operation was "compress". Change to avoid confusion.
* vo_opengl: fix uninitialization logicNiklas Haas2015-03-141-1/+8
| | | | | The FBOs we use never actually got cleaned up anywhere, and the vimg planes were hard-coded to only clean up 3.
* vo_opengl: apply alpha after conversion to rgbNiklas Haas2015-03-131-12/+7
| | | | | Currently this was done before conversion, which could fuck up a hypothetical YUVA stream.
* vo_opengl: replace float array with a structwm42015-03-131-29/+27
| | | | Slightly less painful, because C arrays suck.
* vo_opengl: remove unused declarationwm42015-03-131-5/+0
| | | | Stupid compiler.
* vo_opengl: don't test for arrayswm42015-03-131-3/+0
| | | | | | Even the lowest supported GL versions have arrays. This test was for returning arrays from functions, which didn't work in lower GL versions, but we don't need it anymore.
* vo_opengl: minor fix to a commentwm42015-03-131-2/+2
|
* vo_opengl: sample from the right tex for separated scalersNiklas Haas2015-03-131-8/+8
| | | | | These were still hard-coded to texture0, rather than respecting src_tex like they should. A simple oversight.
* vo_opengl: refactor shader generation (part 2)Niklas Haas2015-03-121-187/+677
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* vo_opengl: refactor shader generation (part 1)wm42015-03-121-1297/+628
| | | | | | | | | | | | | | | | | | | The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
* vo_opengl: move minor helper to common codewm42015-03-091-10/+1
| | | | | The generic image format code should cary most of the "knowledge" about image formats.
* vo_opengl: make smoothmotion-threshold inclusiveNiklas Haas2015-03-051-2/+2
| | | | | This behavior makes more sense near the borders, eg. smoothmotion-threshold=0 and smoothmotion-threshold=0.5.
* vo_opengl: increase ambient light changes log levelStefano Pigozzi2015-03-041-1/+1
| | | | info is a quite too annoying. increase it to verbose.
* vo_opengl: add gamma-auto optionStefano Pigozzi2015-03-041-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | This automatically sets the gamma option depending on lighting conditions measured from the computer's ambient light sensor. sRGB – arguably the “sibling” to BT.709 for still images – has a reference viewing environment defined in its specification (IEC 61966-2-1:1999, see http://www.color.org/chardata/rgb/srgb.xalter). According to this data, the assumed ambient illuminance is 64 lux. This is the illuminance where the gamma that results from ICC color management is correct. On the other hand, BT.1886 formalizes that the gamma level for dim environments to be 2.40, and Apple resources (WWDC12: 2012 Session 523: Best practices for color management) define the BT.1886 dim at 16 lux. So the logic we apply is: * >= 64lux -> 1.961 gamma * =< 16lux -> 2.400 gamma * 16lux < x < 64lux -> logaritmic rescale of lux to gamma. The human perception of illuminance roughly follows a logaritmic scale of lux [1]. [1]: https://msdn.microsoft.com/en-us/library/windows/desktop/dd319008%28v=vs.85%29.aspx
* Revert "Revert recent vo_opengl related commits"Niklas Haas2015-02-281-18/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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-1/+16
| | | | | | | | | | | | | | | 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-16/+1
| | | | | | | | | | | 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.
* vo_opengl: delete 16 bit test texturewm42015-02-271-0/+1
| | | | | Essentially a leak, but not that bad since it's small and allocated only once.
* vo_opengl: fix some commentswm42015-02-271-3/+3
|
* options: handle choice -> flag fallback automaticallywm42015-02-271-2/+2
| | | | | | | | | | | | | | | In the past it happened quite often that flag options (yes/no) were changed to choice options (yes/no/some more). The problem with this was that while flag options don't need a parameter, this wasn't the case with choice options. A hack was introduced to compensate for this: setting M_OPT_OPTIONAL_PARAM on the option, and an empty string ("") was added as choice, so that the choice could be used like a flag. So, for example, "--mute" would set the choice "". Fix this by 1. not requiring a parameter if there's a "yes" choice, and 2. redirect an empty parameter to "yes". The effect is that a choice option with the choices ["yes", "no"] is pretty much equivalent to a flag option.
* vo_opengl: implement antiringing for tensor scalersNiklas Haas2015-02-271-3/+3
| | | | | | | | | | | | This is based on pretty much the same (somewhat naive) logic right now. I'm not convinced that the extra logic that eg. madVR includes is worth enough to warrant heavily confusing the logic for it. This shouldn't slow down the logic at all in any sane shader compiler, and indeed it doesn't on any shader compiler that I tested. Note that this currently doesn't affect cscale at all, due to the weird implementation details of that.
* vo_opengl: test FBOs only if they're going to be usedwm42015-02-261-30/+28
| | | | | | | | | | Change test_fbo() so that it checks the FBO lazily, and restructure check_gl_features() to invoke it only if we know that a FBO will be needed for a certain enabled feature. This can avoid strange error messages when using --vo=opengl and the FBO format does not work. It's also less confusing when reading the verbose log (users might think that the FBO is actually used, etc.).
* vo_opengl: greatly increase smoothmotion performanceNiklas Haas2015-02-241-71/+105
| | | | | | | | | | | | | | | | | | | | Instead of rendering and upscaling each video frame on every vsync, this version of the algorithm only draws them once and caches the result, so the only operation that has to run on every vsync is a cheap linear interpolation, plus CMS/dithering. On my machine, this is a huge speedup for 24 Hz content (on a 60 Hz monitor), up to 120% faster. (The speedup is not quite 250% because of the overhead that the larger FBOs and CMS provides) In terms of the implementation, this commit basically swaps interpolation and upscaling - upscaling is moved to inter_program, and interpolation is moved to the final_program. Furthermore, the main bulk of the frame rendering logic (upscaling etc.) was moved to a separete function, which is called from gl_video_interpolate_frame only if it's actually necessarily, and skipped otherwise.
* vo_opengl: another GLES2 issuewm42015-02-241-1/+9
| | | | | | | | | | GLES2 randomly does not support the transpose parameter in matrix uniform calls. So we have to do this manually. Sure it was worth to mutilate the standard just so all these shitty SoC vendors can safe 3 lines of code. (Obviously trying to handle all of GLES2 to GL 4.x in a single codebase was a mistake.)
* vo_opengl: support polar filters of any radiusNiklas Haas2015-02-241-6/+7
| | | | | We can now truly pass a radius of 3.2383154841662362 or another real zero of the jinc function to get a better result.
* vo_opengl: explicitly check potential candidates for polar filtersNiklas Haas2015-02-241-2/+6
| | | | | | | This adds a small check for candidates that could potentially be inside the radius, but aren't necessarily. This speeds up performance by a negligible amount on my hardware, but it's mainly a prerequisite for a further change (using a larger true radius).
* vo_opengl: fix smoothmotion coefficient calculation, for real this timeNiklas Haas2015-02-201-24/+31
| | | | | | I've reworked pretty much all the logic to correspond to what the theory actually describes. With this commit, playback is wonderfully smooth on my machine.
* vo_opengl: fix smoothmotion coefficient calculationStefano Pigozzi2015-02-131-7/+3
| | | | | Using prev_pts as the start of the scale was plain wrong. Change it to prev_vsync.
* Revert "vo_opengl: disable alpha by default"wm42015-02-061-2/+2
| | | | | | | | | | This reverts commit a33b46194c3525cb585cc78b449ec275dbfd7f83. It turns out FFmpeg really considers this a bug, and fixed it by making the decoder output the correct pixel format. Fixes #1565. Reverts the fix #1528, though it should work fine with a recent git master FFmpeg.
*