The main need I see for this is with libmpv - it would be confusing if
some application showed up as "mpv" on whateverthehell PulseAudio uses
it for (generally it does show up on various PA GUI tools).
Note that you can't pass .cue or .edl files to it, at least not yet.
Requested in context of allowing to specify custom chapters. For that
to work well, we probably need to add some sort of chapter metadata
pseudo-demuxer.
This is probably what libmpv users want; and it also improves error
reporting (or we'd have to add a way to communicate such mid-playback
failures as events).
No development activity (or even any sign of life) for almost a year.
A replacement based on youtube-dl will probably be provided before the
next mpv release. Ask on the IRC channel if you want to test.
Simplify the Lua check too: libquvi linking against a different Lua
version than mpv was a frequent issue, but with libquvi gone, no
direct dependency uses Lua, and such a clash is rather unlikely.
Doing that doesn't make sense anyway: it's meant for interactive input,
and if the output of the player is not on the terminal, how will you
interact with it?
It was also quite in the way when trying to read verbose output with
e.g. less while the player was running, because the player would grab
half of all input meant for less (simply because stdin is still
connected to the terminal).
Remove the now redundant special-casing of pipe input.
Apparently using the stream index is the best way to refer to the same
streams across multiple FFmpeg-using programs, even if the stream index
itself is rarely meaningful in any way.
For Matroska, there are some possible problems, depending how FFmpeg
actually adds streams. Normally they seem to match though.
Thanks to the recently introduced mp_lua_PITA(), this is "simple" now.
It fixes leaks on Lua errors. The hack to avoid stack overflows
manually isn't needed anymore, and the Lua error handler will take
care of this.
mp_stat() instead of stat() was used in the normal code (i.e. even
on Unix), because MinGW-w64 has an unbelievable macro-mess in place,
which prevents solving this elegantly.
Add some dirty workarounds to hide mp_stat() from the normal code
properly. This now requires replacing all functions that use the
struct stat type. This includes fstat, lstat, fstatat, and possibly
others. (mpv currently uses stat and fstat only.)
Now requires newest libass git. Since this feature wasn't part of a
libass release yet, I'm not bothering making the mpv code compatible
with as how it was previously implemented (it will just be disabled
with any older libass).
CC: @mpv-player/stable (because mpv-build uses libass git, and this
breaks the feature)
This is the first of a series of commits that will change the Cocoa way in a
way that is easily embeddable inside parent views. To reach that point common
code must avoid referencing the parent NSWindow since that could be the host
application's window.
--x11-netwm=yes now forces NetWM fullscreen, while --x11-netwm=auto
(detect whether NetWM fullsctreen support is available) is the old
behavior and still the default.
See #888.
Apparently this is what users want. When playing with normal speed,
nothing is done. When playing slower than normal, resampling is used
instead, because scaletempo (which does the pitch correction) adds
too many artifacts.
This would play some silence in case video was slower than audio. If
framedropping is already enabled, there's no other way to keep A/V
sync, short of changing audio playback speed (which would give worse
results). The --audiodrop option inserted silence if there was more
than 500ms desync.
This worked somewhat, but I think it was a silly idea after all. Whether
the playback experience is really bad or slightly worse doesn't really
matter. There also was a subtle bug with PTS handling, that apparently
caused A/V desync anyway at ridiculous playback speeds.
Just remove this feature; nobody is going to use it anyway.
E.g. --loop-file=2 will play the file 3 times (one time normally, and 2
repeats).
Minor syntax issue: "--loop-file 5" won't work, you have to use
"--loop-file=5". This is because "--loop-file" still has to work for
compatibility, so the "old" syntax with a space between option name and
value can't work.
It's just confusing; users are encouraged to edit input.conf instead
(changing the argument to the "add" command).
Update input.conf to keep the old behavior.
Until now, you could override only level 3 with --osd-status-msg. Extend
this, add add --osd-msg1 to --osd-msg3 (one for each OSD level). OSD
level 0 always means disable OSD, so that isn't included.
--osd-msg3 corresponds to --osd-status-msg, but they're not exactly the
same. To allow more customization, --osd-msgN do not include the OSD
symbol. The symbol can be manually added with "${osd-sym-cc}". We keep
the "old" option for some short-term compatibility.
--osd-msg1 should be particularly useful; for example you could do:
--osd-msg1='${?pause==yes:${osd-sym-cc}}'
to display a "paused" symbol when paused, and nothing during normal
playback. (Although admittedly, the syntax is quite a bit of work.)
With default settings, this allows you to hit the 100% mark (with
default --softvol-max in the middle) even if you've reached min or max
volume before. This is because 50 is not divisible by 3 (old default)
but by 2 (new default).
Not really sure why there still can be issues with higher --softvol-max
and --volstep=1, but this is where I stop caring.
The memcpy() is actually not enough: the types are incompatible, and no
memcpy, union, etc. will change that. (Although no real compiler will
ever break this.) Attempt to make this theoretically correct by actually
using a struct pointer. It's not the same struct type, but supposedly
it's ok, because all struct pointers always have the same size and
representation in standard C.
Don't worry, your ~/.config/... paths are safe. This merely removes
handling of $XDG_CONFIG_DIRS for global paths.
Maybe there is a better solution for this, like still including the
"traditional" config dir. But I will leave the fine reading of this
(crappy) spec and fixing the code accordingly to someone else. So, if
anyone has interest in getting this behavior back, you will have to
write a patch. This patch should _also_ not break expected behavior.
Fixes#1060.
--hls-bitrate=min/max lets you select the min or max bitrate. That's it.
Something more sophisticated might be possible, but is probably not even
worth the effort.
This catches a few cases which basically call:
m_property_strdup_ro(..., ..., NULL)
which would return NULL strings. This should generally be avoided
(although it's allowed due to reasons), and it seems most callers
actually intend this to mean M_PROPERTY_UNAVAILABLE.
This inserts an automatic conversion filter if a Matroska file is marked
as 3D (StereoMode element). The basic idea is similar to video rotation
and colorspace handling: the 3D mode is added as a property to the video
params. Depending on this property, a video filter can be inserted.
As of this commit, extending mp_image_params is actually completely
unnecessary - but the idea is that it will make it easier to integrate
with VOs supporting stereo 3D mogrification. Although vo_opengl does
support some stereo rendering, it didn't support the mode my sample file
used, so I'll leave that part for later.
Not that most mappings from Matroska mode to vf_stereo3d mode are
probably wrong, and some are missing.
Assuming that Matroska modes, and vf_stereo3d in modes, and out modes
are all the same might be an oversimplification - we'll see.
See issue #1045.
A (hopefully) temporary hack to make stream switching delays tolerable.
It's not clear how this should be handled (either executing a precise
seek on track switching, or always enabling all streams), so get this
issue out of the way for now by picking a rather low value.
bstr.c doesn't really deserve its own directory, and compat had just
a few files, most of which may as well be in osdep. There isn't really
any justification for these extra directories, so get rid of them.
The compat/libav.h was empty - just delete it. We changed our approach
to API compatibility, and will likely not need it anymore.
Add the --cache-secs option, which literally overrides the value of
--demuxer-readahead-secs if the stream cache is active. The default
value is very high (10 seconds), which means it can act as network
cache.
Remove the old behavior of trying to pause once the byte cache runs
low. Instead, do something similar wit the demuxer cache. The nice
thing is that we can guess how many seconds of video it has cached,
and we can make better decisions. But for now, apply a relatively
naive heuristic: if the cache is below 0.5 secs, pause, and wait
until at least 2 secs are available.
Note that due to timestamp reordering, the estimated cached duration
of video might be inaccurate, depending on the file format. If the
file format has DTS, it's easy, otherwise the duration will seemingly
jump back and forth.
--demuxer-readahead-secs now controls how much the demuxer should
readahead by an amount of seconds. This is based on the raw packet
timestamps. It's not always very exact. For example, h264 in Matroska
does not store any linear timestamps (only PTS values which are going
to be reordered by the decoder), so this heuristic is usually off by
several hundred milliseconds.
The decision whether to readahead is basically OR-ed with the other
--demuxer-readahead-packets options. Change the manpage descriptions
to subtly convey these semantics.
Since the display FPS is currently detected on X11 only (and even there
it's known to be wrong on certain setups), it seems like a good idea to
make this user-configurable.
This mostly uses the same idea as with vo_vdpau.c, but much simplified.
On X11, it tries to get the display framerate with XF86VM, and limits
the frequency of new video frames against it. Note that this is an old
extension, and is confirmed not to work correctly with multi-monitor
setups. But we're using it because it was already around (it is also
used by vo_vdpau).
This attempts to predict the next vsync event by using the time of the
last frame and the display FPS. Even if that goes completely wrong,
the results are still relatively good.
On other systems, or if the X11 code doesn't return a display FPS, a
framerate of 1000 is assumed. This is infinite for all practical
purposes, and means that only frames which are definitely too late are
dropped. This probably has worse results, but is still useful.
"--framedrop=yes" is basically replaced with "--framedrop=decoder". The
old framedropping mode is kept around, and should perhaps be improved.
Dropping on the decoder level is still useful if decoding itself is too
slow.
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
Completely useless, and could accidentally be enabled by cycling
framedrop modes. Just get rid of it.
But still allow triggering the old code with --vd-lavc-framedrop, in
case someone asks for it. If nobody does, this new option will be
removed eventually.
The parser can be called with dst (the target) set to NULL if the option
should be verified only. The code didn't respect this, and could result
in crashes when used in config profiles or filter sub-options.
Fixes#981.
Almost nothing was left of it.
The only thing this commit actually removes is support for reading
input commands from stdin. But you can emulate this via:
--input-file=/dev/stdin --input-terminal=no
However, this won't work on Windows. Just use a named pipe.
Useful for Windows stuff. Actually, ENCA support should catch this, but,
well, whatever, everyone seems to hate ENCA.
Detection with BOM is trivial, although it needs some hackery to
integrate it with the existing autodetection support. For one, change
the default value of --sub-codepage to make this easier.
Probably fixes issue #937 (the second part).
This adds a thread to the demuxer which reads packets asynchronously.
It will do so until a configurable minimum packet queue size is
reached. (See options.rst additions.)
For now, the thread is disabled by default. There are some corner cases
that have to be fixed, such as fixing cache behavior with webradios.
Note that most interaction with the demuxer is still blocking, so if
e.g. network dies, the player will still freeze. But this change will
make it possible to remove most causes for freezing.
Most of the new code in demux.c actually consists of weird caches to
compensate for thread-safety issues (with the previously single-threaded
design), or to avoid blocking by having to wait on the demuxer thread.
Most of the changes in the player are due to the fact that we must not
access the source stream directly. the demuxer thread already accesses
it, and the stream stuff is not thread-safe.
For timeline stuff (like ordered chapters), we enable the thread for the
current segment only. We also clear its packet queue on seek, so that
the remaining (unconsumed) readahead buffer doesn't waste memory.
Keep in mind that insane subtitles (such as ASS typesetting muxed into
mkv files) will practically disable the readahead, because the total
queue size is considered when checking whether the minimum queue size
was reached.
Something like "char *s = ...; isdigit(s[0]);" triggers undefined
behavior, because char can be signed, and thus s[0] can be a negative
value. The is*() functions require unsigned char _or_ EOF. EOF is a
special value outside of unsigned char range, thus the argument to the
is*() functions can't be a char.
This undefined behavior can actually trigger crashes if the
implementation of these functions e.g. uses lookup tables, which are
then indexed with out-of-range values.
Replace all <ctype.h> uses with our own custom mp_is*() functions added
with misc/ctype.h. As a bonus, these functions are locale-independent.
(Although currently, we _require_ C locale for other reasons.)
Until now, the config functions added various allocations to the user-
provided talloc context. Make it so that they're all under the returned
allocation instead. This allows avoiding having to create an extra
temporary context for some callers, and also avoids adding random memory
leaks by accidentally passing a NULL context.
mp_find_all_config_files() has to be changed not to return a pointer
into the middle array for this to work. Make it add paths in order
(instead of reverse), and then reverse the array entries after that.
Also remove the declarations for the win-specific private functions.
Remove STRNULL(); it's barely needed anymore and the functions are
not called with NULL filenames anymore.
This means normally the XDG config dir will be used. But if the old
config dir (~/.mpv) exists and the XDG config dir does not, then don't
create it.
To simplify the code, also make mp_path_exists() accept NULL paths. In
that case it's considered as not existing. (Funnily, on Linux this
already worked, because the string is passed directly to the kernel,
and the kernel will just return EFAULT on invalid memory.)
Search $XDG_CONFIG_HOME and $XDG_CONFIG_DIRS for config files.
This also negates the need to have separate user and global variants of
mp_find_config_file()
Closes#864, #109.
Signed-off-by: wm4 <wm4@nowhere>
For remarks, pretty much see the manpage additions. Could help with
network streams that require too much seeking (maybe), or might be
extended to help with the use case of watching and downloading a file
at the same time.
In general, it might be a useless feature and could be removed again.
The "classic" sub-option stuff is not really needed anymore. The only
remaining use can be emulated in a simpler way. But note that this
breaks the --screenshot option (instead of the "flat" options like
--screenshot-...). This was undocumented and discouraged, so it
shouldn't affect anyone.
Instead of absuing m_option to store the property list, introduce a
separate type for properties. m_option is still used to handle data
types. The property declaration itself now never contains the option
type, and instead it's always queried with M_PROPERTY_GET_TYPE. (This
was already done with some properties, now all properties use it.)
This also fixes that the function signatures did not match the function
type with which these functions were called. They were called as:
int (*)(const m_option_t*, int, void*, void*)
but the actual function signatures were:
int (*)(m_option_t*, int, void*, MPContext *)
Two arguments were mismatched.
This adds one line per property implementation. With additional the
reordering of the parameters, this makes most of the changes in this
commit.
This means use of the min/max fields can be dropped for the flag option
type, which makes some things slightly easier. I'm also not sure if the
client API handled the case of flag not being 0 or 1 correctly, and this
change gets rid of this concern.
Also clarify the semantics.
It seems --idx didn't do anything. Possibly it used to change how the
now removed legacy demuxers like demux_avi used to behave. Or maybe
it was accidental.
--forceidx basically becomes --index=force. It's possible that new
index modes will be added in the future, so I'm keeping it
extensible, instead of e.g. creating --force-index.
Does anyone actually use this?
For now, update it, because it's the only case left where an option
points to a global variable (and not a struct offset).
Similar to previous commits.
This also renames --doubleclick-time to --input-doubleclick-time, and
--key-fifo-size to --input-key-fifo-size. We could keep the old names,
but these options are very obscure, and renaming them seems better for
consistency.
While I'm not very fond of "const", it's important for declarations
(it decides whether a symbol is emitted in a read-only or read/write
section). Fix all these cases, so we have writeable global data only
when we really need.
Additionally to removing the global variables, this makes the options
more uniform. --ssf-... becomes --sws-..., and --sws becomes --sws-
scaler. For --sws-scaler, use choices instead of magic integer values.
Pretty much nothing changes, but using -tv-scan with suboptions doesn't
work anymore (instead of "-tv-scan x" it's "-tv scan-x" now). Flat
options ("-tv-scan-x") stay compatible.
Basically, this allows gapless playback with similar files (including
the ordered chapter case), while still being robust in general.
The implementation is quite simplistic on purpose, in order to avoid
all the weird corner cases that can occur when creating the filter
chain. The consequence is that it might do not-gapless playback in
more cases when needed, but if that bothers you, you still can use
the normal gapless mode.
Just using "--gapless-audio" or "--gapless-audio=yes" selects the old
mode.
--sub-file is actually a string list, so you can add multipel external
subtitle files. But to be able to set a list, the option value was split
on ",". This made it impossible to add filenames.
One possible solution would be adding escaping. That's probably a good
idea (and some other options already do this), but it's also complicated
both to implement and for the user.
The simpler solution is making --sub-file appending, and make it take
only a single entry.
I'm not quite sure about this yet. It breaks the invariant that if a
value is printed and parsed, you get the same value back. So for now,
just go with the simple solution.
Fixes#840.
(The old "force" choice of that option is renamed to "force-default".)
This allows overriding native ASS script subtitle styles with the style
provided by the --sub-text-* options (like --sub-text-font etc.). This
is disabled by default, and needs to be explicitly enabled with the
--ass-style-override=force option and input property.
This uses in fact exactly the same options (--sub-text-*) and semantics
as the ones used to configure unstyled text subtitles.
It's recommended to combine this with this in the mpv config file:
ass-force-style="ScaledBorderAndShadow=1" # work around dumb libass behavior
Also, adding a key binding to toggle this behavior should be added,
because overriding can easily break:
L cycle ass-style-override
This would cycle override behavior on Shift+L and allows quickly
disabling/enabling style overrides.
Note: ASS should be considered a vector format rather than a subtitle
format. There is no easy or reliable way to determine whether the style
of a given subtitle event can be changed without destroying visuals or
not. This patch relies on a simple heuristic, which often works and
often breaks.
This simply writes the file name as a comment to the top of the watch later
config file.
It can be useful to the user for determining whether a watch later config file
can be manually removed (e.g. in case the corresponding media file has been
deleted) or not.
This accidentally rejected d==0. We can actually deal with sub-normals
fine, we just want to exclude nan and infinity (although infinity is
already accounted for, but anyway).
stream.start_pos was needed for optical media only, and (apparently) not
for very good reasons. Just get rid of it.
For stream_dvd, we don't need to do anything. Byte seeking was already
removed from it earlier.
For stream_cdda and stream_vcd, emulate the start_pos by offsetting the
stream pos as seen by the rest of mpv.
The bits in discnav.c and loadfile.c were for dealing with the code
seeking back to the start in demux.c. Handle this differently by
assuming the demuxer is always initialized with the stream at start
position, and instead seek back if initializing the demuxer fails.
Remove the --sb option, which worked by modifying stream.start_pos. If
someone really wants this option, it could be added back by creating a
"slice" stream (actually ffmpeg already has such a thing).
Some options change from percentages to number of kilobytes; there are
no cache options using percentages anymore.
Raise the default values. The cache is now 25000 kilobytes, although if
your connection is slow enough, the maximum is probably never reached.
(Although all the memory will still be used as seekback-cache.)
Remove the separate --audio-file-cache option, and use the cache default
settings for it.
The code paths for setting options by string and by direct "raw" value
were too different, which resulted in some weird code. Make the code
paths closer to each other.
Also, use this to remove the weirdness in the mpv_set_option()
implementation.
This allows disabling of decoder framedrop during hr-seek.
It's basically another useless option, but it will help exploring
whether this framedropping really makes seeking faster, or whether
disabling it helps with precise seeking (especially frame backstepping).
Basically, extract the option table from DOCS/man/en/changes.rst, and
search the table if an option wasn't found. If there's an entry about
it, print it. Hopefully this behavior is slightly more userfriendly.
This is strictly bound to option names. It doesn't work for option
values, nor does it attempt to emulate the old option.
Also remove MSGL_SMODE and friends.
Note: The indent in options.rst was added to work around a bug in
ReportLab that causes the PDF manual build to fail.
This allows client API users and Lua scripts to side-step the pretty
horrible video filter string "language" (although it's back and can't be
avoided when using libavfilter).
This should fix some issues, such as not being able to set the
"no-video" option with MPV_FORMAT_FLAG.
Note that this changes semantics a bit. Now setting an option strictly
overwrite it, even if the corresponding command line option does not.
For example, if we change --sub to append by default, then setting the
"sub" option via the client API would still never append. (Oddly, this
also applies to --vf-add, which will overwrite the old value when using
the client API.)
I'm doing this because there's no proper separation between the command
line parser and setting an option using the MPV_FORMAT_STRING format.
Maybe the solution to this mess would be adding format aware code (i.e.
m_option_set_node) to every option type, and falling back to strings
only if needed - but this would mean that you couldn't set e.g. an
integer option using MPV_FORMAT_STRING, which doesn't seem to be ideal
either.
In conclusion, the current approach seems to be most robust, but I'm
open to suggestions should someone find that these semantics are a
problem.
glob() is mandated by POSIX. For the only non-POSIX platform we support,
Windows, we have our own replacement. So the ifdeffery is not needed.
Still leave the checks in the configure scripts, because they have to
decide whether to compile the replacement or not. (Although this could
be special cased to mingw-only, the wscript seems to make this hard.)
The Windows port uses CommandLineToArgvW, which doesn't expand wildcards
in command line arguments. Use glob to expand them instead, but only for
non-option arguments.
Often, user configs set options that are not suitable for encoding.
Usually, playback and encoding are pretty different things, so it makes
sense to keep them strictly separate. There are several possible
solutions. The approach taken by this commit is to basically ignore the
default config settings, and switch to an [encoding] config profile
section instead. This also makes it impossible to have --o in a config
file, because --o enables encode mode.
See github issue #727 for discussion.
This collects statistics and other things. The option dumps raw data
into a file. A script to visualize this data is included too.
Litter some of the player code with calls that generate these
statistics.
In general, this will be helpful to debug timing dependent issues, such
as A/V sync problems. Normally, one could argue that this is the task of
a real profiler, but then we'd have a hard time to include extra
information like audio/video PTS differences. We could also just
hardcode all statistics collection and processing in the player code,
but then we'd end up with something like mplayer's status line, which
was cluttered and required a centralized approach (i.e. getting the data
to the status line; so it was all in mplayer.c). Some players can
visualize such statistics on OSD, but that sounds even more complicated.
So the approach added with this commit sounds sensible.
The stats-conv.py script is rather primitive at the moment and its
output is semi-ugly. It uses matplotlib, so it could probably be
extended to do a lot, so it's not a dead-end.
It's a bit strange to allow this, so get rid of it.
This probably breaks a bunch of user config files.
The client API still allows setting them with MPV_FORMAT_FLAG with a
value of 1 (i.e. true), but I guess this is tolerable.
The most user visible change is that "420p" is now displayed as
"yuv420p". This is what FFmpeg uses (almost), and is also less confusing
since "420p" is often confused with "420 pixels vertical resolution".
In general, we return the FFmpeg pixel format name. We still use our own
old mechanism to keep a list of exceptions to provide compatibility for
a while.
Also, never return NULL for image format names. If the format is unset
(0/IMGFMT_NONE), return "none". If the format has no name (probably
never happens, FFmpeg seems to guarantee that a name is set), return
"unknown".
This re-allows the previous behaviour of being able to reencode with
metadata removed, which is useful when encoding "inconsistently" tagged
data for a device/player that shows file names when tags are not
present.
These playlist parsers are all what's left from the old mplayer playlist
parsing code. All of it is old code that does little error checking; the
type of C string parsing code that gives you nightmare.
Some playlist parsers have been rewritten and are located in
demux_playlist.c. The removed formats were not reimplemented. ASX and
SMIL use XML, and since we don't want to depend on a full blown XML
parser, this is not so easy. Possibly these formats could be supported
by writing a very primitive XML-like lexer, which would lead to success
with most real world files, but I haven't attempted that. As for NSC, I
couldn't find any URL that worked with MPlayer, and in general this
formats seems to be more than dead.
Move playlist_parse_file() to playlist.c. It's pretty small now, and
basically just opens a stream and a demuxer. No use keeping
playlist_parser.c just for this.
Commit 2c2c1203 sorted the output of --list-options, but the same code
ias also used for listing sub-options, such as --vo=scale:help. For sub-
options, the order actually matters.
Until now, --list-options printed options in random order. There
literally wasn't any logic in its order, they just appeared as they were
declared. So just sort them.
Note that we can't sort them in advance, because for certain things
internal to m_config, the order actually matters.
Also we're using strcasecmp(), which is bad (locale dependent), but this
is output intended for human consumption, so it's not a problem.
This used to display the property type, but it was not always correct or
even available. The way the property mechanism works, we can know this
only at runtime.
The function tag_property() in command.c passed a key action with empty
path to m_property_read_list. This is normally not valid, because key
actions are supposed to access sub-paths. But it's kind of inconvenient
to check for this case in tag_property(). So make it valid by providing
a m_property_unkey() function, which turns a key access to "" into a
top-level action.
We've just checked whether a sub-path started with "name/", but that
changes behavior whether the property name has a trailing '/' or not.
Using a helper function to split of path components avoids this problem.
Setting string options to strings over the m_option fallback (i.e.
M_PROPERTY_SET_STRING is called if the option type is CONF_TYPE_STRING)
failed. This was because m_option_parse() returns 0. 0 still means
success, but the property code tried to be clever, and considered 0 not
a success in order to disallow setting flags to an emtpy string (which
in turn is allowed, because the command line allows flag options without
parameters).
Fix this by removing the overly clever code.
This could happen when e.g. using the "set" command on options/title (a
string option), and also was a problem for the client API.
Closes#610.
--ass-style-override=force now attempts to override the 'Default' style.
May or may not work. In some situations it will work, but also mess up
seemingly unrelated things like signs typeset with ASS.
Will be helpful to track down strange wait times and such issues, as
well when you have develop something timing related. (Then you may print
timestamps in your debug output, and the --msgtime timestamps will help
giving context.)
This is a bit weird: m_option_string types (i.e. char*) can be NULL. But
they're supposed to be treated just like empty strings. So don't make
the m_option_type.print function return NULL for these values. Returning
NULL would mean failure.
This didn't matter much before, but was quite visible through the client
API.
This is only half-implemented: actually the option will first be
converted from mpv_node to its native type, then it's converted to a
string, and then back to its native type. This is because the option
API was made for strings and not anything else.
Other than being grossly inelegant, the only downside is probably with
string lists and key/value lists, which don't escape strings containing
syntax elements correctly.
This automatically allows accessing properties like chapter-list and
track-list to be read as mpv_node. This affects all properties which use
m_property_read_sub() and m_property_read_list().
Allows retrieving properties by their native values (or something close
to it), rather than having to go through string conversion. The caller
could actually just copy the value itself and then use the m_option
functions to convert it to mpv_node, but maybe it's more flexible this
way.
m_option is basically the mechanism to handle C data types in a dynamic
way. Add functions to convert values to and from mpv_node. For example,
string lists are turned into mpv_node using MPV_FORMAT_NODE_ARRAY, and
so on.
Some code accessed m_option.name to get the property name. (Maybe only
show_property_osd() had a significant use of it.) Remove that, and
remove setting names and dummy names as well.
The old code usually assumed that the name was set, and
show_property_osd() used it to get the proper name of deprecated
aliases.
The "vf" property was listed as "vf*". Not sure why that was done, but
it works without anyway.
Doesn't require other code to care about this, which will allow us to
simplify the property code.
Only "wildcard" options like "vf" and string lists used this, and
m_option_list_findb() (which is excused).
M_OPT_PARSE_ESCAPES was pretty stupid, and broke the (useful) assumption
that string variables contain exactly the same value as set by the
option. Simplify it, and move escape handling to the place where it's
used.
Escape handling itself is not terribly useful, but still allows useful
things like multiline custom OSD with "\n".
This adds a mechanism for easier export of sub-properties. The following
commits will make use of it to export fine grained information about
certain things. The sub-property mechanism reduces the amount of code
needed to export a data value to 1 line.
Until now, the --no-config was explicitly checked in multiple places to
suppress loading of config files.
Add such a check to the config path code itself, and refuse to resolve
_any_ configuration file locations if the option is set.
osc.lua needs a small fixup, because it didn't handle the situation when
no path was returned. There may some of such cases in the C code too,
but I didn't find any on a quick look.
Try to make it more intuitive by not requiring hex values. The new way
uses float values in the range 0.0-1.0, separated by '/' (':' was
suggested, but that wouldn't allow color options in sub-options).
Example: --osd-color=1.0/0.0/0.0/0.75
Using the range 0.0-1.0 has the advantage that it could be easily
extended to colors beyond 8 bit.
Details see manpage.
Suggestions for alternative syntax or value ranges are welcome, but be
quick with it.
The values set by this new option can be queried by Lua scripts using
the mp.getopt() function. The function takes a string parameter, and
returns the value of the first key that matches. If no key matches, nil
is returned.
The terminal OSD code includes the handling of the terminal status line,
showing player OSD messages on the terminal, and showing subtitles on
terminal (the latter two only if there is no video window, or if
terminal OSD is forced).
This didn't handle some corner cases correctly. For example, showing an
OSD message on the terminal always cleared the previous line, even if
the line was an important message (or even just the command prompt, if
most other messages were silenced).
Attempt to handle this correctly by keeping track of how many lines the
terminal OSD currently consists of. Since there could be race conditions
with other messages being printed, implement this in msg.c. Now msg.c
expects that MSGL_STATUS messages rewrite the status line, so the caller
is forced to use a single mp_msg() call to set the status line.
Instead of littering print_status() all over the place, update the
status only once per playloop iteration in update_osd_msg(). In audio-
only mode, the status line might now be a little bit off, but it's
perhaps ok.
Print the status line only if it has changed, or if another message was
printed. This might help with extremely slow terminals, although in
audio+video mode, it'll still be updated very often (A-V sync display
changes on every frame).
Instead of hardcoding the terminal sequences, use
terminfo/termcap to get the sequences. Remove the --term-osd-esc option,
which allowed to override the hardcoded escapes - it's useless now.
The fallback for terminals with no escape sequences for moving the
cursor and clearing a line is removed. This somewhat breaks status line
display on these terminals, including the MS Windows console: instead of
querying the terminal size and clearing the line manually by padding the
output with spaces, the line is simply not cleared. I don't expect this
to be a problem on UNIX, and on MS Windows we could emulate escape
sequences. Note that terminal OSD (other than the status line) was
broken anyway on these terminals.
In osd.c, the function get_term_width() is not used anymore, so remove
it. To remind us that the MS Windows console apparently adds a line
break when writint the last column, adjust screen_width in terminal-
win.c accordingly.
Doesn't make any sense anymore. X11 (which was mentioned in the manpage)
autodetects it, and everything else ignored the option values.
Since for incomprehensible reasons the backends and vo.c still need to
exchange information about the screensize using the option fields,
they're not removed yet.
This basically reverts the default as set by commit 812798c5. This seems
to be a matter of taste, but personally I think keeping the pause
setting is better.
This code is shared between input.conf parser and option parser. Until
now, the performance didn't really matter. But I want to use this code
for JSON parsing too, and since JSON will have to be parsed a lot, it
should probably try to avoid realloc'ing too much.
This commit moves parsing of C-style escaped strings into a common
function, and allows using it in a way realloc can be completely
avoided, if the already allocated buffer is large enough.
Set the flag CODEC_FLAG_OUTPUT_CORRUPT by default. Note that there is
also CODEC_FLAG2_SHOW_ALL, which is older, but this seems to be ffmpeg
only.
Note that whether you want this enabled depends on the user. Some might
prefer that only good frames are output, while others want the decoder
to try as hard as possible to output _anything_. Since mplayer/mpv is
rather the kind of player that tries hard instead of being "clever", set
the new default to override libavcodec's default.
A nice way to test this is switching video tracks. Since mpv doesn't
wait for the next key frame, it'll start feeding the decoder with a
packet from the middle of the stream.
Also, make sure that a track can't be selected twice. While this might
work in some situations, it certainly won't work with subtitles demuxed
from a stream.
Fixes#425.
This is relatively hacky, but it's Christmas, so it's ok. This does two
things: 1. allow selecting two subtitle tracks, and 2. include a hack
that renders the second subtitle always as toptitle. See manpage
additions how to use this.
