the title bar is now within the window bounds instead of outside. same
as QuickTime Player. it supports several standard styles, two dark and
two light ones. additionally we have properly rounded corners now and
the borderless window also has the proper window shadow.
Also make the earliest supported macOS version 10.10.
Fixes#4789, #3944
the swift object file wasn't linked when libmpv was linked, which
resulted in a missing symbol error. add the swift object to the linking
list for libmpv too.
Fixes#5522
for convenience reasons i used strings for subprocess commands instead
of command lists, which made it mandatory to use a shell. for security
reasons, among others, we removed the shell usage and converted the
commands to actual command lists.
c82fed8 fixed the detection with python3 but broke it on python2. the
decode function on python2 converts the str to unicode which causes
problems when concatenating to str when building. instead of decoding
the output we change the subprocess to operate in text mode.
also use check_output instead of Popen for simplicity.
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend in the future. the problems are various shortcomings of
Apple's opengl implementation and buggy behaviour in certain
circumstances that couldn't be properly worked around. there are also
certain regressions on newer macOS versions from 10.11 onwards.
- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations
all the problems were caused by using a normal opengl context, that
seems somewhat abandoned by apple, and are fixed by using a layer backed
opengl context instead. problems that couldn't be fixed could be
properly worked around.
this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
and it needed to be in sync, hopefully i can work around that in the
future.
this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.
some credit goes to @pigoz for the initial swift build support which
i could improve upon.
Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739,
#2392, #2217
on macOS mpv was linked to the system SDK which didn't cause any
problems as long as the system SDK was the same as the dev SDK. though
it started to cause linking warnings when a new xcode version with the
SDK for the next macOS was installed. in the worst case it could also
cause linking errors. to fix this we explicitly set the SDK path to the
SDK that is used for building instead.
Directory-opening never worked on Windows because MSVCRT's open()
doesn't open directories and its fstat() doesn't recognise directory
handles. These are just MSVCRT restrictions, and the Windows API itself
has no problem with opening directories as file objects, so reimplement
mpv's mp_open and mp_stat to use the Windows API directly. This should
fix directory playback.
This also populates the st_dev and st_ino fields of struct stat, so
filesystem loop checking in demux_playlist.c should now work on Windows.
Fixes#4711
The wayland code was written more than 4 years ago when wayland wasn't
even at version 1.0. This commit rewrites everything in a more modern way,
switches to using the new xdg v6 shell interface which solves a lot of bugs
and makes mpv tiling-friedly, adds support for drag and drop, adds support
for touchscreens, adds support for KDE's server decorations protocol,
and finally adds support for the new idle-inhibitor protocol.
It does not yet use the frame callback as a main rendering loop driver,
this will happen with a later commit.
See "Copyright" file for caveats.
This changes the remaining "almost LGPL" files to LGPL, because we think
that the conditions the author set for these was finally fulfilled.
Instead of "deps", "deps_neg", and "deps_any" fields, just have a single
"deps" field, which changes from an array to a string. The string is now
an expression, which can contain the operators &&, ||, !, and allows
grouping with ( ).
It's probably overkill. If it gets a maintenance burden, we can switch
to specifiying the dep expressions as ASTs (or maybe eval()-able Python
expressions), and we could simplify the code that determines the reason
why a dependency is not fulfilled. The latter involves a complicated
conversion of the expression AST to DNF.
The parser is actually pretty simple, and pretty much follows:
https://en.wikipedia.org/wiki/Shunting_yard_algorithm
This reverts commit ea40fa36ee.
This caused strange runtime failure on Raspbian (when running mpv,
vc_dispmanx_display_open() returned 0, while other dispmanx using
programs were fine). The problem must have been something about the
compiler flags, maybe linking order or set of include paths.
In a bunch of cases, we emulate highly platform specific APIs on a
higher level across all OSes, such as IPC, terminal, subprocess
handling, and more. We have source files for each OS, and they implement
all the same mpv internal API.
Selecting which source file to use on an OS can be tricky, because there
is partially overlapping and emulated APIs (consider Cygwin on Windows).
Add a pick_first_matching_dep() function to make this slightly easier
and more structured.
Also add dummy backends in some cases, to deal with APIs not being
available.
Clarify the Windows dependency identifiers, as these are the most
confusing.
Most of the DVB test fragment was added in 2e399f39 by someone who
wasn't asked for LGPL relicensing permission. Thus remove it. (For some
weird reason, the configure check wasn't even for the later added actual
DVB code.)
Since DVB is disabled by default, this isn't too bad. But if someone
enables it, and the system doesn't support it, he will receive a weird
compilation error. That has to be good enough, until maybe someone adds
a new check.
The user bugmen0t was apparently a shared github account with publicly
available login. Thus, we can't get LGPL relicensing permission from the
people who used this account. To relicense successfully, we have to
remove all their changes.
This commit should remove 20d1fc13, f26fb009, defbe48d. It also should
remove whatever test fragments were copied from the ancient configure,
as well as some configure logic (potentially that device path stuff).
I think this change still preserves the most important use-cases of OSS:
BSDs, and the Linux OSS emulation (the latter for testing only).
According to an OSS user, the 4front checks were probably broken anyway.
The SunAudio stuff was probably for (Open)Solaris, which is dead.
ao_oss.c itself will remain GPL, and still contains bugmen0t changes.
Most contributors have agreed. This claims it's based on gstreamer code,
but this was LGPL at the time (and still is). Contributors whose code
was removed were not accounted for. There are still some potentially
problematic cases:
06eee1b67 is potentially the most problematic case. Most of these
changes are gone due to mpv not using BITMAPINFOHEADER anymore. Some
of the other changes are rather trivial. If someone contests this and
claims that copyrightable changes are left, the original change can
simply be reverted.
62bfae140 has only 2 lines left: a "char *name;" struct field, and a
line that prints a message. All other code was removed. The parsing code
in particular was made declarative, which replaced reading this element
explicitly (and other elements, see 1b22101c77). I'm putting the log
message under HAVE_GPL, but I don't think the declaration is
copyrightable, or the mere concept of reading this element. Redoing the
other 2 lines of code would result in the same program text.
d41e860ba was applied by someone who (potentially) disagreed. The patch
itself is from someone who did agree, though. It's unknown whether the
applier changed the patch. But it seems unlikely, and the change was
mostly rewritten.
50a86fcc3 all demux_mkv changes were reverted (old stdout slave mode)
3a406e94d same
2e40bfa13 the old MPlayer subtitle code was completely removed
316bb1d44 completely removed in 1cf4802c1d87f93d9d7 same
11bfc6780 relative seeks were removed in 92ba630796be54f4813 the corresponding demux_mkv code was removed in 5dabaaf093efd53eed6 all internal vobsub handling is now in FFmpeg
d7f693a20 removed in f3db4b0b93e8a1b3713 removed in 522ee6b783cfb890259 removed, see 6b1374b203 for analysis
c80808b5a same
When mpv is being linked against static libraries which have shared
libraries as dependencies, linker will throw error because pkg-config
with --static flag will return shared libraries which will be placed
under the -Wl,-Bstatic section, while pkg-config without --static flag
will omit the private libraries required to link the static library.
With this function users can modify the wscript to insert the dependencies
when necessary. For example, linking FFmpeg with shared OpenSSL and zlib:
'func': check_pkg_config_mixed(['crypto','ssl','z'], 'libavcodec')
Upstream provides pkgconfig files for quite some time now [1,2].
Use them to determine the required flags instead of hard coding.
This makes cross-compilation easy, which I dare to say is important for
many raspberry-pi users. This also prevents picking libEGL and libGLESv2
from mesa when they are present, which can happen with the current code.
Good distros should put these pkgconfig files into default pkg-config
search path or populate PKG_CONFIG_PATH for users. However, be nice to
everybody and manually look into '/opt/vc/lib/pkgconfig' just in case.
Hence the PKG_CONFIG_PATH mangling.
[1]: https://github.com/raspberrypi/userland/issues/245
[2]: 05d60a01d5
This reverts commit fae7307931.
Before the waf build system was used, we had a configure script written
in shell. To drop the build dependency on Python, someone rewrote the
Python scripts we had to Perl. Now the shell configure script is gone,
and it makes no sense to have a build dependency on both Perl and
Python.
This isn't just a straight revert. It adds the new Matroska EBML
elements to the old Python scripts, adjusts the waf build system, and of
course doesn't add anything back needed by the old build system.
It would be better if this used matroska.py/file2string.py directly by
importing them as modules, instead of calling them via "python". But for
now this is simpler.
The test ended up failing if cuda.h wasn't present, even if cuda.h
isn't used during the actual build.
This test is attempting to establish if the ffmpeg being built
against has dynlink_cuda support. While it might theoretically be
possible to build against the older normally-linked-cuda version
of ffmpeg, it seems more trouble than it's worth.
We always want to use __declspec(selectany) to declare GUIDs, but
manually including <initguid.h> in every file that used GUIDs was
error-prone. Since all <initguid.h> does is define INITGUID and include
<guiddef.h>, we can remove all references to <initguid.h> and just
compile with -DINITGUID to get the same effect.
Also, this partially reverts 622bcb0 by re-adding libuuid.a to the
build, since apparently some GUIDs (such as GUID_NULL) are not declared
in the source file, even when INITGUID is set.
For clang, it's enough to just put (void) around usages we are
intentionally ignoring the result of.
Since GCC does not seem to want to respect this decision, we are forced
to disable the warning globally.
I got a report that the build on a recent aarch64 Linux kernel failed.
DVB support was detected, but errored on compilation:
In file included from ../stream/stream_dvb.c:57:0:
../stream/dvbin.h:72:5: error: unknown type name 'fe_bandwidth_t'
fe_bandwidth_t bw;
Make the test stricter, which should take care of this. (I couldn't find
out what exactly triggered the failure, nor could I attempt to reproduce
it.)
The change in stream/dvbin.h is to make sure that this isn't caused by
incorrect header inclusion. It now includes the same files as the
configure test.