diff options
| author | Philip Langdale <philipl@overt.org> | 2022-07-31 13:47:23 -0700 |
|---|---|---|
| committer | Philip Langdale <github.philipl@overt.org> | 2022-08-09 10:19:18 -0700 |
| commit | 25fa1b0b45b5508148d2131e0906da320967aee8 (patch) | |
| tree | a692a8db3f5bdd9cf3765ccae876721e14df161e /DOCS | |
| parent | c9ecaedc44d5ea005840df80ac800ef9f3659142 (diff) | |
| download | mpv-25fa1b0b45b5508148d2131e0906da320967aee8.tar.bz2 mpv-25fa1b0b45b5508148d2131e0906da320967aee8.tar.xz | |
hwdec/drmprime: add drmprime hwdec-interop
In the confusing landscape of hardware video decoding APIs, we have had
a long standing support gap for the v4l2 based APIs implemented for the
various SoCs from Rockship, Amlogic, Allwinner, etc. While VAAPI is the
defacto default for desktop GPUs, the developers who work on these SoCs
(who are not the vendors!) have preferred to implement kernel APIs
rather than maintain a userspace driver as VAAPI would require.
While there are two v4l2 APIs (m2m and requests), and multiple forks of
ffmpeg where support for those APIs languishes without reaching
upstream, we can at least say that these APIs export frames as DRMPrime
dmabufs, and that they use the ffmpeg drm hwcontext.
With those two constants, it is possible for us to write a
hwdec-interop without worrying about the mess underneath - for the most
part.
Accordingly, this change implements a hwdec-interop for any decoder
that produces frames as DRMPrime dmabufs. The bulk of the heavy
lifting is done by the dmabuf interop code we already had from
supporting vaapi, and which I refactored for reusability in a previous
set of changes.
When we combine that with the fact that we can't probe for supported
formats, the new code in this change is pretty simple.
This change also includes the hwcontext_fns that are required for us to
be able to configure the hwcontext used by `hwdec=drm-copy`. This is
technically unrelated, but it seemed a good time to fill this gap.
From a testing perspective, I have directly tested on a RockPRO64,
while others have tested with different flavours of Rockchip and on
Amlogic, providing m2m coverage.
I have some other SoCs that I need to spin up to test with, but I don't
expect big surprises, and when we inevitably need to account for new
special cases down the line, we can do so - we won't be able to support
every possible configuration blindly.
Diffstat (limited to 'DOCS')
| -rw-r--r-- | DOCS/man/options.rst | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/DOCS/man/options.rst b/DOCS/man/options.rst index 59fc79c89e..8b88c5dc79 100644 --- a/DOCS/man/options.rst +++ b/DOCS/man/options.rst @@ -1253,6 +1253,8 @@ Video :vaapi-copy: copies video back into system RAM (Linux with some GPUs only) :nvdec: requires ``--vo=gpu`` (Any platform CUDA is available) :nvdec-copy: copies video back to system RAM (Any platform CUDA is available) + :drm: requires ``--vo=gpu`` (Linux only) + :drm-copy: copies video back to system RAM (Linux ony) Other hwdecs (only use if you know you have to): |