A "watch later" command is now mapped to Shift+Q. This quits the player
and stores the playback state in a config file in ~/.mpv/watch_later/.
When calling the player with the same file again, playback is resumed
at that time position.
It's also possible to make mpv save playback state always on quit with
the --save-position-on-quit option. Likewise, resuming can be disabled
with the --no-resume-playback option.
This also attempts to save some playback parameters, like fullscreen
state or track selection. This will unconditionally override config
settings and command line options (which is probably not what you would
expect, but in general nobody will really care about this). Some things
are not backed up, because that would cause various problems. Additional
subtitle files, video filters, etc. are not stored because that would be
too hard and fragile. Volume/mute state are not stored because it would
mess up if the system mixer is used, or if the system mixer was
readjusted in the meantime.
Basically, the tradeoff between perfect state restoration and
complexity/fragility makes it not worth to attempt to implement
it perfectly, even if the result is a little bit inconsistent.
Now vid/aid/sid can be used as properties. video/audio/sub still work,
but they are aliases for the "real" properties.
This guarantees that options/properties use the same value range. One
consequence is that the video/audio/sub properties return "no" as value
if no track is selected instead of -1.
Also, mark demuxer as not capable if DVD playback is done. The problem
with DVD is that playback time (stream_pts) is not reported frame-exact,
and the time is a "guess" at best.
YCgCo can be manually selected, but will also be used if the decoder
reports YCgCo. To make things more fun, files are sometimes marked
incorrectly, which will display such broken files incorrectly starting
with this commit.
This is an attempt to make quoting of sub-option values less awkward,
even if it works only with some shells. This is needed mainly for
vf_lavfi. Also update the vf_lavfi manpage section.
Rename the struct MPOpts "start_pause" field to "pause". Store the user-
pause state in that field, so that both runtime pause toggling and the
--pause switch change the same variable. Simplify the initialization of
pause so that using --pause and changing the file while paused is
exactly the same case (changing the file while paused doesn't unpause,
this has been always this way).
Also make it a bit more consistent. Before, starting with --pause would
reset the pause state for every file, instead of following the usual
semantics for option switches (compare with behavior of --fs).
The core pauses and unpauses automatically to wait for the network
cache (also known as buffering). This conflicted with user pause
control, and was perceived as if the player was unresponsive and/or
the cache just overturned the user's decisions.
Change it so that the actual pause state and the pause state as
intended by the user never conflict. If the user toggles pause, the
pause state will be in the expected state as soon as the cache is
loaded.
There were two problems.
First, frames past the end of the current segment were added to the
index, which messed up backstepping. Check for the endpts before
added a frame to the index.
Second, it wasn't possible to step over segments which change the file.
Changing a file causes decoder reinitialization, which (rightfully)
is treated as discontinuity (and vo_pts_history_seek_ts was changed).
Add some extra code to pretend that a segment-switching seek/reinit
does not introduce discontinuities.
There's still a weird corner case: sometimes, you can frame step forward
on the last frame of a segment without reaching the next segment
immediately. This is because the playloop switches into audio-only mode.
The segment is switched when both audio and video have ended, so the
frame stepping will play random sized chunks of audio until the segment
will be switched. This gives the impression that backstepping doesn't
work perfectly, even though it's the other way around and frame stepping
behaves weird. This is a consequence of wanting to make frame stepping
work with audio, and is not really a bug.
Allows stepping back one frame via the frame_back_step inout command,
bound to "," by default.
This uses the precise seeking facility, and a perfect frame index built
on the fly. The index is built during playback and precise seeking, and
contains (as of this commit) the last 100 displayed or skipped frames.
This index is used to find the PTS of the previous frame, which is then
used as target for a precise seek. If no PTS is found, the core attempts
to do a seek before the current frame, and skip decoded frames until the
current frame is reached; this will create a sufficient index and the
normal backstep algorithm can be applied.
This can be rather slow. The worst case for backstepping is about the
same as the worst case for precise seeking if the previous frame can be
deduced from the index. If not, the worst case will be twice as slow.
There's also some minor danger that the index is incorrect in case
framedropping is involved. For framedropping due to --framedrop, this
problem is ignored (use of --framedrop is discouraged anyway). For
framedropping during precise seeking (done to make it faster), we try
to not add frames to the index that are produced when this can happen.
I'm not sure how well that works (or if the logic is sane), and it's
sure to break with some video filters. In the worst case, backstepping
might silently skip frames if you backstep after a user-initiated
precise seek. (Precise seeks to do indexing are not affected.)
Likewise, video filters that somehow change timing of frames and do not
do this in a deterministic way (i.e. if you seek to a position, frames
with different timings are produced than when the position is reached
during normal playback) will make backstepping silently jump to the
wrong frame. Enabling/disabling filters during playback (like for
example deinterlacing) will have similar bad effects.
It's not sure if there's anything that could trigger this accidentally.
Normally this can't happen, because hrseek ends always if the PTS is
large enough, the same condition which disables framedrop. Seeking
resets hrseek framedrop anyway.
On the other hand, this change makes the code easier to understand,
and might be more robust against weird corner cases.
Block X11's native key repeat, and use mpv's key repeat handling in
input.c instead.
No configure check for XKB. Even though it's an extension, it has been
part of most (all?) xlibs since 1996. If XKB appears to be missing,
just refuse enabling x11.
This is a potentially controversial change. mpv will use its own key
repeat rate, instead of X11's. This should be better, because seeking
will have a standardized "speed" (seek events per seconds when keeping
a seek key held down). It will also allow disabling key repears for
certain commands, though this is not done anywhere yet.
The new behavior can be disabled with the --native-keyrepeat option.
Key repeats were skipped when playloop iterations took too long. Fix
this by using the total times for key repeat calculation, instead of the
time difference to the last key repeat event.
Key bindings can include mutiple keys at once (additional to key
modifiers like ctrl etc.). This becomes annoying when quickly switching
between two bound keys, e.g. when seeking back and forth, you might end
up hitting the "left" and "right" keys at once. The user doesn't expect
to invoke the key binding "left-right", but would prefer a key stroke to
invoke the binding it was supposed to invoke.
So if there's no binding for a multi-key combination, try to find a
binding for the key last held down. This preserves the ability to define
multi-key combinations, while the common case works as expected.
VOs can use the MP_KEY_STATE_DOWN modifier to pass key up/down events to
input.c, instead of just simple key presses. This allows doing key auto-
repeat handling in input.c, if the VO doesn't want to do that.
One issue is that so far, this code has been used only for mouse events,
even though the code was originally written with keyboard keys in mind.
One difference between mouse keys and keyboard keys is that the initial
key down should not generate an input command with mouse buttons
(input.c did that), while keyboard events should (input.c didn't do
that). Likewise, releasing a key should generate input commands for
mouse buttons releases, but not for the keyboard.
Change the code so mouse buttons (recognized via the MP_NO_REPEAT_KEY
flag) follow the old hehavior, while other keys generate input commands
on key down, but not on key release.
Note that a key release event is posted either using
MP_INPUT_RELEASE_ALL, or a normal key press event after having sent a an
event with MP_KEY_STATE_DOWN. This is probably a bit confusing, and a
MP_KEY_STATE_RELEASE should be added.
Fix shift-handling with MP_KEY_STATE_DOWN as well.
Empty sub-option parameters mean the sub-option should be skipped,
e.g. -vf gradfun=:10 sets the second option (by position) to 10. This
was broken in commit 04f1e2d.
This allows things like:
'--vf=lavfi="gradfun=20:30"'
Adjust the documentation for vf_lavfi to make the example less verbose.
As an unrelated change, add a general description to vf_lavfi.
Requires recent FFmpeg/Libav git versions. Earlier versions will not
be supported, as the API is different. (A libavfilter version that
uses AVFrame instead of AVFilterBuffer is needed.)
Note that this is sort of useless, because the option parser prevents
you from making use of the full libavfilter graph syntax. This has to be
fixed later.
Most of the filter creation code (half of the config() function) has
been taken from avplay.c.
This code is not based on MPlayer's vf_lavfi. The MPlayer code doesn't
compile as it hasn't been updated through multiple libavfilter API
changes, making it completely useless as a starting point.
Parsing sub-configs (like --rawvideo=subopts or the suboptions for
--vo=opengl:subopts) was completely different from the -vf parsing code
for a variety of reasons. This change at least makes -vf use the same
splitter code as sub-config options.
The main improvement is that -vf now accepts quotes, so you can write
things like:
-vf 'lavfi=graph="gradfun=10:20"'
(The '' quotes are for shell escaping.)
This is a rather big and intrusive change. Trying some -vf lines from
etc/encoding-example-profiles.conf seems to confirm it still works.
This also attempts to unify one subtle difference in handling of
positional arguments. One consequence is that a minor detail changes.
Sub-configs don't know positional arguments, and something like "--
opt=sub1=val1:sub2" means that sub2 has to be a flag option. In -vf
parsing, sub2 would be a positional option value. To remove this
conflict and to facilitate actual unification of the parsers in the
future, the sub2 will be considered a flag option if and only if such a
flag option exists. Otherwise, it's considered a value for a positional
option.
E.g. if there's a filter "foo" with a string option "sopt" and a flag
option "fopt", the behavior of the following changes:
-vf foo=fopt
Before this commit, this would set "sopt=fopt" in the filter. Now, it
enables the fopt flag, and the sopt option remains unset. This is not an
actual problem to my knowledge.
Remove the "object settings" based track range parsing (needed by
stream_cdda only), and make stream_cdda use CONF_TYPE_INT_PAIR.
This makes the -vf parsing code completely independent from other
options. A bit of that code was used by the mechanism removed with
this commit.
Before this commit, it was more or less random which subtitle was
preferred if there was both an auto-loaded external subtitle, and a
subtitle loaded via -sub or -subfile. -sub subtitles happened to be
preferred over auto-loaded subs, while -subfile didn't. Fix the -subfile
case, and make the behavior consistent by making the selection behavior
explicit.
Get rid of the 1-char subtitle type field. Use sh_stream->codec instead
just like audio and video do. Use codec names as defined by libavcodec
for simplicity, even if they're somewhat verbose and annoying.
Note that ffmpeg might switch to "ass" as codec name for ASS, so we
don't bother with the current silly "ssa" name.
Matroska files can contain multiple segments, which are literally
further Matroska files appended to the main file. They can be referenced
by segment linking.
While this is an extraordinarily useless and dumb feature, we support it
for the hell of it.
This is implemented by adding a further demuxer parameter for skipping
segments. When scanning for linked segments, each file is opened
multiple times, until there are no further segments found. Each segment
will have a separate demuxer instance (with a separate file handle
etc.).
It appears the Matroska spec. has an even worse feature for segments:
live streaming can completely reconfigure the stream by starting a new
segment. We won't add support for it, because there are 0 people on this
earth who think Matroska life streaming is a good idea. (As opposed to
serving Matroska/WebM files via HTTP.)
With Matroska ordered chapters, the main file (i.e. the file you're
playing) can be empty, while all video/audio data is in linked files.
Some files don't even contain the track list, only chapter information.
mpv refused to play these, because normally, the main file dictates the
track layout.
Fix this by using the first segment for track data if no part of the
timeline is sourced from the main file.
I am aware this detection may occur too late, depending on other
settings, but at least it usually works and is portable.
Where the output fd can be changed, though, it'd be better to force a
similar behaviour via file descriptor use: use pipe:3 as output to FD 3,
and change the calling program to expect the stream on FD 3.
Anything this option did has been removed in the preceding 3 commits.
Note that even though these options sounded like a good idea (like
setting accuracy vs. speed tradeoffs), they were not really properly
implemented.
Switch the internal channel order to libavcodec's. If the channel number
mismatches at some point, use libavresample for up- or downmixing.
Remove the old af_pan automatic downmixing.
The libavcodec channel order should be equivalent to WAVEFORMATEX order,
at least nowadays. reorder_ch.h assumes that WAVEFORMATEX and libavcodec
might be different, but all defined channels have the same mappings.
Remove the downmixing with af_pan as well as the channel conversion with
af_channels from af.c, and prefer af_lavrresample for this. The
automatic downmixing behavior should be the same as before (if the
--channels option is set to 2, which is the default, the audio output
is forced to 2 channels, and libavresample does all downmixing).
Note that mpv still can't do channel layouts. It will pick the default
channel layout according to the channel count. This will be fixed later
by passing down the channel layout as well.
af_hrtf depends on the order of the input channels, so reorder to ALSA
(for which this code was written). This is better than changing the
filter code, which is more risky.
ao_pulse can accept waveext order directly, so set that as channel
mapping.
Make sure automatically inserted filters are removed on full reinit
(they are re-added later if they are really needed). Automatically
inserted filters were never explicitly removed, instead, it was
expected that redundant conversion filters detach themselves. This
didn't work if there were several chained format conversion filters,
e.g. s16le->floatle->s16le, which could result from repeated filter
insertion and removal. (format filters detach only if input format and
output format are the same.)
Further, the dummy filter (which exists only because af.c can't handle
an empty filter chain for some reason) could introduce bad conversions
due to how the format negotiation works. Change the code so that the
dummy filter never takes part on format negotiation. (It would be better
to fix format negotiation, but that would be much more complicated and
would involving fixing all filters.)
Simplify af_reinit() and remove the start audio filter parameter. This
means format negotiation and filter initialization is run more often,
but should be harmless.
This option can be used to selectively reset settings when playing the
next file in the playlist (i.e. restore mplayer and mplayer2 behavior).
Might remove this option again should it turn out that nobody uses it.
Consider:
mpv --volume 10 file1.mkv file2.mkv
Before this commit, the volume was reset to 10 when playing file2.mkv.
This was inconsistent to most other options. E.g. --brightness is a
rather similar case.
In general, settings should never be reset when playing the next file,
unless the option was explicitly marked file-local. This commit
corrects the behavior of the --volume and --mute options.
File local --volume still works as expected:
mpv --{ --volume 10 file1.mkv file2.mkv --}
This sets the volume always to 10 on playback start.
Move the m_config_leave_file_local() call down so that the mixer code
in uninit_player() can set the option volume and mute variables without
overwriting the global option values.
Another subtle issue is that we don't want to set volume if there's no
need to, which is why the user_set_volume/mute fields are introduced.
This is important because setting the volume might change the system
volume depending on other options.
Commit bc20f2c moved the variable default_max_pts_correction (which
backs the --mc option) to the MPOpts struct. The initializer was
forgotten when doing this, so it was left at 0. This disabled part of
the A/V sync mechanism. This was apparent when using ad_spdif (this
decoder has other A/V sync related problems, and thus triggers this
issue easily).
Closes#59.
Makes sure that seeking to a given time position shows the subtitle at
that position. This can fail if the subtitle packet is not close enough
to the seek target. Always enabled for hr-seeks, and can be manually
enabled for normal seeks with --mkv-subtitle-preroll.
This helps displaying subtitles correctly with ordered chapters. When
switching ordered chapter segments, a seek is performed. If the subtitle
is timed slightly before the start of the segment, it normally won't be
demuxed. This is a problem with all seeks, but in this case normal
playback is affected. Since switching segments always uses hr-seeks,
the code added by this commit is always active in this situation.
If no subtitles are selected or the subtitles come from an external
file, the demuxer should behave exactly as before this commit.
In the last cleanup round, this was accidentally changed from a store
option to int, and the option value was passed as flag value.
(Not that anyone needs/uses/cares about this option...)
The main problem with video PTS was that it wasn't very useful when
playing audio files with cover art. Using the audio time instead was an
obvious solution. Unfortunately, this leads to "inexact" reporting of
the playback time in paused mode, and audio is always ahead by small,
essentially random amounts of time ahead. This is possibly because the
times reported by AOs are not entirely accurate when paused (see commit
9b3bf76).
Switch back to video PTS, and use a simpler way to deal with the cover
art case: if the video has ended, use the audio PTS.
Also see commit f9a259e (and the commits referenced from there).
Trying to step over a segment boundary didn't work, and the video was
stuck at the end of the current chapter. At this point, both video and
audio of the segment has ended, and the segment switching code is going
to call seek() to go to the next segment (the part of the code in
run_playloop that uses end_is_chapter). However, this seek() is not
called if playback is paused, and the framestepping code always paused
before this code is run.
Move the framestepping code below the chapter switching code. The added
restart_playback condition makes sure the code is called only after at
least one video frame has been shown. Also don't reset the framestep
counter after seek. It's not needed, and removing it prevents full
unpausing when stepping over a segment boundary.
This also terminates playback when frame stepping at the end of the
file. The --keep-open option can be used to get the old behavior.
The OSX part of the Apple Remote was unmaintained for a long time and was not
working anymore. I tried to update the cookies to what the current versions of
OS X expect without much luck. I decided to remove it since Apple is not
including the IR receiver anymore in new hardware and it's clear that wifi
based remotes are the way to go.
A third party iOS app should be used in it's place. In the future we could look
into having a dedicated iOS Remote Control app like VLC and XBMC do.
The Linux side (`appleir.c`) was relatively tidy but it looks like LIRC can be
configured to work with any version of Apple Remote [1] and is more maintained.
[1] LIRC Apple Remote configs: http://lirc.sourceforge.net/remotes/apple/
Drawing the bar with vector drawings (instead with characters from the
OSD font) offers more flexibility and looks better. This also adds
chapter marks to the OSD bar, which are visible as small triangles on
the top and bottom inner border of the bar.
Change the default position of the OSD bar below the center of the
screen. This is less annoying than putting the bar directly into the
center of the view, where it obscures the video. The new position is
not quite on the bottom of the screen to avoid collisions with
subtitles.
The old centered position can be forced with ``--osd-bar-align-y=0``.
Also make it possible to change the OSD bar width/height with the new
--osd-bar-w and --osd-bar-h options.
It's possible that the new OSD bar renders much slower than the old
one. There are two reasons for this: 1. the character based bar
allowed libass to cache each character, while the vector drawing forces
it to redraw every time the bar position changes. 2., the bar position
is updated at a much higher granularity (the bar position is passed
along as float instead of as integer in the range 0-100, so the bar
will be updated on every single video frame).
gl_video.c contains all rendering code, gl_lcms.c the .icc loader and
creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is
reduced to interfacing between the various parts.
Makes the code a bit simpler to follow, at least in the "modern"
decoding path (update_video_nocorrect_pts() is used with old demuxers,
which don't return proper packets and need further parsing, so this code
looks less simple now).
There were complaints that ${fps} was printed as e.g. "23.98" instead of
"23.976". Since there's no way to format floats exactly _and_ in a user-
friendly way, just change the default precision for printing floats.
This way it's possible to retrieve correct information about video, like
actual width/height, which in general are available only after at least
one frame has been sent to the video output, such as dwidth/dheight.
mpv_identify.sh becomes a bit slower, because we let it decode enough
audio and video to fill the audio buffers and to send one frame to the
video output. Also, --playing-msg isn't shown anymore with --frames=0
(could be fixed by special-casing it, should this break any use cases).
Note that in some corner cases, like when the demuxer for some reason
returns lots of audio packets but no video packets at the start, but
video actually starts later, the --playing-msg will still be output
before video starts.
This has the same (useless) definition as frame stepping in audio-only
mode: one frame means one playloop iteration. (It's relatively useless,
because one playloop iteration has a random duration. But it makes
--frames=1 work, which is useful again.)
Add new properties "dwidth" and "dheight", which contain the video
size as known by the VO (not necessarily what the VO makes out of them,
i.e. without window scaling and panscan).
Some time ago, all old special-cased commands (like "volume 1" to change
volume by one) have been removed. These commands are still emulated
using simple text replacement. This emulation is done to not break
everyone's input.conf, especially because the input.conf provided by
standard mplayer* still uses the old commands.
Every use of a deprecated command prints a replacement warning, which
was visible only with -v. Make these warnings visible by default.
There's actually not much reason to do this, but since commands like
"volume 5 1" don't work anymore, it's better to be verbose about this.
Also simplify the replacement for "vo_fullscreen".
Normal text was set to gray foreground color. This didn't work for
terminals with white background.
Instead of setting a color for normal text, reset the color attributes.
This way, only errors and warnings are formatted differently.
Also change the default color for MSGL_HINT from bold white to yellow.
A recent change accidentally set the flags options to -1 (probably
confusing it with the defasult value?), which mistakenly set all flags
and rejected all option values (except 0).
We consider FFmpeg 1.x and Libav 0.9.x releases compatible. Support
for FFmpeg 0.9.x and Libav 0.8.x is considered infeasible and has been
dropped in the previous commits. The bits that break compatibility are
mainly the CodecID renaming (trivial, but would require nasty hacks
everywhere), the avcodec_encode_video2() function (missing in older
releases, mandatory in newer ones), and the resampler changes (older
releases miss lib{av,sw}resample, newer versions removed the
libavcodec resampler).
Remove some other compatibility bits that were needed to for releases
for which we drop support.
The comment about Libav 0.9 in compat/libav.h is incorrect and should
have been 0.8 (the symbol is present in Libav 0.9).
The old names have been deprecated a while ago, but were needed for
supporting older ffmpeg/libav versions. The deprecated identifiers
have been removed from recent Libav and FFmpeg git.
This change breaks compatibility with Libav 0.8.x and equivalent
FFmpeg releases.
Move them into per-instance structs. This should get rid of all global
variables in mplayer.c (not counting those referenced by cfg-mplayer.h).
In core/input/ar.c, just remove checking the slave_mode variable. I'm
not sure what this code was supposed to achieve, but slave mode is
broken, slave mode is actually infeasible on OSX (ar.c is completely OSX
specific), and the correct way of doing this would be to disable this
input device per command line switch.
Missing entries cause avcodec_descriptor_get() to return NULL, and in
turn mp_codec_from_av_codec_id() will return NULL. This shouldn't
happen, and avcodec_descriptor_get() returning NULL for a valid codec is
clearly a bug.
But make it more robust anyway, and use the decoder's name if this
happens, because I doubt maintainance of the AVCodecDescriptor table
in ffmpeg/Libav will always be perfect and reliable.
Latest nvidia drivers ignore the application setting, so this switch
makes even less sense than before. It's still possible to control this
with VO specific suboptions.
Separate the video output options from the big MPOpts structure and also only
pass the new mp_vo_opts structure to the vo backend.
Move video_driver_list into mp_vo_opts
The spdif decoder was hardcoded to assume that the spdif output is
capable of accepting high (>1.5Mbps) bitrates. While this is true
for modern HDMI spdif interfaces, the original coax/toslink system
cannot deal with this and will fail to work.
This patch adds an option --dtshd which can be enabled if you use
a DTS-capable receiver behind a HDMI link.
Removes almost every global variabel in vo.h and puts them in a special struct
in MPOpts for video output related options.
Also we completly remove the options/globals pts and refresh rate because
they were unused.
When paused, --cursor-autohide worked with a precision of 500ms, which
is the main loop's default sleep time when paused. Cursor hiding is
polled in x11_common, and the main loop never called the X11 code at
the right time. Fix this by allowing the VO to set a time when it
should be called next.
Emulate percentage-seeks (SEEK_FACTOR) as normal time-seeks if possible.
This fixes some issues with (let's call it) low quality implementations
of SEEK_FACTOR (e.g. demux_mkv basically interprets this as byte-seek,
and also seeking to 99.9% makes it seek back to the start).
For weird MPEG formats the demuxer level SEEK_FACTOR is still used.
These formats, which can have timestamp resets, are identified by
setting demuxer->ts_resets_possible to true.
Also, have get_current_pos_ratio() follow the same rules, and calculate
the percentage position with the file position if timestamp resets are
possible.
This actually fixes percentage-seeks in .ts files with demux_lavf.c.
This kind of seek is not really used now, but it will be more important
when we add a progress bar.
Note: seeking in chained ogg files is still completely broken. The main
issue is that ffmpeg doesn't provide a sane API for dealing with
timestamp resets, and trying to do byte seeks with ogg confuses demuxer
and decoder (or something like this) and just does random things.
(Tested with two concatenated flac-in-ogg files).
OPT_BASE_STRUCT defines which struct the OPT_ macros (like OPT_INT etc.)
reference implicitly, since these macros take struct member names but no
struct type. Normally, only cfg-mplayer.h should need this, and other
places shouldn't be bothered with having to #undef it.
(Some files, like demux_lavf.c, still store their options in MPOpts. In
the long term, this should be removed, and handled like e.g. with VO
suboptions instead.)
Change the option definition macros so that they cause compiler warnings
if the type of the referenced option struct member doesn't match the
type implied by the macro. The compiler warning printed isn't very
telling, but it's better than silently invoking undefined behavior by
violating the C strict aliasing rules.
Also fix some minor cases that violate the type rules. For the option
"no-aspect" we have to add a new option type to handle it properly.
Some option types are hard to check, so we don't in these cases.
VFCAP_OSD was used to determine at runtime whether the VO supports OSD
rendering. This was mostly unused. vo_direct3d had an option to disable
OSD (was supposed to allow to force auto-insertion of vf_ass, but we
removed that anyway). vo_opengl_old could disable OSD rendering when a
very old OpenGL version was detected, and had an option to explicitly
disable it as well.
Remove VFCAP_OSD from everything (and some associated logic). Now the
vo_driver.draw_osd callback can be set to NULL to indicate missing OSD
support (important so that vo_null etc. don't single-step on OSD
redraw), and if OSD support depends on runtime support, the VO's
draw_osd should just do nothing if OSD is not available.
Also, do not access vo->want_redraw directly. Change the want_redraw
reset logic for this purpose, too. (Probably unneeded, vo_flip_page
resets it already.)
Use floats instead of integers in the range 0-100. Currently, the OSD
is currently made up of 46 elements so no change should be visible, but
rendering of the bar will be changed later to use vector drawings (using
pixel coordinates) instead of glyphs. This commit is for preparation.
The percent position is used for the OSD, the status line, and for the
OSD bar (shown on seeks). By default, the PTS of the last demuxed packet
was used to calculate it. This led to a "jumpy" display when the
percentage value (casted to int) was changing. The reasons for this were
the presence of video frame reordering (packet PTS is not monotonic), or
getting PTS values from different streams (like audio/subs).
Since these rely on PTS values and correct file durations anyway,
simplify it by calculating it with the current playback position in
mplayer.c instead.
This allowed making the player switch the monitor video mode when
creating the video window. This was a questionable feature, and with
today's LCD screens certainly not useful anymore. Switching to a random
video mode (going by video width/height) doesn't sound too useful
either.
I'm not sure about the win32 implementation, but the X part had several
bugs. Even in mplayer-svn (where x11_common.c hasn't been receiving any
larger changes for a long time), this code is buggy and doesn't do the
right thing anyway. (And what the hell _did_ it do when using multiple
physical monitors?)
If you really want this, write a shell script that calls xrandr before
and after calling mpv.
vo_sdl still can do mode switching, because SDL has native support for
it, and using it is trivial. Add a new sub-option for this.
The message reads: "Screenshot: filename", where the filename is what
mpv passes to fopen(). It will also show error messages when saving the
screenshot fails.
This means a commands like "seek 13:00 absolute" actually behaves like
"--start=13:00", instead of interpreting the argument as fraction as
with normal float options. This is probably slightly closer to what
you'd expect.
As a consequence, the seek argument's type changes from float to double
internally.
Apparently the intention was parsing numbers reliably in presence of
non-C locales. mpv is always in C locale, and not being in C locale
would probably break even more things, so remove this code.
You can just use --wid=0 if you really want this.
This only worked/works for X11, and even then it might interact badly
with most desktop environments. All the option did was setting --wid to
0, and the property did nothing.
"End of file" was printed to the terminal instead of "Quit" when exiting
with the "quit" slave command (closing the window and such). Note that
it will still print EOF when it exists because the end of the playlist
is reached.
Do some other (not strictly related) simplifications.
Was very complicated to use, and its uses have been removed in the
previous commits.
(While this feature sounded kind of useful, it could be rewritten in
a much simpler way, like storing presets as strings, and then using
the option parser to apply a preset. The removed code did some major
pointer juggling to handle raw values, which made it hard to use.)
For all suboptions, "flat" options were available by separating the
parent option and the sub option with ":", e.g. "--rawvideo:w=123". Drop
this syntax and use "-" as separator. This means even suboptions are
available as normal options now, e.g. "--rawvideo-w=123". The old syntax
doesn't work anymore.
Note that this is completely separate from actual suboptions. For
example, "-rawvideo w=123:h=123" still works. (Not that this syntax is
worth supporting, but it's needed anyway, for for other things like vf
and vo suboptions.)
As a consequence of this change, we also have to add new "no-" prefixed
options for flag suboptions, so that "--no-input-default-bindings"
works. ("--input-no-default-bindings" also works as a consequence of
allowing "-input no-default-bindings" - they are handled by the same
underlying option.)
For --input, always use the full syntax in the manpage. There exist
suboptions other than --input (like --tv, --rawvideo, etc.), but since
they might be handled differently in the future, don't touch these yet.
M_OPT_PREFIXED becomes the default, so remove it. As a minor unrelated
cleanup, get rid of M_OPT_MERGE too and use the OPT_SUBSTRUCT() macro in
some places.
Unrelated: remove the duplicated --tv:buffersize option, fix a typo in
changes.rst.
`--fs-screen` allows to decide what display to go fullscreen into. The
semantics of `--screen` changed and now it is only used to select the windowed
display when starting the application.
This is useful for people using mpv with an external TV. They will start
windowed on their laptop's screen and switch to fullscreen on the TV.
@wm4 worked on the x11 and w32 parts of the code. All is squashed in one
commit for history clarity.
Being able to insert newline characters ("\n") is useful for
--osd-status-msg, and possibly also for anything that prints to the
terminal. Espcially --term-osd-esc looks relatively useless without
being able to specify escapes.
Maybe parsing escapes should happen during command line / config parsing
instead (for all options).
This was supposed to be fixed in f897138, but there's another corner
case. Basically, set_osd_function() reset the OSD time, which is not
nice at all and breaks the logic of letting OSD elements disappear when
they're not wanted anymore. Fix this by adding a separate timer for
this.
Additionally, make sure the OSD bar is _really_ always updated when
visible. Also, redraw the OSD only if the OSD bar actually changes to
prevent redrawing too often (every vo_osd_changed() will flag that the
OSD should be redrawn, even if nothing changes).
Increase robustness against out of bound chapter numbers. Normally
these functions expect that the callers sanitize the chapter number.
This went wrong at least in add_seek_osd_messages() (which displayed
a chapter "-1" when chapters were not available). Make these functions
a bit friendler and add some reasonable checks and fallbacks, which
fixes the mentioned chapter seeking case as well.
Printed "error parsing option profile-desc=..." when using that inside
of profile sections. This happened because we now check the presence of
an option before setting it, and profile-desc is not an option, but
special cased in the config parser.
This affects the "show_progress" command, by defualt on the 'P' key.
If there are complaints, I'll probably remove it again. (It looks
relatively annoying, but it also valueable information... sort of.)
Until now, setting a property that is not available (e.g. deinterlacing
if not using vdpau and no deinterlacing filter is inserted) silently
failed (except for a messager on the terminal). Instead show on the OSD
that the property is unavailable.
Seeks can be performed with OSD bar invisible (e.g. "osd-msg seek ..."
command), and then an already visible bar won't be updated. But the bar
will stick around until the OSD text is hidden. This is confusing, so
change it that the bar is updated. (Making the bar disappear on such
seeks would require much more changes, so we're lazy and go with this
commit.)
Commit 4a40eed "options: change handling of "no-" options" generally
improved the handling of automatically added negation options
(recognizing "--no-opt", even though only "--opt" is declared in the
option list).
Unfortunately, one corner case was missed, which broke the option
"--input=no-default-bindings" (other suboptions, e.g. VO suboptions,
were not affected, and this is the only option where this mattered).
Instead of increasing the complexity further, use a completely different
approach: add the "--no-" options at runtime, and make them behave like
real options. This approach could be considered slightly less elegant,
because the code now has to worry about some option implementation
details rather than leaving it to the parser, but all in all the new
code is simpler and there are less weird corner cases to worry about.
The seek bar appeared to be "stuck" to the start of the current chapter.
This is a regression from 630a2b1. This commit assumed that hrseek_pts
would always contain the hrseek target time (when hrseek_active==true).
But this is not always the case: when playing timeline stuff (e.g.
ordered chapters), hrseek framedropping is abused to handle an obscure
corner case, and then hrseek_pts contains something completely unrelated
to the current playback time. See the added comment in mplayer.c and
commit c1232c9.
Fix this by trying something else to get a correct time "during"
hr-seeks. mpctx->restart_playback looks ideal, because it's set while
audio is being synced / audio buffers being filled, so we know that the
audio time is probably bogus while it is set. Let's hope this is
correct.
Do this to reduce conflicts with <linux/input.h>, which contains some
conflicting defines.
This changes the meaning of MP_KEY_DOWN:
KEY_DOWN is renamed to MP_KEY_DOWN (cursor down key)
MP_KEY_DOWN is renamed to MP_KEY_STATE_DOWN (modifier for key down state)
int64_t was accidentally used with "%lld" format specifiers, which is
incorrect (even though long long int is always 64 bits, the type behind
int64_t can be different, e.g. it can be long int on 64 bit platforms).
Instead of putting codec header data into WAVEFORMATEX and
BITMAPINFOHEADER, pass it directly via AVCodecContext. To do this, we
add mp_copy_lav_codec_headers(), which copies the codec header data
from one AVCodecContext to another (originally, the plan was to use
avcodec_copy_context() for this, but it looks like this would turn
decoder initialization into an even worse mess).
Get rid of the silly CodecID <-> codec_tag mapping. This was originally
needed for codecs.conf: codec tags were used to identify codecs, but
libavformat didn't always return useful codec tags (different file
formats can have different, overlapping tag numbers). Since we don't
go through WAVEFORMATEX etc. and pass all header data directly via
AVCodecContext, we can be absolutely sure that the codec tag mapping is
not needed anymore.
Note that this also destroys the "standard" MPlayer method of exporting
codec header data. WAVEFORMATEX and BITMAPINFOHEADER made sure that
other non-libavcodec decoders could be initialized. However, all these
decoders have been removed, so this is just cruft full of old hacks that
are not needed anymore. There's still ad_spdif and ad_mpg123, bu neither
of these need codec header data. Should we ever add non-libavcodec
decoders, better data structures without the past hacks could be added
to export the headers.
Also move the lang field into the general stream header. (SH_COMMON is
an old hack to "share" code between audio/video/sub headers.)
There should be no functional changes, other than not printing stream
info in verbose mode or with slave mode. (The frontend already prints
stream info, and this is just a leftover when individual demuxers did
this, and slave mode remains broken.)
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.
Simplify --no-config and make it a normal flag option, and doesn't take
an argument anymore. You can get the same behavior by using --no-config
and then --include to explicitly load a certain config file.
Make --no-config work for input.conf as well. Make it so that
--input:conf=file still works in this case. As a technically unrelated
change, the file argument now works as one would expect, instead of
making it relatively to "~/.mpv/". This makes for simpler code and
easier to understand option semantics. We can also print better error
messages.
Doesn't have much of a purpose for normal playback. You can get
milliseconds display with --osd-fractions. It's also possible to build
a custom status line with --status-msg.
This gives more space on the status line and, in my opinion, is a bit
less annoying.
OPT_MAKE_FLAGS() used to emit two options (one with "no" prefixed),
but that has been long removed by special casing flag options in the
option parser. OPT_FLAG_ON() used to imply that there's no "no-"
prefixed option, but this hasn't been the case for a while either.
(Conceptually, it has been replaced by OPT_FLAG_STORE().)
Remove OPT_FLAG_OFF, which was unused.
There were two option syntax variations:
"old": -opt value
"new": --opt=value
"-opt=value" was invalid, and "--opt value" meant "--opt=" followed by
a separate option "value" (i.e. interpreted as filename). There isn't
really any reason to do this. The "old" syntax used to be ambiguous
(you had to call the option parser to know whether the following
argument is an option value or a new option), but that has been removed.
Further, using "=" in the option string is always unambiguous.
Since the distinction between the two option variants is confusing,
just remove the difference and allow "--opt value" and "-opt=value".
To make this easier, do some other cleanups as well (e.g. avoid having
to do a manual lookup of the option just to check for M_OPT_PRE_PARSE,
which somehow ended up with finally getting rid of the m_config.mode
member).
Error reporting is still a mess, and we opt for reporting too many
rather than too few errors to the user.
There shouldn't be many user-visible changes. The --framedrop and
--term-osd options now always require parameters.
The --mute option is intentionally made ambiguous: it works like a flag
option, but a value can be passed to it explicitly ("--mute=auto"). If
the interpretation of the option is ambiguous (like "--mute auto"), the
second string is interpreted as separate option or filename. (Normal
flag options are actually ambiguous in this way too.)
Now setting a value with "=" is not required anymore in config files.
This should work analogous to command line arguments. Putting an entry
"opt=value" into the config file is like "--opt=value" on the command
line, and "opt" is like "--opt=" and "--opt".
Normally, all flag options can be negated by prepending a "no-", for
example "--no-opt" becomes "--opt=no". Some flag options can't actually
be negated, so add a CONF_TYPE_STORE option type to disallow the "no-"
fallback.
Do the same for choice options. Remove the explicit "no-" prefixed
options, add "no" as choice.
Move the handling of automatic "no-" options from parser-mpcmd.c to
m_config.c, and use it in m_config_set_option/m_config_parse_option.
This makes these options available in the config file. It also
simplifies sub-option parsing, because it doesn't need to handle "no-"
anymore.
This could write .edl files in MPlayer's format. Support for playing
these files has been removed from mplayer2 quite a while ago. (mplayer2
can play its own, "new" .edl format, but does not support writing it.)
Since this is a rather obscure functionality, and it's not really clear
how it should behave (e.g. what should it do if a new file is played),
and wasn't all that great to begin with (what if you made a mistake?
the "edl_mark" command sucks for editing), get rid of it.
Suggestions how to reimplement this in a nicer way are welcome. If it's
just about retrieving timecodes, this in input.conf will do:
KEY print_text "position: ${=time-pos}"
This fixes a problem that happened with syncplay.pl [1] when ad_mpg123
was in use, and get_current_time() returning a bogus time position.
This only happens during seeking; the reported time is correct after the
seek is done.
The audio PTS as returned by playing_audio_pts() is simply bogus during
hr-seek. With ad_ffmpeg, it was actually set to MP_NOPTS_VALUE during
seeking, so get_current_time() did a fallback to the video PTS. However,
ad_mpg123 is different and explicitly decodes some audio when resetting
on seek (reasons why it does this unknown and uninvestigated; apparently
it's to reinit libmpg123). As a result, the audio PTS was set to the
start position of the seek (or something similar), which could be very
different from the seek target time.
This confused syncplay. It got the bogus time because it spams the
player with read commands to the "time-pos" property, so this corner
case was hit.
Fix this by making get_current_time() return the seek target time if
hr-seek is active. This should make behavior the same as before commit
3f949cf "mplayer: prefer audio PTS over video PTS for status line".
[1] http://syncplay.pl
When doing a framestep while there is no more video, nothing happened,
and audio continued to play. When advancing to the next file, the player
was paused. Fix it so that it always pauses (except on very low frame
rate video, which is yet another corner case).
We also change the meaning of framestepping a bit: in audio only mode,
framstepping unpauses for a single playloop iteration. This is probably
not useful at all, but makes the code a bit more simpler/uniform.
Just like the previous commit, this matters most for audio files with
cover art, for which this special case is the normal case.
