summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* vd_lavc: check if av_device_ref is availableKacper Michajłow2023-06-261-1/+3
| | | | | | Fixes crashes when hwdevice failed to create. Fixes: #11769
* 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.
* f_hwtransfer: disable vulkan multiplane images when uploading from cudaPhilip Langdale2023-05-283-3/+24
| | | | | | | | | | | | | | | | Although we can support vulkan multiplane images, cuda lacks any such support, and so cannot natively import such images for interop. It's possible that we can do separate exports for each plane in the image and have it work, but for now, we can selectively disable multiplane when we know that we'll be consuming cuda frames. As a reminder, even though cuda is the frame source, interop is one way so the vulkan images have to be imported to cuda before we copy the frame contents over. This logic here is slightly more complex than I'd like but you can't just set the flag blindly, as it will cause hwframes ctx creation to fail if the format is packed or if it's planar rgb. Oh well.
* 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-284-0/+343
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 is motivated by a need to access it from vo_gpu_next's opengl wrapping code, and justified by it being an inherent property of the GL context itself,
* vo: make mp_frame_perf thread safeKacper Michajłow2023-05-253-7/+7
| | | | | | | It was unsafe to return pointer to memory that was freed on another thread, just copy the string to caller owned sturcture. Fixes crashes when displaying passes stats with gpu-next.
* vo_gpu_next: add size guard for pass->num_samplesKacper Michajłow2023-05-251-2/+3
| | | | | This shouldn't happen as the array sizes are the same, but guard against it in case libplacebo do something naughty.
* vo_gpu_next: synchronize voctrl_performance_data accessKacper Michajłow2023-05-251-0/+11
| | | | | info_callback is fired quite often and from different thread than any accesses to this structure.
* vo_gpu_next: fix off by one in info_callbackKacper Michajłow2023-05-251-1/+1
| | | | Fixes invalid memory writes.
* vo_dmabuf_wayland: rewrite around wl_listDudemanguy2023-05-243-426/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | | | vo_dmabuf_wayland worked by allocating entries to a pool and then having a lot of complex logic dealing with releasing buffers, pending entries, etc. along with some other not so nice things. Instead, we can rewrite this logic so that the wl_buffers created by the imported dmabuf is instead stored in a linked list, wl_list. We can simply append our buffers to the list when needed and destroy everything at the end. On every frame, we can check the ids of our surfaces and reuse existing buffers, so in practice there will only ever be a handful at a time. Some other small changes were made in an attempt to organize the vaapi/drmprime code a little better as well. An important change is to always enforce at least a minimum number of buffers. Certain formats would not make enough unique buffers, and this results in flickering/artifacts occuring. The old way to attempt to deal with this was to clear out all the existing buffers and remake them, but this gets complicated and also didn't always work. An easy solution to this is just create more buffers which appears to solve this problem. The actual number needed is not really based on anything solid, but 8 is a reasonable number to create for the lifetime of a file and it seems to do the trick. Additionally, seeking/loading new files can result in flicker artificts due to buffers being reused when they shouldn't. When that happens, we flip a bool so all the buffers get destroyed in draw_frame to avoid any visual glitches.
* vo_gpu_next: fix build on older libplaceboNiklas Haas2023-05-241-1/+0
| | | | | | Introduced by, of all things, a rebase... Fixes: a5da8b2c87dc3ace0038ccb5dc8f221df7f52206
* vo_gpu_next: update to new libplacebo gamut mapping APINiklas Haas2023-05-241-3/+29
| | | | | | | | This just replaces the API calls to get rid of deprecation warnings, it doesn't yet expand the enum, nor replace them by the proper options. The translation from tone map modes to hybrid mix parameters is taken from the libplacebo source code.
* vo_gpu_next: remove --tone-mapping-crosstalkNiklas Haas2023-05-243-5/+1
| | | | Removed upstream, to be replaced by constant 0.04.
* context_drm_egl: check for non-existant drm in uninitMatthew Lindner2023-05-221-19/+24
| | | | | | | | Previously, if vo_drm_init failed at the start of drm_egl_init it caused a use-after-free in drm_egl_uninit when it tried to access the non-existant drm context. At that point vo_drm_uninit had already been called resulting in two different null pointer dereference. In this situation the DRM private context had also not been allocated.
* ra_d3d11: change how messages are ignored during texture size lookupKacper Michajłow2023-05-181-13/+9
| | | | | | | | | | | | Filtering globally D3D11_MESSAGE_ID_CREATETEXTURE2D_INVALIDDIMENSIONS is suboptimal, because can also hide other invalid usages. In the same time it is not enough, because not only this message is emitted, but also one about E_INVALIDARG. Just flush queue before and clear messages after to ignore this part of code. As a side note, I don't believe this texture size lookup is in fact useful, but since it is there and is relatively harmless, let's leave it as is.
* wayland: improve guessing when mpv is focusedDudemanguy2023-05-171-6/+16
| | | | | | | | | | The current implementation is order dependent and assumes that getting keyboard input happens before the toplevel is activated. This isn't necessarily the case and indeed mutter activates the toplevel first. Improve this by simply spinning off the check to a function and calling it in the three places where it would be needed: the toplevel configuration event, keyboard entering, and keyboard leaving. This fixes #11694.
* vo_gpu_next: allow to use ICC profile luminance valueKacper Michajłow2023-05-133-4/+16
| | | | | | Also while at it respect target-peak option when ICC profile is used. Fixes #11449
* mp_image: use the ffmpeg interlaced frame flags where availablePhilip Langdale2023-05-111-0/+14
| | | | | The old frame properties are deprecated and have been replaced by frame flags.
* player: use XDG_CACHE_HOME by defaultDudemanguy2023-05-097-10/+35
| | | | | | | | | | | | This adds cache as a possible path for mpv to internally pick (~/.cache/mpv for non-darwin unix-like systems, the usual config directory for everyone else). For gpu shader cache and icc cache, controlling whether or not to write such files is done with the new --gpu-shader-cache and --icc-cache options respectively. Additionally, --cache-on-disk no longer requires explicitly setting the --cache-dir option. The old options, --cache-dir, --gpu-shader-cache-dir, and --icc-cache-dir simply set an override for the directory to save cache files. If unset, then the cache is saved in XDG_CACHE_HOME.
* wayland: add support for wl_surface.preferred_buffer_scaleSimon Ser2023-04-301-2/+49
| | | | | | | See [1] for the motivation. Very similar to the fractional scale, except it's in core and integer-only. [1]: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/220
* vo_gpu_next: fixes to allow using dllimportKacper Michajłow2023-04-241-3/+3
| | | | | | | Address of variables can't be used for constant initialization in C language modes. See https://github.com/llvm/llvm-project/commit/0c43d8077e605ab78d85180f0dcaa4df1ae37607
* hwdec_drmprime: support rpi4_8 and rpi4_10 formatsEmperorPenguin182023-04-202-1/+14
| | | | | | | | | | | | HEVC hardware decode with drm wasn't working on the RPi 4. Mpv would report the image format (rpi4_8 for 8-bit and rpi4_10 for 10-bit) wasn't supported. The change to hwdec_drmprime.c identifies these two formats as NV12 because it functions exactly the same. The change to dmabuf_interop_gl.c adds support for P030 which rpi4_10 uses. These changes were tested on a Pi 4 with this fork of ffmpeg: https://github.com/jc-kynesim/rpi-ffmpeg. Signed-off-by: EmperorPenguin18 <60635017+EmperorPenguin18@users.noreply.github.com>
* wayland: correctly scale configure_boundsiczero2023-04-111-2/+2
|
* video/out/gpu: Fix compilation warning of out of bound accessMika Kuoppala2023-04-101-7/+9
| | | | | | Make the index into the arrays in copy_image() unsigned to make compiler trust that we dont access out of bounds.
* mp_image: always add AV_FRAME_DATA_DOVI_METADATA when presentquietvoid2023-04-101-8/+2
| | | | | | | | As the Dolby Vision metadata is only supported for vo_gpu_next, the check whether to use the metadata is now handled by `mp_map_dovi_metadata_to_pl`. It doesn't hurt to keep the metadata in `mp_image`, and might be useful to library users.
* win32: follow Windows settings and update dark mode stateKacper Michajłow2023-04-041-0/+48
| | | | | | | | | | | | | | | | | Microsoft documented how to enable dark mode for title bar: https://learn.microsoft.com/windows/apps/desktop/modernize/apply-windows-themes https://learn.microsoft.com/windows/win32/api/dwmapi/ne-dwmapi-dwmwindowattribute Documentation says to set the DWMWA_USE_IMMERSIVE_DARK_MODE attribute to TRUE to honor dark mode for the window, FALSE to always use light mode. While in fact setting it to TRUE causes dark mode to be always enabled, regardless of the settings. Since it is quite unlikely that it will be fixed, just use UxTheme API to check if dark mode should be applied and while at it enable it fully. Ideally this function should only call the DwmSetWindowAttribute(), but it just doesn't work as documented. Fixes: #6901
* d3d11: retry device creation without debug, if SDK is not availableKacper Michajłow2023-04-021-1/+10
| | | | Fixes #11512
* context_angle: include eglext_angle.h explicitlyKacper Michajłow2023-03-301-0/+1
| | | | | Recent MSYS update switched to using vanilla EGL headers, which doesn't include eglext_angle.h implicitly.
* various: fix various typos in the code baseAlexander Seiler2023-03-283-11/+11
| | | | Signed-off-by: Alexander Seiler <seileralex@gmail.com>
* various: fix typosHarri Nieminen2023-03-2813-16/+16
| | | | Found by codespell
*