aboutsummaryrefslogtreecommitdiffstats
path: root/libavutil/hwcontext_vaapi.c
Commit message (Collapse)AuthorAgeFilesLines
* lavu/hwcontext_vaapi: Add option to allow to specify vendor id when init hw ↵Fei Wang2024-08-091-0/+29
| | | | | | | | | | device Vendor id will help to select desired device in case of kernel driver is unknow or unsupported, for vendor may support different kernel driver on different platforms. Signed-off-by: Fei Wang <fei.w.wang@intel.com>
* avutil/hwcontext_vaapi: use the correct type for ↵James Almer2024-08-011-1/+1
| | | | | | | | VASurfaceAttribExternalBuffers.buffers Should fix ticket #11115. Signed-off-by: James Almer <jamrial@gmail.com>
* lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffersDavid Rosca2024-04-291-0/+12
| | | | | This allows some optimizations in driver, such as not having to read back the data if write-only mapping is requested.
* avutil/hwcontext: Allocate AVHWFramesCtx jointly with its internalsAndreas Rheinhardt2024-03-071-3/+3
| | | | | | | | | | | This is possible because the lifetime of these structures coincide. It has the advantage of allowing to remove AVHWFramesInternal from the public header; given that AVHWFramesInternal.priv is no more, most accesses to AVHWFramesInternal are no more; indeed, the only field accessed of it outside of hwcontext.c is the internal frame pool, making this commit very simple. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avutil/hwcontext_vaapi: Allocate pub and priv frames hwctx togetherAndreas Rheinhardt2024-02-201-10/+14
| | | | | | | | | This is possible because the lifetime of both coincide. Besides reducing the number of allocations this also simplifies access to VAAPIFramesContext as one no longer has to go through AVHWFramesInternal. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avutil/hwcontext_vaapi: Allocate public and priv device hwctx togetherAndreas Rheinhardt2024-02-201-9/+13
| | | | | | | | | This is possible because the lifetime of both coincide. Besides reducing the number of allocations this also simplifies access to VAAPIDeviceContext as one no longer has to go through AVHWDeviceInternal. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* lavu/hwcontext_vaapi: ignore nonexistent device in default DRM device selectionHaihao Xiang2023-12-051-2/+13
| | | | | | | | | | It is possible that renderD128 doesn't exist but renderD129 is available in a system (see [1]). This change can make sure the default DRM device selection works even if renderD128 doesn't exist. [1] https://github.com/intel/intel-device-plugins-for-kubernetes/blob/main/cmd/gpu_plugin/README.md#issues-with-media-workloads-on-multi-gpu-setups Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* avutil/hwcontext_vaapi: return ENOSYS for unsupported operationZhao Zhili2023-10-291-3/+3
| | | | | | | | av_hwframe_transfer_data try with src_ctx first. If the operation failed with AVERROR(ENOSYS), it will try again with dst_ctx. Return AVERROR(EINVAL) makes the second step being skipped. Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
* lavu/hwcontext_vaapi: Add vaapi_drm_format_map support for x2rgb10David Rosca2023-08-171-0/+3
| | | | | Support for allocating frames with x2rgb10 format was added in c00264f5013, this adds support for importing DMA-BUFs.
* lavu/hwcontext_vaapi: Add Windows/VAAPI support with vaGetDisplayWin32Sil Vilerino2023-04-241-2/+76
| | | | | | | | | | | | Libva 2.17+ adds a new libva-win32 node and Mesa 22.3 adds a VAAPI driver based on Direct3D 12 for Windows. Both of them are available at: https://www.nuget.org/packages/Microsoft.Direct3D.VideoAccelerationCompatibilityPack Initial review at https://github.com/intel-media-ci/ffmpeg/pull/619/ Signed-off-by: Sil Vilerino <sivileri@microsoft.com> Reviewed-by: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Reviewed-by: Wu, Tong1 <tong1.wu@intel.com>
* lavu/hwcontext_vaapi: sync surface before export its DRM handleFei Wang2023-02-271-1/+10
| | | | | | | | | | According to description of vaExportSurfaceHandle in libva, vaSyncSurface must be called if the contents of the surface will be read. Fixes ticket #9967. Reviewed-by: Zhao Zhili <zhilizhao@tencent.com> Signed-off-by: Fei Wang <fei.w.wang@intel.com>
* lavu/hwcontext_vaapi: Skip 'vgem' driverBrian Norris2022-12-081-7/+22
| | | | | | | | | | | | | | | | | | | There can be more than one available render node, and it's not guaranteed the first node we come across is the correct one. In particular, 'vgem' devices are common, and are never VAAPI-enabled and thus not valid here. We have a 'kernel_driver' arg already for specifying a single driver we *do* want, but it doesn't support a negation, nor a list. It's easier just to automatically skip 'vgem' anyway, to avoid foisting this burden on users. This has precedent in libva-utils already: bfb6b98ed62a exclude vgem node and invalid drm node in vainfo https://github.com/intel/libva-utils/commit/bfb6b98ed62ac14a840ba62639ab902a23912258 Signed-off-by: Brian Norris <briannorris@chromium.org>
* lavu/hwcontext_vaapi: Fix type specifier for uintptr_tCarl Eugen Hoyos2022-10-231-1/+1
| | | | | Fixes a format specifier warning on x86_32 Linux. Fixes part of ticket #9986.
* lavc/vaapi: Add support for remaining 10/12bit profilesPhilip Langdale2022-09-031-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the necessary pixel formats defined, we can now expose support for the remaining 10/12bit combinations that VAAPI can handle. Specifically, we are adding support for: * HEVC ** 12bit 420 ** 10bit 422 ** 12bit 422 ** 10bit 444 ** 12bit 444 * VP9 ** 10bit 444 ** 12bit 444 These obviously require actual hardware support to be usable, but where that exists, it is now enabled. Note that unlike YUVA/YUVX, the Intel driver does not formally expose support for the alphaless formats XV30 and XV360, and so we are implicitly discarding the alpha from the decoder and passing undefined values for the alpha to the encoder. If a future encoder iteration was to actually do something with the alpha bits, we would need to use a formal alpha capable format or the encoder would need to explicitly accept the alphaless format.
* lavc/vaapi: Switch preferred 8bit 444 format to VUYXPhilip Langdale2022-08-251-1/+6
| | | | | | | | | As vaapi doesn't actually do anything useful with the alpha channel, and we have an alphaless format available, let's use that instead. The changes here are mostly 1:1 switching, but do note the explicit change in the number of declared channels from 4 to 3 to reflect that the alpha is being ignored.
* lavu/hwcontext_vaapi: Map the AYUV formatPhilip Langdale2022-08-031-0/+1
| | | | This is the format used by Intel VAAPI for 8bit 4:4:4 content.
* libavutil/hwcontext_vaapi: Re-enable support for libva v1Ingo Brückl2022-04-061-1/+56
| | | | | | | | | | | | | | | | Commit e050959103f375e6494937fa28ef2c4d2d15c9ef implemented passing in modifiers by using the PRIME_2 memory type, which only exists in v2 of the library. To still support v1 of the library, conditionally compile using VA_CHECK_VERSION() for both the new code and the old code before the commit. Note PRIME_2 memory was introduced from VA-API 1.1, so use VA_CHECK_VERSION(1, 1, 0) instead of VA_CHECK_VERSION(2, 0, 0) (Haihao) Signed-off-by: Ingo Brückl <ib@wupperonline.de> Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* libavutil/hwcontext_vaapi: Add a new nv12 format map to support vulkan frameWenbin Chen2021-12-101-0/+1
| | | | | | | Vulkan will map nv12 to R8 and GR88, so add this map to vaapi to support vulkan frame. Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
* hwcontext_vaapi: Use PRIME_2 memory type for modifiers.Bas Nieuwenhuizen2021-12-101-44/+114
| | | | | | | | | | | | | | | | | | | | | | | | | This way we can pass explicit modifiers in. Sometimes the modifier matters for the number of memory planes that libva accepts, in particular when dealing with driver-compressed textures. Furthermore the driver might not actually be able to determine the implicit modifier if all the buffer-passing has used explicit modifier. All these issues should be resolved by passing in the modifier, and for that we switch to using the PRIME_2 memory type. Tested with experimental radeonsi patches for modifiers and kmsgrab. Also tested with radeonsi without the patches to double-check it works without PRIME_2 support. v2: Cache PRIME_2 support to avoid doing two calls every time on libva drivers that do not support it. v3: Remove prime2_vas usage. Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
* avutil/buffer: Switch AVBuffer API to size_tAndreas Rheinhardt2021-04-271-1/+1
| | | | | | | Announced in 14040a1d913794d9a3fd6406a6d8c2f0e37e0062. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com> Signed-off-by: James Almer <jamrial@gmail.com>
* avutil: use the buffer_size_t typedef where requiredJames Almer2021-03-101-1/+1
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* hwcontext_vaapi: Don't require a render node when deriving from DRMMark Thompson2020-08-311-12/+16
| | | | | | | | | | | | | The V4L2 driver does not actually have an associated DRM device at all, so users work around the requirement by giving libva an unrelated display-only device instead (which is fine, because it doesn't actually do anything with that device). This was broken by bc9b6358fb7315c0173de322472641766f6289da forcing a render node, because the display-only device did not have an associated render node to use. Fix that by just passing through the original non-render DRM fd if we can't find a render node. Reported-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Tested-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
* hwcontext_vaapi: remove duplicate formats from sw_format listHaihao Xiang2020-07-271-5/+25
| | | | | | | | | | | | | | | | | | | | | | hwcontext_vaapi maps different VA fourcc to the same pix_fmt for U/V plane swap cases, however duplicate formats are not expected in sw_format list when merging formats. For example: ffmpeg -loglevel debug -init_hw_device vaapi -filter_hw_device vaapi0 \ -f lavfi -i smptebars -vf \ "hwupload=derive_device=vaapi,scale_vaapi,hwdownload,format=yuv420p" \ -vframes 1 -f null - Without this fix, an auto scaler is required for the above command Duplicate formats in ff_merge_formats detected [auto_scaler_0 @ 0x560df58f4550] Setting 'flags' to value 'bicubic' [auto_scaler_0 @ 0x560df58f4550] w:iw h:ih flags:'bicubic' interl:0 [Parsed_hwupload_0 @ 0x560df58f0ec0] auto-inserting filter 'auto_scaler_0' between the filter 'graph 0 input from stream 0:0' and the filter 'Parsed_hwupload_0' Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* hwcontext_vaapi: avoid fd leak in vaapi_device_deriveHaihao Xiang2020-07-271-1/+6
|
* lavu/hwcontext_vaapi: add vaapi_format_map support for x2rgb10Fei Wang2020-06-121-0/+3
| | | | Signed-off-by: Fei Wang <fei.w.wang@intel.com>
* hwcontext: add av_hwdevice_ctx_create_derived_optsLynne2020-05-231-1/+2
| | | | | | | | | | | | | This allows for users who derive devices to set options for the new device context they derive. The main use case of this is to allow users to enable extensions (such as surface drawing extensions) in Vulkan while deriving from the device their frames are on. That way, users don't need to write any initialization code themselves, since the Vulkan spec invalidates mixing instances, physical devices and active devices. Apart from Vulkan, other hwcontexts ignore the opts argument since they don't support options at all (or in VAAPI and OpenCL's case, options are currently only used for device selection, which device_derive overrides).
* hwcontext_vaapi: Only accept a render node when deriving from DRM deviceMark Thompson2020-02-241-3/+43
| | | | | | | | | | | | | If we are given a non-render node, try to find the matching render node and fail if that isn't possible. libva will not accept a non-render device which is not DRM master, because it requires legacy DRM authentication to succeed in that case: <https://github.com/intel/libva/blob/master/va/drm/va_drm.c#L68-L75>. This is annoying for kmsgrab because in most recording situations DRM master is already held by something else (such as a windowing system), leading to device derivation not working and forcing the user to create the target VAAPI device separately.
* lavu/hwcontext_vaapi: add vaapi_format_map support for Y210Linjie Fu2020-02-241-0/+3
| | | | | | | | | | | | | VA_RT_FORMAT describes the desired sampling format for surface. When creating surface, VA_RT_FORMAT will be used firstly to choose the expected fourcc/media_format for the surface. And the fourcc will be revised by the value of VASurfaceAttribPixelFormat. Add vaapi_format_map support for new pixel_format Y210. This is fundamental for both VA-API and QSV. Signed-off-by: Linjie Fu <linjie.fu@intel.com>
* avutil/hwcontext_vaapi: move kernel_driver into CONFIG_LIBDRMSteven Liu2019-07-111-1/+3
| | | | | Reviewed-by: Zhong Li <zhong.li@intel.com> Signed-off-by: Steven Liu <lq@onvideo.cn>
* hwcontext_vaapi: Try to create devices via DRM before X11Mark Thompson2019-06-021-21/+21
| | | | | | | | Opening the device via X11 (DRI2/DRI3) rather than opening a DRM render node directly is only useful if you intend to use the legacy X11 interop functions. That's never true for the ffmpeg utility, and a library user who does want this will likely provide their own display instance rather than making a new one here.
* hwcontext_vaapi: Add option to set driver nameMark Thompson2019-06-021-0/+17
| | | | | | | For example: -init_hw_device vaapi:/dev/dri/renderD128,driver=foo This may be more convenient that using the environment variable, and allows loading different drivers for different devices in the same process.
* hwcontext_vaapi: Make default DRM device selection more helpfulMark Thompson2019-06-021-16/+60
| | | | | | | | | | | | Iterate over available render devices and pick the first one which looks usable. Adds an option to specify the name of the kernel driver associated with the desired device, so that it is possible to select a specific type of device in a multiple-device system without knowing the card numbering. For example: -init_hw_device vaapi:,kernel_driver=amdgpu will select only devices using the "amdgpu" driver (as used with recent AMD graphics cards). Kernel driver selection requires libdrm to work.
* hwcontext_vaapi: Add option to specify connection typeMark Thompson2019-06-021-4/+28
| | | | Can be set to "drm" or "x11" to force a specific connection type.
* hwcontext_vaapi: Improve format mappingMark Thompson2018-09-231-57/+76
| | | | | | | Give the entries in the VAAPI format map table an explicit type and add functions to do the necessary lookups. Add another field to this table indicating whether the chroma planes are swapped (as in YV12), and use that rather than explicit comparisons where swapping is needed.
* hwcontext_vaapi: Improve logging around quirk detectionMark Thompson2018-09-231-8/+19
| | | | | | | Clarify that the list is the naughty list, and therefore being on it is not desirable. The i965 driver does not need to be on the list after version 2.0 (when the standard parameter buffer rendering behaviour was changed).
* hwcontext_vaapi: Fix mapping from DRMMark Thompson2018-05-241-1/+3
| | | | | This was broken by bed670a1de29b58fcb3fe046562d8bd125b1457f, which added an assert that always failed.
* hwcontext_vaapi: Add an assert in vaapi_map_from_drm()Haihao Xiang2018-05-101-0/+2
| | | | | | | Every fourcc in vaapi_drm_format_map should be in vaapi_format_map, so add an assert to ensure we have the right maps. Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* hwcontext_vaapi: Fix compilation with libva versions < 1.4.0Mark Thompson2018-04-271-0/+5
| | | | The BufferHandle API was added in libva 1.4.0 / VAAPI 0.36.0.
* hwcontext_vaapi: Pass correct read/write flags when exporting surfacesMark Thompson2018-03-221-3/+8
|
* hwcontext_vaapi: Add support for legacy DRM mappingMark Thompson2018-03-221-12/+182
| | | | | | The old vaAcquireBufferHandle() API works in fewer cases and provides less information than the current vaExportSurfaceHandle(), but it exists on older versions and is already used by the OpenCL code.
* hwcontext_vaapi: Always include DRM hwcontext headerMark Thompson2018-03-181-3/+1
| | | | | | Fixes building with VAAPI but not libdrm, which was broken by 389f4c3e0d0a26a7d3d2696017384874cf5e93fa. Just unconditionally include the header, since it doesn't depend on libdrm being present.
* hwcontext_vaapi: Fix condition for DRM device derivationMark Thompson2018-03-181-1/+1
| | | | vaGetDisplayDRM() is required for this code to work, libdrm is not.
* hwcontext_vaapi: Fix frames context creation with external attributesMark Thompson2018-02-211-2/+2
|
* hwcontext_vaapi: Add more surface formatsMark Thompson2018-02-211-0/+3
| | | | Adds YUV 4:1:1, 4:4:0 and 4:4:4 - these will be needed for JPEG decoding.
* hwcontext_vaapi: Do not assume that sw_format is transferableMark Thompson2017-11-261-7/+14
| | | | | | Drivers can support a format for surfaces without also supporting it for images, so we can't assume that sw_format is usable for transfer. This would previously hit an assert in cases where it isn't.
* hwcontext_vaapi: add the fourcc of I420 format map.Jun Zhao2017-11-201-1/+3
| | | | | | | VA-API 2.0 have enable the I420, so enable this map. Signed-off-by: Jun Zhao <jun.zhao@intel.com> Signed-off-by: Mark Thompson <sw@jkqxz.net>
* hwcontext_vaapi: Fix build with libva 2.0Mark Thompson2017-11-121-1/+1
| | | | | | vaExportSurfaceHandle() wasn't included in the 2.0 release. Fixes ticket #6828.
* hwcontext_vaapi: Add support for mapping to DRM objectsMark Thompson2017-10-091-2/+106
| | | | Uses vaExportSurfaceHandle() from libva2.
* hwcontext_vaapi: Set message callbacks on internally-created devicesMark Thompson2017-10-091-0/+21
| | | | | The message callbacks are library-safe in libva2, so we can now use them.
* hwcontext_vaapi: Factorise out common connection codeMark Thompson2017-10-091-29/+24
| | | | | This was duplicated between normal device creation and creation by derivation from a DRM device.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 09:49:35 +0000