Commit Graph

262 Commits

Author SHA1 Message Date
Philip Langdale b83bfea05d hwdec_cuda: Rename config variable to be more consistent
'cuda-gl' isn't right - you can turn this on without any GL and
get some non-zero benefit (with the cuda-copy hwaccel). So
'cuda-hwaccel' seems more consistent with everything else.
2016-09-16 14:26:30 +02:00
wm4 9b6c93e904 vo_opengl: drm: use new EGL context creation code 2016-09-14 11:00:17 +02:00
wm4 c56f5f0681 vo_opengl: wayland: use new EGL context creation code 2016-09-14 10:46:52 +02:00
wm4 5819a4e301 vo_opengl: rpi: use new egl context creation helper function
Only for the "new" vo_opengl backend code.
2016-09-13 20:16:45 +02:00
wm4 0ccceecdc6 vo_opengl: mali fbdev support
Minimal support just for testing.

Only the window surface creation (including size determination) is
really platform specific, so this could be some generic thing with
platform-specific support as some sort of sub-driver, but on the other
hand I don't see much of a need for such a thing.

While most of the fbdev usage is done by the EGL driver, using this
fbdev ioctl is apparently the only way to get the display resolution.
2016-09-13 18:26:06 +02:00
Philip Langdale 2048ad2b8a hwdec/opengl: Add support for CUDA and cuvid/NvDecode
Nvidia's "NvDecode" API (up until recently called "cuvid" is a cross
platform, but nvidia proprietary API that exposes their hardware
video decoding capabilities. It is analogous to their DXVA or VDPAU
support on Windows or Linux but without using platform specific API
calls.

As a rule, you'd rather use DXVA or VDPAU as these are more mature
and well supported APIs, but on Linux, VDPAU is falling behind the
hardware capabilities, and there's no sign that nvidia are making
the investments to update it.

Most concretely, this means that there is no VP8/9 or HEVC Main10
support in VDPAU. On the other hand, NvDecode does export vp8/9 and
partial support for HEVC Main10 (more on that below).

ffmpeg already has support in the form of the "cuvid" family of
decoders. Due to the design of the API, it is best exposed as a full
decoder rather than an hwaccel. As such, there are decoders like
h264_cuvid, hevc_cuvid, etc.

These decoders support two output paths today - in both cases, NV12
frames are returned, either in CUDA device memory or regular system
memory.

In the case of the system memory path, the decoders can be used
as-is in mpv today with a command line like:

mpv --vd=lavc:h264_cuvid foobar.mp4

Doing this will take advantage of hardware decoding, but the cost
of the memcpy to system memory adds up, especially for high
resolution video (4K etc).

To avoid that, we need an hwdec that takes advantage of CUDA's
OpenGL interop to copy from device memory into OpenGL textures.

That is what this change implements.

The process is relatively simple as only basic device context
aquisition needs to be done by us - the CUDA buffer pool is managed
by the decoder - thankfully.

The hwdec looks a bit like the vdpau interop one - the hwdec
maintains a single set of plane textures and each output frame
is repeatedly mapped into these textures to pass on.

The frames are always in NV12 format, at least until 10bit output
supports emerges.

The only slightly interesting part of the copying process is that
CUDA works by associating PBOs, so we need to define these for
each of the textures.

TODO Items:
* I need to add a download_image function for screenshots. This
  would do the same copy to system memory that the decoder's
  system memory output does.
* There are items to investigate on the ffmpeg side. There appears
  to be a problem with timestamps for some content.

Final note: I mentioned HEVC Main10. While there is no 10bit output
support, NvDecode can return dithered 8bit NV12 so you can take
advantage of the hardware acceleration.

This particular mode requires compiling ffmpeg with a modified
header (or possibly the CUDA 8 RC) and is not upstream in ffmpeg
yet.

Usage:

You will need to specify vo=opengl and hwdec=cuda.

Note that hwdec=auto will probably not work as it will try to use
vdpau first.

mpv --hwdec=cuda --vo=opengl foobar.mp4

If you want to use filters that require frames in system memory,
just use the decoder directly without the hwdec, as documented
above.
2016-09-08 16:06:12 +02:00
wm4 c6b7a4dace atomics: readd some emulation
This time it's emulation that's supposed to work (not just dummied out).
Unlike the previous emulation, no mpv code has to be disabled, and
everything should work (albeit possibly a bit slowly). On the other
hand, it's not possible to implement this kind of emulation without
compiler support. We use GNU statement expressions and __typeof__ in
this case.

