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.
This removes the rather complicated configure and Makefile parts
related to auto-detecting available languages for manpages and locales.
We don't have non-English manpages or any locales, so this is
pointless. It didn't even work: configure --language=all created an
invalid config.mak that would cause "make install" to fail.
Remove installation of locales. There are no translations at all which
could be installed. Should there ever be someone who is interested in
adding translations, this can be added back in a simpler way.
Rename the --enable-translation configure option to --enable-gettext.
This is what this option really does: enable gettext() use. This may
be interesting for people who want to experiment with localizing mpv,
but is entirely useless for normal use.
Remove detection of the binary codecs directory in configure.
Finish renaming directories and moving files. Adjust all include
statements to make the previous commit compile.
The two commits are separate, because git is bad at tracking renames
and content changes at the same time.
Also take this as an opportunity to remove the separation between
"common" and "mplayer" sources in the Makefile. ("common" used to be
shared between mplayer and mencoder.)
file2string.pl and vdpau_functions.pl are direct ports.
matroska.py was reimplemented as the Parse::Matroska module in CPAN,
and matroska.pl was made a client of Parse::Matroska.
A copy of Parse::Matroska is included in TOOLS/lib, and matroska.pl
looks there first when trying to load the module.
osxbundle.py was not ported since I have no means to verify it.
Python is always available on OSX though, so there is no harm in
removing the check for it on configure.
libavutil: for av_get_packed_sample_fmt()
libavcodec: for avcodec_encode_video2()
It's actually untested whether these are really the minimum required
versions. I didn't want to bump them further yet.
This allows to remove the call to the deprecated `UpdateSystemActivity`. The
additional benefit is power management is disabled only if the video is really
playing. A paused video will not stop the system from idling.
This changes the name of this project to mpv. Most user-visible mentions
of "MPlayer" and "mplayer" are changed to "mpv". The binary name and the
default config file location are changed as well.
The new default config file location is: ~/.mpv/
Remove etc/mplayer.desktop. Apparently this was for the MPlayer GUI,
which has been removed from mplayer2 ages ago.
We don't have a logo, and the MS Windows resource files sort-of require
one, so leave etc/mplayer.ico/.xpm as-is.
Remove the debian and rpm packaging scripts. These contained outdated
dependencies and likely were more harmful than useful. (Patches which
add working and well-tested packaging are welcome.)
ao_dsound.c depended on the same configure check as vo_directx.c, which
was removed in commit 0e2c48a3ce. This accidentally disabled
inclusion of ao_dsound.
Fix it by adding a new check. Also, move it below ao_portaudio on the
auto-select list, as ao_dsound is considered deprecated.
Unrelated to that, move ao_lavc below ao_null to prevent it from being
auto-selected.
Most of these have very limited actual use, or are even entirely
useless. They only serve to bloat the codebase and to make life harder.
Drowning users in tons of barely useful filters isn't exactly helpful
either. Some of these filters were redundant or marked as obsolete.
The dlopen and lua (to be added soon) video filters provide ways to add
custom filters.
Detailed listing for each filter with reasons (with contributions from
divVerent and lachs0r):
1bpp:
Replaced by "scale".
2xsai:
Pixel art scaling algorithm, useless with lossy video.
blackframe:
Not very useful. Apparently one use is combining it with scripts,
that pass the
bmovl:
Weirdly complex and insane (using FIFO commands), questionable use.
cropdetect:
Only sort-of useful when used with scripts, and then it will be
very fragile.
It's probably better to use the dlopen rectangle filter, or to
implement the common use-case in a better way.
decimate:
Not needed/useful with modern video codecs, is an
encoding-only filter.
denoise3d:
"hqdn3d" is better.
detc:
Some of the worse deteleciners.
dint:
Useless, actually crashes. (On an assert in vf.c that is disabled
by default in mplayer-svn.)
dvbscale:
Not even practical, and the same effect can be achieved through
other means.
eq:
Worse/older version of eq2.
field:
Limited use, available as dlopen filter.
fil:
Quoting the manpage:
This filter is very similar to the il filter but much faster,
the main disadvantage is that it does not always work.
Especially if combined with other filters it may produce
randomly messed up images, so be happy if it works but do not
complain if it does not for your combination of filters.
filmdint:
Kind of redundant with pullup, and slightly worse.
fixpts:
Never useful. (Most if not all filters have been fixed for PTS.)
framestep:
Questionable use. For things like creating thumbnails, ffmpeg or
--sstep should be used.
geq:
Limited use, will be redundant with the "lua" filter.
halfpack:
Useless, probably redundant with "scale".
harddup:
Useless.
hue:
Most VOs support this.
il:
Useless.
ivtc:
Another of the worse deteleciners.
kerndeint:
A bad deinterlacer.
lavc:
For DVB output devices. We removed that support.
lavcdeint:
A bad deinterlacer, was already deprecated.
Still available as --vf=pp=fd.
mcdeint:
A broken deinterlacer that uses lavc internals.
ow:
Very slow, barely any quality benefit over "hqdn3d".
palette:
Done by "scale".
perspective:
Files with incorrect perspective are extremely rare. About the
only real-world use for this is keystone correction, which is
usually done in hardware by the projector or by graphics
drivers/compositors.
pp7:
Another useless postprocessing filter with bad and complicated code.
Use libpostprocess with "pp" instead.
qp:
Useless.
remove-logo:
Redundant with delogo, which is better and more practical.
rgbtest:
Useless.
sab, smartblur, boxblur:
Blur filters, redundant to "unsharp".
softskip:
Does nothing.
spp, fspp, uspp:
Useless postprocessing filters. "spp" needs ffmpeg internals.
"fspp" is the optimized version of the "spp" filter (???), while
"uspp" is the slow version (????).
Use libpostprocess with "pp" instead.
telecine:
Evil and useless. Available as dlopen filter for testing
purposes.
test:
Useless.
tfields:
Useless, probably.
tile:
Questionable use. Available as dlopen filter.
tinterlace:
Evil and useless.
yuvcsp:
Probably useless.
yvu9:
Redundant with "scale".
Also remove the following left-over files: vd_null.c, vqf.h
OpenAL is disabled by default, because it supposedly inteferes with
some other configure tests and makes them fail silently.
Previously, --enable-openal followed configure's utterly braindead
semantics and disabled auto detection. However, since OpenAL was
disabled by default, there was no easy way to enable OpenAL at all,
even if it was explicitly requested. Solve this by making
--enable-openal use auto detection.
Remove the following #defines, which should never change in practice:
CONFIG_FAKE_MONO, OUTBURST, FAST_OSD, FAST_OSD_TABLE
The configure script hardcoded these to particular values in config.h.
They could only be changed by manually editing it. I don't think
anyone would want to.
X11_FULLSCREEN
This once did something, but became meaningless years ago and was now
always set to true if the files using it were compiled at all.
Conflicts:
configure
libvo/osd.c
libvo/vo_gl.c
Merged from mplayer2. The OSD defines were already removed in this fork.
Enabling optimization _still_ causes annoyances when using a debugger,
and it increaes compilation times too.
Now --enable-debug basically replaces the -O2 flag with -g.
Remove printing VO modules that were removed earlier, but were enabled
by configure tests that are still needed.
Print "libavcodecs" with the "Codecs: " output.
Probably all of these are supported by libavcodec. Missing things can
be added back.
Also remove qtpalette.h. It was used by demux_mov.c, and should have
been deleted with commit 1fde09db6f.
The main excuse for removing this is that LIVE555 deprecated the API
the mplayer implementation was using. The old API still seems to be
somewhat supported, but must be explicitly enabled at LIVE555
compilation, so mplayer won't always work on any user installation.
The implementation was also very messy, in C++, and FFmpeg support is
available as alternative.
Remove it completely.
Support for internal libdvdread has been removed in commit 41fbcee1f5,
but some bits have been missed in Makefile/configure.
Support for libdvdread as normal library is left unchanged.
While being able to play videos on a framebuffer device would be nice,
I didn't need it, and couldn't even test it (buggy nvidia binary
drivers that disable framebuffers, buggy DirectFB that crashes when
using the X11 backend). It's just dead weight, get rid of it.
vo_directx was very horrible, and by today it's mostly useless. I didn't
remove it, because there was that-guy who told me in amazement how
awesome mplayer was, because it was the only video player fast enough
for fast playback on his system when using vo_directx. Sorry, that-guy.
When the internal mplayer MPEG demuxer was removed (commit 1fde09db),
the default demuxer when using dvdnav was set to libavformat. Now it
turns out that this doesn't work with libavformat. It will terminate
playback right after the audio runs out (instead of looping it like the
video, or whatever it's supposed to do). I'm not sure what exactly the
problem is, but since 1. even mplayer-svn can't handle DVD menus
directly (missing highlights), 2. DVD menus are essentially worthless,
and 3. I don't directly watch DVDs, don't bother with it and remove it.
For basic playback, there's still libdvdread support.
Also, use pkg-config for libdvdread, and drop support for in-tree
libdvdread. Remove support for in-tree libdvdcss as well.
Remove the win32 loader - the win32 emulation layer, as well as the
code for using DirectShow/DMO/VFW codecs. Remove loading of xanim,
QuickTime, and RealMedia codecs.
The win32 emulation layer is based on a very old version of wine.
Apparently, wine code was copied and hacked until it was somehow able
to load a limited collection of binary codecs. It poked around in the
code segment of some known binary codecs to disable unsupported win32
API calls to make them work. Example from module.c:
for (i=0;i<5;i++) RVA(0x19e842)[i]=0x90; // make_new_region ?
for (i=0;i<28;i++) RVA(0x19e86d)[i]=0x90; // call__call_CreateCompatibleDC ?
for (i=0;i<5;i++) RVA(0x19e898)[i]=0x90; // jmp_to_call_loadbitmap ?
for (i=0;i<9;i++) RVA(0x19e8ac)[i]=0x90; // call__calls_OLE_shit ?
for (i=0;i<106;i++) RVA(0x261b10)[i]=0x90; // disable threads
Just to show how utterly insane this code is. You wouldn't want even
your worst enemy to have to maintain this. In fact, it seems nobody
made major changes to this code ever since it was committed.
Most formats can be decoded by libavcodecs these days, and the loader
couldn't be used on 64 bit platforms anyway. The same is (probably)
true for the other binary codecs.
General note about how support for win32 codecs could be added back:
It's not possible to replace the win32 loader code by using wine as
library, because modern wine can not be linked with native Linux
programs for certain reasons. It would be possible to to move DirectShow
video decoding into a separate process linked with wine, like the
CoreAVC-for-Linux patches do. There is also the mplayer-ww fork, which
uses the dshownative library to use DirectShow codecs on Windows.
Since slave mode is not planned to be kept, this VO is useless and I'm
removing it.
This VO was useful for OSX GUIs. Since in cocoa you can't embed views in
windows from other processes, this VO was writing to a sharedbuffer with
mmap. The OSX GUIs would then read from the buffer and render the image
with an external renderer.
If in the future we will want to support GUIs we will need to reasearch the
IOSurface framework. This allows to share kernel managed image data
across processes and integrates well with OpenGL.
The commit 74df1d8e05 (and f752212c62) replaced the configure
endian check with byte order macros defined by standard headers. It
turns out that MinGW-w64 actually doesn't define these macros in the
sys/types.h system header. (I assumed it does, because a quick test
seemed to work. But that was because gcc -W -Wall doesn't warn against
undefined macros. You need -Wundef for that.) MinGW-w64 has a
sys/params.h header defining these macros, but sys/types.h doesn't
include it, so it's useless without special casing the mplayer code.
Add a hack top configure instead. Define the macros directly, and
assume MinGW-w64 only works on little endian machines.
The other changes are basically random typos and superficial oversights.
The removed VO and AO took MPEG data and decoded it with V4L2. I'm not
exactly sure what's the use of this today, but get rid of it.
As far as feeding video data to V4L2 is concerned, there are other
ways. For example, there is this script, that feeds yuv4mpeg formatted
raw video data to V4L2:
https://raw.github.com/umlaeute/v4l2loopback/master/examples/yuv4mpeg_to_v4l2.c
The encoding branch by divverent can handle of these via libavformat.
Note: for some reason, libav/ffmpeg have a GIF muxer only, and no
demuxer. The gif configure checks needef for the mplayer internal gif
demuxer can't be removed yet.
build: Fix vo directx configure check on Cygwin
Without windows.h included syntax errors will
arise inside (some versions of) the ddraw.h header.
The wine-based ddraw.h header was reported to not
have this problems.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34953 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: al
This is required to safely #include inttypes.h in .cpp files.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34231 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: diego
Adding the standard library locations to the search path is doubtful
behavior and unnecessary at least on FreeBSD.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34128 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: diego
This was a horrible little tool to detect the host CPU at build time.
Forgotten in commit 74df1d8e05.
Also remove forgotten codec-cfg entry in .gitignore .
There are still various other RTSP implementations available, such as
libnemesi, live555, and libav. The mplayer native version was a huge
chunk of old unmaintained code.
This was intended for translating filenames from filesystem charset to
the terminal charset. Modern sane platforms use UTF-8 for everything,
and on Windows we use unicode APIs, so this is not needed anymore.
Remove filename_recode, all uses of it, options and configure checks
related to terminal output charset, and code that tries to determine
the same.
Including <malloc.h>, especially if all you want is malloc(), has no
legitimate uses (on sane platforms at least). Remove the check for it,
and remove all uses in the code.
Remove unused check for alloca().
Most of these demuxers and decoders are provided in better form by
libav, while the mplayer builtin ones are essentially unmaintained. The
only legimitate use case for not using the libav ones was working around
libav bugs or bugs related to the way mplayer uses libav. Instead of
trying to keep dead code alive, development effort should go into
improving libav or the mplayer libav glue code.
Note that the libav demuxer have been preferred over the mplayer builtin
ones for a while in mplayer2. There were some exceptions: playing DVDs
with dvdnav or playing network sources. (That's because some stream
modules and network.c requested explicit file formats, such as
DEMUXER_TYPE_MPEG_PS, which mapped to builtin demuxers.) With this
commit, they are switched to use libav. One caveat is that the requested
format is not passed to libavformat, instead we rely on the auto probing
to select the correct libav demuxer (see code in demux_open_stream()).
This used /dev/rtc for timing. /dev/rtc root only by default, and I
have a hard time believing that the standard OS functions are not good
enough. (Even if not, support for POSIX high resolution timers should
be added instead, see clock_gettime() and others.)
The function mp_dbg() was silent if MP_DEBUG was not defined. MP_DEBUG
was defined only if configure was invoked with --enable-debug. Remove
it and make mp_dbg an alias to mp_msg. This has the advantage tha
--enable-debug changes less. (It only adds -g now and disables stripping
the binary on installation.)
Using log levels is the better way to silence annoying debug messages.
mplayer tries to catch all signals by default, and displays a "nice"
crash message if a signal is caught. This is mostly useless for
diagnosing problems, and it's extremely fragile. It's likely to cause
more harm than it possibly solves.
Also remove the current_module variable, which was supposed to give a
hint which submodule was being run. This was far from accurate or
useful.
mplayer also caught SIG_CHILD, and tried to wait for any children. This
potentially gets rid of zombies, but I'm not sure which ones. The only
places that fork(), cache2.c and unrar_exec.c, seem to wait for their
child processes properly. Just get rid of it.
Note that we don't even catch SIGTERM. Maybe this will have to be added
back in order to re-enable screensavers and such when the user
terminates mplayer with ^C on the terminal.
Ancient AMD specific enhancement to the MMX instruction set. Officually
discontinued by AMD.
Note that support for this was already disabled in the previous commit.
This commit removes the actual code.
mplayer had three ways of enabling CPU specific assembler routines:
a) Enable them at compile time; crash if the CPU can't handle it.
b) Enable them at compile time, but let the configure script detect
your CPU. Your binary will only crash if you try to run it on a
different system that has less features than yours.
This was the default, I think.
c) Runtime detection.
The implementation of b) and c) suck. a) is not really feasible (it
sucks for users). Remove all code related to this, and use libav's CPU
detection instead. Now the configure script will always enable CPU
specific features, and disable them at runtime if libav reports them
not as available.
One implication is that now the compiler is always expected to handle
SSE (etc.) inline assembly at runtime, unless it's explicitly disabled.
Only checks for x86 CPU specific features are kept, the rest is either
unused or barely used.
Get rid of all the dump -mpcu, -march etc. flags. Trust the compiler
to select decent settings.
Get rid of support for the following operating systems:
- BSD/OS (some ancient BSD fork)
- QNX (don't care)
- BeOS (dead, Haiku support is still welcome)
- AIX (don't care)
- HP-UX (don't care)
- OS/2 (dead, actual support has been removed a while ago)
Remove the configure code for detecting the endianness. Instead, use
the standard header <endian.h>, which can be used if _GNU_SOURCE or
_BSD_SOURCE is defined. (Maybe these changes should have been in a
separate commit.)
Since this is a quite violent code removal orgy, and I'm testing only
on x86 32 bit Linux, expect regressions.
aclib[_template].c contained inline assembler versions of memcpy using
MMX/SSE/3dnow etc. instructions. It's possible that this gave quite a
speed a decade ago, but it's unlikely to have any use on modern
systems. Also, libc implementations already have their own
optimizations for the native memcpy function.
I did not verify my assumptions eith benchmarks, so I could be wrong.
Also note that some platforms have extremely crappy libc
implementations, and it's well possible that these might suffer from a
major performance loss (hello Windows). Unfortunately, I do not care.
mplayer doesn't use yasm, as or ranlib. They were only needed to
build with internal libav, which is gone.
Also, get rid of nm. nm was used to find out how external symbols are
mangled. Replace this by a platform check in mangle.h. As far as I
know, sane systems don't mangle symbols. Windows prefixes them with
an underscore ("_symbol"). I don't know about OSX.
The win32 emulation code can be used to load Windows binary codecs.
Unfortunately, this code is extremely whacky and unmaintained. It
consists of an ancient copy of wine, that was hacked to death and
back. It does super-whacky stuff like patching the loaded codecs at
fixed memory offsets to make them work.
Not removing yet, because it still has some limited use, and some of
the code is needed to load codecs when running natively on Windows.
(Actually, I only care because mplayer can get video input from the
webcam of that-one-latop under Windows, which I find far too neat to
just kill all the code.)
The previous commit made libass the default OSD renderer. This commit
removes the disabled freetype renderer completely. The commits were
done separately to make rolling back easier, because using libass for
OSD rendering is a risky choice.
Also remove freetype/fontconfig/fribidi code. This is all done by
libass now.
If mplayer is compiled without libass, no OSD is displayed.
The OSD will now be rendered with libass. The old rendering code, which
used freetype/fontconfig and did text layout manually, is disabled. To
re-enable the old code, use the --disable-libass-osd configure switch.
Some switches do nothing with the new code enabled, such as -subalign,
-sub-bg-alpha, -sub-bg-color, and many more. (The reason is mostly that
the code for rendering unstyled subtitles with libass doesn't make any
attempts to support them. Some of them could be supported in theory.)
Teletext rendering is not implemented in the new OSD rendering code. I
don't have any teletext sources for testing, and since teletext is
being phased out world-wide, the need for this is questionable.
Note that rendering is extremely inefficient, mostly because the libass
output is blended with the extremely strange mplayer OSD format. This
could be improved at a later point.
Remove most OSD rendering from vo_aa.c, because that was extremely
hacky, can't be made work with osd_libass, and didn't work anyway in
my tests.
Internally, some cleanup is done. Subtitle and OSD related variable
declarations were literally all over the place. Move them to sub.h and
sub.c, which were hoarding most of these declarations already. Make the
player core in mplayer.c free of concerns like bitmap font loading.
The old OSD rendering code has been moved to osd_ft.c. The font_load.c
and font_load_ft.c are only needed and compiled if the old OSD
rendering code is configured.
This enables playing URLs from libquvi supported streaming sites
directly, e.g. "mplayer http://www.youtube.com/watch?v=...."
Anything opened with mplayer is checked with libquvi. If it looks like
a URL of a supported streaming site, libquvi is used to extract the
media URL, which is then passed to the lower level mplayer code
instead of the HTML URL. Hopefully the libquvi URL checker works well
enough that it doesn't cause any problems with normal URLs, files, or
whatever else mplayer's stream layer accepts.
Add the --libquvi-format option. the option value is directly passed to
libquvi as requested format. The only values that seem to work for any
streaming site seem to be "best" (best quality) and "default" (lowest
quality). The mplayer option defaults to "best" (overriding libquvi's
default).
Outstanding issues:
- Does libquvi checking every opened file really not cause problems?
Should there be a runtime option to disable libquvi use?
(Probably not an issue.)
- Should we check/set the supported protocol? By default libquvi has
support for all protocols enabled. In the worst case, it might return
an URL using a protocol not supported by mplayer, even though it
could extract URLs with other protocols too.
(Probably not an issue.)
- Somehow export metadata (like media title) to the mplayer frontend?
Some of these have only limited use, and some of these have no use at
all. Remove them. They make maintainance harder and nobody needs them.
It's possible that many of the removed drivers were very useful a dozen
of years ago, but now it's 2012.
Note that some of these could be added back, in case they were more
useful than I thought. But right now, they are just a burden.
Reason for removal for each module:
vo_3dfx, vo_dfbmga, vo_dxr3, vo_ivtv, vo_mga, vo_s3fb,
vo_tdfxfb, vo_xmga, vo_tdfx_vid:
All of these are for very specific and outdated hardware. Some
of them require non-standard kernel drivers or do direct HW
access.
vo_dga: the most crappy and ancient way to get fast output on X.
vo_aa: there's vo_caca for the same purpose.
vo_ggi: this never lived, and is entirely useless.
vo_mpegpes: for DVB cards, I can't test this and it's crappy.
vo_fbdev, vo_fbdev2: there's vo_directfb2
vo_bl: what is this even? But it's neither important, nor alive.
vo_svga, vo_vesa: you want to use this? You can't be serious.
vo_wii: I can't test this, and who the hell uses this?
vo_xvr100: some Sun thing.
vo_xover: only useful in connection with xvr100.
ao_nas: still alive, but I doubt it has any meaning today.
ao_sun: Sun.
ao_win32: use ao_dsound or ao_portaudio instead.
ao_ivtv: removed along vo_ivtv.
Also get rid of anything SDL related. SDL 1.x is total crap for video
output, and will be replaced with SDL 2.x soon (perhaps), so if you
want to use SDL, write output drivers for SDL 2.x.
Additionally, I accidentally damaged Sun support, which made me
completely remove Sun/Solaris support. Nobody cares about this anyway.
Some left overs from previous commits removing modules were cleaned up.
Conflicts:
.gitignore
bstr.c
cfg-mplayer.h
defaultopts.c
libvo/video_out.c
The conflict in bstr.c is due to uau adding a bstr_getline function in
commit 2ba8b91a97. This function already existed in this branch.
While uau's function is obviously derived from mine, it's incompatible.
His function preserves line breaks, while mine strips them. Add a
bstr_strip_linebreaks function, fix all other uses of bstr_getline, and
pick uau's implementation.
In .gitignore, change vo_gl3_shaders.h to use an absolute path
additional to resolving the merge conflict.
The player can read codec mapping (codecs.conf) from an external file
or use embedded defaults. Before, the defaults were stored in the
player binary in the form of final already-parsed data structures.
Simplify things by storing the text of the codecs.conf file instead,
and parse that at runtime the same way an external file would be
parsed.
To create the previous parsed form, the build system first compiled a
separate binary named "codec-cfg", which parsed etc/codecs.conf and
then wrote the results as a C data structure that could be compiled
into the program. The new simple conversion of codecs.conf into a C
string is handled by the new script TOOLS/file2string.py.
After removing the codec-cfg binary, HOST_CC is no longer used for
anything. Remove the --host-cc configure option and associated logic.
Also remove the codec2html and codec-cfg-test functionality. Building
those was already broken and nobody cared.
There was a broken 3-character-long "fourcc" entry in etc/codecs.conf.
This happened to be accepted before but triggered a parse error after
the changes. Remove the broken entry and make the parsing functions
explicitly test for this error.
The configure script adds some compiler-specific flags for GCC on OSX.
This was done under a check for compiler binary name not being clang.
Move the test to after $cc_vendor has been determined and check
against that instead.
The previous test worked for clang if you explicitly specified
--cc=clang, but not if the default system "cc" command was used and
mapped to clang. Recent versions of Xcode changed the default compiler
(cc) to clang. This caused a lot of spam from clang, which complained
about the unknown flags when compiling with no explicit --cc option.
The OpenGL autodetection checked for all backends regardless of which
features had been enabled previously. Stop checking for X11 backend if
X11 support is disabled, and stop checking for w32 backend if we are
not on Windows.
This makes the changes in commit 3862d469ae ("configure: OSX: check
for X11 header conflict with corevideo") work as intended. That commit
disabled X11 when a header conflict was detected, but the GL X11
backend could still be autodetected despite that and trigger a
compilation failure.
This AO has potential to be useful on platforms other than Linux. On
Windows in particular, PortAudio can make use of newer/better audio
APIs like WASAPI, instead of DirectSound.
As an implementation choice, the PortAudio callback API was used. The
blocking API might be a better match for mplayer's requirements, but
caused severe problems on Linux/ALSA (possibly PortAudio bugs).
Conflicts:
bstr.c
bstr.h
libvo/cocoa_common.m
libvo/gl_common.c
libvo/video_out.c
mplayer.c
screenshot.c
sub/subassconvert.c
Merge of cocoa_common.m done by pigoz.
Picking my version of screenshot.c. The fix in commit aadf1002f8 will
be redone in a follow-up commit, as the original commit causes too many
conflicts with the work done locally in this branch, and other work in
progress.
Check that headers from ApplicationServices and X11 do not conflict
before enabling X11 support on OSX. Both headers would be included in
vo_corevideo.m (through QuartzCore/QuartzCore.h and gl_common.h). The
conflict exists on versions of Mac OSX prior to 10.7, where
ApplicationServices includes the deprecated QuickDraw framework,
resulting in a clash on the Cursor type definition.
Run dlopen on the OpenGL dynamic library instead of on the binary.
This should prevent crashes due to function conflicts when X11/lGL is
linked.
Remove mutual exclusion of the X11 and Cocoa backends.
Add code to wake up the select() call in input.c when an OSX event is
available and a Cocoa OpenGL backend is initialized.
Fixes the slow response to input or other events in Cocoa-based VOs
during long select() sleeps (e.g., when mplayer2 is paused) introduced
by commit 7040968.
This OSX video output is replaces the previous shared_buffer mode of
vo_corevideo. It manages a shared buffer and a Cocoa distributed
object to communicate with GUIs.
Splitting this code into a separate VO allows to get rid of harmful
code coupling, performance inefficiencies (useless image memory
copies) and ugly code (big if-else conditionals).
Change vo_corevideo to use cocoa_common to create and manage the
window. This doesn't affect external OSX GUIs, since they don't use
vo_corevideo window management, but only read the image data from the
shared buffer.
The --enable-debug and --enable-profile options set their own compiler
flags, completely different from normal flag selection. These flags
sucked; especially '-W' (an obsolete alias for '-Wextra') generated a
huge number of irrelevant warnings. Change configure to only add "-g"
or similar to the flags that would be used otherwise.
This new vo is heavily based on vo_gl.c. It provides better scale
filters, dithering, and optional color management with LittleCMS2.
It requires OpenGL 3.
Many features are enabled by default, so it will be slower than vo_gl.
However, it can be tuned to behave almost as vo_gl.
The recommended way to get function pointers to the functions in the
OpenGL library is through dlopen/dlsym/dlclose. This causes problems
in the Cocoa OpenGL backend when -lGL (X11's OpenGL headers) is linked
to the binary together with -framework OpenGL.
The linked OpenGL symbols are always from -lGL, causing all the
function pointers to point to null when getFunctions is called against
a Cocoa OpenGL context.
For this reason change the configure autodetection code to disable
the vo_gl X11 backend when cocoa is active.
This video output is not useful anymore. It is based on Carbon to draw
the mplayer window and this has been deprecated by Apple in 10.5.
The upcoming 10.8 OSX release should deprecate most of Carbon, so it
doesn't make sense to keep vo_quartz in the codebase when there are
modern and better alternatives (vo_gl and vo_corevideo).
macosx_finder_args was using Carbon and wasn't usable any longer on
modern versions of MacOSX. This is very useful to embed mplayer in a
mac application bundle.
When using application bundles, the operating system will call the
main function with only one argument that identifies the process
serial number (this is some additional process identifier in osx other
than the pid). File open events are then dispatched to the application
through events that must be handled accordingly.
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.
Alexander Preisinger
wm4
Uoti Urpala
Rudolf Polzer
Stefano Pigozzi
Kovensky
mplayer-svn
wm4
Thomas Orgis
Rico Tzschichholz
diego