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 bc9b6358fb
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 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>
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).
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.
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>
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.
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.
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.
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.
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).
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>
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.
Fixes building with VAAPI but not libdrm, which was broken by
389f4c3e0d. Just unconditionally include
the header, since it doesn't depend on libdrm being present.
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.
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 e791b915c7)
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 3606602f11.
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>
The Intel binary iHD driver does not support the
VASurfaceAttribMemoryType, so surface allocation will fail when using
it.
(cherry picked from commit 2124711b95)
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.
(cherry picked from commit 121f34d5f0)
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.
(cherry picked from commit 4926fa9a4a)
* commit 'fe498ef5144d3712b887f44a0c5e654add99ead7':
hwcontext_vaapi: Return all formats for constraints without config
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
