summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* vo_dmabuf_wayland: error out if compositor doesn't support the formatDudemanguy2023-07-141-2/+71
| | | | | | | | | | | | This was never implemented so in cases where the compositor didn't have support for the underlying format, the window would just be black and quite unhelpful. Well it turns out that fixing this is actually really easy because mpv has reconfig2 which returns the entire mp_image on every reconfig. We can just use that mp_image to try and obtain the format and modifier pair and then use that to check against what we know the compositor supports. If there are any problems, error out gracefully. Some code duplication with the vaapi/drmprime importers, but it's probably better to keep these separate. Fixes #11198 and fixes #11664
* build: make dmabuf-wayland a build option and require drmDudemanguy2023-07-141-7/+1
| | | | | | | It makes more sense as an option at this point. Also libdrm is not optional at all. You have to get a drm format and modifier for this to even work (the VO will just fail without DRM). Just hard require it and remove the guards. vaapi can remain optional.
* wayland: use xdg_surface_set_window_geometryDudemanguy2023-07-131-0/+1
| | | | | | | | | mpv has never used this because we never really seemed to need it, but it actually has a purpose. This informs the compositor of the actual dimensions of the mpv window and avoids errors with sizes not matching (particularly with weston). It's a better way to fix the "maximizing causing an error on weston" issue since it also works for dmabuf-wayland (which always had this problem).
* Revert "wayland_gl: wait until resize to create egl_window"Dudemanguy2023-07-131-32/+37
| | | | | | | | | | | | | | The original reason for this commit was to prevent a compositor error on weston when going into the maximized state. The configured dimensions of mpv didn't match its actual size and Weston is super strict about this so it threw a compositor error which is fatal. It only happened in opengl and this seemed like an OK workaround, so I went with this. However, there's actually a far easier way to solve this problem and we don't need this anymore. This has the benefit of avoiding a harmless warning message that appears with gpu-next on opengl. The next commit is the proper solution. Closes #10324. This reverts commit 661b5542de21d46d4d7c4693e564f4eec0526812.
* vo_dmabuf_wayland: guard in destroy_osd_buffersDudemanguy2023-07-121-0/+3
| | | | *sigh*
* vo_dmabuf_wayland: stop lazy loading hwdecDudemanguy2023-07-121-17/+12
| | | | | | | | | The implementation was copied from vo_gpu/vo_gpu_next but fundamentally it doesn't make sense for this VO. Hardware decoding is not optional in vo_dmabuf_wayland. We should be sure to request and load all supported formats in the preinit and fail if there are any problems. There should be no functional change from before, but it's more conceptually correct this way.
* vo_dmabuf_wayland: don't try to get pts without frame->currentDudemanguy2023-07-121-1/+2
| | | | Fixes a segfault with --force-window=immediate.
* vo_dmabuf_wayland: add osd supportDudemanguy2023-07-123-10/+230
| | | | | | | | | | | | | | | | | | This adds osd support via shm buffers using a similar approach that the normal buffers do, but it differs in a few key areas. One thing to note is that sway and weston actually handle this extremely differently which required all the abstractions here. In particular, weston does not cope well with destroying the wl_buffer from shm outside of the release handler at all (i.e. it segfaults). The workaround here is to simply attach a NULL to the osd surface and do a surface commit before we destroy the buffers. This is reasonable enough and seems to work well although it's pretty weird. Sway is more straightforward although it actually releases the osd buffer when the window goes out of sight. Also, I found that it doesn't always release every buffer before you close it unlike weston seems to do which is part of the reason all this bookkeeping is required. I don't know if there's any other compositor out there that can possibly handle vo_dmabuf_wayland right now, but suffering through these two is good enough for now I think.
* vo_dmabuf_wayland: init wl_list at the top of preinitDudemanguy2023-07-121-2/+2
| | | | | | Otherwise, we could fail and skip to uninit without initalizing this which then will segfault because the list is null and accessed while trying to destroy buffers.
* vo_dmabuf_wayland: stop guarding viewport interfacesDudemanguy2023-07-121-4/+2
| | | | | | It's entirely pointless. Not having viewport is already a fatal error for this VO as it cannot possibly work without that protocol. Just drop all these redundant if's.
* wayland: add xdg_toplevel.wm_capabilities handlerllyyr2023-07-101-0/+10
| | | | Fixes crash when compositors advertise xdg_toplevel version >= 5
* wayland: add support for suspended toplevel stateDudemanguy2023-07-091-2/+14
| | | | | | | mpv already guesses when the window is hidden so plugging in a proper event that actually tells us this is really trivial. Note that there's some redundancy with setting wl->hidden in a few spots, but nothing can really be done about that as long as the crappy hack is still in place.
* wayland: add cursor-shape-v1 supportDudemanguy2023-07-092-12/+63
| | | | | | This protocol no longer requires us to draw a separate cursor surface and all of that horrible stuff. We can just ask the compositor for the default cursor instead since that's literally all mpv cares about.
* vo_wlshm: bail out of resize if width/height is 0Dudemanguy2023-07-081-0/+4
| | | | | | | It can happen during initialization and of course nothing good will happen if we let this go through (i.e. segfault). Return and wait for geometry to finish setting up in the wayland stuff before doing the initial resize.
* wayland: fix memory leak with multiple monitorsDudemanguy2023-07-081-7/+5
| | | | | | | | | Very dumb. I can't remember if it was always like this or if I broke it at some point, but clearly each wl_output should just be freed in remove_output. Freeing it if it happens to be wl->current_output only works for that one monitor, so remove that whole line. This has to happen before we close the wayland connection so reorder the uninit a little bit.
* various: correctly ignore cache files with --no-configDudemanguy2023-07-062-10/+18
| | | | | | | | | | | | --no-config should prevent loading user files of any type: configs, cache, etc. For cache files, this case wasn't properly handled and it was assumed they would always get something. vo_gpu's shader cache actually already handles this, so it was left untouched. In theory, demuxer cache should never have this issue because saving it to disk is disabled by default (and likely that will never change), but go ahead and change it for consistency's sake. Fixes some segfaults with --no-config and various combinations of settings (particularly --vo=gpu-next).
* vo_gpu/vo_gpu_next: enable gpu shader and icc cache by defaultDudemanguy2023-07-042-0/+2
| | | | | | | | | | | 4502522a7aee093c923e79a65e4684ea2634af30 changed the way mpv handled and saved cached files. In particular, it made a separate boolean option for actually enabling cache and left the *-dir options as purely just a path (i.e. having a dir set didn't mean you save cache). This technically regressed people's configs, so let's just turn the cache on by default. Linux users already expect random stuff in ~/.cache and well everyone else can just live with some files possibly appearing in their config directory.
* vo_gpu: fix some cache related memory leaksDudemanguy2023-07-042-2/+3
| | | | I goofed this up.
* player: add --input-cursor-passthrough optionDudemanguy2023-07-042-2/+44
| | | | | | | | | | | | | Add an option for allowing pointer events to pass through the mpv window. This could be useful in cases where a user wants to display transparent images/video with mpv and interact with applications beneath the window. This commit implements this functionality for x11 and wayland. Note that whether or not this actually works likely depends on your window manager and/or compositor. E.g. sway ignores pointer events but the entire window becomes draggable when you float it (nothing under the mpv window receives events). Weston behaves as expected however so that is a compositor bug. Excuse the couple of completely unrelated style fixes (both were originally done by me).
* vo_gpu_next: remove synchronization from info_callbackKacper Michajłow2023-07-021-9/+0
| | | | VOCTRL is processed on VO thread.
* vo_gpu_next: use pl_dispatch_info_move to avoid useless data copyKacper Michajłow2023-07-021-21/+45
| | | | | Instead copy the data on-demand when VOCTRL_PERFORMANCE_DATA is requested.
* vo_x11: don't rely on XFree to free calloc-ed dataNRK2023-07-021-1/+6
|
* vo_x11: check for calloc() failureNRK2023-07-021-3/+5
|
* win32: add support for drag-and-drop optionDudemanguy2023-07-013-3/+16
|
* options: add no to drag-and-dropDudemanguy2023-07-012-19/+23
| | | | | Suggested by @sfan5. Naturally, "no" disables all drag and drop behavior.
* wayland: remove erroneous POLLERR usageNRK2023-06-291-1/+1
| | | | POLLERR is only returned in `.revents` and is ignored in `.events`
* mp_image: abort on av_buffer_ref() failureNRK2023-06-281-3/+1
| | | | | | | | | | | | | | this changes mp_image_new_ref() to handle allocation failure itself instead of doing it at its many call-sites (some of which never checked for failure at all). also remove MP_HANDLE_OOM() from the call sites since this is not necessary anymore. not all the call-sites have been touched, since some of the caller might be relying on `mp_image_new_ref(NULL)` returning NULL. Fixes: https://github.com/mpv-player/mpv/issues/11840
* hwdec: fix undeclared identifier in mediacodec_embedsyphyr2023-06-281-1/+1
| | | | mediacodec_embed is a `vo` and not a `hwdec`.
* vo_drm: fix null dereference and using closed fdNRK2023-06-281-5/+0
| | | | | | | | | | | | | | | | | | | when vo_drm_init() fails inside of preinit(), uninit() will be called as part of cleanup with vo->drm being NULL and thus `drm->fd` would lead to null dereference. and since vo_drm_uninit() closes drm->fd, destroy_framebuffer() ends up using a closed fd. according to the drm-gem manpage [0]: > If you close the DRM file-descriptor, all open dumb-buffers are > automatically destroyed. so remove the destroy_framebuffer() loop entirely, which fixes both the issues. [0]: https://www.systutorials.com/docs/linux/man/7-drm-gem/
* hwdec: do not add hwdec device if it failed to createKacper Michajłow2023-06-2610-8/+64
|
* vo: hwdec: prioritise `drmprime` over `drmprime_overlay`Philip Langdale2023-06-221-1/+1
| | | | | | | | | | | | | | I originally left `drmprime_overlay` as higher priority because `drmprime` was new, and because I didn't have any hardware where both worked (only one or the other) so I couldn't compare relative performance, and if only one worked, the priority didn't matter. But with time and more usage, we've reached a point where we can say we would recommend using `drmprime` in situations where both work, and we've also been able to identify hardware where both do indeed work and it seems that `drmprime` is more reliable. So, let's flip them.
* vo_gpu_next: add --corner-rounding optionNiklas Haas2023-06-211-0/+6
| | | | For better or worse.
* vo_gpu_next: add missing --gamut-mapping-mode optionsNiklas Haas2023-06-213-4/+25
| | | | | Adds the missing upstream values that were exposed by the new gamut mapping API.
* vo_dmabuf_wayland: drop linux-dmabuf-v2 (again)Dudemanguy2023-06-164-34/+2
| | | | | | It was done once before but later reverted for testing reasons. This time it's permanent though since I can test this VO on ARM and with an up to date system.
* wayland: bump wayland-protocols to 1.25Dudemanguy2023-06-162-14/+1
| | | | | 1.27 would have been nicer but ubuntu 22.04 is on 1.25 so we'll just compromise.
* wayland: bump required version to 1.20Dudemanguy2023-06-161-8/+0
| | | | This lets us remove some ifdefs.
* vo_dmabuf_wayland: update the image of pending buffersDudemanguy2023-06-141-7/+3
| | | | | | | | | | | | | | | | | When using a display-* video-sync mode, it is possible for buffers with a matching id to already have an image associated with them (i.e. the compositor hasn't released it yet). Previously, it was thought that we could just unref, return null, and make a new buffer but this eventually leads to a fatal error that originates from libwayland itself which stops playback. Admittedly, the reason for the error is a bit nebulous but likely it seems to be some kind of mismatch between dmabuf params and the associated image with the buffer. However, we can simplify this process greatly. Instead when the previously mentioned edge case happens, the old image can simply be freed and we give the buffer the new image. This saves creating a new buffer and also avoids that nasty libwayland error. A nice win-win all around. Fixes #11773.
* vo_dmabuf_wayland: use a minimum of 15 buffersDudemanguy2023-06-141-1/+1
| | | | | | | | | | | | | vo_dmabuf_wayland has a pool of wl_buffers that it cycles through when drawing frame. There needs to be at least some minimum number otherwise a flickering artifact occurs where old frames are mistakenly repeated. When using display-resample and other similar modes, it seems more buffers are required (more drawing happens so it makes sense) and the current minimum of 8 isn't good enough. Let's just bump this to 15. It's also a random ad hoc number, but as far as I know there's not really a way to predict how many buffers a random video may need. From testing, it works fine and overall 15 is still a tiny amount of objects to create considering the lifetime of a video, so we'll just go with this.
* player: add drag-and-drop optionDudemanguy2023-06-122-5/+13
| | | | | | | | | | | Some platforms (wayland) apparently have a lot of trouble with drag and drop. The default behavior is still the same which is basically obeying what we get from the window manager/compositor, but the --drag-and-drop option allows forcibly overriding the drag and drop behavior. i.e. you can force it to always replace the playlist or append at the end. This only implements this in X11 and Wayland but in theory windows and macos could find this option useful (both hardcode the shift key for appending). Patches welcome.
* wayland: avoid misleading log messages on drag/dropDudemanguy2023-06-121-4/+6
| | | | | | | | In data_offer_actions, it's possible to get the WL_DATA_DEVICE_MANAGER_DND_ACTION_NONE action which would set wl->dnd_action to DND_APPEND (did nothing in practice) but also log a message which is confusing and misleading. Instead, just ignore and don't do anything when we get this case.
* hwdec_cuda: clear vulkan semaphore fd after passing ownership to cudaPhilip Langdale2023-06-041-0/+1
| | | | | | This is not technically necessary, because we never touch the fd again after passing to cuda, but having it there could lead to future code accidentally using it.
* hwdec_vulkan: respect probing flag when logging during initPhilip Langdale2023-06-031-3/+4
| | | | | | All hwdecs should respect the probing flag and demote their lgoging to verbose level, so that initialisation failures during probing do not spam the user. I forgot to do this for the Vulkan hwdec.
* vulkan: don't assume all ra_ctx implementations have a swapchainPhilip Langdale2023-06-031-1/+1
| | | | | | | | | | | The dmabuf-wayland vo has a stub ra implementation that doesn't have a swapchain. That means that it's currently not safe to call ra_vk_ctx_get on that ra_ctx, but it must be safe to call on all ra implementations as this is how we discover if it is a vulkan ra. This hasn't been an issue before because no Vulkan code paths would be triggered when using dmabuf-wayland, but with the new vulkan hwdec, it becomes possible to trigger when hwdecs are probed.
* hwdec_cuda: remove usage of deprecated libplacebo sync APIPhilip Langdale2023-06-031-1/+105
| | | | | | | | | | | | | | | | | | | The libplacebo sync abstraction is deprecated and we should be using the more explicit Vulkan semaphore helpers instead. This means that more of the book keeping moves to our side, but it's not too bad. There are two main things going on here: 1. After a lot of back and forth, I decided to write the new code with timeline semaphores to streamline things, and that also means all the variables are separate - which makes the #ifdefs easier to read. Which is important because: 2. While pl_sync owned the exported fd/handle, pl_vulkan_sem does not, so we are responsible for managing them. That means reversing the previous logic - we now can pass an original fd to CUDA and never think about it again, while we have to clean up a Win32 Handle because CUDA will not take ownership.
* video/out/android: assert WinID value before usesfan52023-06-032-0/+2
|
* hwdec_vulkan: enable AV1 support if availablePhilip Langdale2023-05-291-0/+2
| | | | | | | | | | | AV1 support in Vulkan is extremely bleeding edge - to the point that the extension is not present in official Khronos releases, but it has a reserved identifier and we can look it up with a string literal for now. This will be skipped and ignored if the driver doesn't support it, so it's safe if/when the name changes later (it'll just never be activated in that case).
* vo: hwdec_aimagereader: fix compilesfan52023-05-291-1/+1
| | | | forgotten in 085f3e31a091daf7d6649508b162cfcde826702a
* hwdec_vulkan: simplify requirement checks for Vulkan interopPhilip Langdale2023-05-291-12/+8
| | | | | | | | | | | | | I originally wrote this trying to avoid doing an explicit version check on the headers, but it just makes things more confusing, and the requirements harder to understand. So, Vulkan interop now takes a dependency on the header release where they finalised the video decode headers. VK_EXT_descriptor_buffer was added in 1.3.235, so that's covered as well. Along the way I fixed a bug in the waf build where it was depending on libplacebo-next instead of libplacebo-decode.
* vo/vulkan: do not define zero sized arrayKacper Michajłow2023-05-291-4/+2
| | | | It is not needed at all.
* hwdec_vulkan: account for vulkan frames now using presentation sizePhilip Langdale2023-05-291-12/+2
| | | | | | | | | | | | | | | | | ffmpeg was previously allocating images for frames as the code size, rather than the presentation one (1088 vs 1080 in the most common example). Using the coded size when wrapping images for libplacebo resulted in incorrect scaling from 1088 -> 1080, but even using the presentation size wasn't perfect, as discussed in the original commit. However, ffmpeg has now been updated to use the presentation size for the frame images, after discussions that concluded this must be done because there is no way for a frame consumer to fix the dimensions without copying the frame. With that ffmpeg change, we can just use the normal layout information like all the other hwdecs.
* vo: vulkan: request additional extensions and features for ffmpegPhilip Langdale2023-05-281-0/+47
| | | | | | | | | | | | | | | | | Vulkan hwdec interop with the ffmpeg 6.1 vulkan code will require additional features beyond those activated by libplacebo by default. Enabling these features requires both requesting the features' extensions and then explicitly turning on the features. libplacebo handles detecting unsupported features and dropping them, to avoid failing to create the vulkan device. We then leave it to ffmpeg to decide if any missing features are required for functionality, and error out if necessary. As ffmpeg requires at least one bleeding edge extension (descriptor buffers), all of this logic is gated on the presence of sufficiently new Vulkan headers.
* hwdec_vulkan: add Vulkan HW InteropPhilip Langdale2023-05-282-0/+336
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Vulkan Video Decoding has finally become a reality, as it's now showing up in shipping drivers, and the ffmpeg support has been merged. With that in mind, this change introduces HW interop support for ffmpeg Vulkan frames. The implementation is functionally complete - it can display frames produced by hardware decoding, and it can work with ffmpeg vulkan filters. There are still various caveats due to gaps and bugs in drivers, so YMMV, as always. Primary testing has been done on Intel, AMD, and nvidia hardware on Linux with basic Windows testing on nvidia. Notable caveats: * Due to driver bugs, video decoding on nvidia does not work right now, unless you use the Vulkan Beta driver. It can be worked around, but requires ffmpeg changes that are not considered acceptable to merge. * Even if those work-arounds are applied, Vulkan filters will not work on video that was decoded by Vulkan, due to additional bugs in the nvidia drivers. The filters do work correctly on content decoded some other way, and then uploaded to Vulkan (eg: Decode with nvdec, upload with --vf=format=vulkan) * Vulkan filters can only be used with drivers that support VK_EXT_descriptor_buffer which doesn't include Intel ANV as yet. There is an MR outstanding for this. * When dealing with 1080p content, there may be some visual distortion in the bottom lines of frames due to chroma scaling incorporating the extra hidden lines at the bottom of the frame (1080p content is actually stored as 1088 lines), depending on the hardware/driver combination and the scaling algorithm. This cannot be easily addressed as the mechanical fix for it violates the Vulkan spec, and probably requires a spec change to resolve properly. All of these caveats will be fixed in either drivers or ffmpeg, and so will not require mpv changes (unless something unexpected happens) If you want to run on nvidia with the non-beta drivers, you can this ffmpeg tree with the work-around patches: * https://github.com/philipl/FFmpeg/tree/vulkan-nvidia-workarounds
* vo: hwdec: Pass the ra_ctx to hwdecs instead of just the raPhilip Langdale2023-05-2828-56/+65
| | | | | | We will need the full ra_ctx to be able to look up all the state required to initialise an ffmpeg vulkan hwcontext, so pass let's pass the ra_ctx instead of just the ra.
* vo_gpu_next: fix to allow using dllimportKacper Michajłow2023-05-271-1/+1
| | | | | Address of variables can't be used for constant initialization in C language modes.
* vo_gpu_next: respect `gl->flipped`Niklas Haas2023-05-271-2/+4
| | | | This fixes flipped rendering on angle/dxinterop instances.
* opengl: move `ra_gl_ctx_params.flipped` to `struct GL`Niklas Haas2023-05-275-8/+8
| | | | | | This