-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add derive-device function which searches for existing devices in both directions #25
base: master
Are you sure you want to change the base?
Conversation
/submit |
Submitted as pull.25.ffstaging.FFmpeg.1651349262.ffmpegagent@gmail.com To fetch this version into
To fetch this version to local tag
|
User |
User |
/submit |
Submitted as pull.25.v2.ffstaging.FFmpeg.1653142062.ffmpegagent@gmail.com To fetch this version into
To fetch this version to local tag
|
This allows to create AVBufferRef from AVBuffer directly. Signed-off-by: softworkz <softworkz@hotmail.com>
…ting devices 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) Signed-off-by: softworkz <softworkz@hotmail.com>
…_ctx_get_or_create_derived() Signed-off-by: softworkz <softworkz@hotmail.com>
…d method Signed-off-by: softworkz <softworkz@hotmail.com>
97d2792
to
7ee28b7
Compare
/submit |
Submitted as pull.25.v3.ffstaging.FFmpeg.1658446783.ffmpegagent@gmail.com To fetch this version into
To fetch this version to local tag
|
On the FFmpeg mailing list, Soft Works wrote (reply to this):
|
This is an updated version of:
[PATCH v4 1/1] avutils/hwcontext: When deriving a hwdevice, search for
existing device in both directions
There has been an objection that the earlier patchset would change
API behavior, and that this change should be limited to ffmpeg cli.
To achieve this, the API behavior is left unchanged now and a new
function av_hwdevice_ctx_get_or_create_derived() is added and
used by the hwupload and hwmap filters.
v2: Implemented concept for "weak references" to avoid circular
reference lockup.
v3: rebased due to conflicts
cc: Mark Thompson sw@jkqxz.net
cc: Soft Works softworkz@hotmail.com