Commit Graph

70 Commits

Author SHA1 Message Date
wm4 416d3f2c00 vaapi: correct broken NULL check
Clearly, we want to check whether vaGetDisplayDRM() returned NULL.
out_display itself is already implied non-NULL.

Fixes: #7739
2020-06-03 15:12:08 +02:00
wm4 26f4f18c06 options: change option macros and all option declarations
Change all OPT_* macros such that they don't define the entire m_option
initializer, and instead expand only to a part of it, which sets certain
fields. This requires changing almost every option declaration, because
they all use these macros. A declaration now always starts with

   {"name", ...

followed by designated initializers only (possibly wrapped in macros).
The OPT_* macros now initialize the .offset and .type fields only,
sometimes also .priv and others.

I think this change makes the option macros less tricky. The old code
had to stuff everything into macro arguments (and attempted to allow
setting arbitrary fields by letting the user pass designated
initializers in the vararg parts). Some of this was made messy due to
C99 and C11 not allowing 0-sized varargs with ',' removal. It's also
possible that this change is pointless, other than cosmetic preferences.

Not too happy about some things. For example, the OPT_CHOICE()
indentation I applied looks a bit ugly.

Much of this change was done with regex search&replace, but some places
required manual editing. In particular, code in "obscure" areas (which I
didn't include in compilation) might be broken now.

In wayland_common.c the author of some option declarations confused the
flags parameter with the default value (though the default value was
also properly set below). I fixed this with this change.
2020-03-18 19:52:01 +01:00
wm4 a3ddddff3a vaapi: reduce log levels further
Try to exclude mostly uninteresting information from verbose logging,
but still include it in debug logging.
2020-01-11 16:35:30 +01:00
Philip Langdale 49cbc5017c vo_gpu: hwdec_vaegl: remove support for old-style interop
In vaapi 1.1.0 (which confusingly is libva release 2.1.0), they
introduced a new surface export API that is more efficient, and
we've been supporting that and the old API ever since (Feb 2018).

If we drop support for the old API, we can do some fairly nice cleanup
of the code.

Note that the pkgconfig entries are explicitly versioned by the API
version and not the library version. I confirmed the upstream pkgconfig
files.
2019-12-28 14:31:34 -08:00
wm4 09b916965b vaapi: remove hacks for pre-libva2 log callbacks
Instead, you ancient libva will do default logging, which means printing
to stderr. Not a loss, just update your libva.
2019-10-18 15:37:16 +02:00
Rostislav Pehlivanov e3e2c794ef vaapi: add option to select a non-default device path
On machines with multiple GPUs, /dev/dri/renderD128 isn't guaranteed
to point to a valid vaapi device. This just adds the option to specify
what path to use.

The old fallback /dev/dri/card0 is gone but that's not a loss as its
a legacy interface no longer accepted as valid by libva.

Fixes #4320
2018-03-30 14:16:07 -07:00
wm4 2ce7face96
hwdec: remove unused fields
These were replaced by a different mechanism, but the old fields weren't
removed.
2017-12-21 19:31:36 +01:00
wm4 292724538c video: remove some more hwdec legacy stuff
Finally get rid of all the HWDEC_* things, and instead rely on the
libavutil equivalents. vdpau still uses a shitty hack, but fuck the
vdpau code.

Remove all the now unneeded remains. The vdpau preemption thing was not
unused anymore; if someone cares this could probably be restored.
2017-12-02 04:53:55 +01:00
wm4 23a9efd124 vd_lavc, vdpau, vaapi: restore emulated API avoidance
This code is for trying to avoid using an emulation layer when using
auto probing, so that we end up using the actual API the drivers
provide. It was destroyed in the recent refactor.
2017-12-02 04:53:51 +01:00
wm4 a0d9e15342 video: refactor hw device creation for hwdec copy modes
Lots of shit code for nothing. We probably could just use libavutil's
code for all of this. But for now go with this, since it tends to
prevent stupid terminal messages during probing (libavutil has no
mechanism to selectively suppress errors specifically during probing).

Ignores the "emulated" API flag (for avoiding vaapi/vdpau wrappers), but
it doesn't matter that much for -copy anyway.
2017-12-01 08:05:16 +01:00
Mark Thompson 2ecf240b1c vaapi: Use libva2 message callbacks
They are no longer global, so they work vaguely sensibly.
2017-10-09 21:35:47 +02:00
wm4 f3512686ee vaapi: replace error macro implementation
The current check_va_status() function could probably be argued to be
derived from the original VAAPI's patch check_status() function, thus
GPL-only. While I have my doubts that it applies to an idiom on this
level, it's better to replace it. Similar idea, different expression
equals no copyright association.

An earlier commit message promised this, but it was forgotten.
2017-09-30 16:07:00 +02:00
wm4 e544c3f7b3 vaapi: change license to LGPL
Originally mpv vaapi support was based on the MPlayer-vaapi patches.
These were never merged in upstream MPlayer. The license headers
indicated they were GPL-only. Although the actual author agreed to
relicensing, the company employing him to write this code did not, so
the original code is unusable to us.

Fortunately, vaapi support was refactored and rewritten several times,
meaning little code is actually left. The previous commits removed or
moved that to GPL-only code. Namely, vo_vaapi.c remains GPL-only. The
other code went away or became unnecessary mainly because libavcodec
itself gained the ability to manage the hw decoder, and libavutil
provides code to manage vaapi surfaces. We also changed to mainly using
EGL interop, making any of the old rendering code unnecessary.

hwdec_vaglx.c is still GPL. It's possibly relicensable, because much of
it was changed, but I'm not too sure and further investigation would be
required. Also, this has been disabled by default for a while now, so
bothering with this is a waste of time. This commit simply disables it
at compile time as well in LGPL mode.
2017-09-29 18:44:47 +02:00
wm4 6a69e897ff vaapi: move legacy code to vo_vaapi.c
Done for license reasons. vo_vaapi.c is turned into some kind of
dumpster fire, and we'll remove it as soon as I'm mentally ready for
unkind users to complain about removal of this old POS.
2017-09-29 18:32:56 +02:00
wm4 d462a2a321 vf_vavpp: use libavutil hw frames API for frame pool and upload
Another step to get rid of the legacy crap in vaapi.c. (Most is still
kept, because it's in use by vo_vaapi.c.)
2017-09-29 18:17:51 +02:00
wm4 6265a2d779 vaapi: minor changes
This is for relicensing. Some of this code is loosely based on
vo_vaapi.c from the original MPlayer-vaapi patches. Most of the code has
changed, and only the initialization code and check_status() look
remotely similar. The initialization code is changed to be like Libav's
(hwcontext_vaapi.c). check_va_status() is just a C idiom, but to play it
safe, we'll either drop it from LGPL code (or recreate it).

vaapi.c still contains plenty of code from the original patches, but the
next commits will move them out of the LGPL code paths.
2017-09-29 16:51:30 +02:00
wm4 ae7db6503b video: drop old D3D11/DXVA2 support
Now you need FFmpeg git, or something.

This also gets rid of the last real use of gpu_memcpy(). libavutil does
that itself. (vaapi.c still used it, but it was essentially unused,
because the code path isn't really in use anymore. It wasn't even
included due to the d3d-hwaccel dependency in wscript.)
2017-09-26 18:58:45 +02:00
wm4 1ad036a2ef video: get rid of swapped packed YUV
Another legacy annoyance. The only place where packed YUV is still
important is slightly older Apple hardware or drivers, which require
it for efficient hardware decoding.
2017-06-30 18:01:29 +02:00
wm4 b5b3aadf40 vdpau, vaapi: unref libavutil device ref
It's a simple memory leak. (The API objects were destroyed anyway.)
2017-04-29 15:09:40 +02:00
wm4 6aa4efd1e3 vd_lavc, vaapi: move hw device creation to generic code
hw_vaapi.c didn't do much interesting anymore. Other than the function
to create a device for decoding with vaapi-copy, everything can be done
by generic code. Other libavcodec hwaccels are planned to provide the
same API as vaapi. It will be possible to drop the other hw_ files in
the future. They will use this generic code instead.
2017-02-20 08:39:55 +01:00
wm4 443d3a91d3 vaapi: remove central lock around vaapi API calls
The lock was disabled recently. This commit gets rid of the dummied out
calls. The main reason for removing it is that there is no apparent need
for it anymore, and the new FFmpeg vaapi code does not use or provide
such a lock (there are some places which we cannot control and which do
vaapi API calls, like frame destructors).
2017-01-28 18:27:30 +01:00
wm4 398e2d5d42 vaapi: fix va_surface_get_uncropped_size() for libavutil surfaces
Fixes vf_vavpp crashing with the new vaapi decode API.
2017-01-18 08:17:10 +01:00
wm4 bbdecb792a hwdec: add a AVBufferRef(AVHWDeviceContext) field
This makes "generic" interaction with libav* components easier.
2017-01-16 16:10:22 +01:00
wm4 d9376fc86f vaapi: always create AVHWDeviceContext on init
For convenience. Since we still have code that works even if creating a
AVHWDeviceContext fails, failure is ignored. (Although currently, it
succeeds creation even with the stale/abandoned vdpau wrapper driver.)
2017-01-13 13:35:31 +01:00
wm4 06b30cc81f vaapi: use libavutil functions for copying hw surfaces to memory
Makes va_surface_download() call mp_image_hw_download() for
libavutil-allocated surfaces, which in turn calls
av_hwframe_transfer_data().

mp_image_hw_download() is actually not specific to vaapi, and can be
used for any hw surface allocated by libavutil.
2017-01-12 13:58:28 +01:00
wm4 a51e991b56 vaapi: set our own context in AVHWFramesContext not AVHWDeviceContext
AVHWDeviceContext.user_opaque is reserved to libavutil under certain
circumstances, while AVHWFramesContext.user_opaque is truly free for use
by us. It's slightly simpler too.
2017-01-12 13:58:28 +01:00
wm4 a41bedfce5 vaapi: add missing config.h include
A recent commit added code that checks some HAVE_ symbols in this file.
No config.h include was added, so they could be unavailable and break
compilation (in practice, just --hwdec=vaapi-copy would break).

Not sure how I missed this, maybe waf defined these symbols on the
compiler command line for some reason.
2017-01-11 18:45:04 +01:00
wm4 f4263922c7 vaapi: add hacks to support vaapi surfaces created by libavutil
We usually attach some significant metadata and context to "our"
surfaces. Surfaces created by libavutil (such as we plan to do it when
using the new vaapi decode API in the following commit) don't have this
context, so e.g. copy decoding mode won't work.

Add tons of hacks to make this somehow work.

Eventually we will use libavutil's mechanisms and drop the hacks.
2017-01-11 16:34:18 +01:00
wm4 9fd986b53a vaapi: move standalone display creation code to common code
Preparation for the following commits.
2017-01-11 16:34:18 +01:00
wm4 2ce5523893 vaapi: set libva message callbacks
This is available since the first commit after libva 0.39.4. Since the
version wasn't bumped since, we just check some random other symbol that
was added since (I'd rather not add a configure check).

The libva message callback repeats the endlessly repeated API mistakes
of libraries using global message callback handlers. But it's the only
way to shut up libva's dumb messages to stderr, so add something
complicated and dumb to workaround libva's stupidity.
2017-01-08 07:45:23 +01:00
wm4 f2a24ccfa5 vaapi: rearrange va_initialize() internals and fix double-free on error
Just some minor refactoring within va_initialize() as preparation for
the next commit.

Also, do not call vaTerminate(display) on failures. All callers already
do this, so this would have led to a double-free.
2017-01-08 07:32:44 +01:00
wm4 85488f6892 video: change hw_subfmt meaning
The hw_subfmt field roughly corresponds to the field
AVHWFramesContext.sw_format in ffmpeg. The ffmpeg one is of the type
AVPixelFormat (instead of the underlying hardware format), so it's a
good idea to switch to this too for preparation.

Now the hw_subfmt field is an mp_imgfmt instead of an opaque/API-
specific number. VDPAU and Direct3D11 already used mp_imgfmt, but
Videotoolbox and VAAPI had to be switched.

One somewhat user-visible change is that the verbose log will now always
show the hw_subfmt as image format, instead of as nonsensical number.

(In the end it would be good if we could switch to AVHWFramesContext
completely, but the upstream API is incomplete and doesn't cover
Direct3D11 and Videotoolbox.)
2016-07-15 13:04:17 +02:00
wm4 46fff8d31a video: refactor how VO exports hwdec device handles
The main change is with video/hwdec.h. mp_hwdec_info is made opaque (and
renamed to mp_hwdec_devices). Its accessors are mainly thread-safe (or
documented where not), which makes the whole thing saner and cleaner. In
particular, thread-safety rules become less subtle and more obvious.

The new internal API makes it easier to support multiple OpenGL interop
backends. (Although this is not done yet, and it's not clear whether it
ever will.)

This also removes all the API-specific fields from mp_hwdec_ctx and
replaces them with a "ctx" field. For d3d in particular, we drop the
mp_d3d_ctx struct completely, and pass the interfaces directly.

Remove the emulation checks from vaapi.c and vdpau.c; they are
pointless, and the checks that matter are done on the VO layer.

The d3d hardware decoders might slightly change behavior: dxva2-copy
will not use the VO device anymore if the VO supports proper interop.
This pretty much assumes that any in such cases the VO will not use any
form of exclusive mode, which makes using the VO device in copy mode
unnecessary.

This is a big refactor. Some things may be untested and could be broken.
2016-05-09 20:03:22 +02:00
wm4 f5ff2656e0 vaapi: determine surface format in decoder, not in renderer
Until now, we have made the assumption that a driver will use only 1
hardware surface format. the format is dictated by the driver (you
don't create surfaces with a specific format - you just pass a
rt_format and get a surface that will be in a specific driver-chosen
format).

In particular, the renderer created a dummy surface to probe the format,
and hoped the decoder would produce the same format. Due to a driver
bug this required a workaround to actually get the same format as the
driver did.

Change this so that the format is determined in the decoder. The format
is then passed down as hw_subfmt, which allows the renderer to configure
itself with the correct format. If the hardware surface changes its
format midstream, the renderer can be reconfigured using the normal
mechanisms.

This calls va_surface_init_subformat() each time after the decoder
returns a surface. Since libavcodec/AVFrame has no concept of sub-
formats, this is unavoidable. It creates and destroys a derived
VAImage, but this shouldn't have any bad performance effects (at
least I didn't notice any measurable effects).

Note that vaDeriveImage() failures are silently ignored as some
drivers (the vdpau wrapper) support neither vaDeriveImage, nor EGL
interop. In addition, we still probe whether we can map an image
in the EGL interop code. This is important as it's the only way
to determine whether EGL interop is supported at all. With respect
to the driver bug mentioned above, it doesn't matter which format
the test surface has.

In vf_vavpp, also remove the rt_format guessing business. I think the
existing logic was a bit meaningless anyway. It's not even a given
that vavpp produces the same rt_format for output.
2016-04-11 22:03:26 +02:00
wm4 453ea2cb6c vaapi: replace VA_STR_FOURCC 2016-01-11 20:30:36 +01:00
wm4 9693e0f57a Remove some VLAs
They are evil and should be eradicated. Some of these were pretty dumb
anyway.

There are probably some more around in platform specific code or other
code not enabled by default on Linux.
2015-11-06 21:12:20 +01:00
wm4 0eb45343ca vaapi: drop non-existing FourCC
This VA_FOURCC isn't even defined by latest drivers, so I'm just
assuming it doesn't exist and never existed. For planar 4:2:0,
VA_FOURCC_YV12 is normally preferred, and there's even a VA_FOURCC_IYUV
for 4:2:0 with unswapped planes.
2015-10-17 14:20:53 +02:00
wm4 ac5538c7df vaapi: use GPU memcpy for reading back from HW surface
This makes it much faster if the surface is really mapped from GPU
memory. It's slightly slower than system memcpy if used on system
memory. We don't really know definitely in which type of memory
it's located, so we use the GPU memcpy in all cases.

Fixes #2317.
2015-09-25 19:18:16 +02:00
wm4 38b747bb67 vaapi: cosmetics, minor fixes
Printing "Using vaDeriveImage()" every frame is too verbose, so raise
the log level.

mp_image strides are in int and not unsigned int; fix this. It's not
like it actually matters, though.

Finish a comment.
2015-09-25 12:10:43 +02:00
wm4 2ed9370bd6 vf_vavpp: allocate output surfaces with the same size as input
This can happen if the hw decoder allocates padded surfaces (e.g.
mod16), but the VPP output surface was allocated with the exact size.
Apparently VPP requires matching input and output sizes, or it will add
artifacts. In this case, it added mirrored pixels to the bottom few
pixels.

Note that the previous commit should have fixed this. But it didn't
work, while this commit does.

Fixes #2320.
2015-09-23 14:20:50 +02:00
wm4 7ef8f457a8 vaapi: destroy derived VAImage after each use
Appears to be required by some hardware. Whatever.
2015-07-15 13:30:32 +02:00
wm4 50bd2807ad vaapi: don't assume vaQueryImageFormats() returns sorted list
vaQueryImageFormats() returns a randomly ordered list - so we shouldn't
assume the first format on the list which works is the best. This
effectively switches to nv12 instead of yuv420p on some drivers.

We handle this by reusing va_to_imgfmt[], and ordering it by preference.
We hardcode that GPUs prefer nv12 pver yuv420p. In theory we could do
complicated probing (allocate dummy surface + use vaDeriveImage on it,
then retrieve the FourCC) - but all things which could break assumption
in the future are not supported yet (like 10 bit or 4:4:4), so this is
fine.
2015-07-15 13:27:25 +02:00
wm4 e3e20f1431 Revert "vaapi: remove vaDeriveImage() code path"
This reverts commit d660e67be9.

Fixes #2123.
2015-07-15 13:15:58 +02:00
wm4 db2268d5b1 vaapi: drop compatibility crap and vo_vaapi deinterlacer
Drop libva versions below 0.34.0. These are ancient, so I don't care.

Drop the vo_vaapi deinterlacer as well. With 0.34.0, VPP is always
available, and deinterlacing is done with vf_vavpp.

The vaCreateSurfaces() function changes its signature - actually it did
in 0.34.0 or so, and the <va/va_compat.h> defined a macro to make it use
the old signature.
2015-07-08 14:48:11 +02:00
wm4 ef3d121c9e vaapi: treat cropped decoder output slightly more correctly
Work around that FFmpeg doesn't distinguish between surface and cropped
size. The decoder always aligns the surface size to something
"convenient" (e.g. 16 for h264), and to get to the correct cropped size,
the output image's width/height is reduced. Using the cropped size
instead of the real surface size breaks the libva API in certain cases,
so we simply store and use the original size in our per-surface struct.

(If data is cropped on the left/top borders, hw decoding will simply
display these - FFmpeg doesn't let us do better.)
2015-06-29 15:13:45 +02:00
wm4 e0b1b88e83 vaapi: fix potential NULL deref on memory allocation failure 2015-06-29 15:10:17 +02:00
wm4 d660e67be9 vaapi: remove vaDeriveImage() code path
In theory, this code path avoids a copy. In practice, it never seems
to get enabled at all. But it does have potential for weird bugs or
performance issues (like being mapped from non-cacheable memory),
so kill it.
2015-06-29 15:10:07 +02:00
wm4 991af7dfb1 video: reduce error message when loading hwdec backend fails
When using --hwdec=auto, about half of all systems will print:

    "[vdpau] Error when calling vdp_device_create_x11: 1"

this happens because usually mpv will be linked against both vdpau and
vaapi libs, but the drivers are not necessarily available. Then trying
to load a driver will fail. This is a normal part of probing, but the
error messages were printed anyway. Silence them by explicitly
distinguishing probing.

This pretty much goes through all the layers. We actually consider
loading hw backends for vo_opengl always "auto probed", even if a hw
backend is explicitly requested. In this case vd_lavc will print a
warning message anyway (adjust this message a bit).
2015-06-20 22:26:57 +02:00
wm4 2a9534871d command: add property returning detected hwdec API
This is somewhat imperfect, because detection of hw decoding APIs is
mostly done on demand, and often avoided if not necessary. (For example,
we know very well that there are no hw decoders for certain codecs.)

This also requires every hwdec backend to identify itself (see hwdec.h
changes).
2015-02-02 22:43:13 +01:00
wm4 74581a6106 video: handle hwdec screenshots differently
Instead of converting the hw surface to an image in the VO, provide a
generic way to convet hw surfaces, and use this in the screenshot code.

It's all relatively straightforward, except vdpau is being terrible. It
needs a huge chunk of new code, because copying back is not simple.
2015-01-22 18:18:23 +01:00