Latest liblivemedia version disables APIs we need. The code still
exists in the library and the changelog says the old interface can be
enabled with "#define RTSPCLIENT_SYNCHRONOUS_INTERFACE". However, the
code on the library side is disabled by default too, and seems to be
disabled in distro packages, so defining that in the player does not
help (just delays the failure until link time). It's possible the
distro packages will be changed to enable this, but since dropping
live555 support is desirable anyway, change configure to disable
support by default at least for now.
The live555 code is the only part of the source that's in C++.
Including C headers in code compiled as C++ has caused issues at
times, so deleting this code would have a maintenance benefit.
Reportedly the rtsp support in Libav has improved, so there should
be less need for live555.
This makes MinGW redirect certain stdio functions (such as the sprintf
family) from the MSVCRT libc to a standard compliant MinGW
implementation.
This fixes a crash in talloc.c when compiling mplayer with MinGW-w64.
The problem is most likely with talloc_vasprintf(), which calls
vsnprintf with a small buffer and checks its return value to find out
how much space the formatted string requires. Without this commit,
vsnprintf would always return -1, and then the code calls abort().
(lachs0r figured out this one.)
If --enable-cross-compile is specified, passing
--target=i686-w64-mingw32 for example will check if
i686-w64-mingw32-gcc can be used. This is only done if the compiler
isn't specified via --cc or the CC environment variable.
The same is done for some other build tools, such as pkg-config.
(Only the C compiler will try to use a fallback in this case.)
This didn't work very well when cross compiling from Linux to Windows:
it tries to execute an .exe file, which succeeds if wine is installed.
As consequence it detects "no" as result.
In general this won't work if emulation for the target architecture is
available. Remove it.
When the build wrapper repo scripts run configure they set a custom
PKG_CONFIG_PATH environment variable. Show the value of this in
config.log to make it easier to rerun configure with a tweaked version
of the same parameters. Also show CFLAGS if set, as it's likely to
break things.
Remove "Please check mtrr settings at /proc/mtrr" and "NOTE: Win32
codec DLLs are not supported on your CPU" messages printed at the end
of a configure run. mtrr should be irrelevant on today's machines, and
the DLLs are a lot less important nowadays. Also remove mtrr detection
logic that was only used to decide whether or not to print that
message. Bizarrely, there were --enable-mtrr and --disable-mtrr
options for this too (with no effect except for the message).
libpostproc has been removed from Libav and the library now exists as
a separate project. Because it's not essential, separate it from the
Libav library check and allow compiling without it.
Add helper function pkg_config_add() that checks for the presence of a
package and also adds cflags/ldflags if it is found. Change existing
pkg-config-using feature tests to use that. Also change the freetype
test that used a separate libfreetype-config binary before; using
pkg-config instead helps cross-compiling. Drop other kinds of checks
(such as test compiles) from these tests. It's possible that this
could cause problems on some (broken) systems, but that can't be
verified without user testing.
Change various code to use the latest Libav API. The libavcodec
error_recognition setting has been removed and replaced with different
semantics. I removed the "--lavdopts=er=<value>" option accordingly,
as I don't think it's widely enough used to be worth attempting to
emulate the old option semantics using the new API. A new option with
the new semantics can be added later if needed.
Libav dropped APIs that were necessary with all Libav versions
until quite recently (like setting avctx->age), and it would thus not
be possible to keep compatibility with previous Libav versions without
adding workarounds. The new APIs also had some bugs/limitations in the
recent Libav release 0.8, and it would not work fully (at least some
avcodec options would not be set correctly). Because of those issues,
this commit makes no attempt to maintain compatibility with anything
but the latest Libav git head. Hopefully the required fixes and
improvements will be included in a following Libav point release.
Require versions of the Libav libraries corresponding to Libav release
0.7. These are:
libavutil 51.7.0
libavcodec 53.5.0
libavformat 53.2.0
libswscale 2.0.0
libpostproc 52.0.0
Also disable the fallback to simple header check if these libraries
could not be found with pkg-config; now compiling without pkg-config
support for these always requires explicitly setting --enable-libav
and any needed compiler/linker flags. The simple check would have let
compilation proceed even if a version mismatch was detected.
Add native Cocoa code to display an OpenGL window. Some of the code is
based on the OpenGL parts of vo_corevideo but I took the time to remove
old code based on Carbon.
There is autodetection in the configure script but you can use
--enable[disable]-cocoa to enable[disable] this.
Something like the OSD menu functionality could be useful. However the
current implementation has several problems and would require a
relatively large amount of work to get into good shape. As far as I
know there are few users of the existing functionality. Nobody is
working on the existing code and keeping it compiling at all while
changing other code would require extra work. So delete the menu code
and some related code elsewhere that's used by nothing else.
Delete the vo_gl2 and vo_matrixview implementations.
vo_gl2 was barely useful anymore. It was a hack based on an old
vo_gl.c version, and all it did differently was rendering the video in
tiles instead of using a single texture. That made it work with some
crappy OpenGL implementations. These days all GPUs support textures of
at least 2048x2048 pixels, which is enough for HD playback. On the
other hand, gl2 suffered from various bugs and deficiencies, all of
which are fixed in gl. Its existence also confused users; many thought
that gl2 is the next version of gl and attempted to use it, even
though it's much worse than gl and they should have used that instead.
Should it turn out that tiling is actually useful, it should be
implemented in vo_gl, instead of keeping vo_gl2 alive.
vo_matrixview was a toy that couldn't even properly display a video.
All it did was display a screensaver-like animation that showed "a
Matrix-like running-text effect". (mplayer is not a screensaver.)
Codec selection for audio and video decoding had a "dynamic plugin"
feature that tried to load a shared library for any codec that had not
been enabled at compilation (disabled by default, but could be enabled
with --enable-dynamic-plugins configure switch; for unknown reasons
some distro packages have enabled it). The implementation was buggy
and could cause normal codec selection fallback to fail if the feature
was enabled. I'm not aware of any real uses of such dynamic plugins
and the feature seems questionable anyway (there are no ABI guarantees
that would make it safe to use). Remove the buggy feature.
Use the "--print-errors" flag of pkg-config when testing for the
presence of Libav libraries. Even though the error output is a bit
messy (printed on the same "Checking for"... line), it does contain
useful information for this test which checks for several libraries at
once.
Also change the test name from "FFmpeg" to "Libav" and rename the
option from --disable-ffmpeg to --disable-libav. The change should
cause no compatibility problems as the option is very rarely used.
Before there was no attempt to set warning flags sanely when compiling
with clang. Set some reasonable defaults that cut down noise and
enable various non-default warnings that are enabled with GCC too.
I'm not sure whether clang is supposed to support more of the options
now used with GCC - it accepts some of those options but they
apparently have no effect; I didn't find any real documentation about
the individual warnings.
The name of the project is "libass". "ASS" alone refers only to the
subtitle format, not the library, and --disable-ass did not completely
disable handling of subtitles in this format - only advanced rendering
with libass. Thus --disable-libass is a better name.
Do a proper calculation of free RAM to be used as V4L buffers.
The code uses sysinfo to query the available RAM, however it used
ancient form available in some early development 2.3.x kernels.
Newer form reports the size in memory units (usually same as page size),
as result the code would fall back on 2 buffers even on multi GB system.
The commit does: Improve the check in configure to ensure that we
do use sysinfo struct with present mem_unit. Use free RAM instead of
total RAM (to avoid swapping). Tweak memory constants and simplify code.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33732 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix "sse in cpuinfo implies mmxext" hack to still work when
--disable-sse is used.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33714 b3059339-0415-0410-9bf9-f77b7e298cf2
Add -Werror-implicit-function-declaration to the default compiled
flags used with GCC. Add the option through a new variable ERRORFLAGS
instead of the existing WARNFLAGS to avoid using it in configure
tests. I think it's overall preferable not to fail tests because of
the warning - in some case this could cause a compilation failure
later, but on the other hand it could be just an unreliable test
triggering the warning and even if it does fail those are likely cases
worth closer investigation.
Only set NEED_GLOB on Windows, as currently this has the effect of
compiling win32-only code - and even if that compiled it would not be
used anyway, since mf.c uses glob under "#if defined(HAVE_GLOB) ||
defined(__MINGW32__)".
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33587 b3059339-0415-0410-9bf9-f77b7e298cf2
Set host_cc after cross-compile check. This allows to set "cc" as a
more sensible, almost always working default when cross-compiling
instead of using the cross-compiler as host-cc which is just
nonsense.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33580 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix _libcdio staying on "auto" if cdparanoia test succeeded before.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33555 b3059339-0415-0410-9bf9-f77b7e298cf2
Make features depending on X check its availability at their
individual checks rather than having the X11 check disable them if
needed. This makes each individual feature check self-contained, which
is desirable.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33371 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove checks for compiler support of >= 10 assembler operands and
named assembler arguments. Just assume the features are always
available. These features were only missing from obsolete GCC versions
which are not supported any more.
Due to libavcodec changes vo_xvmc would have needed some modifications
to keep working. However, I think there's little real demand for XvMC,
so I'll just drop XvMC support. XvMC only supported MPEG-2, making it
of very limited usefulness nowadays, plus the vo_xvmc implementation
was not high quality and never worked particularly well or reliably
anyway.
Change the behavior of the iconv, freetype, fontconfig and libass
tests when autodetection fails. They now abort instead of silently
creating a crippled build. Users who really want to build without
those features can use explicit --disable flags.
If --enable-3dfx is specified but dga is not available then 3dfx is
disabled nonetheless. However, this disabling is not done properly,
and libvo/vo_3dfx.c is still compiled (but cannot be used). Fix.
The behavior of automatically disabling vo_3dfx despite --enable-3dfx
is itself questionable, but I'm not changing that now.
Remove --with-glib-config, --with-gtk-config, --enable-gui,
--disable-gui, --enable-gtk1, --disable-gtk1. The only one of these
that still had any effect was --enable-gui which printed a warning
about GUI removal and exited. The --with options were still shown in
help output, the rest had already been deleted from that.
Delete mp3lib which has been the default mp3 decoder until now. In
addition to being an unnecessary embedded library it now fails to
compile correctly with the new gcc-4.6, producing noise.
After the deletion the default decoder priority for mp3 will be first
libmpg123 (a newer version of the code that mp3lib was based on) if
available, then ffmp3float which should be available in all normal
compiles. I think that some tweaking may be required as these decoder
alternatives get wider testing, but any problems should be solvable
and there should be no need for mp3lib.
Windows pthreads requires certain functions to be called to initialize
itself. It can do that through DllMain but no such luck when linked
statically; mplayer needs to call the initialization explicitly.