In commit 94782e464d, code was added to remove the first
command line argument. (Because that is essentially useless.) The code
for printing with command line on -v still assumed the first argument
should be skipped.
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.
The terminal status line (showing playback status etc.) was too long
for the standard 80 column width in some cases. Shorten the output by
abbreviating some fields with single letters.
Change "(PAUSED!)" to "(Paused)". This looks nicer.
Move the speed field forward and omit the explicit "header". It's
probably intuitively clear that "x2.00" means double speed.
The field showing the playback time in seconds was padded with spaces.
This just takes space away and wasn't really needed.
This was a hack for .mov reference files. The mov demuxer, which
triggered this code, has been removed in commit 1fde09db6f.
The code serves no purpose anymore, and it was bogus in the first
place. (This mov feature should have been handled either by the core's
timeline support, or as normal playlist.)
It's not clear why this video filter supported OSD rendering.
The manpage says:
"Can be used for placing subtitles/OSD in the resulting black bands."
But every single VO already does this if vf_expand adds black borders.
This feature is 100% pointless.
Commit 7484ae8e2e attempted to introduce two ass_library handles
(as it was needed to deal with how ass_library manages fonts), but the
commit was completely bogus: it assumed osd_state->ass_library would be
used by osd_libass.c only, which is not the case. As result, some of the
subtitle code used the wrong ass_library handle.
We need two ass_library handles in osd_state. The one from the mplayer
core for subtitles (osd_state->ass_library), and one for OSD rendering
(osd_state->osd_ass_library).
osd_libass.c used the same ASS_Library object as the player core. This
caused a problem: when playing a new file, all fonts loaded by the
ASS_Library object were unloaded, including the OSD font. Parts of the
OSD would stop being rendered correctly.
Solve this by creating a separate ASS_Library, with its own set of
fonts.
Commit 168293e0ae assumed the OSD drawing routines (which have the
functions osd_draw_text/_ext as entrypoint) would always be called, and
relied on that to reset the change flag.
Some VOs, such as vo_null, didn't do this. Pausing could turn into
endless framestepping in some cases. Restore the part of the OSD drawing
logic that dealt with this. (Alternatively, the VOs could be obliged to
always call the OSD drawing routines, even if the VO doesn't actually
draw the OSD. But it seems even more messy to rely on that.)
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.
Options parsing used to be ambiguous, as in the splitting into option
and values pairs was ambiguous. Example:
-option -something
It wasn't clear whether -option actually takes an argument or not. The
string "-something" could either be a separate option, or an argument
to "-option". The code had to call the option specific parser function
to resolve this.
This made everything complicated and didn't even have a real use. There
was only one case where this was actually used: string lists
(m_option_type_string_list) and options based on it. That is because
this option type actually turns a single option into a proxy for several
real arguments, e.g. "vf*" can handle "-vf-add" and "-vf-clr". Options
suffixed with "-clr" are the only options of this group which take no
arguments.
This is ambiguous only with the "old syntax" (as shown above). The "new"
option syntax always puts option name and value into same argument.
(E.g. "--option=--something" or "--option" "--something".)
Simplify the code by making it statically known whether an option takes
a parameter or not with the flag M_OPT_TYPE_OLD_SYNTAX_NO_PARAM. If it's
set, the option parser assumes the option takes no argument.
The only real ambiguity left, string list options that end on "-clr",
are special cased in the parser.
Remove some duplication of the logic in the command line parser by
moving all argument splitting logic into split_opt(). (It's arguable
whether that can be considered code duplication, but now the code is a
bit simpler anyway. This might be subjective.)
Remove the "ambiguous" parameter from all option parsing related code.
Make m_config unaware of the pre-parsing concept.
Make most CONF_NOCFG options also CONF_GLOBAL (except those explicitly
usable as per-file options.)
This also requires that the OSD stack related functions carry a pointer
to MPContext.
Free the OSD stack items (mp_osd_msg) at exit by making MPContext the
talloc parent. (E.g. when exiting while something is still displayed on
the OSD.)
The only place exit_player() should be called is the main() function.
exit_player() should be the only function allowed to call exit(). This
makes it easier to guarantee proper deinitialization, and allows using
the --leak-report flag without showing false positives.
The quit slave command now sets a flag only. It uses the same mechanism
that's normally used to advance to the next file on the playlist, so the
rest of the playback path should be able to react to the quit command
quickly enough. That is, the player should react just as fast to quit
requests in practice as before this commit.
In reinit_audio_chain(), the player was actually exited if
init_audio_filters() failed. Reuse the normal error handling path to
handle this condition.
The print_timeline() function actually had contained some code that
changed the MPContext state. Since you wouldn't expect that from a
function named print, move that code out of the function. The
misleading code structure was introduced in commit 6f564fe82b.
Commit 89a17bcda6 simplified the idle loop to run any commands
mplayer receives, not just playlist related commands. Unfortunately, it
turns out many slave commands always assume the presence of a demuxer.
MPContext->demuxer is assumed not to be NULL. This made the player
crash when receiving slave commands like pause/unpause, chapter
control, subtitle selection.
We want mplayer being able to handle this. Any slave command or
property, as long as it's backed by a persistent setting, should be run
successfully, even if no file is being played. If the slave command
doesn't make sense in this state, it shouldn't crash the player.
Insert some NULL checks when accessing demuxers. If sh_video or
sh_audio are not NULL, assume demuxer can't be NULL.
(There actually aren't that many properties which need to be changed. If
it gets too complicated, we could employ alternative mechanisms instead,
such as explicitly marking safe properties with a flag.)
There are different C types for each stream type: sh_video for video,
sh_audio for audio, sh_sub for sub. There is no type that handles all
stream types in a generic way. Instead, there's a macro SH_COMMON, that
is used to define common fields for all 3 stream structs. Accessing
the common fields is hard if you want to be independent from the stream
type.
Introduce an actual generic stream struct (struct sh_stream), which is
supposed to unify all 3 stream types one day. Once all fields defined
by SH_COMMON have been moved into sh_stream, the transition is complete.
Move some fields into sh_stream, and rewrite osd_show_tracks to use
them.
The SH_COMMON lang field seems to be blatantly unreliable and is not
always set by demux_lavf (at least not with dvdnav:// ).
Also fix the same for the show_tracks_osd slave command.
The structure is now as follows:
- main():
* basic initializations (e.g. init_libav() and more)
* pre-parse command line (verbosity level, config file locations)
* load config files (parse_cfgfiles())
* parse command line, add files from the command line to playlist
(m_config_parse_mp_command_line())
* call:
- handle_help_options():
* check each help-related option
* print help if requested
* main() exits if help was requested
* call function that works down the playlist:
- play_files():
* run idle loop (idle_loop()), until there are files in the
playlist or an exit command was given (slave mode only)
* actually load and play a file:
- play_current_file():
* run all the dozens of functions to load the file
and initialize playback
* run a small loop that does normal playback, until
the file is done or a slave command terminates
playback
(each iteration, run_playloop() is called)
* uninitialize playback
* determine next entry on the playlist to play
* loop
* call exit_player_with_rc() (there are many other places which
use this function, though)
This is about the vo_x11_init_state() call. It basically opens a X11
connection. It's called in the main() function once. It's not really
clear why this isn't done on VO creation instead. Maybe one reason was
that --no-fixed-vo used to be the default: when playing a new file, the
full VO state would be free'd and recreated. Keeping the X11 connection
possibly improved things, although the question is how. In summary,
there is no good reason to do this, and it only adds platform specific
details to the player frontend.
Do the X11 initialization in the respective VOs instead.
The intention is to make the main() function smaller (which is at
about 1000 lines currently).
This commit also changes the order of some initializations, but that
should be safe.
Remove variable that is only assigned but never used.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34791 b3059339-0415-0410-9bf9-f77b7e298cf2
Allow using a cache size of up to 4 TB.
Obviously anything close to 4 GB will always fail
on 32 bit systems.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34792 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace off_t by int64_t in cache code.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34793 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove casts that are no longer necessary.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34794 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix header file after r34793.
Patch by Stephen Sheldon, sfsheldo gmail com.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34802 b3059339-0415-0410-9bf9-f77b7e298cf2
Put #include <inttypes.h> into the header file where it should be.
Reported by Stephen Sheldon, sfsheldo gmail com.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34798 b3059339-0415-0410-9bf9-f77b7e298cf2
Correct r34798.
The header only needs stdint.h while the C file needs inttypes.h.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34799 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Teletext requires special OSD support. Because I can't even test
teletext, I can't restore support for it. Since teletext can be
considered ancient and obscure, and since it doesn't make sense to keep
the remaining teletext code without being able to use it, I'm removing
it.
The --title option, which sets the GUI window caption, is now expanded
as slave mode property string (like osd_show_property_text). Make the
default value for --title include the filename. This makes a behavior
similar to --use-filename-title the default.
Remove the --use-filename-title option, as it's redundant now.
vo_osd_changed() was a weird function: it was used both to query and
mutate state, which is a bad combination. The VOs used it to query
and reset the state, and the mplayer frontend mostly used it to set
the state. In some cases, the frontend did both (that code used a
variable "int hack" to backup the state and set it again).
Simplify it and make the VOs use a vo_osd_has_changed() function to
query whether the OSD bitmaps have to be recreated. vo_osd_changed()
on the other hand is now used to update state only. The OSD change
state is reset when osd_draw_text() is called.
Update vo_corevideo.m to use vo_osd_resized() as well (forgotten change
from libass-OSD merge).
Simplify osd_set_text() and its usages.
This was done with the help of callcatcher [1]. Only functions which
are statically known to be unused are removed.
Some unused functions are not removed yet, because they might be needed
in the near future (such as open_output_stream for the encode branch).
There is one user visible change: the --subcc option did nothing, and is
removed with this commit.
[1] http://www.skynet.ie/~caolan/Packages/callcatcher.html
The code to format the playback time was duplicated a few times. There
were also minor differences in how the time is formatted. Remove most
of these differences. This also fixes a bug in the output of the
osd_show_progression command, introduced in 74e7a1e937.
There was some logic to display the percent position in the OSD status
for a short while after seeking. Remove that logic and always display
the percent position.
Make --osd-fractions a flag option. This removes the ability to show
the number of frames played since the start of the current second
(i.e. the fraction of the time was turned into a frame number). This
features wasn't so great anyway, because modern video file formats
don't always have a (valid) FPS set, and could lead to inaccurate
display.
Still to sort out:
Unfortunately, the terminal status is still formatted differently from
the OSD, and even worse, it has a completely different time source.
Not sure if I like how the status line looks now (it's a bit "full"?).
Maybe it will be changed again later.
Summary:
- There is no playtree anymore. It's reduced to a simple list.
- Options are now always global. You can still have per-file options,
but these are optional and require special syntax.
- The slave command pt_step has been removed, and playlist_next
and playlist_prev added. (See etc/input.conf changes.)
This is a user visible incompatible change, and will break slave-mode
applications.
- The pt_clear slave command is renamed to playlist_clear.
- Playtree entries could have multiple files. This is not the case
anymore, and playlist entries have always exactly one entry. Whenever
something adds more than one file (like ASX playlists or dvd:// or
dvdnav:// on the command line), all files are added as separate
playlist entries.
Note that some of the changes are quite deep and violent. Expect
regressions.
The playlist parsing code in particular is of low quality. I didn't try
to improve it, and merely spent to least effort necessary to keep it
somehow working. (Especially ASX playlist handling.)
The playtree code was complicated and bloated. It was also barely used.
Most users don't even know that mplayer manages the playlist as tree,
or how to use it. The most obscure features was probably specifying a
tree on command line (with '{' and '}' to create/close tree nodes). It
filled the player code with complexity and confused users with weird
slave commands like pt_up.
Replace the playtree with a simple flat playlist. Playlist parsers that
actually return trees are changed to append all files to the playlist
pre-order.
It used to be the responsibility of the playtree code to change per-file
config options. Now this is done by the player core, and the playlist
code is free of such details.
Options are not per-file by default anymore. This was a very obscure and
complicated feature that confused even experienced users. Consider the
following command line:
mplayer file1.mkv file2.mkv --no-audio file3.mkv
This will disable the audio for file2.mkv only, because options are
per-file by default. To make the option affect all files, you're
supposed to put it before the first file.
This is bad, because normally you don't need per-file options. They are
very rarely needed, and the only reasonable use cases I can imagine are
use of the encode backend (mplayer encode branch), or for debugging. The
normal use case is made harder, and the feature is perceived as bug.
Even worse, correct usage is hard to explain for users.
Make all options global by default. The position of an option isn't
significant anymore (except for options that compensate each other,
consider --shuffle --no-shuffle).
One other important change is that no options are reset anymore if a
new file is started. If you change settings with slave mode commands,
they will not be changed by playing a new file. (Exceptions include
settings that are too file specific, like audio/subtitle stream
selection.)
There is still some need for per-file options. Debugging and encoding
are use cases that profit from per-file options. Per-file profiles (as
well as per-protocol and per-VO/AO options) need the implementation
related mechanisms to backup and restore options when the playback file
changes.
Simplify the save-slot stuff, which is possible because there is no
hierarchical play tree anymore. Now there's a simple backup field.
Add a way to specify per-file options on command line. Example:
mplayer f1.mkv -o0 --{ -o1 f2.mkv -o2 f3.mkv --} f4.mkv -o3
will have the following options per file set:
f1.mkv, f4.mkv: -o0 -o3
f2.mkv, f3.mkv: -o0 -o3 -o1 -o2
The options --{ and --} start and end per-file options. All files inside
the { } will be affected by the options equally (similar to how global
options and multiple files are handled). When playback of a file starts,
the per-file options are set according to the command line. When
playback ends, the per-file options are restored to the values when
playback started.
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.
This had very limited usefulness, and you're much better off using
ffmpeg directly. Even if that should not be sufficient, the mplayer
encoding branch might provide a better way out.
Pausing the player used to print the message "===== PAUSE =====". It
also inserted a newline for some reason. When pausing and unpausing a
lot, the terminal would be clobbered with "old" useless status lines.
Remove the pause message, and display the status message instead. This
looks better, doesn't fill up the terminal with crap, and needs less
code.
Side note: when cache is enabled, the status line is reprinted on every
idle iteration to reflect possible cache changes. If the platform's
WAKEUP_PERIOD is very small (like on Windows) and terminal output is
slow (like on Windows), it's possible that this leads to a minor
performance degradation. This is probably not a problem (and I don't
care anyway), but maybe something that should be kept in mind.
Disabling the status line with --quiet will help.
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()).
Instead of displaying audio and video separately, there's now one
position printed. The idea is that displaying both audio and video
position is redundant. The A/V synchronisation is still printed, so
that you can see if the video time is off.
Also, always print the duration of the file, not only when playing
audio only.
Print "ct" (average A/V sync change) and the number of dropped frame
only if they're significant.
Remove output of outdated and crapified things, like frame position
(these can't be reasonably done with modern media formats, and the
playback code paths for these don't touch them).
This will break some slave mode applications, because they attempt to
parse the status line.
The code used for benchmarking and showing CPU stats in the status line
was inaccurate, misleading and fragile. The final nail in the coffin is
the fact that many libav decoders are multithreaded now, and mplayer
couldn't possibly measure the CPU time consumed by them.
Add the --untimed option. This makes the video untimed, just like
--benchmark did (still requires disabling audio synchronization).
The msg level for the version output is elevated to verbose. When
running mplayer without arguments, the version is printed a second
time (with default msg level) before the help output.
When playing a file, users (i.e. me) expect mplayer to print a list of
video/audio/subtitle streams. Currently, this is done in each demuxer
separately. This also means the output is formatted differently
depending which demuxer is active.
Add code to print an uniformly formatted streams list in the player
front end. Extend the streams headers to export additional information
about the streams. Change the lavf and mkv demuxers to follow this new
scheme, and raise the log level for the "old" printing functions.
The intention is to make every demuxer behave like this eventually.
The stream list output attempts to provide codec information. It's a
bit hacky and doesn't always provide useful output, and I'm not sure
how to do it better.
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.)
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.
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.
Change the "main" name from "mplayer2" to "mplayer". Note that upstream
mplayer2 uses "MPlayer2", and mplayer uses "MPlayer", so it's
unambiguous.
The version.sh script used to put the latest tag into the version
script. The intention was to add a new tag on each release, but this
hasn't been done in over a year, making the tag absolutely pointless.
Remove it. Now "git-SHORTHASH" is used.
Remove the string "MPlayer & mplayer2 teams" after the copyright date,
because that sounded silly.
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.
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.
There was some confusion about the "flags" field in demuxer packets.
Demuxers set it to either 1 or 0x10 to indicate a keyframe (and the
field was not used to indicate anything else). This didn't cause
visible problems because nothing read the value. Replace the "flags"
field with a boolean "keyframe" field. Set AV_PKT_FLAG_KEY based on
this field in packets fed to libavcodec video decoders (looks like PNG
and ZeroCodec are the only ones which depend on values from demuxer;
previously this was hardcoded to true for PNG).
Make demux_mf set the keyframe field in every packet. This matters for
PNG files now that the demuxer flag is forwarded to libavcodec.
Fix logic setting the field in demux_mkv. It had probably not been
updated when adding SimpleBlock support. This probably makes no
difference for any current practical use.
Add support for using libavcodec decoders that do not have entries in
codecs.conf. This is currently only used with demux_lavf, and the
codec selection is based on codec_id returned by libavformat. Also
modify codec-related terminal output somewhat to make it use
information from libavcodec and avoid excessively long default output.
The new any-lavc-codec support is implemented with codecs.conf entries
that invoke vd_ffmpeg/ad_ffmpeg without directly specifying any
libavcodec codec name. In this mode, the decoders now instead select
the libavcodec codec based on codec_id previously set by demux_lavf
(if any). These new "generic" codecs.conf entries specify "status
buggy", so that they're tried after any specific entries with
higher-priority status.
Add new directive "anyinput" to codecs.conf syntax. This means the
entry will always match regardless of fourcc. This is used for the
above new codecs.conf entries (so the driver always gets to decide
whether to accept the input, and will fail init() if it can't find a
suitable codec in libavcodec). Remove parsing support for the obsolete
codecs.conf directive "cpuflags". This directive has not had any
effect and has not been used in default codecs.conf since many years
ago.
Shorten codec-related terminal output. When using libavcodec decoders,
show the libavcodec long_name field rather than codecs.conf "info"
field as the name of the codec. Stop showing the codecs.conf entry
name and "vfm/afm" name by default, as these are rarely needed;
they're now in verbose output only. Show "VIDEO:" line at VO
initialization rather than at demuxer open. This didn't really belong
in demuxer code; the new location may show more accurate values (known
after decoder has been opened) and works right if video track is
changed after initial demuxer open.
The vd.c changes (primarily done for terminal output changes) remove
round-to-even behavior from code setting dimensions based on aspect
ratio. I hope nothing depended on this; at least the even values were
not consistently guaranteed anyway, as the rounding code did not run
if the video file did not specify a nonzero aspect value.
written_audio_pts() can be called even if no audio track is active (at
least through get_current_time() when there's no known video PTS).
This triggered a crash due to NULL dereference. Add a check to return
MP_NOPTS_VALUE if no audio track exists.
Also remove a questionable update_osd_msg() call from per-file
initialization code. The call was at a point where an audio track
might be selected but not properly initialized, possibly also causing
a crash if update_osd_msg() queries current position. I don't see any
reason why the call would have been needed; it should get called
anyway before OSD contents are actually used for the new file.
Add an alternate mode for option parser objects (struct m_config)
which is not inherently tied to any particular instance of an option
value struct. Instead, this type or parsers can be used to initialize
defaults in or parse values into a struct given as a parameter. They
do not have the save slot functionality used for main player
configuration. The new functionality will be used to replace the
separate subopt_helper.c parsing code that is currently used to parse
per-object suboptions in VOs etc.
Previously, option default values were handled by initializing them in
external code before creating a parser. This initialization was done
with constants even for dynamically-allocated types like strings.
Because trying to free a pointer to a constant would cause a crash
when trying to replace the default with another value, parser
initialization code then replaced all the original defaults with
dynamically-allocated copies. This replace-with-copy behavior is no
longer supported for new-style options; instead the option definition
itself may contain a default value (new OPTDEF macros), and the new
function m_config_initialize() is used to set all options to their
default values. Convert the existing initialized dynamically allocated
options in main config (the string options --dumpfile, --term-osd-esc,
--input=conf) to use this. Other non-dynamic ones could be later
converted to use this style of initialization too.
There's currently no public call to free all dynamically allocated
options in a given option struct because I intend to use talloc
functionality for that (make them children of the struct and free with
it).
When using an audio output without a native playback rate (such as
ao_pcm), the code plays audio further when the current write position
is behind video. After support for continuing audio after the end of
video was added, this could cause a deadlock: audio was not played
further, but neither was EOF triggered. Fix the code to properly
handle playback of remaining audio after video ends in the untimed
audio case (audio-only case was not affected, only the case where a
video stream exists but ends before the audio stream).
Each option type had three separate operations to copy option values
between memory locations: copy between general memory locations
("copy"), copy from general memory to active configuration of the
program ("set"), and in the other direction ("save"). No normal option
depends on this distinction any more. Change everything to define and
use a single "copy" operation only. Change the special options
"include" and "profile", which depended on hacky option types, to be
special-cased directly in option parsing instead. Remove the now
unused option types m_option_type_func and m_option_type_func_param.
Handle -v flags as a special case in command line preparsing stage,
and change the option entry into a dummy one. Specifying "v" in config
file no longer works (and the dummy entry shows an error in this
case); "msglevel" can still be used for that purpose. Because the flag
is now interpreted at an earlier parsing stage, it now affects the
printing of some early messages that were only affected by the
MPLAYER_VERBOSE environment variable before.
The main motivation for this change is to get rid of the last
CONF_TYPE_FUNC option.
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.
Conflicts:
command.c
libao2/ao_alsa.c
libao2/ao_dsound.c
libao2/ao_pulse.c
libao2/audio_out.h
mixer.c
mixer.h
mplayer.c
Replace my mixer changes with uau's implementation, which is based on
my code.
MSWindows does not have properly working support for detecting events
on file descriptors. As a result the current mplayer2 code does not
support waking up when new input events occur. Make the central
playloop wake up more often to poll for events; otherwise response
would be a lot laggier than on better operating systems during pause
or other cases where the process would not otherwise wake up.
Make A/V sync at the start of playback with nonzero --delay behave the
same way as it does when seeking to the beginning later, meaning video
plays from the start and audio is truncated or padded with silence to
match timing. This was already the default behavior in case the
streams in the file started at different times, but not if the
mismatch was due to --delay. Trigger similar audio synchronization
when switching to a new video stream. Previously, switching a video
stream on after playing for some time in audio-only mode was buggy and
caused initial desync equal to the duration of prior audio-only
playback.
Uninitialize video and audio outputs when switching to a file without
a corresponding track (audio-only file / file with no sound), or when
entering --idle mode. Switching track choice to "off" during playback
already did this.
It could be useful to have a mode where the video window stays open
even when no video plays, but implementing that properly would require
more than just leaving the window on screen like the code did before
this commit.
The player tried to disable mute before exiting, so that if mute is
emulated by setting volume to 0 and the volume setting is a
system-global one, we don't leave it at 0. However, the logic doing
this at process exit was flawed, as volume settings are handled by
audio output instances and the audio output that set the mute state
may have been closed earlier. Trying to write reliably working logic
that restores volume at exit only would be tricky, so change the code
to always unmute an audio driver before closing it and restore mute
status if one is opened again later.
MPlayer volume control was originally implemented with the assumption
that it controls a system-wide volume setting which keeps its value
even if a process closes and reopens the audio device. However, this
is not actually true for --softvol mode or some audio output APIs that
only consider volume as a per-client setting for software mixing. This
could have annoying results, as the volume would be reset to a default
value if the AO was closed and reopened, for example whem moving to a
new file or crossing ordered chapter boundaries. Add code to set the
previous volume again after audio reinitialization if the current
audio chain is known to behave this way (softvol active or the AO
driver is known to not keep persistent volume externally).
This also avoids an inconsistency with the mute flag. The frontend
assumed the mute status is persistent across file changes, but it
could be similarly lost.
The audio drivers that are assumed to not keep persistent volume are:
coreaudio, dsound, esd, nas, openal, sdl. None of these changes have
been tested. I'm guessing that ESD and NAS do per-connection
non-persistent volume settings.
Partially based on code by wm4.
Current volume was always queried from the the audio output driver (or
filter in case of --softvol). The only case where it was stored on
mixer level was that when turning off mute, volume was set to the
value it had before mute was activated. Change the mixer code to
always store the current target volume internally. It still checks for
significant changes from external sources and resets the internal
value in that case.
The main functionality changes are:
Volume will now be kept separately from mute status. Increasing or
decreasing volume will now change it relative to the original value
before mute, even if mute is implemented by setting AO level volume to
0. Volume changes no longer automatically disable mute. The exception
is relative changes up (like the volume increase key in default
keybindings); that's the only case which still disables mute.
Keeping the value internally avoids problems with granularity of
possible volume values supported by AO. Increase/decrease keys could
work unsymmetrically, or when specifying a smaller than default
--volstep, even fail completely. In one case occurring in practice, if
the AO only supports changing volume in steps of about 2 and rounds
down the requested volume, then volume down key would decrease by 4
but volume up would increase by 2 (previous volume plus or minus the
default change of 3, rounded down to a multiple of 2). Now, the
internal value will keep full precision.
Stop trying to read terminal input if a read attempt returns EOF. The
most important case where this matters is when someone runs the player
with stdin redirected from /dev/null and without specifying
--no-consolecontrols. This used to cause 100% CPU load while paused,
as select() would continuously trigger on stdin (the need for
--no-consolecontrols was not apparent to people with older mplayer
versions, as input reading was less efficient and latencies like
hardcoded sleeps kept CPU use well below 100%). Now this will only
cause a "Dead key input" error message.
Make the code read current real time again after drawing OSD. This
ensures time taken in OSD drawing is properly deducted from the
duration of the following sleep. The main practical effect is to avoid
the A-V field on the status line staying at a value a couple of
milliseconds above 0 (depending on VO).
Fix a missing check that could sometimes result in video frames being
shown after specified end pts (end of timeline segment or --endpos).
Fix mistaken video EOF detection after aspect change in video stream,
when there is no current valid visible frame but the next frame is
already buffered in VO.
For ao_pulse, the current latency is not a good indicator of how soon
the AO requires new data to avoid underflow. Add an internal pipe that
can be used to wake up the input loop from select(), and make the
pulseaudio main loop (which runs in a separate thread) use this
mechanism when pulse requests more data. The wakeup signal currently
contains no information about the reason for the wakup, but audio
buffers are always filled when the event loop wakes up.
Also, request a latency of 1 second from the Pulseaudio server. The
default is normally significantly higher. We don't need low latency,
while higher latency helps prevent underflows reduces need for
wakeups.
Timeline handling converted the pts values from demuxed subtitles to
timeline scale. Change the code to do most subtitle handling in
original subtitle source pts, and instead convert current playback
timeline pts to those units when deciding which subtitle to show.
The main functionality changes are that now demuxed subtitles which
overlap chapter boundaries are handled correctly (at least for libass
subtitles), and external subtitles are assumed to use same pts scale
as current source (this needs improvements later).
Before, a video subtitle that had a duration continuing past the end
of the chapter would continue to be shown for the original duration,
even if the chapter ended and playback switched to a position in the
source where the subtitle shouldn't exist. Now, the subtitle will
correctly end.
Before, external subtitle files were interpreted as specifying pts
values in timeline scale. Now, they're interpreted as specifying pts
values in source file time scale, for _every_ source file. This is
probably more likely to be what the user wants for the "main" source
file in case there is one, but almost certainly not quite right for
multiple source files where the same subs could be shown over
different scenes. If the user wants them to match some main source
file, it's probably still better to have incorrect extra subs for
video from some files than to have every subtitle appearing at the
wrong time. The new code makes it easier to change the interpretation
of the subtitle times, and some configurability should be added in
the future.
When switching to a timeline part from another file, decoders were
reinitialized after doing the demuxer-level seek. This is necessary
for audio because some decoders read from the demuxer stream during
initialization and the previous stream position before seek could have
been at EOF. However, this initialization sequence could lose first
subtitles or first part of audio.
The problem for subtitles was that the seek itself or audio
initialization could already have buffered subtitle packets from the
new position, and the way subtitles are reinitialized flushes packet
buffers. Thus early subtitles could be lost (even if they were demuxed
- unfortunately demuxers may not know about still active subtitles
earlier in the file, but that's another issue). Fix this by moving
subtitle and video reinitialization before the demuxer seek; they
don't have the problems which prevent that for audio.
Audio initialization can already decode and buffer some output.
However, the seek_reset() call done last would then throw away this
buffered output. Work around this by adding an extra flag to
seek_reset().
Restructure parts of the code in the main play loop. The main
functionality difference is that if a video track ends first, now
audio will continue to be played until it ends too.
Now the process also wakes up less often if there's no need to update
video or audio. This will reduce unnecessary wakeups especially when
paused, but may make handling of input events laggier when fd-based
notifications are not supported (like most input on Windows).
Change the terminal status line to show "???" instead of a huge
negative number if audio or video pts is missing (there was a partial
workaround for audio before, but not video or A-V difference).
The name "MPlayer2" isn't used anywhere. It's either "MPlayer" or
"mplayer2". Make it more consistent by using "mplayer2" instead.
Note that the version string passed as network user-agent changes from
"MPlayer" to "mplayer2" as well.
The current code tried to print -1000 as unsigned integer if the
chapter time was unknown. Print -1 instead. This affects only the
-identify output used for slave mode, such as ID_CHAPTER_0_START.
Remove the old EDL implementation that was activated with the --edl
option. It is mostly redundant and inferior compared to the newer
demux_edl support, though currently there's no support for using the
same EDL files with the new implementation and the mute functionality
of the old implementation is not supported. The main reason to remove
the old implementation at this point is that the mute functionality
would conflict with following audio volume handling changes, and
working on the old code would be a wasted effort in the long run as at
some point it would be removed anyway.
The --edlout functionality is kept for now, even though after this
commit there is no code that could directly read its output.
Windows uses a legacy codepage for char* / runtime functions accepting
char *. Using UTF-8 as the codepage with setlocale() is explicitly
forbidden.
Work this around by overriding the MSVCRT functions with wrapper
macros, that assume UTF-8 and use "proper" API calls like _wopen etc.
to deal with unicode filenames. All code that uses standard functions
that take or return filenames must now include osdep/io.h. stat()
can't be overridden, because MinGW-w64 itself defines "stat" as a
macro. Change code to use use mp_stat() instead.
This is not perfectly clean, but still somewhat sane, and much better
than littering the rest of the mplayer code with MinGW specific hacks.
It's also a bit fragile, but that's actually little different from the
previous situation. Also, MinGW is unlikely to ever include a nice way
of dealing with this.
The _UWIN define causes the mingw headers not to declare deprecated (on
Windows) function names such as open and mkdir. But the code uses these. I
have no idea why this used to work (if it even did), but the original
reason why it was defined seems to have vanished.
This adds the --screenshot-template option, which specifies a template
for the filename used for a screenshot. The '%' character is parsed as
format specifier. These format specifiers insert metadata into the
filename. For example, '%f' is replaced with the filename of the
currently played file.
The following format specifiers are available:
%n Insert sequence number (padded with 4 zeros), e.g. "0002".
%0Nn Like %n, but pad to N zeros (N = 0 to 9).
%n behaves like %04n.
%#n Like %n, but reset the sequence counter on every screenshot.
(Useful if other parts in the template make the resulting
filename already mostly unique.)
%#0Nn Use %0Nn and %#n at the same time.
%f Insert filename of the currently played video.
%F Like %f, but with stripped file extension ("." and rest).
%p Insert current playback time, in HH:MM:SS format.
%P Like %p, but adds milliseconds: HH:MM:SS.mmmm
%tX Insert the current local date/time, using the date format X.
X is a single letter and is passed to strftime() as "%X".
E.g. "%td" inserts the number of the current day.
%{prop} Insert the value of the slave property 'prop'.
E.g. %{filename} is the same as %f. If the property doesn't
exist or is not available, nothing is inserted, unless a
fallback is specified as in %{prop:fallback text}.
%% Insert the character '%'.
The strings inserted by format specifiers will be checked for
characters not allowed in filenames (including '/' and '\'), and
replaced with the placeholder '_'. (This doesn't happen for text that
was passed with the --screenshot-template option, and allows specifying
a screenshot target directory by prefixing the template with a relative
or absolute path.)
Callign add_step_frame is not necessary, because mplayer always decodes
at least one frame when starting a new file. Calling pause_player is
sufficient, and unlike add_step_frame doesn't play any audio.
The terminal OSD line was written with mp_msg(MSGT_CPLAYER, ...) but
erased with printf(). This meant that disabling MSGT_CPLAYER messages
would prevent the terminal line from being printed, but a line
(probably unrelated) would still be cleared. Change the clearing code
to use mp_msg(MSGT_CPLAYER, ...) too.
If mplayer is started with -msglevel cplayer=-1, there can't be any
terminal OSD output, but the terminal line was still cleared
unconditionally. Fix this by using mp_msg(), which will throw away the
output to clear the terminal if disabled.
Fixes#154.
The --paused option will start the player in paused state. That means it
will start out with a still image of the first frame.
This can be useful in combination with --ss to inspect a certain frame.
Caveat: this plays a small bit of audio at the start, which might be
perceived as an annoying artifact. This is because this is implemented
by frame stepping after initialization in order to decode and display
the first video frame.
The vd_ffmpeg decode() function returned without doing anything if the
input packet had size 0. This meant that flushing buffered frames at
EOF did not work. Remove this test. Have the core code skip such
packets coming from the file being played instead (Libav treats
0-sized packets as flush signals anyway, so better assume such packets
do not represent real frames with any codec).
