summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu_next: avoid rendering subtitles as HDR/wide gamutNiklas Haas2022-02-251-1/+9
| | | | Fixes #9911
* mp_image: fix mp_image_plane_w/hNiklas Haas2022-02-241-4/+2
| | | | | | | | | | | | | These helpers, for some reason, decided to round the returned values up to multiples of the nearest plane alignment. This logic makes no sense to me, and completely breaks any sort of oddly-sized mp_image. This logic was introduced, presumably in error and without real justification, as part of a major refactor commit (caee8748), As far as I can tell, removing it again doesn't regress anything. Fixes several serious bugs including buffer underflows and GPU crashes in vo_gpu and vo_gpu_next.
* vo_gpu_next: refactor subtitle renderingNiklas Haas2022-02-213-30/+56
| | | | | | | | | | | | | | | Render subs at the output resolution, rather than the video resolution. Uses the new APIs found in libplacebo 197+, to allow controlling the OSD resolution even for image-attached overlays. Also fixes an issue where the overlay state did not get correctly updated while paused. To avoid regenerating the OSD / flushing the cache constantly, we keep track of OSD changes and only regenerate the OSD when the OSD state is expected to change in some way (e.g. resolution change). This requires introducing a new VOCTRL to inform the VO when the UPDATE_OSD-tagged options have changed. Fixes #9744, #9524, #9399 and #9398.
* vo_gpu: hwdec: load hwdec interops on-demand by defaultPhilip Langdale2022-02-177-23/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* vf_format: simplify frame type checking after addition of DoVi optionJan Ekström2022-02-061-1/+5
| | | | | | | | | | | We only wish to touch actual video frames, which should have an allocated image attached to them, so just check the frame type early, and exit by passing through such non-video frames to further filters in the chain without attempting to process them. Fixes a crash in case of non-video (EOF/NONE) frames being passed onto the filter when the dovi option was set to false since 05ccc51d53424a771ece5bb818713d474d7874ce .
* 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.
* image_writer: replace deprecated av_init_packet()sfan52022-01-101-10/+9
|
* 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
|
* vf_format: add dolbyvision sub-optionNiklas Haas2022-01-091-2/+8
| | | | | | | | | | Useful to strip dolbyvision from the output, in cases where the user does not want it applied. Doing this as a video filter gives users the abiilty to easily toggle this stripping at runtime in a way that properly propagates to any (potentially stateful) VO. It also thematically fits the rest of the options in vf_format, which are similarly concerned with modifying the video image parameters.
* mp_image: add dolbyvision metadataLynne2022-01-092-0/+12
| | | | Co-authored-by: Niklas Haas <git@haasn.dev>
* 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
* vd_lavc: enable hwdec for prores by defaultrcombs2021-12-291-1/+1
|
* 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.
* mp_image, f_decoder_wrapper: implement AV_FRAME_DATA_DISPLAYMATRIXAlex Xu (Hello71)2021-12-151-0/+8
| | | | | | fixes #9249 (JPEG orientation support) with ffmpeg commit [0]. [0] https://github.com/FFmpeg/FFmpeg/commit/e93c9986027d17917c3b4f533b28ee4a2ce7cd4c
* {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<