1
mirror of https://github.com/mpv-player/mpv synced 2024-10-30 04:46:41 +01:00
Commit Graph

258 Commits

Author SHA1 Message Date
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
wm4
32cd85bc7e vo_opengl: x11egl: retrieve framebuffer depth
This is used for dithering, although I'm not aware of anyone who got
higher than 8 bit depth support to work on Linux.

Also put this into egl_helpers.c. Since EGL is pseudo-portable at best I
have no hope that the EGL context creation code in all the backends can
be fully shared. But some self-contained functionality can definitely be
shared.
2015-12-19 14:14:12 +01:00
James Ross-Gowan
3d12312806
vo_opengl: add dxinterop backend
WGL_NV_DX_interop is widely supported by Nvidia and AMD drivers. It
allows a texture to be shared between Direct3D and WGL, so that
rendering can be done with WGL and presentation can be done with
Direct3D. This should allow us to work around some persistent WGL
issues, such as dropped frames with some driver/OS combos, drivers that
buffer frames to increase performance at the cost of latency, and the
inability to disable exclusive fullscreen mode when using WGL to render
to a fullscreen window.

The addition of a DX_interop backend might also enable some cool
Direct3D-specific enhancements in the future, such as using the
GetPresentStatistics API to get accurate frame presentation timestamps.

Note that due to a driver bug, this backend is currently broken on
Intel. It will appear to work as long as the window is not resized too
often, but after a few changes of size it will be unable to share the
newly created renderbuffer with GL. See:
https://software.intel.com/en-us/forums/graphics-driver-bug-reporting/topic/562051
2015-12-11 18:29:18 +01:00
wm4
475fe453cc stream: drop PVR support
This is only for specific Hauppage cards. According to the comments in
who is actively using this feature. Get it out of the way.

Anyone who still wants to use this should complain. Keeping this code
would not cause terribly much additional work, and it could be restored
again. (But not if the request comes months later.)
2015-12-10 22:53:02 +01:00
wm4
f626bef7c8 win32: enable internal pthreads wrapper by default 2015-12-04 16:32:31 +01:00