aboutsummaryrefslogtreecommitdiffstats
path: root/libavutil/hwcontext.h
diff options
context:
space:
mode:
authorSoft Works <softworkz@hotmail.com>2021-11-25 02:41:32 +0000
committerHaihao Xiang <haihao.xiang@intel.com>2022-01-05 11:05:06 +0800
commita4289497755386435783774a4f520eb7fc23cbc9 (patch)
tree12508d3460f2f87b2729b6cf9bbc337066f5a526 /libavutil/hwcontext.h
parentdb28bb8fb46b5ef0554ac73c6ca741ca55e91451 (diff)
downloadffmpeg-a4289497755386435783774a4f520eb7fc23cbc9.tar.gz
avutils/hwcontext: When deriving a hwdevice, search for existing device in both directions
The test /libavutil/tests/hwdevice checks that when deriving a device from a source device and then deriving back to the type of the source device, the result is matching the original source device, i.e. the derivation mechanism doesn't create a new device in this case. Previously, this test was usually passed, but only due to two different kind of flaws: 1. The test covers only a single level of derivation (and back) It derives device Y from device X and then Y back to the type of X and checks whether the result matches X. What it doesn't check for, are longer chains of derivation like: CUDA1 > OpenCL2 > CUDA3 and then back to OpenCL4 In that case, the second derivation returns the first device (CUDA3 == CUDA1), but when deriving OpenCL4, hwcontext.c was creating a new OpenCL4 context instead of returning OpenCL2, because there was no link from CUDA1 to OpenCL2 (only backwards from OpenCL2 to CUDA1) If the test would check for two levels of derivation, it would have failed. This patch fixes those (yet untested) cases by introducing forward references (derived_device) in addition to the existing back references (source_device). 2. hwcontext_qsv didn't properly set the source_device In case of QSV, hwcontext_qsv creates a source context internally (vaapi, dxva2 or d3d11va) without calling av_hwdevice_ctx_create_derived and without setting source_device. This way, the hwcontext test ran successful, but what practically happened, was that - for example - deriving vaapi from qsv didn't return the original underlying vaapi device and a new one was created instead: Exactly what the test is intended to detect and prevent. It just couldn't do so, because the original device was hidden (= not set as the source_device of the QSV device). This patch properly makes these setting and fixes all derivation scenarios. (at a later stage, /libavutil/tests/hwdevice should be extended to check longer derivation chains as well) Reviewed-by: Lynne <dev@lynne.ee> Reviewed-by: Anton Khirnov <anton@khirnov.net> Tested-by: Wenbin Chen <wenbin.chen@intel.com> Signed-off-by: softworkz <softworkz@hotmail.com> Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Diffstat (limited to 'libavutil/hwcontext.h')
-rw-r--r--libavutil/hwcontext.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
index 04d19d89c2..0979fa2715 100644
--- a/libavutil/hwcontext.h
+++ b/libavutil/hwcontext.h
@@ -37,6 +37,7 @@ enum AVHWDeviceType {
AV_HWDEVICE_TYPE_OPENCL,
AV_HWDEVICE_TYPE_MEDIACODEC,
AV_HWDEVICE_TYPE_VULKAN,
+ AV_HWDEVICE_TYPE_NB, ///< number of hw device types, not part of API/ABI.
};
typedef struct AVHWDeviceInternal AVHWDeviceInternal;