Add derive-device function which searches for existing devices in both directions #25
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
/submit |
|
Submitted as pull.25.ffstaging.FFmpeg.1651349262.ffmpegagent@gmail.com To fetch this version into To fetch this version to local tag |
![ffmpeg-codebot[bot]](https://avatars.githubusercontent.com/in/158557?s=60&v=4){kind=small}
|
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>
softworkz
force-pushed
the
derive_devices
branch
from
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): |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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