summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu: reduce the --alpha=blend-tiles checkerboard intensityNiklas Haas2017-09-221-1/+1
| | | | | | | | This was sort of grating by default and made it really hard to actually read e.g. text on top of a transparent background. I decided to approach the problem from both directions, making the whites darker and the grays lighter. This brings it closer to the dynamic range of e.g. the wikipedia transparent svg preview.
* vo_gpu: simplify compute shader coordinate calculationNiklas Haas2017-09-221-5/+2
| | | | Since the removal of FBOTEX_FUZZY, this can be made slightly simpler.
* vo_gpu: simplify structs / namesNiklas Haas2017-09-2212-377/+331
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
* vo_gpu: kill off FBOTEX_FUZZYNiklas Haas2017-09-223-35/+18
| | | | | | | | | | I've observed the garbage pixels in more scenarios. They also were never really needed to begin with, originally being a discovered work-around for bug that we fixed since then anyway. Doesn't really seem to even help resizing, since the OpenGL drivers are all smart enough to pool resources internally anyway. Fixes #1814
* Revert "cocoa: re-enable double buffering"James Ross-Gowan2017-09-222-3/+3
| | | | | | | | Enabling double buffering fixed some graphical glitches when entering fullscreen, but it also caused a fullscreen performance regression. We decided that the glitches were preferable to the performance regression. This reverts commit cee764849e4fe22b00fb3f31838a63906e2e0d54.
* vo_gpu: override ra_swapchain_fns for the d3d11 surfaceJames Ross-Gowan2017-09-221-89/+112
| | | | | ANGLE can take advantage of some of these when using the external swapchain-backed surface.
* vo_gpu: opengl: fix possible screenshot window crashNiklas Haas2017-09-221-1/+1
| | | | | | gl_read_fbo_contents can fail Fixes #4905
* vo_opengl_cb: fix segfault on uninitNiklas Haas2017-09-221-1/+3
| | | | | | | | | The code used ra_ctx_destroy even though ra_ctx_create was never called (since it's just a dummy ctx), which led to a conflict of assumptions. The proper fix is to only use ra_gl_ctx_uninit (mirroring the ra_gl_ctx_init) and free the dummy ctx manually. Fixes https://github.com/cmdrkotori/mpc-qt/issues/129
* options: properly handle deprecated options with CLI actionswm42017-09-221-1/+1
| | | | | | | | We want e.g. --opengl-shaders-append=foo to resolve to the new option, all while printing an option name. --opengl-shader is a similar case. These options are special, because they apply "actions" on actual options by specifying a suffix. So the alias/deprecation handling has to be part of resolving the actual option from prefix and suffix.
* vo_gpu: fix autoprobing messagewm42017-09-221-2/+4
|
* build: make vo_gpu + infrastructure non-optionalwm42017-09-221-2/+0
| | | | | Also readd the the error message for when no GL backends are found (why was this removed?).
* vd_lavc: revert accidental vaapi changes revertwm42017-09-221-7/+5
| | | | | | | Commit bfa9b628589068 accidentally reverted these (because my editor did not reload the file correctly). Fixes #4904.
* vo_opengl_cb: hwdec_ios: fix buildAman Gupta2017-09-221-3/+5
| | | | | | | | | | | | | | [179/188] Compiling video/out/vo_lavc.c ../../video/out/opengl/hwdec_ios.m:135:9: warning: unused variable 'gl' [-Wunused-variable] GL *gl = ra_gl_get(mapper->ra); ^ ../../video/out/opengl/hwdec_ios.m:247:48: warning: incompatible pointer to integer conversion passing 'CVOpenGLESTextureRef' (aka 'struct __CVBuffer *') to parameter of type 'GLuint' (aka 'unsigned int') [-Wint-conversion] p->gl_planes[i]); ^~~~~~~~~~~~~~~ ../../video/out/opengl/ra_gl.h:9:45: note: passing argument to parameter 'gl_texture' here GLuint gl_texture); ^ 2 warnings generated.
* vo_gpu: fix vo=opengl legacy aliasNiklas Haas2017-09-211-2/+4
| | | | | | | Turns out the option code apparently tries to directly talloc_free() the allocated strings, instead of going through a tactx wrapper or something. So we can't directly overwrite it. Do something else instead..
* vo_gpu: fix memleak in ra_gl_ctxNiklas Haas2017-09-211-2/+5
| | | | | | The ctx->ra was never freed propely, nor was p->wrapped_fb. (TIL: MPV_LEAK_REPORT exists)
* vo_gpu: drop the RA_CAP_NESTED_ARRAY req from EWA computeNiklas Haas2017-09-212-26/+24
| | | | | | | | | | Almost as fast as the old code, but more general. Notably, glslang doesn't support nested arrays. (cf. https://github.com/KhronosGroup/glslang/issues/1057) Also much cleaner code-wise, so I think I'll keep it even if glslang implements array_of_arrays.
* wayland: allow vo_wayland_uninit(NULL)Niklas Haas2017-09-211-0/+3
|
* vo_gpu: fix possible segfault in shader_cache.cNiklas Haas2017-09-211-1/+3
| | | | | If shader compilation fails in an unexpected way, it can end up calling renderpass_run on an invalid pass, since current_shader is never cleared.
* vo_gpu: fix gamma scaleNiklas Haas2017-09-211-3/+3
| | | | | | This never really made sense since the BT.1886 changes. It should get *brighter* for bright rooms, not darker for dark rooms. Picked some new values that seemed reasonable-ish.
* vo_gpu: fix comment on ra_buf_typeNiklas Haas2017-09-211-2/+2
| | | | This hasn't been true for several iterations of this API.
* vo_gpu: describe the plane merging passNiklas Haas2017-09-211-1/+1
| | | | This can get left unknown if something hooks NATIVE
* cocoa: re-enable double bufferingJames Ross-Gowan2017-09-212-2/+3
| | | | | | | | | This causes a performance regression on 10.11 and newer, but the single buffered method was broken and could cause partially rendered frames to be presented to the screen. This reverts 9f30cd8292b4b7bfe5d7db29fe31a07cc76dec2c and e543853a7ff0ab4dcd4ccaf06c448013fd41c03a.
* vo_gpu: convert windows/osx hwdecs/contexts to new APIJames Ross-Gowan2017-09-219-331/+398
|
* vo_opengl: refactor into vo_gpuNiklas Haas2017-09-2151-1795/+2071
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is done in several steps: 1. refactor MPGLContext -> struct ra_ctx 2. move GL-specific stuff in vo_opengl into opengl/context.c 3. generalize context creation to support other APIs, and add --gpu-api 4. rename all of the --opengl- options that are no longer opengl-specific 5. move all of the stuff from opengl/* that isn't GL-specific into gpu/ (note: opengl/gl_utils.h became opengl/utils.h) 6. rename vo_opengl to vo_gpu 7. to handle window screenshots, the short-term approach was to just add it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to ra itself (and vo_gpu altered to compensate), but this was a stop-gap measure to prevent this commit from getting too big 8. move ra->fns->flush to ra_gl_ctx instead 9. some other minor changes that I've probably already forgotten Note: This is one half of a major refactor, the other half of which is provided by rossy's following commit. This commit enables support for all linux platforms, while his version enables support for all non-linux platforms. Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the --opengl- options like --opengl-early-flush, --opengl-finish etc. Should be a strict superset of the old functionality. Disclaimer: Since I have no way of compiling mpv on all platforms, some of these ports were done blindly. Specifically, the blind ports included context_mali_fbdev.c and context_rpi.c. Since they're both based on egl_helpers, the port should have gone smoothly without any major changes required. But if somebody complains about a compile error on those platforms (assuming anybody actually uses them), you know where to complain.
* build: add preliminary LGPL modewm42017-09-217-63/+54
| | | | | | | See "Copyright" file for caveats. This changes the remaining "almost LGPL" files to LGPL, because we think that the conditions the author set for these was finally fulfilled.
* mp_image: don't guess colorspace params in mp_image_copy_attributes()wm42017-09-191-8/+12
| | | | | | | | | | | | | | | | | This is "wrong", because you might want mp_image_copy_attributes() to preserve the information that the colorspace parameters are unknown. This is important for hwdec -copy modes, which call this function before fix_image_params() and mp_colorspace_merge() are called. Instead, just wipe the colorspace attributes if the pixel format changes in an apparently incompatible way. Use mp_image_params_guess_csp() logic for this and factor that into its own function. mp_image_set_attributes() attempts to do something similar, so change that in the same way. Also, mp_image_params_guess_csp() just returned if the imgfmt was invalid or unset - just remove that part, because it annoyingly doesn't fit into the new code, and had little reason to exist to begin with. (Probably.)
* mp_image: always copy pixel aspect ratiowm42017-09-191-4/+2
| | | | | | I see no reason not to do this. I think the check comes from the time when mp_image stored the image aspect ratio, instead of the pixel aspect ratio, where the logic might have made more sense.
* mp_image: always copy color attributes on hw downloadwm42017-09-191-9/+2
| | | | | | | | | | | | | | | | | | It was noticed that -copy hwdec modes typically dropped the chroma_location field. This happened because the attributes on hw download are copied with mp_image_copy_attributes(), which tries to copy these parameters only if src and dst were both YUV (in an attempt to copy parameters only if it makes sense). But hardware formats did not have the YUV flag set (anymore?), and code shouldn't attempt to check the flag in this way anyway. Drop the check, and always copy the whole color metadata struct. There is a call to mp_image_params_guess_csp() below, which tries to unset nonsense metadata if it was copied from a YUV format to RGB. This function would also do the right thing for hw formats (although for the cited bug only the software case matters). Fixes #4804.
* Revert "vd_lavc: change auto-probe order to prefer cuda over vdpau-copy"wm42017-09-191-7/+5
| | | | | | | | | | | This reverts commit 96462040ec79b353457b64949f96fad30bd6e988. I guess the autoprobing is still too primitive to handle this well. What it really should be trying is initializing the wrapper decoder, and if that doesn't work, try another method. This is complicated by hwaccels initializing in a delayed way, so there is no easy solution yet. Probably fixes #4865.
* vo_opengl: make the ra_renderpass names consistentNiklas Haas2017-09-133-3/+3
| | | | The random space kept screwing me over
* vo_opengl: use GLX_MESA_swap_control where availableNiklas Haas2017-09-131-0/+9
| | | | | | | | | | | | | | | | | This overrides the use of GLX_SGI_swap_control, because apparently GLX_SGI_swap_control doesn't support SwapInterval(0), but the GLX_MESA_swap_interval does. Of course, everybody except mesa just accepts SwapInterval(0) even for GLX_SGI_swap_control, but mesa needs to be the special snowflake here and reject it, forcing us to load their stupid named extension instead. Meanwhile khronos has done nothing except spit out GLX_EXT_swap_control (not to be confused with GL_EXT_swap_control, which is exported by WGL_EXT_swap_control), that doesn't fix the problem because mesa doesn't implement it anyway. What a fucking mess.
* vo_opengl: always initialize uniforms on first useNiklas Haas2017-09-121-1/+3
| | | | | | Even if the contents are entirely zero. In the current code, these entries were left uninitialized. (Which always worked for nvidia - but randomly blew up for AMD)
* vo_opengl: generalize UBO packing/handlingNiklas Haas2017-09-126-70/+122
| | | | | | This is simultaneously generalized into two directions: 1. Support more sc_uniform types (needed for SC_UNIFORM_TYPE_PUSHC) 2. Support more flexible packing (needed for both PUSHC and ra_d3d11)
* vo: avoid putting large voctrl_performance_data on stackNiklas Haas2017-09-112-2/+2
| | | | | | This is around 512 kB, which is just way too much. Heap-allocate it instead. Also cut down the max pass count to 64, since 128 was unrealistically high even for vo_opengl.
* vo_opengl: refactor timer_pool_measure (again)Niklas Haas2017-09-112-5/+7
| | | | | | | Instead of relying on power-of-two buffer sizes and unsigned overflow, make this code more robust (and also cleaner). Why can't C get a real modulo operator?
* vo_opengl: fix out-of-bounds access in timer_pool_measureNiklas Haas2017-09-111-1/+2
| | | | | | This was there even before the refactor, but the refactor exposed the bug. I hate C's useless fucking modulo operator so much. I've gotten hit by this exact bug way too many times.
* vo_opengl: fix out-of-bounds read in update_uniformNiklas Haas2017-09-111-2/+1
| | | | | | | | | | Since the addition of UBOs, the assumption that the uniform index corresponds to the pass->params.inputs index is no longer true. Also, there's no reason it would even need this - since the `input` is also available directly in sc_uniform. I have no idea how I've been using this code for as long as I have without any segfaults until earlier today.
* vo_opengl: refactor/fix mp_pass_perf codeNiklas Haas2017-09-113-21/+17
| | | | | | | | | | | | | This was needlessly complicated and prone to breakage, because even the references to the ring buffer could end up getting invalidated and containing garbage data on e.g. shader cache flush. For much the same reason why we can't keep around the *timer_pool, we're also forced to hard-copy the entire sample buffer per pass per frame. Not a huge deal, though. This is, what, a few kB per frame? We have more pressing CPU performance concerns anyway. Also simplified/fixed some other code.
* vo_opengl: add a gamut warning featureNiklas Haas2017-09-104-4/+12
| | | | | | | | This clearly highlights all out-of-gamut/clipped pixels. (Either too bright or too saturated) Has some (documented) caveats. Also make TONE_MAPPING_CLIP stop actually clamping the value range (it's unnecessary and breaks this feature).
* vo_opengl: add support for vulkan GLSL dialectNiklas Haas2017-09-044-12/+31
| | | | | | | | | | Redefining texture1D / texture3D seems to be illegal, they are already built-in macros or something. So just use tex1D and tex3D instead. Additionally, GL_KHR_vulkan_glsl requires using explicit vertex locations and bindings, so make some changes to facilitate this. (It also requires explicitly setting location=0 for the color attachment output)
* vo_opengl: use rgba16 for 3DLUTs instead of rgb16Niklas Haas2017-09-042-6/+6
| | | | | | | Vulkan compat. rgb16 doesn't exist on hardware anyway, might as well just generate the 3DLUT against rgba16 as well. We've decided this is the simplest way to do vulkan compatibility: just make sure we never actually need 3-component textures.
* vo_opengl: refactor scaler LUT weight packing/loadingNiklas Haas2017-09-044-36/+24
| | | | | | | | This is mostly done so we can support using textures with more components than the scaler LUTs have entries. But while we're at it, also change the way the weights are packed so that they're always sequential with no gaps. This allows us to simplify pass_sample_separated_get_weights as well.
* vo_opengl: scale deband-grain to the signal rangeNiklas Haas2017-09-033-4/+8
| | | | | This prevents blowing up for high dynamic range sources, where a noise level of 48 can suddenly mean 4800.
* filter_kernels: correct spline64 kernelJames Ross-Gowan2017-09-031-4/+4
| | | | | | This seems to have had some copy/paste errors. It should now match the implementation in fmtconv: https://github.com/EleonoreMizo/fmtconv/blob/00453a86dd73/src/fmtcl/ContFirSpline64.cpp#L58-L76
* input: merge mouse wheel and axis keycodesJames Ross-Gowan2017-09-038-19/+19
| | | | | | | | | | | | | | | | | | | | | | Mouse wheel bindings have always been a cause of user confusion. Previously, on Wayland and macOS, precise touchpads would generate AXIS keycodes and notched mouse wheels would generate mouse button keycodes. On Windows, both types of device would generate AXIS keycodes and on X11, both types of device would generate mouse button keycodes. This made it pretty difficult for users to modify their mouse-wheel bindings, since it differed between platforms and in some cases, between devices. To make it more confusing, the keycodes used on Windows were changed in 18a45a42d524 without a deprecation period or adequate communication to users. This change aims to make mouse wheel binds less confusing. Both the mouse button and AXIS keycodes are now deprecated aliases of the new WHEEL keycodes. This will technically break input configs on Wayland and macOS that assign different commands to precise and non-precise scroll events, but this is probably uncommon (if anyone does it at all) and I think it's a fair tradeoff for finally fixing mouse wheel-related confusion on other platforms.
* cocoa: fix button numbering for back/forwardJames Ross-Gowan2017-09-031-4/+7
| | | | | | It seems like the Cocoa backend used to return the same mpv keycodes for mouse back/forward as it did for scrolling up and down. Fix this by explicitly mapping all Cocoa button numbers to the right mpv keycodes.
* input: use mnemonic names for mouse buttonsJames Ross-Gowan2017-09-036-26/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | mpv's mouse button numbering is based on X11 button numbering, which allows for an arbitrary number of buttons and includes mouse wheel input as buttons 3-6. This button numbering was used throughout the codebase and exposed in input.conf, and it was difficult to remember which physical button each number actually referred to and which referred to the scroll wheel. In practice, PC mice only have between two and five buttons and one or two scroll wheel axes, which are more or less in the same location and have more or less the same function. This allows us to use names to refer to the buttons instead of numbers, which makes input.conf syntax a lot easier to remember. It also makes the syntax robust to changes in mpv's underlying numbering. The old MOUSE_BTNx names are still understood as deprecated aliases of the named buttons. This changes both the input.conf syntax and the MP_MOUSE_BTNx symbols in the codebase, since I think both would benefit from using names over numbers, especially since some platforms don't use X11 button numbering and handle different mouse buttons in different windowing system events. This also makes the names shorter, since otherwise they would be pretty long, and it removes the high-numbered MOUSE_BTNx_DBL names, since they weren't used. Names are the same as used in Qt: https://doc.qt.io/qt-5/qt.html#MouseButton-enum
* vo_opengl: fix overlay mode (again)wm42017-08-301-7/+8
| | | | Did I mention yet that I regret this overlay mode thing?
* vd_lavc: change auto-probe order to prefer cuda over vdpau-copywm42017-08-301-5/+7
| | | | | This aims at making --opengl-hwdec-interop=cuda --hwdec=yes select the correct decoding mode: cuda instead of vdpau-copy.
* vo_opengl: don't discard buffered video on redundant resize callswm42017-08-291-0/+5
| | | | | | | | | | If a VO-area option changes, gl_video_resize() is called unconditionally. This function does something even if the size does not change (at least it discards buffered frames for interpolation), which can lead to stutter when you keep firing option change events during playback. Check for an actual resize, and if nothing changes, exit early.
* vo_opengl: don't assume imgfmt=0 is validwm42017-08-291-1/+1
| | | | | | Could cause a crash if anything called ra_get_imgfmt_desc(imgfmt=0). Let it fail correctly. This can happen if a hwdec backend does not set hw_subfmt correctly.
* vo_opengl: fix the renderpass target format at creation timeNiklas Haas2017-08-273-4/+19
| | | | Required for vulkan.
* vo_opengl: fix misleading comment in ra.hNiklas Haas2017-08-271-6/+6
| | | | tex_upload is not just for buffers
* vo_opengl: use UBOs where supported/requiredNiklas Haas2017-08-274-14/+167
| | | | | | | | | | | | This also introduces RA_CAP_GLOBAL_UNIFORM. If this is not set, UBOs *must* be used for non-bindings. Currently the cap is ignored though, and the shader_cache *always* generates UBO-using code where it can. Could be made an option in principle. Only enabled for drivers new enough to support explicit UBO offsets, just in case... No change to performance, which is probably what we expect.
* vo_opengl: add support for UBOsNiklas Haas2017-08-275-11/+33
| | | | | Not actually used by anything yet, but straightforward enough to add to the RA API for starters.
* vo_opengl: clarify RA_CAP_DIRECT_UPLOADNiklas Haas2017-08-271-1/+2
| | | | | | This no longer concerns the API user except in as much as the API user probably wants to know whether or not PBOs are active, so keep around the CAP field even though it's mostly useless now.