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.