summaryrefslogtreecommitdiffstats
path: root/video/out/hwdec
Commit message (Collapse)AuthorAgeFilesLines
* various: drop unused #include "config.h"Thomas Weißschuh2023-02-205-5/+0
| | | | | | Most sources don't need config.h. The inclusion only leads to lots of unneeded recompilation if the configuration is changed.
* vo_dmabuf_wayland: reject hw formats not supported by compositorAaron Boxer2023-02-114-6/+35
|
* hwdec_cuda: fix enum type for semaphoreKacper Michajłow2023-02-021-4/+4
|
* hwdec/vaapi: zero-initialize VADRMPRIMESurfaceDescriptorDudemanguy2023-01-301-1/+1
| | | | | Otherwise, desc can contain garbage values and segfault trying to close file descriptors that aren't actually there. Fixes #11239.
* hwdec_vaapi: close file descriptors even if surface export failsAaron Boxer2023-01-281-0/+7
| | | | otherwise they can leak
* drm: rewrite based around vo_drm_stateDudemanguy2023-01-212-3/+4
| | | | | | | | | | | A longstanding pain point of the drm VOs is the relative lack of state sharing. While drm_common does provide some sharing, it's far less than other platforms like x11 or wayland. What we do here is essentially copy them by creating a new vo_drm_state struct and using it in vo_drm and context_drm_egl. Much of the functionality that was essentially duplicated in both VOs/contexts is now reduced simple functions in drm_common. The usage of the term 'kms' was also mostly eliminated since this is libdrm nowadays from a userspace perspective.
* 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.
* 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
|
* 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>
* vo: hwdec: remove legacy_namesPhilip Langdale2022-11-153-3/+0
| | | | | These were introduced for configuration compatibility in 0.35 but we don't want to retain them past that point.
* 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
* vo_dmabuf_wayland: wayland VO displaying dmabuf buffersAaron Boxer2022-10-264-4/+75
| | | | | | | | | | | | | 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
* 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/hwdec: rename and introduce legacy names for some interopsPhilip Langdale2022-10-113-3/+327
| | | | | | | | | | | | We've had some annoying names for interops, which we can't simply rename because that would break config files and command lines. So we need to put a little more effort in and add a concept of legacy names that allow us to continue loading them, but with a warning. The two I'm renaming here are: * vaapi-egl -> vaapi (vaapi works with Vulkan too) * drmprime-drm -> drmprime-overlay (actually describes what it does) * cuda-nvdec -> cuda (cuda interop is not nvdec specific)
* vo: hwdec_aimagereader: add missing image format specifiersfan52022-10-031-0/+1
| | | | This is required since e50db4292795de511531e764d7e609c1a37a204f, but was missed during the merge.
* vo_gpu: hwdec: add Android hwdec utilizing AImageReadersfan52022-10-021-0/+396
|
* vo: hwdec: do hwdec interop lookup by image formatPhilip Langdale2022-09-211-0/+1
| | | | | | | | | | | | | | It turns out that it's generally more useful to look up hwdecs by image format, rather than device type. In the situations where we need to find one, we generally know the image format we're dealing with. Doing this avoids us having to create mappings from image format to device type. The most significant part of this change is filling in the image format for the various hw interops. There is a hw_imgfmt field today today, but only a couple of the interops fill it in, and that seems to be because we've never actually used this piece of metadata before. Well, now we have a good use for it.
* hwdec/drmprime: fix buildPhilip Langdale2022-08-091-1/+1
| | | | I accidentally included an adjustment for a pending change.
* hwdec/dmabuf_interop: Properly prefix `priv` structPhilip Langdale2022-08-095-14/+14
| | | | | Obviously, this should be dmabuf_interop_priv as it's declared in a header file that could get included anywhere.
* hwdec/drmprime: Fix small issuesPhilip Langdale2022-08-091-6/+21
| | | | | | | | sfan5 found a few things after I pushed the change, so this fixes them. * Use-after-free on drm_device_Path * Not comparing render_fd against -1 * Not handling dup() errors
* hwdec/drmprime: add drmprime hwdec-interopPhilip Langdale2022-08-091-0/+261
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the confusing landscape of hardware video decoding APIs, we have had a long standing support gap for the v4l2 based APIs implemented for the various SoCs from Rockship, Amlogic, Allwinner, etc. While VAAPI is the defacto default for desktop GPUs, the developers who work on these SoCs (who are not the vendors!) have preferred to implement kernel APIs rather than maintain a userspace driver as VAAPI would require. While there are two v4l2 APIs (m2m and requests), and multiple forks of ffmpeg where support for those APIs languishes without reaching upstream, we can at least say that these APIs export frames as DRMPrime dmabufs, and that they use the ffmpeg drm hwcontext. With those two constants, it is possible for us to write a hwdec-interop without worrying about the mess underneath - for the most part. Accordingly, this change implements a hwdec-interop for any decoder that produces frames as DRMPrime dmabufs. The bulk of the heavy lifting is done by the dmabuf interop code we already had from supporting vaapi, and which I refactored for reusability in a previous set of changes. When we combine that with the fact that we can't probe for supported formats, the new code in this change is pretty simple. This change also includes the hwcontext_fns that are required for us to be able to configure the hwcontext used by `hwdec=drm-copy`. This is technically unrelated, but it seemed a good time to fill this gap. From a testing perspective, I have directly tested on a RockPRO64, while others have tested with different flavours of Rockchip and on Amlogic, providing m2m coverage. I have some other SoCs that I need to spin up to test with, but I don't expect big surprises, and when we inevitably need to account for new special cases down the line, we can do so - we won't be able to support every possible configuration blindly.
* hwdec/dmabuf_interop_gl: support basic multi-plane formatsPhilip Langdale2022-08-031-38/+53
| | | | | | | | | | | | | | | | | I already added the equivalent logic for dmabuf_interop_pl previously but I skipped the GL support because importing dmabufs into GL requires explicitly providing the DRM format, and if you are taking a multi-plane format and trying to treat each plane as a separate layer, you need to come up with a DRM format for each synthetic layer. But my initial testing has shown that the RockPRO64 board I've got to work on drmprime hwdec will only produce NV12 in a single layer multi plane format, and it doesn't have Vulkan support, so I have had to tackle the GL multi-plane problem. To that end, this change introduces the infrastructure to provide new formats for synthetic layers. We only have lookup code for NV12 and P010 as these were the only ones I could test.
* hwdec/dmabuf_interop: use AVDRMFrameDescriptor to describe dmabufsPhilip Langdale2022-08-034-27/+46
| | | | | | | | | | | | Annoyingly, libva and libdrm use different structs to describe dmabufs and if we are going to support drmprime, we must pick one format and do some shuffling in the other case. I've decided to use AVDRMFrameDescriptor as our internal format as this removes the libva dependency from dmabuf_interop. That means that the future drmprime hwdec will be able to populate it directly and the existing hwdec_vaapi needs to copy the struct members around, but that's cheap and not a concern.
* hwdec/dmabuf_interop: refactor out hwdec_vaapi dependenciesPhilip Langdale2022-08-034-39/+53
| | | | | | With the files renamed, we can now disentangle the shared private struct between the interops and hwdec_vaapi. We need this separation to allow the future drmprime hwdec to use the interops.
* hwdec/vaapi: rename interops to reflect more general usePhilip Langdale2022-08-034-11/+11
| | | | | | | | | | | This is the first in a series of changes that will introduce a drmprime hwdec. As our vaapi hwdec is based around exporting surfaces as drmprime dmabufs, we've actually got a lot of useful code already in place in the GL/PL interops. I'm going to reorganise and adjust this code to make the interops usable with the new hwdec as well. The first step is to rename the files and functions. There are no functional or other changes here. They will come next.
* hwdec_vaapi_pl: support simple multi-plane image formatsPhilip Langdale2022-07-233-11/+31
| | | | | | | | | | | | | | | | | This is somewhat academic for now, as we explicitly ask for separate layers and the scenarios where multi-plane images are required also use complex formats that cannot be decomposed after the fact, but nevertheless it is possible for us to consume simple multi-plane images where there is one layer with n planes instead of n layers with one plane each. In these cases, we just treat the planes the same as we would if they were each in a separate layer and everything works out. It ought to be possible to make this work for OpenGL but I couldn't wrap my head around how to provide the right DRM fourcc when pretending a plane is a layer by itself. So I've left that unimplemented.
* vo_gpu[_next]: hwdec: fix logging regression when probingPhilip Langdale2022-03-211-3/+5
| | | | | | | | | When I introduced the concept of lazy loading of hwdecs by img format, I did not propagate the probing flag correctly, leading to the new normal loading path not runnng with probing set, meaning that any errors would show up, creating unnecessary noise. This change fixes this regression.
* vo_gpu: hwdec_vaapi: Improve logging when probing surface formatsPhilip Langdale2022-03-102-4/+25
| | | | | | | | | | | Our logging here today is very poor. We don't make it clear what formats we are probing, or even that a certain format failed in most cases. In the case where we do log the error, we don't make it clear which format it was that failed. The end result is that we have no idea what the possible and final format spaces are, which makes it very hard to debug whether things are working correctly, or to work on supporting additional formats.
* hwdec: release images as soon as possible after mappingNiklas Haas2022-03-031-4/+10
| | | | | | | | | | We don't need to hold on to buffers longer than necessary. Doesn't matter for vo_gpu but greatly matters for vo_gpu_next, since it persists hwdec mapped textures for longer periods. Unfortunately, only provides benefits for hwdecs which do explicit copies in their decode path, which currently just means cuda and d3d11va.
* hwdec_vaapi_vk: rename to vaapi_plNiklas Haas2022-03-033-13/+12
| | | | | | | | There's really nothing vulkan-specific about this hwdec wrapper, and it actually works perfectly fine with an OpenGL-based ra_pl. This is not hugely important at the time, but I still think it makes sense in case we ever decide to make vo_gpu_next wrap OpenGL contexts to ra_pl instead of exposing the underlying ra_gl.
* hwdec_vaapi_gl: properly zero initialize priv structNiklas Haas2022-03-031-6/+8
| | | | | | | | | Easiest way is by just using a designated struct initializer. If we don't, `p->images` ends up inheriting random data, which leaks into e.g. eglDestroyImageKHR. It's a small miracle this never blew up before. Or maybe it did. Who knows.
* 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 v4 naming conventionNiklas Haas2022-02-032-10/+8
| | | | | All of these const struct pointers got typedefs, clean up the code accordingly.
* libplacebo: update log helpersNiklas Haas2022-02-031-4/+3
| | | | | Use the pl_log APIs introduced in libplacebo v4, replacing the deprecated pl_context concept.
* vo_gpu: hwdec_vaapi: avoid drm_fourcc.h dependencyDave Airlie2021-11-251-1/+4
| | | | Suggested by haasn
* vo_gpu: hwdec_vaapi: add dma-buf modifiers support.Dave Airlie2021-11-232-1/+20
| | | | | If the EGL extension is present, pass the modifiers for each plane to the EGL driver.
* vo_gpu: libplacebo: drop conditional code paths for old versionsNiklas Haas2021-10-041-11/+1
| | | | No longer needed with the bump to v3.104.
* vo_gpu: libplacebo: drop code deprecated in libplacebo v3Niklas Haas2021-10-042-4/+0
| | | | | This is only needed for back-compat with libplacebo v2, and will break due to upstream removal starting with libplacebo v4.
* vo_gpu: hwdec_vaapi: silence errors while probingNiklas Haas2021-05-194-4/+7
| | | | | Silences warnings related to DRM format modifiers that can show up while probing formats.
* vo_gpu: vaapi: export plane pitch properlyNiklas Haas2021-02-121-0/+4
|
* vo_gpu: hwdec_vaapi: handle lack of object size with AMD driversPhilip Langdale2020-07-141-0/+26
| | | | | | | | | | | | | It turns out that the AMD driver doesn't bother to set the size field in the descriptor for an exported VA surface. I guess they assume the caller can always use lseek() and don't bother. So, we need to use lseek() in these situations. Modified-by: Niklas Haas <git@haasn.xyz> Guarded this behind PL_API_VER >= 88 to prevent it from exploding on older libplacebo versions, where vaapi support does not yet work properly on AMD due to lack of DRM modifiers.
* vo_gpu: hwdec_vaapi: add support for DRM format modifiersNiklas Haas2020-07-141-2/+5
| | | | | This is required to get non-corrupted textures when importing vaapi planes on AMD drivers.
* vo_gpu: hwdec_vaapi: set correct hw_imgfmt valuewm42020-01-171-0/+1
| | | | | | | As documented on struct mp_hwdec_ctx, hw_imgfmt specifies the hardware surface wrapper format for which supported_formats is valid. If this was not set, f_hwtransfer ignored supported_formats, and assumed all formats were supported.
* vaapi: reduce log levels furtherwm42020-01-111-7/+10
| | | | | Try to exclude mostly uninteresting information from verbose logging, but still include it in debug logging.
* vo_gpu: hwdec_vaapi: silence warning during probingwm42020-01-111-1/+4
| | | | | | | | | | | | | | hwdec_vaapi tries to probe all available surface formats in advance. For that, we iterate over _all_ profiles in an attempt to collect possible surface formats. This means we try profiles we normally wouldn't use for decoding or filtering, and which could be "unrelated" services. It seems some drivers report at least one profile, for which vaQueryConfigEntrypoints() fails (because the profile is not supported; not sure why it lists it, then). So turn the error message into a verbose message to avoid confusing output. Fixes: #7347
* vo_gpu: hwdec_vaegl: remove support for old-style interopPhilip Langdale2019-12-283-128/+5
| | | | | | | | | | | | | In vaapi 1.1.0 (which confusingly is libva release 2.1.0), they introduced a new surface export API that is more efficient, and we've been supporting that and the old API ever since (Feb 2018). If we drop support for the old API, we can do some fairly nice cleanup of the code. Note that the pkgconfig entries are explicitly versioned by the API version and not the library version. I confirmed the upstream pkgconfig files.
* vo_gpu: hwdec_vaapi_gl: use gl_check_extension() instead of strstr()wm42019-12-071-3/+3
| | | | | | | | | | | | In theory, using strstr() to search for extensions is a bad idea, because some extension names might be prefixes for other names, so you could get false positives. gl_check_extension() avoids this case. It's not clear whether this is really needed; maybe not. Surely the EGL committee is aware of these practices (many GL clients do this, which is why it's widely considered bad practice), and would avoid defining new extension names which contain existing names as sub-strings, but whatever.
* vo_gpu: hwdec_vaapi_gl: do not include eglext.hwm42019-12-071-9/+0
| | | | | | | Adding an ifdef mess to deal with insufficient system headers is kind of a mess. It's easier to just provide the definitions manually. This sucks a bit too, but it's the approach we've been using with OpenGL headers in general, and I think that worked pretty well.
* vo_gpu: hwdec_vaapi_gl: add missing PLANE3 defines as wellwm42019-12-071-0/+8
| | | | | | | | | | | | On systems whose EGL headers do not define these extensions, the build still failed due to missing ..._PLANE3_... defines. Although we supplied missing EGL_LINUX_DMA_BUF_EXT defines manually, the PLANE3 ones are actually from a separate extension, which explains why they were not added to the fallback defines in the first place. Add them, now it builds without the eglext.h include. See #6838.
* vo_gpu: hwdec_cuda: Reduce message level of errors while probingPhilip Langdale2019-11-172-5/+7
| | | | | | We should only be printing errors that occur when not probing, to avoid creating the impression that something is wrong - and errors during probing isn't a problem.
* build: fix compilation conditions for vaapi interop initsPhilip Sequeira2019-11-101-2/+2
| | | | | | | | | This makes the condition for including each init match the condition for compiling the file that defines it. It's possible to e.g. HAVE_GL and HAVE_VAAPI without HAVE_VAAPI_EGL, which resulted in "undefined reference to `vaapi_gl_init'" with the old code.
* vo_gpu: hw