summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | These were introduced for configuration compatibility in 0.35 but we don't want to retain them past that point.
* player: add --force-render optionDudemanguy2022-11-152-2/+3
| | | | | | | | mpv has an internal optimization on a couple of platforms where it will not render any frames if the window is minimized or hidden. There's at least once possible use case for wanting to force a render anyway (screensharing with pipeware) so let's just add a simple switch for this that always forces mpv to render. Closes #10846.
* wayland: error out if essential protocol support is missingDudemanguy2022-11-153-0/+36
| | | | | | | | | | | | | | Related issue: #10868. While most protocols are in theory optional, a small amount of them are absolutely essential and nothing will work without them. We should make sure to error out in those cases and not try to actually do anything. For wayland support in general, wl_compositor support is obviously required. If there is no wl_surface, you can't do anything. Additionally, vo_wlshm quite obviously requires wl_shm so mark that one as well. vo_dmabuf_wayland needs linux_dmabuf, viewporter, wl_shm, and wl_subcompositor. In practice, these are all very standard protocols and shouldn't be missing but the linked issue above is at least one example where a compositor was stuck on an ancient version of a wayland interface.
* vo_gpu_next: add tunable shader parametersNiklas Haas2022-11-113-1/+61
| | | | | | | | | | | This is a very simple but easy way of doing it. Ideally, it would be nice if we could also add some sort of introspection about shader parameters at runtime, ideally exposing the entire list of parameters as a custom property dict. But that is a lot of effort for dubious gain. It's worth noting that, as currently implemented, re-setting `glsl-shader-opts` to a new value doesn't reset back previously mutated values to their defaults.
* vo_gpu: mark --gamma-factor and --gamma-auto with deprecation warningssfan52022-11-101-2/+4
| | | | This was forgotten in commit 2207236aaae54f32c1861c6fd77219e28139dc78.
* wayland, x11: fix possibly unsafe bstr usagesfan52022-11-102-3/+3
| | | | | | In practice this never led to any issues due to implementation details of bstr_sanitize_utf8_latin1, but there's no guarantee that a bstr is correctly null-terminated.
* vo_dmabuf_wayland: improve error handling exporting VA surfaceAaron Boxer2022-11-071-23/+25
| | | | | 1. check for all error conditions when calling vaExportSurfaceHandle 2. only clean up valid descriptors
* hwdec_vaapi: only set VADisplay resource if entire init process has succeededAaron Boxer2022-11-071-4/+4
| | | | | This resource is used by dmabuf_waland to decide if it should manage vaapi buffers, so it should not be set if vaapi init has failed
* gpu/context: properly guard wldmabuf contextDudemanguy2022-11-031-1/+1
| | | | | This should only be added if the build has dmabuf-wayland enabled. This fixes #10828.
* vo_gpu_next: set background transparencyNiklas Haas2022-11-011-0/+1
| | | | Fixes: https://github.com/mpv-player/mpv/issues/10815
* wayland_common: always zero out presentation context when destroying itLynne2022-10-311-1/+3
| | | | | A desync between the feedback and the feedback in the context still happens when closing a hidden surface.
* wayland: correct braindead comment (no-op)Dudemanguy2022-10-311-5/+4
| | | | | | | | | | | | | I was confused in d3a28f12c9ced29982fc831722075bd0c73fb821 why it actually even worked, but after not being stupid, it's quite obviously just a dangling pointer. The reason it only happens with wp_presentation_feedback is because the object and listener actually created in frame_callback not the presentation events itself (for vsync timing reasons). So it is possible to free the object, but not immediately recreate it again before quitting (unlike with the frame callback). The actual comment is moved into feedback_presented (which is first) but as of this commit it doesn't have the NULL setting logic (that's the next one).
* wayland: hack around presentation_feedback weirdnessDudemanguy2022-10-301-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | 964692ad4cec90888bb437064c53d8844db9f590 added some code to destroy presentation_feedback we get in the presentation_discarded event. This is the correct thing to do since the compositor could send us this instead of feedback_presented. Without that change, mutter could potentially leak memory on every frame. Unfortunately, life is not so simple and wlroots and weston act differently. These compositors only send one presentation_discarded event if the mpv window is hidden. Not on every single missed frame like mutter. Now in theory this shouldn't matter, but it also turns out that mpv attempts to free the presentation feedback twice if you quit it while it is hidden away (on weston and wlroots compositors only). The inital wp_presentation_feedback_destroy in feedback_discarded fires, but then the function goes off again in vo_wayland_uninit because wl->feedback is apparently not NULL for some reason. Possibly, this is some race condition but we can't just get rid of what's in feedback_discarded since mutter needs this line. Instead, just hack it by explicitly setting wl->feedback to NULL in feedback_discarded after we destroy the presentation feedback. Some valgrind testing in mutter, sway, and weston shows that this works correctly on all of those compositors with various combinations of mpv being visible or not while quitting. feedback_presented doesn't appear to exhibit this behavior so we just leave that as-is.
* wayland: free dmabuf_feedback objectDudemanguy2022-10-301-4/+9
| | | | | | | 666cb91cf12a4f8b42087530104513b0fc4ba16d added dmabuf_feedback, but it was never actually free'd on uninit. Because this function requires wayland protocols 1.24, we have to wrap it in an #if. Also throw in some minor cosmetic changes in here.
* filters/f_hwtransfer: remove VAAPI <-> Vulkan mapping for nowPhilip Langdale2022-10-292-2/+0
| | | | | | | | | This mapping isn't actually relevant until we have the Vulkan interop merged, and it requires a newer version of libavutil than our minimum requirement. So I'm going to remove it from master and put it in the interop PR. Fixes #10813
* build: add an additional check for wayland-protocols 1.24Dudemanguy2022-10-292-3/+7
| | | | | | | | | | | | | | | | | 666cb91cf12a4f8b42087530104513b0fc4ba16d added support for v4 of the dmabuf protocol. This was meant to be optional and the fallback support for the old v2 (dates back to 2017[0] well before the 1.15 wayland-protocol version we depend on) was maintained. However, v4 added several new functions and structs that of course aren't defined in old protocol versions so naturally this breaks the build on those systems. Since this is just a niche feature and not really critical to overall wayland support in mpv, just give in and add another check in the build system and #if out the newer stuff in wayland_common. v4 of linux-dmabuf depends on wayland protocols 1-24[1], so go ahead and make that our new check. Fixes #10807. [0]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/a840b3634ad637b237f238d2efb9ab8f4712d5f4 [1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/8a5cd28a0e84911a5339855cb32ed63fb57ea40a
* vo_dmabuf_wayland: use special ra_ctx_create_by_nameDudemanguy2022-10-284-11/+41
| | | | | | | | | | | | | | | | | | | vo_dmabuf_wayland has its own ra and context so it can handle all the different hwdec correctly. Unfortunately, this API was pretty clearly designed with vo_gpu/vo_gpu_next in mind and has a lot of concepts that don't make sense for vo_dmabuf_wayland. We still want to bolt on a ra_ctx, but instead let's rework the ra_ctx logic a little bit. First, this introduces a hidden bool within the ra_ctx_fns that is used to hide the wldmabuf context from users as an option (unlike the other usual contexts). We also want to make sure that hidden contexts wouldn't be autoprobed in the usual ra_ctx_create, so we be sure to skip those in that function. Additionally, let's create a new ra_ctx_create_by_name function which does exactly what says. It specifically selects a context based on a passed string. This function has no probing or option logic is simplified just for what vo_dmabuf_wayland needs. The api/context validations functions are modified just a little bit to make sure hidden contexts are skipped and the documentation is updated to remove this entries. Fixes #10793.
* vo_dmabuf_wayland: load all hwdecs in preinitDudemanguy2022-10-281-1/+1
| | | | | | | | | | | vo_gpu and vo_gpu_next typically load hwdec interops on demand and vo_dmabuf_wayland naively copied this logic. This is actually wrong however since draw_frame in the VO always inherently relies on hwdec being fully loaded. This can lead to a race condition during startup which happens with --force-window=immediate. Avoid this by simply always loading all the interops. In the case of vo_dmabuf_wayland, this is not really a big deal since there's only vaapi and drmprime to load. Also fixes #10791 (the other half).
* wayland: always do a display_roundtrip at the end of initDudemanguy2022-10-281-0/+4
| | | | | | | | | We really need two roundtrips in the init function. The first one is for running the registry and then second one is for ensuring the xdg_surface and other potential wayland objects are configured at least once before mpv does anything. We've been getting away with only doing the first for a while via luck, but really we should do at least one more wait on the compositor. Fixes #10791 (half of it).
* vo_dmabuf_wayland: fix DRM builds with no VAAPIDave Craig2022-10-271-3/+7
| | | | | | Building on DRM platform without VAAPI broke because of misuse of HAVE_VAAPI with #ifdef in place of #if. Also, the hwcontext_drm.h header is not required for VAAPI builds, only DRM builds.
* video/out/wayland_common: adjust decoration disagreement log levelJan Ekström2022-10-272-12/+8
| | | | | | | | | | | | | Originally, I considered warning once to be useful for figuring out whether the change in logic regarding resetting requested mode actually fixed the reported issue or not, but alas not everyone was happy with that decision. Thus the log level will always be debug. This enables us to lose one level of indent as well as a variable, which is always positive. Additionally, make the message more explicit regarding what could possibly be implied by the mismatch, as it seems like this was not always clear.
* video/out/wayland_common: clear decoration request even if compositor disagreesJan Ekström2022-10-262-1/+24
| | | | | | | | | Otherwise mpv and the compositor can end up in an eternal loop where mpv requests one mode, and compositor tells that the mode is not that (and will most likely not change). Additionally, log these mismatches - first time as a warning, and later as debug logging.
* video/out/wayland_common: don't pass a negative of border flag into ternaryJan Ekström2022-10-261-1/+2
| | | | | Make it clear that we are passing the original requested border mode on.
* video/out/wayland_common: make decoration state usage explicitJan Ekström2022-10-261-3/+9
| | | | | | | | | It is verbose, but makes it more explicit that requested_decoration takes in three values: * 0: no specific mode requested by mpv * ZXDG_TOPLEVEL_DECORATION_V1_MODE_CLIENT_SIDE: (!border) * ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE: (border)
* wayland: bump dmabuf protocol to version 4Emmanuel Gil Peyrot2022-10-263-11/+88
| | | | | | | | | | | | | | | | | Pulled from https://github.com/mpv-player/mpv/pull/10382 The zwp_linux_dmabuf_v1 protocol version 4 provides a file descriptor containing both formats and modifiers, which makes it possible for the compositor to import the buffers onto planes using explicit modifiers. This is an extremely important efficiency improvement, as the 3D hardware can be left powered off altogether, the vaapi buffer being sent directly from the video hardware to the display controller. It could be possible to support zwp_linux_dmabuf_v1 version 3 as well, but there is no reason beyond compatibility with old stacks. I would recommend to ditch version 2 as well, as modifier-less formats aren’t very useful nowadays.
* vo_vaapi_wayland: remove, as it is superceded by vo_dmabuf_waylandAaron Boxer2022-10-263-399/+2
|
* vo_dmabuf_wayland: wayland VO displaying dmabuf buffersAaron Boxer2022-10-2612-5/+813
| | | | | | | | | | | | | Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
* wayland: clean wp_presentation_feedback in discard callback to avoid leakAaron Boxer2022-10-261-0/+2
|
* mp_imgfmt: move DRMPRIME format to end of enumAaron Boxer2022-10-261-1/+1
| | | | | | | dmabuf-wayland vo supports both DRMPRIME and VAAPI formats. If upload filter is needed, we want to try VAAPI hwdec first since most users will be using VAAPI, and there is a several second delay when DRMPRIME hwdec is tried and fails.
* vo_gpu/hwdec: add NULL check for legacy_namePhilip Langdale2022-10-221-1/+1
|
* hwdec_aimagereader: fix incorrect return valuessfan52022-10-221-2/+2
|
* hwdec/dmabuf_interop_gl: work-around implicit rgba swizzlingPhilip Langdale2022-10-151-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | This has been a long standing problem that I think was the root cause for wm4's vaapi shitlist. As DRM explicit supports all possible rgba orderings, but OpenGL only guarantees support for 'rgba8', something has to happen to support import of dmabufs with non-native ordering. Although undocumented, it appears that somewhere in the import on the GL side, the ordering is swizzled to rgba - which makes sense as that's the only way to be able to support importing all the different formats. But we didn't know this, and we do our own swizzling based on the original imgfmt - which matches the drm format. So we get double swizzling and messed up colours. As there is no way for us to express that the GL swizzle happened to the rest of mpv, the easiest thing to do is fudge the format to the natural ordering so the GL doesn't change anything, then our swizzling will do the right thing in the end. Note that this change doesn't handle 0rgb and 0bgr because they seem to be affected by some additional feature/bug that is mangling the ordering somewhere that equally affects Vulkan interop. That could be a vaapi driver bug or something going on in ffmpeg.
* hwdec/vaapi: improve probing of supported sw formatsPhilip Langdale2022-10-151-3/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The logic around trying to establish what formats are supported by vaapi is confusing, and it turns out that we've been doing it wrong. Up until now, we've been going through the list of decoding profile endpoints and checking the formats declared in those profiles to build our list. However, the set of formats that the vaapi driver can actually support is potentially a superset of those supported by any given profile endpoint. This master list is exposed by libavutil via the av_hwframe_transfer_get_formats() function, and so we should use that list as our starting point. Perhaps surprisingly, this change actually removes no code, because we still want the logic that enumerates endpoints and finds supported formats for endpoints. We need this because we must have at least one known sw format to initialise the hwframe_ctx with. Additionally, while in the general case, av_hwframe_transfer_get_formats can return different formats depending on what format you initialise the hwframe_ctx with, I happen to have read the libavutil code, and it doesn't care, so we just need to call it once, we know we'll get back all known formats. In practice, with an Intel vaapi driver, this will result in us supporting a handful of extra formats for hwuploads - particularly yuv420p (so no need to convert to nv12 first) and various orderings of rgb(a).
* vo_gpu_next: fix crash on uninit after startup failurercombs2022-10-141-1/+1
|
* vo_gpu/hwdec: rename and introduce legacy names for some interopsPhilip Langdale2022-10-116-11/+26
| | | | | | | | | | | | We've had some annoying names for interops, w