Age | Commit message (Collapse) | Author |
|
Reviewed-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Steven Liu <lq@onvideo.cn>
|
|
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.
|
|
Can be set to "drm" or "x11" to force a specific connection type.
|
|
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).
|
|
This was broken by bed670a1de29b58fcb3fe046562d8bd125b1457f, which added
an assert that always failed.
|
|
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 BufferHandle API was added in libva 1.4.0 / VAAPI 0.36.0.
|
|
|
|
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
389f4c3e0d0a26a7d3d2696017384874cf5e93fa. Just unconditionally include
the header, since it doesn't depend on libdrm being present.
|
|
vaGetDisplayDRM() is required for this code to work, libdrm is not.
|
|
|
|
Adds YUV 4:1:1, 4:4:0 and 4:4:4 - these will be needed for JPEG decoding.
|
|
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.
|
|
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>
|
|
vaExportSurfaceHandle() wasn't included in the 2.0 release.
Fixes ticket #6828.
|
|
Uses vaExportSurfaceHandle() from libva2.
|
|
The message callbacks are library-safe in libva2, so we can now use
them.
|
|
This was duplicated between normal device creation and creation by
derivation from a DRM device.
|
|
* commit 'fd9212f2edfe9b107c3c08ba2df5fd2cba5ab9e3':
Mark some arrays that never change as const.
Merged-by: James Almer <jamrial@gmail.com>
|
|
|
|
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
|
|
|
|
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)
|
|
* commit '8ad9f9d675eab139aa2208722009eeed981460dd':
hwcontext_vaapi: Frame mapping support
Merged-by: Clément Bœsch <cboesch@gopro.com>
|
|
Cherry-picked from Libav d30719e62de68975cbc7ffd318df03a183037563.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
|
|
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.
|
|
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>
|
|
|
|
|
|
* commit 'f62bb216ac4cfbbff16108c6bac35a0282532972':
hwcontext_vaapi: allow transfers to/from any size of sw frame
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
|
The Intel binary iHD driver does not support the
VASurfaceAttribMemoryType, so surface allocation will fail when using
it.
(cherry picked from commit 2124711b950b03c582a119c75f52a87acc32d6ec)
|
|
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 121f34d5f0c8d7d376829a467590fbbe4c228f4f)
|
|
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 4926fa9a4aa03f3b751f52e900b9efb87fea0591)
|
|
Can map to any supported software format (using a GPU copy if it
doesn't actually match the surface format underneath).
|
|
* commit 'fe498ef5144d3712b887f44a0c5e654add99ead7':
hwcontext_vaapi: Return all formats for constraints without config
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
|
This is required for 10-bit surfaces.
|
|
The Intel binary iHD driver does not support the
VASurfaceAttribMemoryType, so surface allocation will fail when using
it.
|
|
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.
|
|
Fixes ticket #5484.
|
|
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.
|
|
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>
|
|
* commit 'b8bf9194af602cf3a4bcd19a5e278e3d6d69f8fa':
hwcontext_vaapi: implement device creation
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
|
No longer make a dummy device configuration to query. Instead, just
return everything we recognise from the whole format list. Also
change the device setup code to query that list only, rather than
intersecting it with the constraint output.
This makes hwupload more usable on mesa/gallium where the video
processor only declares support for RGB formats, making it unable to
deal with YUV formats before this patch. It might introduce some
different trickier failures in the internal upload/download code
because the set of allowed formats there has changed, though I didn't
find any obvious regressions with i965.
|
|
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
* commit '551c6775abb5e0ad34c26d7e23bc6fbbe8ccc9d4':
lavu: VAAPI hwcontext implementation
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|