| Age | Commit message (Collapse) | Author |
|---|
|
Clear anything that av_hwframe_map() might have done to the destination
frame, but leave caller-provided fields unchanged.
|
|
device in both directions"
This reverts commit a4289497755386435783774a4f520eb7fc23cbc9.
There were objections on ML (see
https://ffmpeg.org/pipermail/ffmpeg-devel/2021-December/290530.html)
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
|
|
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>
|
|
They do the same.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.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).
|
|
Use 0, which selects the alignment automatically.
|
|
|
|
This commit adds the necessary code to initialize and use a Vulkan device
within the hwcontext libavutil framework.
Currently direct mapping to VAAPI and DRM frames is functional, and
transfers to CUDA and native frames are supported.
Lets hope the future Vulkan video decode extension fits well within this
framework.
|
|
We are beginning to consider scenarios where a given HW Context
may be able to transfer frames to another HW Context without
passing via system memory - this would usually be when two
contexts represent different APIs on the same device (eg: Vulkan
and CUDA).
This is modelled as a transfer, as we have today, but where both
the src and the dst are hardware frames with hw contexts. We need
to be careful to ensure the contexts are compatible - particularly,
we cannot do transfers where one of the frames has been mapped via
a derived frames context - we can only do transfers for frames that
were directly allocated by the specified context.
Additionally, as we have two hardware contexts, the transfer function
could be implemented by either (or indeed both). To handle this
uncertainty, we explicitly look for ENOSYS as an indicator to try
the transfer in the other direction before giving up.
|
|
Used to fix unmapping when no direct interop exists between APIs.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
|
|
The change in 309d660775e2b47af6723a0477c4d753bc0c54f4 to call device_init
when doing derivation missed this case - we should only call it if we
actually made a new device.
|
|
* commit '2eb396b175e55e515aa6a13c5b1789a2a18d3935':
hwcontext: Fix memory leak on derived frame allocation failure
Merged-by: James Almer <jamrial@gmail.com>
|
|
|
|
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>
|
|
|
|
|
|
* commit '1bd986ed4b0e95ded368a8eeb5c044853c090f9b':
hwcontext: Move NONE to the be the first member of AVHWDeviceType
Merged-by: James Almer <jamrial@gmail.com>
|
|
The initialisation should be common. For libmfx, it was previously
happening in the derivation function and this moves it out. For VAAPI,
it fixes some failures when deriving from a DRM device because this
initialisation did not run.
|
|
* commit 'fd9212f2edfe9b107c3c08ba2df5fd2cba5ab9e3':
Mark some arrays that never change as const.
Merged-by: James Almer <jamrial@gmail.com>
|
|
|
|
To be used with the new d3d11 hwaccel decode API.
With the new hwaccel API, we don't want surfaces to depend on the
decoder (other than the required dimension and format). The old D3D11VA
pixfmt uses ID3D11VideoDecoderOutputView pointers, which include the
decoder configuration, and thus is incompatible with the new hwaccel
API. This patch introduces AV_PIX_FMT_D3D11, which uses ID3D11Texture2D
and an index. It's simpler and compatible with the new hwaccel API.
The introduced hwcontext supports only the new pixfmt.
Frame upload code untested.
Significantly based on work by Steve Lhomme <robux4@gmail.com>, but with
heavy changes/rewrites.
Merges Libav commit fff90422d181744cd75dbf011687ee7095f02875.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|
|
|
Use the flags argument of av_hwframe_ctx_create_derived() to pass the
mapping flags which will be used on allocation. Also, set the format
and hardware context on the allocated frame automatically - the user
should not be required to do this themselves.
(cherry picked from commit c5714b51aad41fef56dddac1d542e7fc6b984627)
|
|
Some frames contexts are not usable without additional format-specific
state in hwctx. This change adds new functions frames_derive_from and
frames_derive_to to initialise this state appropriately when deriving
a frames context which will require it to be set.
(cherry picked from commit 27978155bc661eec9f22bcf82c9cfc099cff4365)
|
|
Adds functions to convert to/from strings and a function to iterate
over all supported device types. Also adds a new invalid type
AV_HWDEVICE_TYPE_NONE, which acts as a sentinel value.
(cherry picked from commit b7487f4f3c39b4b202e1ea7bb2de13902f2dee45)
|
|
Creates a new device context from another of a different type which
refers to the same underlying hardware.
(cherry picked from commit b266ad56fe0e4ce5bb70118ba2e2b1dabfaf76ce)
|
|
To be used with the new d3d11 hwaccel decode API.
With the new hwaccel API, we don't want surfaces to depend on the
decoder (other than the required dimension and format). The old D3D11VA
pixfmt uses ID3D11VideoDecoderOutputView pointers, which include the
decoder configuration, and thus is incompatible with the new hwaccel
API. This patch introduces AV_PIX_FMT_D3D11, which uses ID3D11Texture2D
and an index. It's simpler and compatible with the new hwaccel API.
The introduced hwcontext supports only the new pixfmt.
Frame upload code untested.
Significantly based on work by Steve Lhomme <robux4@gmail.com>, but with
heavy changes/rewrites.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|
This adds tons of code for no other benefit than making VideoToolbox
support conform with the new hwaccel API (using hw_device_ctx and
hw_frames_ctx).
Since VideoToolbox decoding does not actually require the user to
allocate frames, the new code does mostly nothing.
One benefit is that ffmpeg_videotoolbox.c can be dropped once generic
hwaccel support for ffmpeg.c is merged from Libav.
Does not consider VDA or VideoToolbox encoding.
Fun fact: the frame transfer functions are copied from vaapi, as the
mapping makes copying generic boilerplate. Mapping itself is not
exported by the VT code, because I don't know how to test.
|
|
Use the flags argument of av_hwframe_ctx_create_derived() to pass the
mapping flags which will be used on allocation. Also, set the format
and hardware context on the allocated frame automatically - the user
should not be required to do this themselves.
|
|
Some frames contexts are not usable without additional format-specific
state in hwctx. This change adds new functions frames_derive_from and
frames_derive_to to initialise this state appropriately when deriving
a frames context which will require it to be set.
|
|
* commit 'd06aa24ba583ad08025da9e1b29afcd8218ff9b0':
hwcontext: Hardware frame mapping
Merged-by: Clément Bœsch <cboesch@gopro.com>
|
|
Also use that to fix a warning in av_hwdevice_get_type_name().
|
|
Adds functions to convert to/from strings and a function to iterate
over all supported device types. Also adds a new invalid type
AV_HWDEVICE_TYPE_NONE, which acts as a sentinel value.
|
|
Creates a new device context from another of a different type which
refers to the same underlying hardware.
|
|
|
|
* commit 'fdfe01365d579189d9a55b3741dba2ac46eb1df8':
hwcontext: allocate the destination frame for the pool size
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
|
Adds the new av_hwframe_map() function, which allows mapping between
hardware frames and normal memory, along with internal support for
implementing it.
Also adds av_hwframe_ctx_create_derived(), for creating a hardware
frames context associated with one device using frames mapped from
another by some hardware-specific means.
|
|
See "[FFmpeg-devel] [PATCH] hwcontext: add a QSV implementation"
Suggested-by: nablet developer <sdk@nablet.com>
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
* commit '59e7361cc791e5103be1712dc59a2055f118d0da':
hwcontext: add a QSV implementation
Conflicts:
doc/APIchanges
libavutil/version.h
Merged-by: James Almer <jamrial@gmail.com>
|
|
The source frame may be cropped, so that its dimensions are smaller than
the pool dimensions. The transfer_data API requires the allocated size
of the destination frame to be the same as the pool size.
|
|
* commit '1c9e8616c535ef496e7ee8a5cbc5e9e972a6977d':
hwcontext: add a function for opening devices
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
|
* commit 'c46db38cde8e8fd8ecb1c6602f10ec0e002f29a8':
hwcontext: add a dxva2 implementation
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
|
|
|
|
|
|
|
* commit 'a0f469da744db83db32f3fe13186ee4aa2bc7dc5':
hwcontext: initialize sw_format in av_hwframe_ctx_alloc()
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|
|
|
* commit '551c6775abb5e0ad34c26d7e23bc6fbbe8ccc9d4':
lavu: VAAPI hwcontext implementation
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|
* commit 'b1f01e85a92d401a9b29c79f23db36b7685e8c09':
lavu: add a way to query hwcontext frame constraints
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
