summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu: hwdec: load hwdec interops on-demand by defaultPhilip Langdale2022-02-173-12/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | Historically, we have treated hwdec interop loading as a completely separate step from loading the hwdecs themselves. Some hwdecs need an interop, and some don't, and users generally configure the exact hwdec they want, so interops that aren't relevant for that hwdec shouldn't be loaded to save time and avoid warning/error spam. The basic approach here is to recognise that interops are tied to hwdecs by imgfmt. The hwdec outputs some format, and an interop is needed to get that format to the vo without read back. So, when we try to load an hwdec, instead of just blindly loading all interops as we do today, let's pass the imgfmt in and only load interops that work for that format. If more than one interop is available for the format, the existing logic (whatever it is) will continue to be used to pick one. We also have one callsite in filters where we seem to pre-emptively load all the interops. It's probably possible to trace down a specific format but for now I'm just letting it keep loading all of them; it's no worse than before. You may notice there is no documentation update - and that's because the current docs say that when the interop mode is `auto`, the interop is loaded on demand. So reality now reflects the docs. How nice.
* vo_gpu_next: don't crash on negative plane stridesNiklas Haas2022-02-111-5/+34
| | | | | | | | | | | | | | This is an annoying special case only really needed because of the `vflip` filter. mpv handles this by directly adjusting the plane transform. The libplacebo API, unfortunately, does not allow passing the required information for this to work smoothly. Long-term I plan on adding support for plane flipping in libplacebo directly, but for the meantime, we will have to work-around it by moving the flipping to the whole-image `crop` instead. Not an ideal solution but better than crashing. Fixes #9855
* vo_gpu: d3d11_helpers: don't create UNORDERED_ACCESS backbuffers in Win7James Ross-Gowan2022-02-091-0/+10
| | | | | | | | | | | | | | We're getting bug reports that the recent change to add extra usage flags to swapchain buffers (for gpu-next) breaks mpv on some Windows 7 systems, and it seems like this is only happening with flip-model swapchains. Creating swapchains with DXGI_USAGE_UNORDERED_ACCESS should be valid. At least, it's not specifically disallowed, unlike some other flags[1]. So, just disable it for flip-model swapchains in Windows 7, rather than disabling it everywhere. [1]: https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/dxgi-usage
* wayland: partially fix drag and drop handlingDudemanguy2022-02-071-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Drag and drop in wayland is weird and it seems everyone does this slightly differently (fun). In the past, there was a crash that occured (fixed by 700f4ef5fad353800fa866b059663bc1dd58d3b7) which involved using the wl_data_offer_finish in an incorrect way that triggered a protocol error (always fatal). The fix involved moving the function call to data_device_handle_drop which seemingly works, but it has an unfortunate side effect. It appears like GTK applications (or at least firefox) close the pipe after this function is called which makes it impossible for mpv to read data from the fd (well you could force it open again in theory but let's not do that). Who knows if that was the case when that commit was made (probably not because I'd think I would have noticed; could just be a dummy though), but obviously having broken dnd for a major application isn't so fun (this works with QT and chromium anyway). Ideally one would just simply check the pipe in data_device_handle_drop, but this doesn't work because it doesn't seem the compositor actually sends mpv the data by then. There's not actually a defined event when you're supposed to be able to read data from this pipe, so we wait for the usual event checking loop later for this. In that case, wl_data_offer_finish needs to go back into check_dnd_fd, but we have to be careful when calling it otherwise we'd just commit protocol errors like before. We check to make sure we even have a valid wl->dnd_offer before trying to indicate that it is finished and additionally make sure there is a valid dnd_action (after checking the fd, it's always set back to -1). This doesn't fix everything though. Specifically, sway with focus_follows_mouse (the default) and GTK as the data source still doesn't work. The reason is that when you do a drag and drop in sway with that option on, a new wl_data_device.data_offer event is sent out instantly after the drop event. This happens before any data is sent across the fd and before mpv even has a chance to check it. What GTK does, when getting this new data_offer event, is close the pipe (POLLHUP). This means mpv can't read it when we reach the event loop and thus no data is ever read and broken drag and drop. From the client side, this isn't really fixable since the wayland protocol doesn't have a clear indication of when clients are supposed to read from the fd and both the compositor and data source are doing things totally out of our control. So we'll consider this weird case, "not our bug" at least. The rest should work.
* vo_gpu_next/context: get graphics API-specific contexts from pl_gpuJan Ekström2022-02-061-36/+31
| | | | | | | | | | | | | | By receiving the graphics API-specific contexts from the generic pl_gpu instance, it is not necessary to store them separately. As the current priv struct stores nothing else, this allows its removal. This removal cleans up related compiler warnings regarding unused variables in case of opengl and d3d11 being disabled in mpv/libplacebo. Functions to receive the underlying vulkan,gl,d3d11 structure were added in libplacebo version 4.182. Our current requirement for gpu-next is 4.190, and thus we can freely utilize these helper functions.
* vo_gpu: hwdec_vaapi: Don't probe formats for irrelevant endpointsPhilip Langdale2022-02-061-0/+8
| | | | | | | | | | | | | | While testing support for the exotic formats used by Intel vaapi for 4:2:2 and 4:4:4 surfaces, I realised that we were enumerating all endpoints and checking formats for them. The problem with this is that decoding (VLD) endpoints are only a subset of what vaapi exposes. All the encoding endpoints are there too, and there is also the None profile that we don't care about, but which generates ffmpeg warnings if you try and examine it. So, let's only look at VLD endpoints. This will speed things up a little bit and make the logging less noisy.
* libplacebo: switch to new target format APINiklas Haas2022-02-031-1/+6
| | | | | `target_dummy` got deprecated in version v4.169. We unfortunately have to hide this behind an #if for the time being.
* libplacebo: switch to new GPU limits APIsNiklas Haas2022-02-031-6/+11
| | | | | `caps` is deprecated, and replaced by individual fields in `pl_glsl_version` / `pl_gpu_limits`.
* libplacebo: switch to v4 naming conventionNiklas Haas2022-02-035-50/+46
| | | | | All of these const struct pointers got typedefs, clean up the code accordingly.
* libplacebo: update log helpersNiklas Haas2022-02-038-38/+35
| | | | | Use the pl_log APIs introduced in libplacebo v4, replacing the deprecated pl_context concept.
* libplacebo: bump minimum dependency to 4.157Niklas Haas2022-02-031-10/+3
| | | | | | This has been the latest stable release for about half a year now. This version in particular lets us get rid of all the deprecation warnings in the older code. (See the following commits)
* vo_gpu_next: create shader cache dir if missingNiklas Haas2022-02-031-0/+1
| | | | | Failing to do this results in the shader cache not actually ever being written, ergo no shader caching being done. Oops.
* build: rename libplacebo version checkNiklas Haas2022-02-031-1/+1
| | | | | Rename from "libplacebo-v4" to "libplacebo-next" to more closely capture the intent, since this will become libplacebo v5 eventually (tm).
* wayland: always start rendering after a resizeJulian Orth2022-02-031-0/+6
| | | | | | | | | | | | | | | | | | | The wayland backend contains logic to detect if the window is hidden. If so, we skip rendering as an optimization. However, if we receive multiple resize events in rapid succession, we will send the compositor new buffers faster than the refresh rate of the monitor. Therefore the compositor will not send us frame events which we incorrectly interpret as the window being hidden. Once the last buffer has actually been rendered, the compositor sends us a frame event. However, if at that point playback is paused, there is no logic to restart rendering of frames that we skipped due to the above optimization. Therefore we never send the compositor new buffers corresponding to the new size of the window and the surface will either be too small or too large. The simplest solution is to always render a few frames after we receive a resize event.
* filter kernels: add cosine windowgaramond132022-02-031-0/+6
| | | | filter kernels: add cosine window
* vo_gpu_next: initial attempt at adding d3d11 supportJan Ekström2022-02-021-7/+87
|
* vo_gpu_next/context: common'ize things that would be common for non-vulkanJan Ekström2022-02-021-10/+25
| | | | This prepares us to not duplicate all of this code for d3d11.
* vo_gpu/d3d11: enable access to the underlying ra_ctx swap chainJan Ekström2022-02-022-0/+22
| | | | This enables us to utilize it from gpu-next.
* vo_gpu/d3d11: add more usage flags to the swapchain imagesJames Ross-Gowan2022-02-021-1/+8
| | | | | | | | vo_gpu_next and libplacebo expect swapchain images to be able to be blitted to, which for libplacebo on FL11_0 and up means they have to have DXGI_USAGE_UNORDERED_ACCESS, since libplacebo uses a compute shader to emulate certain kinds of blits. For libplacebo's benefit, set all applicable usage flags on swapchain images.
* vo_gpu/d3d11: early exit in start_frame if output fbo is nullptrJan Ekström2022-02-021-0/+3
|
* win32: apply geometry position to content instead of windowAvi Halachmi (:avih)2022-02-021-1/+6
| | | | | | | | | | | | | | The docs specify that the +-X+-Y geometry values position the content. This used to work correctly but got broken at 8fb4fd9a . Geometry size is unaffected - this only concerns position. Commit 8fb4fd9a made it center the window rather than the content by taking the borders into account during positioning, but forgot to make an exception when a position is specified explicitly. This commit adds this exception, and now if a specific position is requested then the borders are ignored, and the content is positioned correctly.
* wayland: always resize when scale changes on surface enterDudemanguy2022-01-271-0/+1
| | | | | | | | | | | | a02901cae77c86fb9de997a418296d1fc0e3eada changed how mpv was handling wl_surface_set_buffer_scale. It's correct in that constantly setting the surface scale on every resize (which mpv was previously doing) is unneccessary and not right. However, it introduced a slight regression if someone moved a surface to a new monitor with the same resolution but a different scale. It did not trigger a resize and thus the video would have incorrect dimensions. A later refactor changed how things looked inside here, but this regression wasn't fixed. A resize should always be triggered if the scale changes in this surface event. Fixes #9426.
* wayland: support extra mouse buttonsRyan Hendrickson2022-01-281-18/+22
| | | | | | | | | | | | | Mouse button event codes above `BTN_EXTRA` (the ones currently defined in `input-event-codes.h` are `BTN_FORWARD`, `BTN_BACK`, and `BTN_TASK`) are mapped to `MP_MBTN9` and up. (Reminder that due to historical reasons, the names `BTN_FORWARD` and `BTN_BACK` are completely misleading; the real forward and back buttons are `BTN_SIDE` and `BTN_EXTRA` and are already mapped correctly by mpv.) This functionality is analogous to what the X11 backend supports in `video/out/x11_common.c` and what the Cocoa backend supports in `video/out/cocoa/events_view.m`.
* wayland: actually handle 0x0 resizes correctlyDudemanguy2022-01-271-0/+8
| | | | | | | | | | | According to the xdg-shell protocol spec, a 0x0 size from the compositor means that "the client should decide its own window dimension". We were not doing this correctly. What should happen is that mpv should simply reuse the old window size if it is not maximized or fullscreened. This should work on all (reasonably recent) versions of mutter and an compositor that follows the spec. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml#L1050
* Revert "wayland: ignore 0x0 resizes"Dudemanguy2022-01-271-3/+2
| | | | | | | | | | | | | | | So actually according to the xdg-shell spec, a 0x0 resize is meant to indicate that "the client should decide its own window dimension". Previously, this just accidentally worked. In mutter 41.3, they changed how 0x0 resizes were sent and what actually happened was that mpv tried to resize itself to 0x0. This was obviously broken, so the reverted commit naively just ignored 0x0. It actually seemed to work, but it ended up breaking older versions of mutter. It's also not exactly the correct fix so it deserves a revert. This reverts commit d16defac27fcfe3e5fc43af6e42c2e590988cd3d. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml#L1050
* x11: sanitize window title to UTF-8 for EWMHDudemanguy2022-01-241-2/+7
| | | | | | | | | | Both _NET_WM_NAME and _NET_WM_ICON_NAME (part of Extended Window Manager Hints) require that the string is UTF-8*. mpv was not doing this and thus violating the spec. Just sanitize the title for these two atoms. Note that XA_WM_NAME and XA_WM_ICON_NAME have no such requirement so those atoms are left the same. Fixes #8812. *: https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html
* wayland: sanitize toplevel title to UTF-8Dudemanguy2022-01-241-1/+5
| | | | | | | The xdg-shell protocol requires that the toplevel title is UTF-8*. Go ahead and leverage existing mpv tools to sanitize the title. Fixes #9694 *: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/0aaf12157ede8fdf6eda49963da313bd1a7d930f/stable/xdg-shell/xdg-shell.xml#L638
* wayland: ignore 0x0 resizesDudemanguy2022-01-231-2/+3
| | | | | | | | | Apparently mutter can send us 0x0 resizes* for whatever reason. Probably there's some interal reason why this occurs, but for us trying to resize to 0x0 is obviously terrible and results in all kinds of brokenness. Just ignore any 0 values. Fixes #9748. *: https://gitlab.gnome.org/GNOME/mutter/-/issues/2091
* vo_gpu: add HOOKED_gatherNiklas Haas2022-01-151-0/+5
| | | | | Can be used conditionally (via #ifdef HOOKED_gather) to use textureGather in custom shaders.
* vo_gpu_next: fix SUBBITMAP_BGRANiklas Haas2022-01-111-1/+1
| | | | | | | | | The only way to fix the channel order here is to create the texture with bgra format. Incidentally, there used to be a way to set the component map for overlays directly, but no more. Shouldn't matter since everything supports bgra8 anyways, though. Fixes #9699
* sub: rename SUBBITMAP_RGBA to SUBBITMAP_BGRANiklas Haas2022-01-114-11/+11
| | | | | This was a misnomer, the actual channel order is IMGFMT_BGRA (as the comment explicitly point out). Rename the enum for consistency.
* vo_gpu: placebo: add missing gamma functionsNiklas Haas2022-01-101-3/+10
| | | | | | | | | These got added upstream a while ago. Need to be added to the mapping helpers. It might be time to think about bumping the minimum dependency here. Reported-by: Uoti Urpala <uau@glyph.nonexistent.invalid>
* vo_gpu_next: forward dovi metadata to libplaceboNiklas Haas2022-01-091-0/+17
|
* wayland: use `xkb_keymap_new_from_buffer`Julian Orth2022-01-081-1/+2
| | | | | | | | | | | Instead of `xkb_keymap_new_from_string`. The protocol does not require the keymap to be null terminated and if the size of the keymap is a multiple of the page size, using `_from_string` could lead to problems. Some compositors include a null byte and even include the null byte in `size`. Therefore we have to use `strnlen` to find the real length of the string. Note that `_from_string` internally uses `strlen` and then calls `_from_buffer`.
* wayland: map keymaps with `MAP_PRIVATE`Julian Orth2022-01-081-1/+1
| | | | | | | | | | While mpv uses version 1 of the `wl_seat` protocol and `MAP_PRIVATE` is only required from version 7 on, using `MAP_PRIVATE` allows us to be compatible with compositors that have only been tested with newer applications. Since the keymap is not modified after `mmap`, using `MAP_SHARED` has no advantage over `MAP_PRIVATE`.
* vo_gpu: add --tone-mapping-modeNiklas Haas2022-01-074-19/+56
| | | | | | | | | | | This merges the old desaturation control options into a single enumeration, with the goal of both simplifying how these options work and also making this list more extensible (including, notably, new options only supported by vo_gpu_next). For the hybrid option, I decided to port the (slightly tweaked) values from libplacebo's pre-refactor defaults, rather than the old values we had in mpv, to more visually match the look of the vo_gpu_next hybrid.
* vo_gpu: add --gamut-mapping-modeNiklas Haas2022-01-074-13/+41
| | | | | | | Merge --gamut-clipping and --gamut-warning into a single option, --gamut-mapping-mode, better corresponding to the new vo_gpu_next APIs and allowing us to easily extend this option as new modes are added in the future.
* vo_gpu_next: use new HDR metadata optionsNiklas Haas2022-01-073-77/+52
| | | | | Properly forward the HDR metadata from the mpi to the equivalent (new) fields in pl_color_space. Used by the new tone mapping code.
* vo_gpu_next: update for new tone mapping optionsNiklas Haas2022-01-074-26/+61
| | | | | | | This was significantly refactored upstream. Switch to new APIs and add new tone mapping curves and options. cf. https://code.videolan.org/videolan/libplacebo/-/merge_requests/212
* vo_gpu: move image2D precision qualifier to point of usesfan52022-01-021-3/+1
| | | | | | | image2D is only defined from GLSL ES 3.1 onwards, so those statements broke GLES 2.0. Move the qualifier to a place that is only reached with the right version requirements. fixes commit 584ab29c88d6c5ffa03666bffbbc93e4f0740f67
* vo_gpu_next: fix --target-peak scalingNiklas Haas2021-12-291-1/+1
| | | | This is in nits, so it needs to be converted.
* wayland: avoid doing unneccesary window resizesDudemanguy2021-12-201-7/+0
| | | | | | | | | | | | | | | | | Commits 04018c306196888861775b248a8596ae494f122b cd7a7a1de8d8bffa05170befef25b251711c994a introduced behavior that updated window geometry during wayland events (specifically surface and output). This is good but they also are too aggressive with automatically resizing. For example, if a window is manually resized by the user and then dragged to a different monitor with different geometry than the initial monitor, mpv will automatically resize itself to the window's resolution. The initial thought behind this logic was for autofit to automatically readjust itself on a new monitor, but doing that breaks other common use cases. An attempt could be made to distinguish between autofit and a manual resize but that introduces a lot of complexity for an edge case. It's better to simply not change the window geometry here. Internal values are recalculated and scaled of course, but wl->window_size and wl->geometry should not change.
* vo_gpu: stop hard-coding max compute group threadsPhilip Langdale2021-12-196-6/+13
| | | | | | | | | | We've been assuming that maximum number of compute group threads is never less than the 1024 defined by the desktop GL spec. Given that we haven't had working compute shaders for GLES and I guess the Vulkan spec defines at least as high a value, we've gotten away with it so far. But we should really look the value up and respect it.
* vo_gpu_next: implement VOCTRL_EXTERNAL_RESIZEsfan52021-12-192-1/+5
| | | | | | This is only needed on Android and supposed to handle a context resize without reconfiguring the image parameters. reconfig() already does exactly this so plug it in there.
* {player,video}: remove references to obsolete opengl-cb APIsfan52021-12-155-37/+5
|
* vo_gpu: opengl: some fixes to make compute shaders work with GLESPhilip Langdale2021-12-124-10/+15
| | | | | | | | | It's supposed to work with GLES >= 3.1 but we had all sorts of bad assumptions in our version handling, and then our compute shaders turn out not to be GLSL-ES compliant. This change contains some necessary, but insufficient, tweaks to the shaders. Perhaps we'll make it actually work some day.
* vo_gpu: opengl: fix OpenGL ES version and extension handlingPhilip Langdale2021-12-122-5/+25
| | | | | | | | Some of the extension declarations did not include the ES version where they became core functionality, and in some of these cases, there was never actually an ES extension - it first appeared in core. We also had a number of buggy version checks where ES versions were compared against required desktop GL versions.
* vo_gpu: opengl: try and create context at version 440 againPhilip Langdale2021-12-071-0/+9
| | | | | | | | | | | | | | | | | | | | | nvidia follow the OpenGL spec very strictly, with two particular consequences: * They will give you the exact context version that you ask for, rather than the highest possible version that meets your request. * They will hide extensions that the specs say require a higher version than you request, even if it's technically possible to provide the extension at lower versions. In our case, we really want a variety of extensions, particularly compute shaders that are only available in 4.2 or higher. That means that we must explicitly include a high enough version in our list of versions to check for us to be able to get a 'good' enough context. As for which version? We restore the 4.4 version that we had in the old version selection logic. This is the highest version we ever asked for, and we have separate logic that clamps the GLSL version to 4.4, so anything newer wouldn't make a difference.
* vo_gpu: opengl: fix wrong glMemoryBarrierNiklas Haas2021-12-061-1/+1
| | | | This call was completely wrong.
* vo_gpu_next: fix UB in query_format()Niklas Haas2021-12-051-1/+1
| | | | | | | | | `plane_data_from_imgfmt` doesn't zero-initialize the struct, so this contained invalid values for e.g. `row_stride`, causing formats to *randomly* fail. (Especially any formats with specific alignment requirements) Might fix #9424 and #9425.
* wayland: ensure read and draw buffers are assignedKurt Kartaltepe2021-12-043-0/+9
| | | | | | | | | | | | | | | | | This is a workaround for nvidia proprietary drivers. The authors of those drivers interpret the spec such that eglMakeCurrent will not reconfigure the read and draw buffers. Thus windows wont display anything drawn by opengl. nvidia authors refer to https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_no_config_context.txt specifically Issues 2/3 which reference eglMakeCurrent. On mesa this is a non-issue and the read/draw targets are assigned with eglMakeCurrent. The context must be made current in order to query OpenGL strings. An earlier proposal to create the wayland window surface similarly to X11 during init was deemed inappropriate so instead we manually set the targets once we have created a window surface.
* opengl: support DebugMessageCallback on ESKurt Kartaltepe2021-12-021-0/+11
| | | | | This function is provided by a different extension on OpenGL ES so we add a separate gl_functions.
* vo_gpu_next: implement VOCTRL_SCREENSHOTNiklas Haas