summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* hwdec_cuda: drop support for PL_HANDLE_WIN32_KMTNiklas Haas2023-01-172-35/+17
| | | | | | | | | | | | | | | This handle type was only needed for backwards compatibility with windows 7. Dropping it allows us to simplify the code: there is no longer a need for runtime checks, as the handle type can now be statically assigned based on the platform. The motivating usecase here, apart from code simplification, is a desired switch to timeline semaphores, which (in the CUDA API) only supports the non-KMT win32 handles. It's worth pointing out that we need no runtime check for IsWindows8OrGreater(), because the `export_caps.sync` check will already fail on versions of windows not supporting PL_HANDLE_WIN32.
* wayland: only warn when actually missing idle inhibit supportThomas Weißschuh2023-01-161-5/+6
|
* vo: make driver list staticThomas Weißschuh2023-01-161-1/+1
|
* vo: remove trailing NULL element from driver arrayThomas Weißschuh2023-01-161-3/+2
|
* wayland: store presentation feedbacks in a poolDudemanguy2023-01-132-20/+65
| | | | | | | | | Officially, the most cursed part of the wayland code in mpv (third or fourth try now?) This time, let's allocate a pool during init (arbitrarily set to the maximum swapchain length mpv allows, 8; don't even know if this actually works in wayland). Then we add/remove feedbacks from the pool during the lifecycle of the VO, and clean it up all at the end. Hopefully, this does the trick for good this time.
* Revert "wayland: dispatch and wait for compositor events in uninit"Dudemanguy2023-01-132-22/+27
| | | | | | | | | | | This ended up being a bad idea. The problem is that it introduces ordering when destroying events (something we weren't worried about before) and Lynne pointed out a problem with the callback not also being destroyed before the surface in IRC. Just undo this and go with a different approach (next commit). P.S. the wayland_dispatch_events name change is kept though because I like that better. This reverts commit aa8ddfcdf30c4ffb38f3ec5d6663bbabf0b7b4df.
* various: replace abort() with MP_ASSERT_UNREACHABLE() where appropriatesfan52023-01-129-20/+19
| | | | | | | | In debug mode the macro causes an assertion failure. In release mode it works differently and tells the compiler that it can assume the codepath will never execute. For this reason I was conversative in replacing it, e.g. in mpv-internal code that exhausts all valid values of an enum or when a condition is clear from directly preceding code.
* various: replace if + abort() with MP_HANDLE_OOM()sfan52023-01-129-28/+14
| | | | | MP_HANDLE_OOM also aborts but calls assert() first, which will result in an useful message if compiled in debug mode.
* {video,audio}: adjust unsafe strncpy usagessfan52023-01-121-2/+2
|
* video/x11: replace sprintf usagesfan52023-01-121-1/+1
|
* video: replace sprintf usagesfan52023-01-122-2/+2
|
* ra_d3d11: fix incorrect typesfan52023-01-121-1/+1
| | | | As it happens, `SIZE_T` and `size_t` are not the same length on 32-bit Windows
* vo_dmabuf_wayland: drop support for linux-dmabuf-v2Dudemanguy2023-01-123-35/+2
| | | | | | | | | The only real reason this was ever supported is because it was dramatically simpler than v4, so it was put in as an initial implementation. Later, v4 support was added and we left v2 for compatibility, but let's just drop it. Compositors all use v4 nowadays, and v2 is significantly limited (no modifier support for example). It's better to just remove this dead code for simplicity.
* vo_dmabuf_wayland: support panscan and panningAaron Boxer2023-01-111-1/+38
|
* vo_wlshm: properly support video panscanDudemanguy2023-01-091-0/+6
| | | | | Turns out it was already doing this under the hood the entire time. The only catch is that the vo just needed a resize.
* wayland: make vo_wayland_reconfig a boolDudemanguy2023-01-084-10/+4
| | | | | | This was already returning true/false but the type was int. Also simplify a few places in the wayland contexts where we can just return the value of this function instead of doing redundant checks.
* wayland: cleanup on vo_wayland_init errorDudemanguy2023-01-083-13/+12
| | | | | | Instead of just returning true/false, it's better to have this function cleanup itself. We can eliminate some redundant uninit calls elsewhere in the code as well.
* vo: change vo_platform_init to boolDudemanguy2023-01-088-15/+14
| | | | | | | | There's several functions that are used for initializing mpv on a certain platform (x11, wayland, etc.). These currently are all int, but they actually return 1 and 0 like a boolean. This gets a bit confusing because actual vo preinit functions return 0 and -1 instead. Just make these all bool instead and return true/false to make it clearer.
* vo_wlshm: cleanup on failureDudemanguy2023-01-081-15/+18
| | | | | If failure occurs during preinit, vo_wlshm should goto an error and cleaup itself like the other VOs.
* vo_dmabuf_wayland: goto err instead of returningDudemanguy2023-01-081-11/+11
| | | | | Returning early is clearly wrong. It should use to goto to cleanup after itself. Also renamed from error_out to err for purely comestic reasons.
* vulkan: fix build error for 32bit builds with clangChristoph Reiter2023-01-081-1/+1
| | | | | | | | | | | vk->surface is a handle and not a pointer, so assign VK_NULL_HANDLE. This fixes the following build error on 32bit Windows when using clang for example, which errors out when assigning a 32bit pointer to a 64bit integer: ../mpv-0.35.0/video/out/vulkan/utils.c:37:21: error: incompatible pointer to integer conversion assigning to 'VkSurfaceKHR' (aka 'unsigned long long') from 'void *' [-Wint-conversion] vk->surface = NULL; ^ ~~~~
* wayland: dispatch and wait for compositor events in uninitDudemanguy2023-01-032-30/+25
| | | | | | | | | | Similar to some other issues we've had with unprocessed compositor events. When quitting mpv, there's two things we should be doing: dispatching any last minute wayland events and then waiting for a compositor reply. Luckily, there's already an internal helper for this (renamed to wayland_dispatch_events for consistency) that we can use. All of the special casing of wl->feedback becomes unneccesary and we can remove this from vo_wayland_state with this method. Fixes #110022.
* wayland: initalize display_fd as -1Dudemanguy2023-01-031-3/+4
| | | | | | | | In the event of a failed wayland initalization, the display_fd is actually 0 instead of -1 which would correctly indicate it doesn't exist. Also move the fd check inside vo_wayland_dispatch_events since that function shouldn't ever do anything if we don't actually have a display fd.
* wayland: consistently employ use_presentDudemanguy2023-01-031-4/+1
| | | | | | | | | We have a use_present bool that keeps track of whether or not to use presentation time. However, the creation of the feedback listener actually wasn't checking this and was instead checking for the existence of wl->presentation. There's no point in always creating the listener and feedback if mpv isn't actually going to use it. Just change it to use_present instead.
* vo: hwdec: fix drmGetDeviceNameFromFd2() related memory leakrepojohnray2023-01-021-1/+5
| | | | | This commit fixes a minor memory leak related to drmGetDeviceNameFromFd2(). This function returns a string allocated with strdup().
* hwdec_drmprime: fix memory leakrepojohnray2023-01-021-0/+1
|
* vo_opengl: do not blindly reject all Microsoft's OpenGL implementationsKacper Michajłow2022-12-301-3/+3
| | | | | | | | | | | | | This change enables mpv to work in the WSL2 (WSLg) environment where OpenGL is implemented on top of D3D12. This reverts commit 149d98d244. Mentioned OpenGL implementation (GDI Generic) in the original change will be rejected by version check, so there is no need to handle it manually. Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
* x11: add modesetting to the xpresent whitelistSultan Alsawaf2022-12-271-1/+2
| | | | | | | | | | | | | | | | Since the modesetting driver now has TearFree support with integration into xpresent, it's important that xpresent is used with the modesetting driver to get the correct vsync timing when a frame is delayed by one vblank interval due to a pending page-flip enqueued by a different entity. The modesetting driver ensures that the xpresent extension reports the correct presentation timing when TearFree is used; mpv just needs to listen to it. Add the modesetting driver to the xpresent whitelist so mpv can get the correct presentation completion timing when modesetting TearFree is used. This is also helpful for when xpresent performs page flips directly in the modesetting driver and a natural delay in the display pipeline causes a page flip to be delayed by one vblank interval or more.
* build: add configure test for POSIX shm for the sake of vo_kittysfan52022-12-261-4/+5
| | | | Android's POSIX coverage is pretty sketchy but not like we have a choice.
* vo_kitty: Introduce modern sixel alternativeMia Herkt2022-12-212-0/+434
| | | | | | | | | | | | | See https://sw.kovidgoyal.net/kitty/graphics-protocol/ This makes no attempt at querying terminal features or handling terminal errors, as it would require mpv to pass the response codes from the terminal to the vo instead of interpreting them as keystrokes made by the user and acting very unpredictably. Tested with kitty and konsole. Fixes #9605
* hwdec/d3d11va: fix a possible memory leakchen702022-12-211-0/+1
|
* filter_kernels: fix kaisergaramond132022-12-201-1/+1
| | | | Seems to me that params[1] is set to NAN and here should be the same value as in params[0].
* vo_sixel: Implement write() loopMia Herkt2022-12-201-4/+16
| | | | | Not all systems are Linux. Also update the comment to better reflect POSIX documentation.
* vo_sixel: Rename draw-clear -> config-clearMia Herkt2022-12-201-5/+5
|
* osdep/terminal.h: Rename screen buffer controlsMia Herkt2022-12-202-4/+4
| | | | SAVE/RESTORE were a bit misleading.
* vo_sixel: Alias/deprecate exit-clear -> alt-screenMia Herkt2022-12-201-5/+7
| | | | Also update documentation to reflect actual behavior.
* vo_sixel: Make buffering optionalMia Herkt2022-12-201-7/+21
| | | | It can be slower than unbuffered.
* vo_sixel: Buffer full output sequenceMia Herkt2022-12-191-19/+27
| | | | | This allows the VO to write its output without interference from other processes or threads.
* vo_sixel: Use write(2) on POSIX platformsMia Herkt2022-12-191-14/+35
|
* vo_tct: Use newer options APIMia Herkt2022-12-191-28/+24
|
* vo_sixel: Move user options to structMia Herkt2022-12-191-69/+66
|
* vo_sixel: Add option to skip clear while drawingMia Herkt2022-12-191-7/+12
|
* osdep/terminal: Move common esc codes to terminal.hMia Herkt2022-12-192-42/+32
|
* vo_sixel: Use the alternate buffer to restore termMia Herkt2022-12-191-4/+6
|
* vo_tct: Use the alternate buffer to restore termMia Herkt2022-12-191-3/+7
|
* vd_lavc: Set AV_HWACCEL_FLAG_UNSAFE_OUTPUT flagPhilip Langdale2022-12-121-0/+11
| | | | | | | | | | This new hwaccel flag was added to allow us to request that an hwaccel decode not implicitly copy output frames before passing them out. The only hwaccel that would implicitly copy frames is nvdec due to how it has a small output pool that cannot be grown very much. However, we already copy frames as soon as we get our hands on them (in our hwdec) so we're already safe from pool exhaustion, and the extra copy doesn't help us.
* hwdec_drmprime: support yuv420p formatEmperorPenguin182022-12-102-0/+6
| | | | | | | | | | | H264 hardware decode with v4l2m2m wasn't working on the RPi 4. Mpv would report the image format (yuv420p) wasn't supported. The change to hwdec_drmprime.c is to explicitly say that the format now is supported. The change to dmabuf_interop_gl.c is to specify the colour format of the planes before generating egl images. 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>
* player: add window-id propertyNRK2022-12-052-0/+7
| | | | | | | | | | | | | | | | | | | | | currently only supported on x11. one practical use-case of this is wanting to embed something (such as dmenu) into the mpv window to use as a menu/selection. there might be other use-cases as well (e.g doing some shenanigans with `xdotool` or whatnot). it's currently possible to: * listen for 'current-window-scale' change (to check if the window has been created or not) * call an external tool like `xdo` or `xdotool` and grab the xid from mpv's pid. however it adds unnecessary dependency on external tools when mpv is fully capable of easily providing this information. closes: #10918
* ffmpeg: update to handle deprecation of `av_init_packet`Philip Langdale2022-12-031-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This has been a long standing annoyance - ffmpeg is removing sizeof(AVPacket) from the API which means you cannot stack-allocate AVPacket anymore. However, that is something we take advantage of because we use short-lived AVPackets to bridge from native mpv packets in our main decoding paths. We don't think that switching these to `av_packet_alloc` is desirable, given the cost of heap allocation, so this change takes a different approach - allocating a single packet in the relevant context and reusing it over and over. That's fairly straight-forward, with the main caveat being that re-initialising the packet is unintuitive. There is no function that does exactly what we need (what `av_init_packet` did). The closest is `av_packet_unref`, which additionally frees buffers and side-data. However, we don't copy those things - we just assign them in from our own packet, so we have to explicitly clear the pointers before calling `av_packet_unref`. But at least we can make a wrapper function for that. The weirdest part of the change is the handling of the vtt subtitle conversion. This requires two packets, so I had to pre-allocate two in the context struct. That sounds excessive, but if allocating the primary packet is too expensive, then allocating the secondary one for vtt subtitles must also be too expensive. This change is not conditional as heap allocated AVPackets were available for years and years before the deprecation.
* sws_utils: update to handle deprecation of `avcodec_enum_to_chroma_pos`Philip Langdale2022-12-011-0/+14
| | | | This has been replaced by `av_chroma_location_enum_to_pos`.
* vd_lavc: update to handle deprecation of `pkt_duration`Philip Langdale2022-12-011-0/+5
| | | | This has been replaced by `duration`.
* ffmpeg: increase minimum required version to 4.4Philip Langdale2022-12-011-2/+0
| | | | | | | | | Now that 0.35 has been released, we can consider increasing our minimum required ffmpeg version. Currently, we think 4.4 is the most recent version we can move to (from the current requirement of 4.0). This allows us to remove a few conditionals. There are more that we won't be able to remove unless we move further up to 5.1.
* wayland: check for resize/move in touch event firstDudemanguy2022-12-011-8/+9
| | | | | | | | | | | | | | | 8300830951e2b0b90b22fc7d33b7556ed05e139c rearranged/simplified some of the wayland touch code mainly because what was there before was completely broken on my machine in those days (dragging was unreliable, resizing was really buggy, etc.). However, one user said that touch input no longer worked for him after that change. I could not ever reproduce it, but it seems the issue was putting down the key before testing for resize/move in the code. Now who knows why this actually matters, but apparently it works for the user in question and I don't observe any unexpected behavior on my end when swapping the order. Like the mouse/pointer code, we also now do a test for dragging before actually trying a resize/move which is a little more consistent than before. Fixes #9771.
* vo_gpu_next: don't flush cache on OSD updateNiklas Haas2022-11-251-2/+9
| | | | | | | | | | | | | | | | | | | Flushing the cache is a hammer-for-a-screw operation, because it nukes *all* renderer state, including the HDR peak detection state. When enabling e.g. --hdr-compute-peak, or any other future methods of dynamic tone mapping, this would lead to bad results (e.g. brightness fluctuations) whenever the OSD state is updated. Instead of flushing the cache to force an OSD re-render, instead just update the frame signature directly whenever its osd_sync value changes. This accomplishes effectively the same thing but without touching the HDR state. This is slightly violating the libplacebo abstraction in a way that isn't publicly documented. To be on the safe side we could make a carbon copy of the array before modifying it, but given that this is unlikely to change upstream I'll probably just end up explicitly documenting it instead of forcing the copy in mpv.
* lcms: fix validate_3dlut_size_optNiklas Haas2022-11-211-4/+1
| | | | | Not only was this function needlessly convoluted, it was also broken - since it returned a bool value where an error code was expected.
* lcms: always parse lcms2-related optionsNiklas Haas2022-11-211-40/+34
| | | | | | | | | | | | | | Currently, the lcms-related options are only defined when lcms2 is enabled at build time. However, this causes issues (e.g. segfault) for vo_gpu_next, which relies on the presence of these options (to forward them to libplacebo). (That libplacebo internally depends on lcms2 as well is an implementation detail - compiling mpv *without* lcms against libplacebo *with* lcms should be possible in principle) Fixes: #10891 Closes: #10856
* vo_dmabuf_wayland: use single-pixel-buffer-v1LaserEyess2022-11-203-18/+49
| | | | | | | The new single-pixel-buffer protocol is designed to optimize the case for using a solid color as an underlay wl_surface. It works the same as the wl_shm 1x1 pixel trick currently used, but it allows the compositor to make optimizations with more certainty than the wl_shm trick.
* wlbuf_pool.h: add headers for forward declarationsLaserEyess2022-11-202-1/+4
| | | | | | This was previously implicitly included by the order of headers in vo_dmabuf_wayland.c, but it is better to make it an explicit and reorder the headers properly.
* vo_gpu_next: fix undefined behavior on alpha-first formatsNiklas Haas2022-11-191-1/+4
| | | | | | | When the alpha channel is the first component, this code block gets skipped by the continue, meaning the check for c==0 never passes. Fix it by explicitly keeping track of whether bits have been set.
* wayland: also log refresh rate on surface entranceDudemanguy2022-11-181-2/+2
| | | | | Never bothered to log this for some reason, but it's pretty convenient when debugging.
* drm: remove legacy APILaserEyess2022-11-164-119/+54
| | | | | | | | | | | | | The legacy DRM API adds some complexity to the DRM code. There are only 4 drivers that do not support the DRM Atomic API: 1. radeon (early GCN amd cards) 2. gma500 (ancient intel GPUs) 3. ast (ASPEED SoCs) 4. nouveau Going forward, new DRM drivers will be guaranteed to support the atomic API so this is a safe removal.
* wayland: add support for content-type protocolDudemanguy2022-11-152-0/+57
| | | | | | | | | | | | | | | | | | | | The content-type protocol allows mpv to send compositor a hint about the type of content being displayed on its surface so it could potentially make some sort of optimization. Fundamentally, this is pretty simple but since this requires a very new wayland-protocols version (1.27), we have to mess with the build to add a new define and add a bunch of if's in here. The protocol itself exposes 4 different types of content: none, photo, video, and game. To do that, let's add a new option (wayland-content-type) that lets users control what hint to send to the compossitor. Since the previous commit adds a VOCTRL that notifies us about the content being displayed, we can also add an auto value to this option. As you'd expect, the compositor hint would be set to photo if mpv's core detects an image, video for other things, and it is set to none for the special case of forcing a window when there is not a video track. For completion's sake, game is also allowed as a value for this option, but in practice there shouldn't be a reason to use that.
* player/video: add VOCTRL_CONTENT_TYPEDudemanguy2022-11-151-0/+9
| | | | | | | | | | | | mpv's core already keeps track of whether or not it thinks a track is an image. Some VOs (i.e. wayland) would benefit from knowing if what is currently being displayed is an image or not so add a new VOCTRL that signals this anytime we load a new file with a VO. Additionally, let's add a helper enum for signaling the kind of content that is being displayed. There is now MP_CONTENT_NONE (strictly for force window being used on a track with no image/video), MP_CONTENT_IMAGE, and MP_CONTENT_VIDEO. See the next commit for the actual usage of this (with wayland).
* vo: hwdec: remove legacy_namesPhilip Langdale2022-11-155-16/+0