Bump xkbcommon version and use the new xkb_keymap_from_buffer. This is more
secure, because the from_string expects a 0 terminated string, but this cannot
be guaranteed with mmap.
Block X11's native key repeat, and use mpv's key repeat handling in
input.c instead.
No configure check for XKB. Even though it's an extension, it has been
part of most (all?) xlibs since 1996. If XKB appears to be missing,
just refuse enabling x11.
This is a potentially controversial change. mpv will use its own key
repeat rate, instead of X11's. This should be better, because seeking
will have a standardized "speed" (seek events per seconds when keeping
a seek key held down). It will also allow disabling key repears for
certain commands, though this is not done anywhere yet.
The new behavior can be disabled with the --native-keyrepeat option.
Used to be disabled by default, because libavdevice depends on
libavfilter, and earlier versions of libavfilter exports symbols that
clash with mpv's due to its MPlayer filter wrapper. Our configure script
explicitly detects these symbols now, and we can use that to safely
auto-detect libavdevice too. If we detect that libavfilter can't be
safely used, libavdevice is disabled as well.
Requires recent FFmpeg/Libav git versions. Earlier versions will not
be supported, as the API is different. (A libavfilter version that
uses AVFrame instead of AVFilterBuffer is needed.)
Note that this is sort of useless, because the option parser prevents
you from making use of the full libavfilter graph syntax. This has to be
fixed later.
Most of the filter creation code (half of the config() function) has
been taken from avplay.c.
This code is not based on MPlayer's vf_lavfi. The MPlayer code doesn't
compile as it hasn't been updated through multiple libavfilter API
changes, making it completely useless as a starting point.
At least libsdl adds -mwindows to the cflags, which marks the .exe
binary as GUI application. This means the program detaches from the
console when started in cmd.exe, instead of showing the playback
status, receiving console input, and so on.
Append -mconsole to the linker command line to disable -mwindows.
ntddcdrm.h is no longer under the 'ddk' directory in MinGW-w64,
and since MPV focuses on it instead of the old MinGW32, there's no
reason to keep that dir prefix, as it stops VCD support from being
built at all for Windows.
The OSX part of the Apple Remote was unmaintained for a long time and was not
working anymore. I tried to update the cookies to what the current versions of
OS X expect without much luck. I decided to remove it since Apple is not
including the IR receiver anymore in new hardware and it's clear that wifi
based remotes are the way to go.
A third party iOS app should be used in it's place. In the future we could look
into having a dedicated iOS Remote Control app like VLC and XBMC do.
The Linux side (`appleir.c`) was relatively tidy but it looks like LIRC can be
configured to work with any version of Apple Remote [1] and is more maintained.
[1] LIRC Apple Remote configs: http://lirc.sourceforge.net/remotes/apple/
This only matters for those who want to use vf_pp. The old API is marked
as deprecated, and doesn't work on Libav. It was broken on FFmpeg, but
has recently started working again - the fields in question were not un-
deprecated though. Instead you're supposed to use a new API, which does
exactly the same thing (what...?).
Also don't pass the QP table with mp_image_copy_attributes() - it
probably does more harm than it's useful.
By the way, with -vf=dlopen=TOOLS/vf_dlopen/showqscale.so, it appears
the table as output by recent FFmpeg is offset by 1 macroblock in X
direction and 2 macroblocks in Y direction, which most likely will
interfere with normal vf_pp operation. However, this is not my problem.
The only real reason for this commit is that we can finally get rid of
all libav* related deprecation warnings. (Though they are constantly
deprecating APIs, so this will not last long.)
We consider FFmpeg 1.x and Libav 0.9.x releases compatible. Support
for FFmpeg 0.9.x and Libav 0.8.x is considered infeasible and has been
dropped in the previous commits. The bits that break compatibility are
mainly the CodecID renaming (trivial, but would require nasty hacks
everywhere), the avcodec_encode_video2() function (missing in older
releases, mandatory in newer ones), and the resampler changes (older
releases miss lib{av,sw}resample, newer versions removed the
libavcodec resampler).
Remove some other compatibility bits that were needed to for releases
for which we drop support.
The comment about Libav 0.9 in compat/libav.h is incorrect and should
have been 0.8 (the symbol is present in Libav 0.9).
Remove `af_resample` and `af_lavcresample`. The former is a mess while the
latter uses an API that was long deprecated in libavcodec and is now removed.
`af_lavrresample` rougly has the same features and structure of
`af_lavcresample`.
libswresample fallback by wm4.
In theory, projects have to define feature test macros to enable various
system functionality in system headers. (This is done so to ensure new
identifiers can be added to system headers, without breaking old
programs by causing name conflicts.) This includes macros like
_GNU_SOURCE, _BSD_SOURCE, _POSIX_C_SOURCE etc.
Traditionally, gcc as well as glibc headers implicitly assumed
_GNU_SOURCE if no feature test macros were defined by the user.
clang did this too to ensure compatibility with gcc centric programs
(which in practice includes most Linux programs).
However, it appears recent clang versions started to prefer BSD
traditional function over the POSIX, which switches the definition
of a function used by mp_msg.c:
pid_t getpgrp(void); /* POSIX.1 version */
pid_t getpgrp(pid_t pid); /* BSD version */
mp_msg.c expects the POSIX version, while clang gives us the BSD
version, resulting in a compilation failure.
Solve this by defining _GNU_SOURCE. This requests most features from
system headers, and explicitly prefers POSIX definitions over BSD,
which should fix the compilation issue.
-fomit-frame-pointer is enabled by default with recent gcc and clang
compilers if -O2 is used. It also breaks debugging when optimization is
disabled, so it makes absolutely no sense to have -fomit-frame-pointer
explicitly in the CFLAGS.
Get rid of -ffast-math too. It's little more than cargo-culting, and
might actually break NaN handling and such things.
All wayland only specific routines are placed in wayland_common.
This makes it easier to write other video outputs.
The EGL specific parts, as well as opengl context creation, are in gl_common.
This backend works for:
* opengl-old
* opengl
* opengl-hq
To use it just specify the opengl backend
--vo=opengl:backend=wayland
or disable the x11 build.
Don't forget to set EGL_PLATFORM to wayland.
Co-Author: Scott Moreau
(Sorry I lost the old commit history due to the file structure changes)
Commit 4d016a9 added some configure tests using statement_check.
They wrongly used $_ld_tmp, which causes random failure, depending on
whether the previous test using $_ld_tmp was successful. This happened
because I blindly copied the statement_checks from somewhere else.
Fix them.
Use codec names instead of FourCCs to identify codecs. Rewrite how
codecs are selected and initialized. Now each decoder exports a list
of decoders (and the codec it supports) via add_decoders(). The order
matters, and the first decoder for a given decoder is preferred over
the other decoders. E.g. all ad_mpg123 decoders are preferred over
ad_lavc, because it comes first in the mpcodecs_ad_drivers array.
Likewise, decoders within ad_lavc that are enumerated first by
libavcodec (using av_codec_next()) are preferred. (This is actually
critical to select h264 software decoding by default instead of vdpau.
libavcodec and ffmpeg/avconv use the same method to select decoders by
default, so we hope this is sane.)
The codec names follow libavcodec's codec names as defined by
AVCodecDescriptor.name (see libavcodec/codec_desc.c). Some decoders
have names different from the canonical codec name. The AVCodecDescriptor
API is relatively new, so we need a compatibility layer for older
libavcodec versions for codec names that are referenced internally,
and which are different from the decoder name. (Add a configure check
for that, because checking versions is getting way too messy.)
demux/codec_tags.c is generated from the former codecs.conf (minus
"special" decoders like vdpau, and excluding the mappings that are the
same as the mappings libavformat's exported RIFF tables). It contains
all the mappings from FourCCs to codec name. This is needed for
demux_mkv, demux_mpg, demux_avi and demux_asf. demux_lavf will set the
codec as determined by libavformat, while the other demuxers have to do
this on their own, using the mp_set_audio/video_codec_from_tag()
functions. Note that the sh_audio/video->format members don't uniquely
identify the codec anymore, and sh->codec takes over this role.
Replace the --ac/--vc/--afm/--vfm with new --vd/--ad options, which
provide cover the functionality of the removed switched.
Note: there's no CODECS_FLAG_FLIP flag anymore. This means some obscure
container/video combinations (e.g. the sample Film_200_zygo_pro.mov)
are played flipped. ffplay/avplay doesn't handle this properly either,
so we don't care and blame ffmeg/libav instead.
This function sucks and apparently is not very portable (at least on
mingw, the configure check fails). Also remove the emulation of that
function from osdep/strsep*, and remove the configure check.
vsscanf() is in POSIX, C99, mingw, etc. Further, the implementation in
osdep/vsscanf.c was completely broken, and if it worked, it worked only
by chance.
The check determined whether the argument for .align is in bytes, or
log2(bytes). Apparently it's always in bytes for ELF i386 systems, and
this check is used for x86 inline assembler only. Even if this
assumption should be wrong, it likely won't cause much damage: the
existing code uses it only in the form ".align 4", which means in the
worst case it will try to align to 16 bytes, which doesn't cause any
problems (unless the object file format does not support such a high
alignment).
Update the filters that used this.
Quoting the GNU as manual:
For other systems, including ppc, i386 using a.out format, arm and
strongarm, it is the number of low-order zero bits the location counter
must have after advancement. For example `.align 3' advances the
location counter until it a multiple of 8. If the location counter is
already a multiple of 8, no change is needed.
Change the only usage of HAVE_BUILTIN_EXPECT, demux.h, to use an #ifdef
instead. In theory, a configure check is better, but nobody does it this
way anyway, and we seek to reduce the configure script.
This mainly serves as a fallback for platforms where nothing better is
available; also as a debugging help. Both the audio and video driver are
not first class - the audio driver lacks delay detection, and the video
driver only supports a single YUV color space.
Configure options: --disable-sdl2 to disable SDL 2.0+ detection,
--disable-sdl to disable SDL 1.2+ detection. Both options need to be
specified to turn off SDL support entirely.
Now, extra_ldflags ought to only consider LDFLAGS, and all libraries
shall go into libs_mplayer. In the end, the command line first contains
extra_ldflags, and then libs_mplayer.
So altogether this change has the effect that libraries get added to the
linker command line in the order the configure script checks them.
Previously there was some reordering due to some checks adding libraries
to libs_mplayer and some to extra_ldflags.
Add `mp_find_config_file` to search different known paths and use that in
ass_mp to look for the fontconfig configuration file.
Some incidental changes spawned by this feature where:
* Buffer allocation for the strings containing the paths is now performed
with talloc. All of the allocations are done on a NULL context, but it still
improves readability of the code.
* Move the OSX function for lookup inside of a bundle: this code path was
currently not used by the bundle generated with `make osxbundle`. The plan
is to use it again in a future commit to get a fontconfig config file.
This caused errors like:
core/mplayer.c:4308:5: error: implicit declaration of function 'pthread_win32_thread_detach_np' [-Werror=implicit-function-declaration]
It turns out a pthread.h include was missing. It's not clear why this
used to work (or rather, why it happens only sometimes). Possibly some
libraries or system headers recursively include pthread.h under certain
circumstances or configurations.
Fix missing quoting in configure, which led to broken terminal output.
Closes#6.
libavdevice supports various "special" video and audio inputs, such
as screen-capture or libavfilter filter graphs.
libavdevice inputs are implemented as demuxers. They don't use the
custom stream callbacks (in AVFormatContext.pb). Instead, input
parameters are passed as filename. This means the mpv stream layer has
to be disabled. Do this by adding the pseudo stream handler avdevice://,
whose only purpose is passing the filename to demux_lavf, without
actually doing anything.
Change the logic how the filename is passed to libavformat. Remove
handling of the filename from demux_open_lavf() and move it to
lavf_check_file(). (This also fixes a possible bug when skipping the
"lavf://" prefix.)
libavdevice now can be invoked by specifying demuxer and args as in:
mpv avdevice://demuxer:args
The args are passed as filename to libavformat. When using libavdevice
demuxers, their actual meaning is highly implementation specific. They
don't refer to actual filenames.
Note:
libavdevice is disabled by default. There is one problem: libavdevice
pulls in libavfilter, which in turn causes symbol clashes with mpv
internals. The problem is that libavfilter includes a mplayer filter
bridge, which is used to interface with a set of nearly unmodified
mplayer filters copied into libavfilter. This filter bridge uses the
same symbol names as mplayer/mpv's filter chain, which results in symbol
clashes at link-time.
This can be prevented by building ffmpeg with --disable-filter=mp, but
unfortunately this is not the default.
This means linking to libavdevice (which in turn forces linking with
libavfilter by default) must be disabled. We try doing this by compiling
a test file that defines one of the clashing symbols (vf_mpi_clear).
To enable libavdevice input, ffmpeg should be built with the options:
--disable-filter=mp
and mpv with:
--enable-libavdevice
Originally, I tried to auto-detect it. But the resulting complications
in configure did't seem worth the trouble.
The presence of inttypes.h is guaranteed by POSIX. We don't need to
check for it. We don't need to provide a compatibility header either.
Apparently libc5 systems didn't provide inttypes.h. libc5 is ancient,
unmaintained, and not used by modern Linux systems.
This may result in larger binaries by default, and should be harmless
otherwise. Users are advised to use "make install-strip" if they want
binaries without debug symbols.
--disable-optimization removes -O2 from CFLAGS.
Now --enable-debug only adds -g to CFLAGS, and doesn't disable
optimization anymore.
As an obscure feature, --enable-optimization=<n> adds -O<n> to CFLAGS.
Also remove stray $def_debug from configure.
The --enable-profile switch simply adds -p to the CFLAGS, which enables
gcc's extremely worthless "prof" profiling support. This kind of
profiling is broken on the conceptual level and thus harmful, and even
if you want it, you can enable it manually with --extra-cflags.
Also remove $_march $_mcpu from the CFLAGS code. These variables were
always unset, as the code setting them has been removed earlier.
Now "make install" will never strip the binary. "make install-strip"
always will.
The behavior of --enable-debug is unchanged, other than having no
influence anymore on the install targets.
Libav 0.8.4 is ridiculously old (in relative terms), so I don't know
how many things are broken silently.
Encoding is disabled, because the required API hasn't been added yet.
(On the other hand, the old API can't be used in newer versions.)
This should improve compatibility with ffmpeg 0.11.2 as well, which
didn't define AV_CODEC_ID_SUBRIP yet.
Add building the manpage to the all target (which is also the default
target). This fixes the behavior that "make install" tried to build the
manpage if it wasn't built yet.
Add rst2man detection to configure, and disable rst2man usage in the all
and install targets if it hasn't been found. You can still build or
install the man page manually (by using the install-mpv-man target),
but the all and install targets won't attempt to use rst2man.
Additionally, building/installing the manpage by default can be
explicitly inhibited using the --disable-manpage configure option.
It's possible to avoid rst2man by using "make mpv install-no-man" as
well.