This code is inactive if stdatomic.h is available.
2016-09-06 20:15:07 +02:00
pavelxdd c36aaeeb2a wscript: fix typo 2016-09-06 09:43:59 +02:00
wm4 0a0967f48b build: make avutil-mastering-metadata check slightly more robust
Fixes the specific scenario of compiling against a local Libav build,
while the system has FFmpeg installed.
2016-08-18 14:55:43 +02:00
Thomas Petazzoni 8c2e299b84 wscript: improve stdatomic check
The current stdatomic check verifies the availability of the function by
calling atomic_load(). It also uses this test to check if linking
against libatomic is needed or not.

Unfortunately, on specific architectures (namely SPARC), using
atomic_load() does *not* require linking against libatomic, while other
atomic operations do. Due to this, mpv's wscript concludes that
stdatomic is available, and that linking against libatomic is not
needed, causing the following link failure:

[190/190] Linking build/mpv
audio/out/ao.c.13.o: In function `ao_query_and_reset_events':
/home/peko/autobuild/instance-0/output/build/mpv-0.18.1/build/../audio/out/ao.c:399: undefined reference to `__atomic_fetch_and_4'

In order to fix this, the stdatomic check is adjusted to call
atomic_fetch_add() instead, which does require libatomic. Thanks to
this, the wscript realizes that linking against libatomic is needed, and
the build works fine.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-09 17:09:29 +02:00
wm4 d4ee5e5a8a build: always require atomics
Always require them, instead of just for some components which have hard
requirements on correct atomic semantics. They should be widely
available, and are supported by all recent gcc and clang compiler
versions. We even have the fallbacks builtins, which should keep this
working on very old gcc releases.

In particular, w32_common.c recently added a hard requirement on
atomics, but checking this properly in the build system would have been
messy. This commit makes sure it always works.

The fallback where weak atomic semantics are always fine is in theory
rather questionable as well.
2016-08-05 17:10:22 +02:00
Chris Mayo f95cde60ff build: add --htmldir option
Defaults to docdir but makes it possible to install html documentation
separately.
2016-07-30 00:02:40 +02:00
Niklas Haas 5b6cce2b73 vd_lavc: expose mastering display side data reference peak
This greatly improves the result when decoding typical (ST.2084) HDR
content, since the job of tone mapping gets significantly easier when
you're only mapping from 1000 to 250, rather than 10000 to 250.

The difference is so drastic that we can now even reasonably use
`hdr-tone-mapping=linear` and get a very perceptually uniform result
that is only slightly darker than normal. (To compensate for the extra
dynamic range)

Due to weird implementation details, this only seems to be present on
keyframes (or something like that), so we have to cache the last seen
value for the frames in between.

