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.
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().
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()).
The old option parser required adding two options for each flag option:
e.g. "-video" and "-novideo". Later, code was added to handle the "no-"
prefix automatically for flag options. Remove the "no" prefixed options
entirely (unless they are not flag options, then just rename them), and
require the user to use the "no-" prefix instead.
You can't use the old prefix anymore.
Old: -novideo
New: --no-video
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).
libass is way too chatty. The application using it shouldn't be forced
to print useless messages, especially not if the action was initiated
by the application, and libass successfully completes it.
Note that this might be a problem that should be fixed in libass, but
remapping the log levels is needed anyway (instead of relying on the
coincidence that the log level values are similar).
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.
PulseAudio is rather high on the auto proving order (to avoid using an
emulated sound API), but it prints an annoying error message if the
PA client library can't connect to a server. On the other hand, we do
want this error message printed if the user explicitly selects the
pulse audio output driver.
Add a flag to indicate that an AO is opened due to auto probing.
ao_pulse checks that flag, and if it's set, do not print if the
initialization error is PA_ERR_CONNECTIONREFUSED, whcih I assume is
the error signalling PulseAudio unavailability. (This error happens
if no PulseAudio server is installed.)
By default mplayer attempts to use LIRC. If LIRC can't be opened, a
bunch of warnings are printed. Since mplayer is often built with LIRC
enabled by default, many users will see these rather pointless
warnings. Lower verbosity, so that the warnings are not visible by
default anymore.
Someone on the internet once told me that MAD is the best mp3 decoder
(and better than mpg123), so he must be right. I used to force mad in
my config file, but now I'm annoyed by the line "Forced audio codec"
that goes along with it.
Because I think that message is necessary and needed to discourage
users from doing stupid things, but I still want to get rid of this
message, I'm simply moving MAD up in the codec selection order.
(Please look away.)
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.
Both VOs will now by default try to set vsync according to the global
vsync setting. By default, vsync is enabled, and passing --no-vsync will
disable it.
The --vsync option used to matter for vo_vesa only, but that VO has been
removed.
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.
Remove the mem2agpcpy_pic function, which is obviously duplicated from
the other function in this file.
Untested, as this is only used by the directx and directfb2 VOs.
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.
Work around PulseAudio bugs more effectively. In particular, this
should avoid two issues: playback never finishing at end of file /
segment due to PulseAudio always claiming there's still time before
audio playback reaches the end, and jerky playback especially after
seeking due to bogus output from PulseAudio's timing interpolation
code.
This time, I looked into the PulseAudio code itself and analyzed the
bugs causing problems. Fortunately, two of the serious ones can be
worked around in client code. Write a new get_delay() implementation
doing that, and remove some of the previous workarounds which are now
unnecessary. Also add a pa_stream_trigger() call to ensure playback of
files shorter than prebuf value starts (btw doing that by setting a
low prebuf hits yet another PulseAudio bug, even if you then write the
whole file in one call).
There are still a couple of known PulseAudio bugs that can not be
worked around in client code. Especially, bug 4 below can cause issues
when pausing.
Below is a copy of a message I sent to the pulseaudio-discuss mailing
list, describing some of the PulseAudio bugs:
==================================================
A lot of mplayer2 users with PulseAudio have experienced problems. I
investigated some of those and confirmed that they are caused by
PulseAudio. There are quite a few distinct PulseAudio bugs; some are
analyzed below. Overall, however, I wonder why there are so many fairly
obvious bugs in a widely used piece of software. Is there no
maintenance? Or do people not test it? Some of the bugs are probably
less obvious if you request low latency (though they're not specific to
higher-latency case); do people test the low-latency case only?
1. The timing interpolation functionality can return completely bogus
values for playback position and latency, especially after seeking
(mplayer2 does cork / flush / uncork, as flushing alone does not seem to
remove data already in sink). I've seen quickly repeated seeks report
over 10 second latency, when there aren't any buffers anywhere that big.
I have not investigated the exact cause. Instead I disabled
interpolation and added code to always call
pa_stream_update_timing_info(). (I assume that always waiting for this
to complete, instead of doing custom interpolation, may give bad
performance if it queries a remote server. But at least it works better
locally.)
2. Position/latency reporting is wrong at the end of a stream (after the
lack of more data triggers underflow status). As a result mplayer2 never
ends the playback of a file, as it's waiting forever for audio to finish
playing. The reason for this is that the calculations in PulseAudio add
the whole length of data in the sink to the current latency (subtract
from position), even if the sink does not contain that much data *from
this stream* in underflow conditions. I was able to work around this bug
by calculating latency from pa_timing_info data myself as follows
(ti=pa_timing_info):
int64_t latency = pa_bytes_to_usec(ti->write_index - ti->read_index, ss);
latency -= ti->transport_usec;
int64_t sink_latency = ti->sink_usec;
if (!ti->playing)
// this part is missing from PulseAudio itself
sink_latency -= pa_bytes_to_usec(ti->since_underrun, ss);
if (sink_latency > 0)
latency += sink_latency;
if (latency < 0)
latency = 0;
However, this still doesn't always work due to the next bug.
3. The since_underrun field in pa_timing_info is wrong if PulseAudio is
resampling the stream. As a result, the above code indicated that the
playback of a 0.1 second 8-bit mono file would take about 0.5 seconds.
This bug is in pa_sink_input_peek(). The problematic parts are:
ilength = pa_resampler_request(i->thread_info.resampler, slength);
...
if (ilength > block_size_max_sink_input)
ilength = block_size_max_sink_input;
...
pa_memblockq_seek(i->thread_info.render_memblockq, (int64_t) slength, PA_SEEK_RELATIVE, TRUE);
...
i->thread_info.underrun_for += ilength;
This is measuring audio in two different units, bytes for
resampled-to-sink (slength) and original stream (ilength). However, the
block_size_max_sink_input test only adjusts ilength; after that the
values may be out of sync. Thus underrun_for is incremented by less than
it should be to match the slength value used in pa_memblockq_seek.
4. Stream rewind functionality breaks if the sink is suspended (while
the stream is corked). Thus, if you pause for more than 5 seconds
without other audio playing, things are broken after that. The most
obvious symptom is that playback can continue for a significant time
after corking. This is caused by sink_input and sink getting out of
sync. First, after uncorking a stream on a suspended sink,
pa_sink_input_request_rewind() is called while the sink is still in
suspended state. This sets sink_input->thread_info.rewrite_nbytes to -1
and calls pa_sink_request_rewind(). However, the sink ignores rewind
requests while suspended. Thus this particular rewind does nothing. The
problem is that rewrite_nbytes is left at -1. Further calls to
pa_sink_input_request_rewind() do nothing because "nbytes =
PA_MAX(i->thread_info.rewrite_nbytes, nbytes);" sets nbytes to -1, and
the call to pa_sink_request_rewind() is under "if (nbytes != (size_t)
-1) {". Usually, after a sink responds to a rewind request,
rewrite_bytes is reset in pa_sink_input_process_rewind(), but this
doesn't happen if the sink ever ignores one request. This broken state
can be resolved if pa_sink_input_process_rewind() is called due to a
rewind triggered by _another_ stream.
There were more bugs, but I'll leave those for later.
