summaryrefslogtreecommitdiff
path: root/libavutil/hwcontext_vaapi.c
Commit message (Collapse)AuthorAge
* avutil/buffer: Switch AVBuffer API to size_tAndreas Rheinhardt2021-04-27
| | | | | | | 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-10
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* hwcontext_vaapi: Don't require a render node when deriving from DRMMark Thompson2020-08-31
| | | | | | | | | | | | | 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-27
| | | | | | | | | | | | | | | | | | | | | | 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-27
|
* lavu/hwcontext_vaapi: add vaapi_format_map support for x2rgb10Fei Wang2020-06-12
| | | | Signed-off-by: Fei Wang <fei.w.wang@intel.com>
* hwcontext: add av_hwdevice_ctx_create_derived_optsLynne2020-05-23
| | | | | | | | | | | | | 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-24
| | | | | | | | | | | | | 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-24
| | | | | | | | | | | | | 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-11
| | | | | 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-02
| | | | | | | | 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-02
| | | | | | | 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-02
| | | | | | | | | | | | 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-02
| | | | Can be set to "drm" or "x11" to force a specific connection type.
* hwcontext_vaapi: Improve format mappingMark Thompson2018-09-23
| | | | | | | 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-23
| | | | | | | 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-24
| | | | | 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-10
| | | | | | | 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-27
| | | | 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-22
|
* hwcontext_vaapi: Add support for legacy DRM mappingMark Thompson2018-03-22
| | | | | | 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-18
| | | | | | 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-18
| | | | vaGetDisplayDRM() is required for this code to work, libdrm is not.
* hwcontext_vaapi: Fix frames context creation with external attributesMark Thompson2018-02-21
|
* hwcontext_vaapi: Add more surface formatsMark Thompson2018-02-21
| | | | 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-26
| | | | | | 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-20
| | | | | | | 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-12
| | | | | | vaExportSurfaceHandle() wasn't included in the 2.0 release. Fixes ticket #6828.
* hwcontext_vaapi: Add support for mapping to DRM objectsMark Thompson2017-10-09
| | | | Uses vaExportSurfaceHandle() from libva2.
* hwcontext_vaapi: Set message callbacks on internally-created devicesMark Thompson2017-10-09
| | | | | The message callbacks are library-safe in libva2, so we can now use them.
* hwcontext_vaapi: Factorise out common connection codeMark Thompson2017-10-09
| | | | | This was duplicated between normal device creation and creation by derivation from a DRM device.
* Merge commit 'fd9212f2edfe9b107c3c08ba2df5fd2cba5ab9e3'James Almer2017-09-26
|\ | | | | | | | | | | | | * commit 'fd9212f2edfe9b107c3c08ba2df5fd2cba5ab9e3': Mark some arrays that never change as const. Merged-by: James Almer <jamrial@gmail.com>
| * Mark some arrays that never change as const.Anton Khirnov2017-02-01
| |
| * hwcontext_vaapi: Don't abort on failing to allocate from a fixed-size poolMark Thompson2016-11-26
| |
* | hwcontext_vaapi: Fix DRM format mappingMark Thompson2017-09-19
| |
* | hwcontext_vaapi: Fix build failure with old libdrmJun Zhao2017-09-14
| | | | | | | | | | Signed-off-by: Jun Zhao <jun.zhao@intel.com> Signed-off-by: Mark Thompson <sw@jkqxz.net>
* | hwcontext_vaapi: Add DRM to VAAPI mappingMark Thompson2017-09-13
| |
* | hwcontext_vaapi: Try to support the VDPAU wrapperMark Thompson2017-06-14
| | | | | | | | | | | | | | | | | | | | The driver is somewhat bitrotten (not updated for years) but is still usable for decoding with this change. To support it, this adds a new driver quirk to indicate no support at all for surface attributes. Based on a patch by wm4 <nfxjfg@googlemail.com>. (cherry picked from commit e791b915c774408fbc0ec9e7270b021899e08ccc)
* | Merge commit '8ad9f9d675eab139aa2208722009eeed981460dd'Clément Bœsch2017-03-30
|\| | | | | | | | | | | | | * commit '8ad9f9d675eab139aa2208722009eeed981460dd': hwcontext_vaapi: Frame mapping support Merged-by: Clément Bœsch <cboesch@gopro.com>
| * hwcontext_vaapi: Frame mapping supportMark Thompson2016-11-03
| | | | | | | | | | Can map to any supported software format (using a GPU copy if it doesn't actually match the surface format underneath).
| * hwcontext_vaapi: Enable P010 supportMark Thompson2016-10-02
| | | | | | | | This is required for 10-bit surfaces.
| * hwcontext_vaapi: add a quirk for the missing MemoryType attributeAnton Khirnov2016-10-02
| | | | | | | | | | | | The Intel binary iHD driver does not support the VASurfaceAttribMemoryType, so surface allocation will fail when using it.
| * hwcontext_vaapi: Try the first render node as the default DRM deviceMark Thompson2016-08-13
| | | | | | | | | | | | | | | | | | | | If no string argument is supplied when av_hwdevice_ctx_create() is called to create a VAAPI device, we currently only try the default X11 display (that is, $DISPLAY) to find a device, and will therefore fail in the absence of an X server to connect to. Change the logic to also look for a device via the first DRM render node (that is, "/dev/dri/renderD128"), which is probably the right thing to use in most simple configurations which only have one DRM device.
| * hwcontext_vaapi: Add driver quirks to the hwdeviceMark Thompson2016-07-02
| | | | | | | | | | | | | | | | | | | | | | The driver being used is detected inside av_hwdevice_ctx_init() and the quirks field then set from a table of known device. If this behaviour is unwanted, the user can also set the quirks field manually. Also adds the Intel i965 driver quirk (it does not destroy parameter buffers used in a call to vaRenderPicture()) and detects that driver to set it.
* | hwcontext_vaapi: Don't abort on failing to allocate from a fixed-size poolMark Thompson2017-03-02
| | | | | | | | | | | | Cherry-picked from Libav d30719e62de68975cbc7ffd318df03a183037563. Signed-off-by: wm4 <nfxjfg@googlemail.com>
* | Revert "avutil/hwcontext_vaapi: fix SEGV in vaTerminate when vaInitialize fails"Mark Thompson2017-02-05
| | | | | | | | | | | | | | | | | | | | | | The original code is correctly following the API - vaTerminate() must be called to free the resources of a VADisplay after it is created by any of the vaGetDisplay*() calls; it is not necessary to have successfully called vaInitialize() on it. The segfaults which prompted this change must therefore be bugs in libva or the driver it loads. This reverts commit 3606602f1137552ea54f2c259eb140c1e3c026d4.
* | avutil/hwcontext_vaapi: fix SEGV in vaTerminate when vaInitialize failsAman Gupta2017-02-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000000000aff8a4 in vaTerminate () #1 0x0000000000ae50ce in vaapi_device_free (ctx=<optimized out>) at libavutil/hwcontext_vaapi.c:882 #2 0x0000000000ae1f9e in hwdevice_ctx_free (opaque=<optimized out>, data=<optimized out>) at libavutil/hwcontext.c:66 #3 0x0000000000ad856f in buffer_replace (src=0x0, dst=0x7fffa26ef1b8) at libavutil/buffer.c:119 #4 av_buffer_unref (buf=buf@entry=0x7fffa26ef1f8) at libavutil/buffer.c:129 #5 0x0000000000ae299f in av_hwdevice_ctx_create (pdevice_ref=0x170ac50 <hw_device_ctx>, type=type@entry=AV_HWDEVICE_TYPE_VAAPI, device=<optimized out>, opts=opts@entry=0x0, flags=flags@entry=0) at libavutil/hwcontext.c:494 #6 0x0000000000400968 in vaapi_device_init (device=<optimized out>) at ffmpeg_vaapi.c:223 Signed-off-by: Mark Thompson <sw@jkqxz.net>
* | Merge commit 'f62bb216ac4cfbbff16108c6bac35a0282532972'Hendrik Leppkes2016-11-13
|\| | | | | | | | | | | | | * commit 'f62bb216ac4cfbbff16108c6bac35a0282532972': hwcontext_vaapi: allow transfers to/from any size of sw frame Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
| * hwcontext_vaapi: allow transfers to/from any size of sw frameMark Thompson2016-06-28
| | | | | | | | | | | | | | | | The hw frame used as reference has an attached size but it need not match the actual size of the surface, so enforcing that the sw frame used in copying matches its size exactly is not useful. Signed-off-by: Anton Khirnov <anton@khirnov.net>
* | hwcontext_vaapi: add a quirk for the missing MemoryType attributeAnton Khirnov2016-11-13
| | | | | | | | | | | | | | | | The Intel binary iHD driver does not support the VASurfaceAttribMemoryType, so surface allocation will fail when using it. (cherry picked from commit 2124711b950b03c582a119c75f52a87acc32d6ec)
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-07 06:47:47 +0000