Also, in some files the metadata is just completely broken /
nonsensical, so I decided to apply a simple heuristic to detect
completely broken metadata.
2016-07-03 19:42:52 +02:00
Niklas Haas 9278ce98f7 vo_opengl: implement ARIB STD-B68 (HLG) HDR TRC
This HDR function is unique in that it's still display-referred, it just
allows for values above the reference peak (super-highlights). The
official standard doesn't actually document this very well, but the
nominal peak turns out to be exactly 12.0 - so we normalize to this
value internally in mpv. (This lets us preserve the property that the
textures are encoded in the range [0,1], preventing clipping and making
the best use of an integer texture's range)

This was grouped together with SMPTE ST2084 when checking libavutil
compatibility since they were added in the same release window, in a
similar timeframe.
2016-06-28 19:48:29 +02:00
Bin Jin 61bc96518a vo_opengl: remove nnedi3 prescaler 2016-06-18 19:16:27 +02:00
wm4 1c5fd2d901 Revert "wscript: Require recent FFmpeg by default"
This reverts commit b51957fab5.

Breaks big time. It appears to ignore explicitly configured paths within
the libav* .pc files, which for example breaks mpv-build.
2016-06-09 21:05:33 +02:00
Martin Herkt b51957fab5
wscript: Require recent FFmpeg by default
Distros and users alike should be made aware of the fact that old
FFmpeg versions are bad. When users come to us with FFmpeg-related
trouble, the answer is “update FFmpeg” more often than not
(and no further support will be provided until they have done so),
so instead we just nag them about it here.
2016-06-09 01:41:53 +02:00
Quentin Glidic f0d7437412 build: Do not link to libGL for egl-drm
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
2016-05-20 14:15:44 +02:00
Niklas Haas b6c40953cb
csputils: add AVCOL_TRC_SMPTEST2084 support
This now lets us auto-detect appropriately tagged HDR content using
FFmpeg's new TRC entries (when available).

Hidden behind an #if because Libav stable doesn't have it yet.
2016-05-16 13:59:57 +02:00
wm4 fd82e14888 build: merge d3d11va and dxva2 hwaccel checks
We don't have any reason to disable either. Both are loaded dynamically
at runtime anyway. There is also no reason why dxva2 would disappear
from libavcodec any time soon.
2016-05-11 15:40:31 +02:00
wm4 fde20d10bc vo_opengl: angle: dynamically load ANGLE
ANGLE is _really_ annoying to build. (Requires special toolchain and a
recent MSVC version.) This results in various issues with people
having trouble to build mpv against ANGLE (apparently linking it
against a prebuilt binary doesn't count, or using binaries from
potentially untrusted sources is not wanted).

Dynamically loading ANGLE is going to be a huge convenience. This commit
implements this, with special focus on keeping it source compatible to
a normal build with ANGLE linked at build-time.
2016-05-11 15:39:29 +02:00
wm4 f54e555d27 wscript: make at least 1 OpenGL output mandatory
You have to explicitly disable it if you really want to compile without
it (like with libass).
2016-05-01 20:15:53 +02:00
James Ross-Gowan 622bcb0e37 win32: replace libuuid.a usage with initguid.h
Including initguid.h at the top of a file that uses references to GUIDs
causes the GUIDs to be declared globally with __declspec(selectany). The
'selectany' attribute tells the linker to consolidate multiple
definitions of each GUID, which would be great except that, in Cygwin
and MinGW GCC 6.1, this method of linking makes the GUIDs conflict with
the ones declared in libuuid.a.

Since initguid.h obsoletes libuuid.a in modern compilers that support
__declspec(selectany), add initguid.h to all files that use GUIDs and
remove libuuid.a from the build.

Fixes #3097
2016-05-01 21:10:24 +10:00
wm4 e13cc25a2c build: add check for AVHWFramesContext API
It's not used yet anywhere. Pushing this now so switching between
branches is less bothersome.
2016-04-14 18:20:13 +02:00
Rudolf Polzer 49431626cb Revert "build: disable encoding mode by default"
Reverting because the use of deprecated API has been fixed.

This reverts commit d0238711dc.
2016-04-11 14:59:33 -04:00
wm4 aec928d753 build: fix AVCodecParameters FFmpeg API check (again)
Commit 0d746522 was complete non-sense. The description and the code
mention the wrong struct.

This time I actually tested it.
2016-04-02 18:45:09 +02:00
wm4 0d74652232 build: fix AVCodecParameters FFmpeg API check
FFmpeg partially merged the API change. It added the AVCodecParameters
definition, but not the AVCodecContext.codecpar field. The new code
compiles only with the API fully merged, so adjust the check.
2016-04-01 10:13:13 +02:00
wm4 d0238711dc build: disable encoding mode by default
Encoding mode uses deprecated API. See previous commit. Encoding mode
will stop working/compiling at some point in the future, so unless
someone fixes the encoding code, it will stay disabled by default.

(Note that the deprecations are not merged in FFmpeg yet, but they will
soon. They've been deprecated in Libav for a while now.)
2016-03-31 22:04:22 +02:00
wm4 c971220cdd demux_lavf, ad_lavc, ad_spdif, vd_lavc: handle FFmpeg codecpar API change
AVFormatContext.codec is deprecated now, and you're supposed to use
AVFormatContext.codecpar instead.

Handle this for all of the normal playback code.

Encoding mode isn't touched.
2016-03-31 22:00:45 +02:00
Kevin Mitchell a7110862c8 vd_lavc: add d3d11va hwdec
This commit adds the d3d11va-copy hwdec mode using the ffmpeg d3d11va
api. Functions in common with dxva2 are handled in a separate decode/d3d.c
file. A future commit will rewrite decode/dxva2.c to share this code.
2016-03-30 09:01:27 -07:00
wm4 e0cf90a0c8 build: allow plain-gl build on OSX
Still requires Cocoa for various things, but no vo_opengl.

Untested. Fixes #2980 (probably).
2016-03-26 19:39:38 +01:00
wm4 4300bfd518 ad_lavc, vd_lavc: support new Libav decoding API
For now only found in Libav.
2016-03-24 17:53:30 +01:00
Ilya Zhuravlev 72aea5a12b ao: initial OpenSL ES support
OpenSL ES is used on Android. At the moment only stereo output is
supported. Two options are supported: 'frames-per-buffer' and
'sample-rate'. To get better latency the user of libmpv should pass
values obtained from AudioManager.getProperty(PROPERTY_OUTPUT_FRAMES_PER_BUFFER)
and AudioManager.getProperty(PROPERTY_OUTPUT_SAMPLE_RATE).
2016-02-27 00:00:36 +01:00
Kevin Mitchell 0d40140668 wscript: remove dxva2-dxinterop configure test
Wasn't really necessary as it was equivalent to gl-dxinterop.
2016-02-17 10:17:52 -08:00
Kevin Mitchell 2d1f42089c vo_opengl: dxinterop: add dxva2 passthrough
Use dxva2 surface to fill RGB IDirect3DSurface9 shared with opengl via
DXRegisterObjectNV.
2016-02-17 09:07:12 -08:00
wm4 166fa30f4b build: enable vaapi under drm-only
Fixes #2808.
2016-02-11 22:03:24 +01:00
Jan Ekström 4b97869e5f Enable building the opengl-cb video renderer on Android
* Add Android-specific OpenGL ES feature and checks
* Add missing GL_* symbols for Android
  (list gathered by Ilya Zhuravlev <whatever@xyz.is>)
2016-02-10 21:29:42 +01:00
Jan Ekström ff0112e08d Initial Android support
* Adds an 'android' feature, which is automatically detected.
* Android has a broken strnlen, so a wrapper is added from FreeBSD.
2016-02-10 21:29:36 +01:00
wm4 09d61032ca build: enable vo_opengl_cb if GL headers are present
To be more specific, enable vo_opengl and vo_opengl_cb, if libmpv is
compiled, and the GL headers happen to be in the default search paths.

Although platform specific code can be useful for libmpv (for window
embedding, and even with vo_opengl_cb for certain forms of hardware
decoding), it's not a requirement to use the opengl_cb API.

Enabling vo_opengl is not useful here, but the rest of the build system
doesn't distinguish vo_opengl and vo_opengl_cb, and I see no reason to.
2016-02-08 20:53:19 +01:00
wm4 c3348d86f2 build: make posix_spawn optional
OK, Android doesn't support it.
2016-02-08 20:29:08 +01:00
wm4 f04e7bc529 wscript: mark subprocess as required
We either need to be on Windows, or have posix_spawn available.

If someone can come up with a system that is POSIX, but does not provide
posix_spawn, we could make it optional.
2016-02-07 16:51:47 +01:00
wm4 45345d9c41 build: make libavfilter mandatory
The complex filter support that will be added makes much more complex
use of libavfilter, and I'm not going to bother with adding hacks to
keep libavfilter optional.
2016-02-05 23:17:33 +01:00
Michael Reed 27ecc417fe wscript: Update `--lua' help
This was outdated after a1f949d3b8.
2016-01-22 00:25:43 +01:00
wm4 68366b05f2 vo_opengl: add KMS/DRM VAAPI hardware decoding interop
Just requires glueing it together with Bloat Super Glue (tm).
2016-01-20 19:41:29 +01:00
Stefano Pigozzi 7c804cd796 build: add option to customize config files system path
Some packagers need to install default config files to some path but
automatically load system configuration files from another path.

See #2704
2016-01-11 21:11:10 +01:00
wm4 2a80680d95 Fix build on older libavcodec versions
avcodec_profile_name() was added only a week ago or so.
2016-01-08 17:19:04 +01:00
wm4 3e90a5fe81 ao_dsound: remove this audio output
It existed for XP-compatibility only. There was also a time where
ao_wasapi caused issues, but we're relatively confident that ao_wasapi
works better or at least as good as ao_dsound on Windows Vista and
later.
2016-01-06 13:52:15 +01:00
Chris Mayo d0cd7fa31b build: add option of html manual 2016-01-05 11:24:08 +01:00
wm4 946bd52a1d vo_opengl: fall back to gcc thread local storage (2)
Commit 1a6f3c56 added a fallback for the case when C11 TLS was not
available, but GCC TLS was. But it forget to enable VAAPI EGL interop in
the build system in this case.

Just remove the build system check. Should someone find a compiler that
works on Linux and does not support GCC extensions or C11, it will still
compile and just fail to init at runtime.

Actually fixes #2631 (hopefully).
2015-12-23 22:00:04 +01:00
James Ross-Gowan 7558d1ed7b win32: input: use Vista CancelIoEx
libwaio was added due to the complete inability to cancel synchronous
I/O cleanly using the public Windows API in Windows XP. Even calling
TerminateThread on the thread performing I/O was a bad solution, because
the TerminateThread function in XP would leak the thread's stack.

In Vista and up, however, this is no longer a problem. CancelIoEx can
cancel synchronous I/O running on other threads, allowing the thread to
exit cleanly, so replace libwaio usage with native Vista API functions.

It should be noted that this change also removes the hack added in
8a27025 for preventing a deadlock that only seemed to happen in Windows
XP. KB2009703 says that Vista and up are not affected by this, due to a
change in the implementation of GetFileType, so the hack should not be
needed anymore.
2015-12-20 21:06:02 +11:00