This warns about player/audio.c:253 with gcc 8.2.0. Although this
warning could be useful to check the worst case estimation, the compiler
doesn't explain how it gets its dumb, bogus result, so this is useless.
You'd just end up trying to make the compiler happy for no reason.
this migrates our current swift code to version 5 and 4. building is
support from 10.12.6 and xcode 9.1 onwards.
dynamic linking is the new default, since Apple removed static libs
from their new toolchains and it's the recommended way.
additionally the found macOS SDK version is printed since it's an
important information for finding possible errors now.
Fixes#6470
this is in preparation for the upcoming swift 5 transition, where static
linking was replaced by dynamic linking the swift libraries as the
preferred way, by Apple. furthermore Apple removed the static swift libs
from their dev Tools starting with xcode 10.2/swift 5.
because of ABI incompatibility dynamic linking for swift versions prior
to 5 doesn't use the system lib path for the dynamic swift libs.
for now static linking is still the default, but that will be changed
when swift 5 support is added and swift 3 support is dropped.
Fixes#6232
the xcode-select tool only properly works with Apple provided toolchains
but not with third party ones from swift.org. in the latter case the
swift compiler executable is found in the proper path but the swift libs
from the xcode or command line tools will be picked. this leads to a
not wanted discrepancy of the swift compiler and libs and possible
errors.
instead of relying on the xcode-select tool search for the libs relative
to the swift executable. that relative path seems to be the same for all
toolchains. if for any reasons a swift executable is not found in the
relative path, fall back to the old xcode-select method.
furthermore, both static and dynamic libs will be searched for but only
the former will be used for now. this is a preparation for the upcoming
swift 5 migration.
C99 still works, but in theory we're using C11 features already, such as
stdatomic.h. gcc/clang let us use it in C99 mode too, but using C11 is
at least more proper.
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
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
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
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.
This sets the minimum supported Windows version to Windows Vista. The
subsystem version also affects some Windows API functions, including
GetSystemMetrics(SM_CXPADDEDBORDER).
This is based on an older patch by James Ross-Gowan. It was rebased and
cleaned up. Also, the DWM API usage present in the older patch was
removed, because DWM reports nonsense rates at least on Windows 8.1
(they are rounded to integers, just like with the old GDI API - except
the GDI API had a good excuse, as it could report only integers).
Signed-off-by: wm4 <wm4@nowhere>
Revert "win32: more wchar_t -> WCHAR replacements"
Revert "win32: replace wchar_t with WCHAR"
Doing a "partial" port of this makes no sense anymore from my
perspective. Revert the changes, as they're confusing without
context, maintenance, and progress. These changes were a bit
premature anyway, and might actually cause other issues
(locale neutrality etc. as it was pointed out).
This was essentially missing from commit 0b52ac8a.
Since L"..." string literals have the type wchar_t[], we can't use them
for UTF-16 strings. Use C11 u"..." string literals instead. These have
the type char16_t[], but we simply assume char16_t is the same
underlying type as WCHAR. In practice, they're both unsigned short.
For this reason use -std=c11 on Windows. Since Windows is a "special"
environment (we require either MinGW or Cygwin), we don't need to worry
too much about compiler compatibility.
It's useless, and creates a bogus warning in subprocess-posix.c.
Since I don't know which compilers might have it by default, just change
it to -Wno-redundant-decls.
Add a platform-specific entry-point for Windows. This will allow some
platform-specific initialization to be added without the need for ugly
ifdeffery in main.c.
As an immediate advantage, mpv can now use a unicode entry-point and
convert the command line arguments to UTF-8 before passing them to
mpv_main, so osdep_preinit can be simplified a little bit.
This warning wasn't overly helpful in the past, and warned against
perfectly fine code. But at least with recent gcc versions, this is the
warning that complains about assignments in if expressions (why???), so
we want to enable it.
Also change all the code this warning complains about for no reason.
__STRICT_ANSI__ disables functions and definitions that aren't in ANSI
C. Unfortunately this includes j1(), which is used by the new
ewa_lanczos code. Cygwin's CFLAGS already unset __STRICT_ANSI__, but it
should be unset for both Cygwin and MinGW.
The idea of using -Werror=format-security comes from MPlayer.
Try to use the compiler flags with any compiler. There's no reason not
to apply them on clang.
This warning makes absolutely no sense. Passing an empty string to
printf-like functions is perfectly fine. In the OSD case, it just sets
an empty message, practically clearing the OSD.
There is no standard mechanism for detecting endianess. Doing it at
compile time in a portable way is probably hard. Doing it properly
with a configure check is probably hard too. Using the endian
definitions in <sys/types.h> (usually includes <endian.h>, which is
not available everywhere) works under circumstances, but the previous
commit broke it on OSX.
Ideally all code should be endian dependent, but that is not possible
due to the dependencies (such as FFmpeg, some video output APIs, some
audio output APIs).
Create a header osdep/endian.h, which contains various fallbacks.
Note that the last fallback uses libavutil; however, it's not clear
whether AV_HAVE_BIGENDIAN is a public symbol, or whether including
<libavutil/bswap.h> really makes it visible. And in fact we don't want
to pollute the namespace with libavutil definitions either. Thus it's
only the last fallback.
_GNU_SOURCE defines the kitchen sink, and also prefers glibc definitions
where glibc and POSIX conflict. Even though POSIX is worth less than
toilet paper, we still prefer the POSIX definitions.
rar.c needs asprintf(), which is _GNU_SOURCE-only. So we define
_GNU_SOURCE too specifically for this file.
These were in the old configure script too.
Two flags are explicitly tested, because I have no idea how widespread
support for them is, and testing them is just easier than trying to look
them up in various gcc/clang manuals. There are people using gcc 4.2
out there, so some caution is warranted.
-Wempty-body is not available on all gcc versions but we were using it
unconditionally. Also remove the usage from the clang case. clang still
defines `__GNUC__` so it still gets all the gcc specific flags.
This should fix the build on systems with older gcc versions like OpenBSD which
still comes bundled with gcc 4.2 for license issues.
Not needed anymore. I'm not opposed to having asm, but inline asm is too
much of a pain, and it was planned long ago to eventually get rid fo all
inline asm uses.
For the note, the inline asm use that was removed with the previous
commits was almost worthless. It was confined to video filters, and most
video filtering is now done with libavfilter. Some mpv filters (like
vf_pullup) actually redirect to libavfilter if possible.
If asm is added in the future, it should happen in the form of external
files.
wm4
der richter
Rodger Combs
Anton Kindestam
James Ross-Gowan
James Ross-Gowan
stepshal
Niklas Haas
Tsukasa OMOTO
Alessandro Ghedini
Stefano Pigozzi