summaryrefslogtreecommitdiffstats
path: root/video/out/gl_video.c
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* vo_opengl: add support for linear scaling without CMSNiklas Haas2015-02-061-18/+27
| | | | | | | | | | This introduces a new option linear-scaling, which is now implied by srgb, icc-profile and sigmoid-upscaling. Notably, this means (sigmoidized) linear upscaling is now enabled by default in opengl-hq mode. The impact should be negligible, and there has been no observation of negative side effects of sigmoidized scaling, so it feels safe to do so.
* vo_opengl: redraw when pausing while showing an interpolated framewm42015-02-041-1/+11
| | | | | If smoothmotion is enabled, and the screen shows an interpolated frame the moment you pause, redraw a non-interpolated frame.
* vo_opengl: disable alpha by defaultwm42015-02-031-2/+2
| | | | | | | | | | | | | This reverts the default behavior introduced in commit 93feffad. Way too often libavcodec will return RGB data that has an alpha channel as per pixel format, but actually contains garbage. On the other hand, this will actually render garbage color values in e.g. PNG files (for pixels with alpha==0, the color value should be essentially ignored, which is what the old alpha blend mode did). This "fixes" #1528, which is probably a decoder bug (or far less likely, a broken file).
* vo_opengl: avoid unnecessary shader reinit on fullscreen togglewm42015-02-031-2/+4
| | | | | Makes it unnecessarily slow. It's still needed if the sigmoid crap is actually used.
* vo_opengl: change initialization of gamma optionwm42015-02-031-14/+36
| | | | | | | | | | Make the lazy gamma initialization less weird, and make the default value of the "gamma" sub-option 1.0. This means --vo=opengl:help will list the actual default value. Also change the lower bound to 0.1 - avoids a division by zero (I don't know how shaders handle NaN, but it's probably not a good idea to give them this value).
* csputils, vo_opengl: remove per-component gammawm42015-02-031-4/+2
| | | | | | | | | 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.
* vo_opengl: change upper bound of :gamma to 2.0Niklas Haas2015-02-031-1/+1
| | | | | This allows a spread of 1.0 in either direction, which is already close to absurd. Anything higher than that is pretty pointless.
* vo_opengl: fix breakage with rotated video on initial displaywm42015-02-021-11/+11
| | | | | | | Resizing was happening before reconfig, so src_rect_rot was outdated and didn't include the rotation. This resulted in corrupted rendering on initial display, which fixed itself after the first time the window was somehow resized.
* vo_opengl: use triangle strip for videowm42015-01-301-41/+24
| | | | | | | | | A small simplification. Couldn't be done before, because it was also used by the OSD code, which required disjoint quads in a single draw call. Also mess with the unrelated code in gl_osd.c to simplify it a little as well.
* vo_opengl: don't unnecessarily call glDebugMessageCallback()wm42015-01-301-1/+2
| | | | | | We still do redundant calls to it, but obviously we can avoid calling it if we don't want to set a callback at all. May or may not help with default.
* vo_opengl: let hwdec driver report the exact image formatwm42015-01-291-19/+21
| | | | | | | | | | | | | | | | | | | | Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
* vo_opengl: move remaining OSD rendering parts to gl_osd.cwm42015-01-291-120/+22
| | | | | | | | | | | | Reduces the size of gl_video.c a bit further. This also uses a separate vertex array object for OSD elements, so the video one can be simplified slightly. OSD shader generation is still in gl_video.c, which leads to the strange additional parameter to mpgl_osd_init(). The issue is that video parameters influence the OSD shader (????), and also OSD needs to go through the screen colormanagement.
* vo_opengl: split out a helper for drawing primitiveswm42015-01-291-12/+1
| | | | | | | | Useful if we want to reduce the size of gl_video.c further. To some degree this emulates traditional glDrawArrays() usage. It also leaves a loophole for avoiding a reupload every time by leaving ptr==NULL, although this is unused for now.
* vo_opengl: some minor cleanupswm42015-01-291-99/+45
| | | | | | | | | | | | | | | default_tex_params() and texture_size() are each called only once, so move inline/reimplement them at the caller. image_dw/dh were unused. texture_w/h, image_format, and component_bits were rarely used, and can be replaced. Regroup some other fields. Rename surface_num to surface_idx, because the former sounded like a count, and not an index. Move fbosurface_next() closer to its callers too. Move the DebugMessageCallback() code to gl_utils.c (also simplify it by always setting the callback, instead of only when it changes).
* vo_opengl: move FBO helper to gl_utilswm42015-01-291-118/+31
| | | | | | | | | | | | | This is somewhat messy, because fbotex_init() itself was depending on some gl_video parameters unrelated to FBO creation (like what scaler was in use - what the fuck did this check do in this function?), so this commit does a bit more than moving code around. In particular, the FBO for the separate scaling intermediate step now always uses GL_NEAREST sampling, and all FBOs are destroyed/recreated on renderer reinitialization. This also moves the function matrix_ortho2d() - trivial enough not to put it into a separate commit.
* vo_opengl: create abstraction for VAOswm42015-01-281-62/+15
| | | | | | Handles stupid boilerplate OpenGL requires you to handle. It's the same code as in gl_video.c, although if no VAOs are available, the fallback code rebinds them on every draw call instead of just once.
* vo_opengl: move utility functions from loader to a separate filewm42015-01-281-0/+1
| | | | | | | gl_common.c contained the function loader (which is big) and additional utility functions (not so big, but will grow when moving more out of gl_video.c). Just split them. There are no changes other than some modifications to comments.
* vo_opengl: remove is_linear_rgb and clean up codeNiklas Haas2015-01-281-11/+11
| | | | This opportunity for refactoring was enabled by f3c84a3.
* vo_opengl: fix the fix for fixing odd video sizeswm42015-01-281-16/+15
| | | | | | | Commit acb40644 fixed video with unaligned luma/chroma sizes. It attempted to disable the fix for videos where it effectively does nothing (just some minor performance paranoia), but this check was broken - fix it by not duplicating the logic for this.
* vo_opengl: fix display of ARGB ith color management enabledwm42015-01-281-27/+8
| | | | | | | | | | | | | | | | | | | | PNG uses a different component order from GL_RGBA, so we upload the surface using the "wrong" order, and then fix it in the shader. This breaks if a sRGB texture (GL_SRGB) is used: the hardware will not touch the alpha channel, which means that the B component is not adjusted, leading to incorrect output. Just remove the use of sRGB textures completely. It might lead to a slight slow down when playing RGB with color management enabled, but with this combination of obscure use case with minor performance impact it's not a meaningful disadvantage. Unfortunately this also means that alpha is handled incorrectly with our own color management, but alpha isn't so important and can be fixed later. (0.0 and 1.0 are unchanged by the transfer function, so it "mostly" works.) Fixes #1530.
* vo_opengl: change the way unaligned chroma size is handledwm42015-01-271-10/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This deals with subsampled YUV video that has odd sizes, for example a 5x5 image with 4:2:0 subsampling. It would be easy to handle if we actually passed separate texture coordinates for each plane to the shader, but as of now the luma coordinates are implicitly rescaled to chroma one. If luma and chroma sizes don't match up, and this is not handled, you'd get a chroma shift by 1 pixel. The existing hack worked, but broke separable scaling. This was exposed by a recent commit which switched to GL_NEAREST sampling for FBOs. The rendering was accidentally scaled by 1 pixel, because the FBO size used the original video size, while textures_sizes[0] was set to the padded texture size (i.e. one pixel larger). It could be fixed by setting the padded texture size only on the first shader. But somehow that is annoying, so do something else. Don't pad textures anymore, and rescale the chroma coordinates in the shader instead. Seems like this somehow doesn't work with rectangle textures (and introduces a chroma shift), but since it's only used when doing VDA hardware decoding, and the bug occurs only with unaligned video sizes, I don't care much. Fixes #1523.
* vo_opengl: make "mitchell" the hq default filter for downscalingwm42015-01-261-1/+2
| | | | | | | | | | | | | Seems like several people agree that it's a good filter for downscaling. Setting this option by default may also prevent people from accidentally using an unsuitable filter for downscaling by setting "scale" and without being aware of the impliciations (maybe). On the other hand, this change is not strictly backwards compatible for the same reasons. Also, allow disabling this option with scale-down="" (before this, not setting it was the only way to do this - not possible anymore if it's set by default). This is what the change in handle_scaler_opt() does.
* vo_opengl: simplify radius initializationwm42015-01-261-16/+5
| | | | | | | | | | | | | | | Somehow, the default radius for filters with variable radius was set in mp_init_filter(). gl_video.c used NAN as default value for the radius, which would make the filter use the default radius. Simplify this, and set the default radius directly in the gl_video options. It also makes the options easier to understand, because the default value listed in --vo=opengl:help actually shows the default value. Remove the function can_use_filter_kernel(), because it doesn't set a radius if none is set. The function is worthless anyway (something about making filter_kernels.c reusable to other VOs, and trying to deal with the possibility that it could provide filters not supported by vo_opengl.)
* vo_opengl: fancy-downscale affects luma-scaler onlywm42015-01-251-1/+1
|
* vo: simplify VOs by adding generic screenshot supportwm42015-01-241-6/+0
| | | | | | | | | | | At the time screenshot support was added, images weren't refcounted yet, so screenshots required specialized implementations in the VOs. But now we can handle these things much simpler. Also see commit 5bb24980. If there are VOs in the future which can't do this (e.g. they need to write to the image passed to vo_driver->draw_image), this still could be disabled on a per-VO basis etc., so we lose no potential performance advantages.
* vo_opengl: add smoothmotion frame blendingStefano Pigozzi2015-01-231-7/+132
| | | | | | | | | | | | | | | | | | | SmoothMotion is a way to time and blend frames made popular by MadVR. It's intended behaviour is to remove stuttering caused by mismatches between the display refresh rate and the video fps, while preserving the video's original artistic qualities (no soap opera effect). It's supposed to make 24fps video playback on 60hz monitors as close as possible to a 24hz monitor. Instead of drawing a frame once once it's pts has passed the vsync time, we redraw at the display refresh rate, and if we detect the vsync is between two frames we interpolated them (depending on their position relative to the vsync). We actually interpolate as few frames as possible to avoid a blur effect as much as possible. For example, if we were to play back a 1fps video on a 60hz monitor, we would blend at most on 1 vsync for each frame (while the other 59 vsyncs would be rendered as is). Frame interpolation is always done before scaling and in linear light when possible (an ICC profile is used, or :srgb is used).
* vo_opengl: improve terminal messages with lscale suboption errorswm42015-01-221-5/+13
| | | | Make it more apparent what the hell the user did wrong.
* vo_opengl: remove scale-sep and indirect optionsNiklas Haas2015-01-221-14/+12
| | | | | | | | | | | | These are now auto-detected sanely; and enabled whenever it would be a performance or quality gain (which is pretty much everything except bilinear/bilinear scaling). Perhaps notably, with the absence of scale_sep, there's no more way to use convolution filters on hardware without FBOs, but I don't think there's hardware in existence that doesn't have FBOs but is still fast enough to run the fallback (slow) 2D convolution filters, so I don't think it's a net loss.
* vo_opengl: rename all scale options to make more senseNiklas Haas2015-01-221-16/+28
| | | | | This emphasizes the fact that scale is used for *all* image upscaling, with cscale only serving a minor role for subsampled material.
* vo_opengl: switch to nearest neighbour for trivial resamplingNiklas Haas