summaryrefslogtreecommitdiffstats
path: root/options
Commit message (Collapse)AuthorAgeFilesLines
* m_option: fix runtime changing of --audio-channelswm42019-12-271-3/+14
| | | | | | | | This option type, used by --audio-channels, had a completely broken m_option_type.equal implementation, and thus reacted incorrectly to runtime option changes. Broken since commit b16cea750f527088be7977.
* stream, demux: redo origin policy thingwm42019-12-202-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mpv has a very weak and very annoying policy that determines whether a playlist should be used or not. For example, if you play a remote playlist, you usually don't want it to be able to read local filesystem entries. (Although for a media player the impact is small I guess.) It's weak and annoying as in that it does not prevent certain cases which could be interpreted as bad in some cases, such as allowing playlists on the local filesystem to reference remote URLs. It probably barely makes sense, but we just want to exclude some other "definitely not a good idea" things, all while playlists generally just work, so whatever. The policy is: - from the command line anything is played - local playlists can reference anything except "unsafe" streams ("unsafe" means special stream inputs like libavfilter graphs) - remote playlists can reference only remote URLs - things like "memory://" and archives are "transparent" to this This commit does... something. It replaces the weird stream flags with a slightly clearer "origin" value, which is now consequently passed down and used everywhere. It fixes some deviations from the described policy. I wanted to force archives to reference only content within them, but this would probably have been more complicated (or required different abstractions), and I'm too lazy to figure it out, so archives are now "transparent" (playlists within archives behave the same outside). There may be a lot of bugs in this. This is unfortunately a very noisy commit because: - every stream open call now needs to pass the origin - so does every demuxer open call (=> params param. gets mandatory) - most stream were changed to provide the "origin" value - the origin value needed to be passed along in a lot of places - I was too lazy to split the commit Fixes: #7274
* options: fix incorrect deprecation messagewm42019-12-191-2/+4
| | | | | Passing multiple items to a key/value option is OK, only for -add suffixed options it's deprecated.
* options: fix UB/crash in key/values parserwm42019-12-181-2/+2
| | | | | | | | keyvalue_list_find_key() was called on a "partially" constructed list, because the terminating NULL was added only later. Didn't I say this code is cursed? Fixes: #7273
* options: deprecate -del for list optionswm42019-12-181-0/+6
| | | | | | I never liked that these used integer indexes. -remove should have existed from the start. This deprecation is yet another empty threat, though.
* options: fix filter list comparison (again)wm42019-12-182-17/+17
| | | | | | | | | | | This was completely broken: it compared the first item of the filter list only. Apparently I forgot that this is a list. This probably broke aspects of runtime filter changing probably since commit b16cea750f52. Fix this, and remove some redundant code from obj_settings_equals(). Which is not the same as m_obj_settings_equal(), so rename it to make confusing them harder. (obj_setting_match() has these very weird label semantics that should probably just be killed. Or not.)
* options: add -remove action to list optionswm42019-12-181-7/+36
| | | | | | Actually I wanted this for key/value lists only, but add it to the others for consistency too. (For vf/af it barely makes even sense, but anyway.)
* options: make keys in key/value lists uniquewm42019-12-181-0/+27
| | | | | | | | | | | | | | I don't even know anymore whether this was intended or not. Certain use cases for the "-o" options might require this. These options are for passing general FFmpeg options. These are translated to av_opt_set() calls, which may or may not accumulate the option values on multiple calls with the same option name (how should I know?). Anyway, it seems crazy to allow non-unique keys, so make them unique. The ad-hoc nature of the option code makes this wonderfully complicated (when I wrote that this code is cursed, I meant it). In combination with lazy testing, it probably means there are lots of bugs here.
* options: increase consistency between list options and document themwm42019-12-181-3/+16
| | | | | | | | | | | | | | | | | | | | Whenever I deal with this, I have to look at the code to make sense of this. And beyond that, there are some strange inconsistencies. (I think this code is cursed. It always was, and maybe always will be.) Although the manpage claimed that using multiple items for -add etc. is deprecated, string list options didn't warn against it. So add the warning, and add something in the changelog (even though nobody will ever read this). The manpage mentioned --vf-append, but this didn't even exist. So add it, I guess. We encourage using -append for the other option types, so for consistency, it should work on filter options. (And I already tricked me into believing it existed when I mentioned it in the manpage.) Make the "operations" table separate for all option types, and mention the option type on every single of the top-level list options.
* command: slightly simplify input-ipc-server change detection/initwm42019-12-171-2/+2
| | | | | | | The generic change detection now handles this just as well. The way how this function is manually called at init is slightly gross. Make that part slightly more explicit to hopefully avoid confusion.
* m_option: clamp integer before adding a valuewm42019-12-161-0/+2
| | | | | | | | | | | | | | This is for the previous commit, and should affect behavior with the special M_PROPERTY_GET_CONSTRICTED_TYPE mechanism only. The effect is that cycling the "edition" property, if the option is set to "auto", will change to the second edition instead of the first. Normally, option values must always be within their range, so this should not affect anything else. M_PROPERTY_GET_CONSTRICTED_TYPE is sort-of fine with this kind of behavior. If this affects any other M_PROPERTY_GET_CONSTRICTED_TYPE users neqatively, I will revert the change.
* console.lua: add this scriptJames Ross-Gowan2019-12-082-0/+3
| | | | | | | | | | | | | | | | | | | | | Merged from mpv-repl git repo commit 5ea2bf64f9c239f0326b02. Some changes were made on top of it: - Tabs were converted to 4 spaces indentation (plus some manual indentation fixes in some places). - All user-visible mentions of "repl" were renamed to "console". - The README was converted to a manpage (with heavy changes, some additions taken from stats.rst; rossy converted the key bindings table to RST). - The method to change the default key binding was changed. - Change minor detail about "font" default value setting (not a functional change). - Integrate into the player as builtin script, including an option to prevent loading it. Above changes and commit message done by wm4. Signed-off-by: wm4 <wm4@nowhere>
* options: move cursor autohiding opts to mp_vo_optsdudemanguy2019-12-042-6/+7
| | | | | | Certain backends (i.e. wayland) will need to do special things with the mouse. It makes sense to expose the values of these options to them, so they can behave correctly.
* m_config: remove change callback before unintializationwm42019-11-301-0/+1
| | | | | | | | | | | | | | | We don't want m_config uninitialization to call random change callbacks. This happens at the end of mp_destroy(), when almost everything else is already destroyed, and the change callbacks would probably trigger UB all over the place. The change callbacks could be trigger by m_config_restore_backups(), which is just used as a cheap way to free the remaining state. The worst is that this depends on which options may still have been part of this "backup" state, which depends on user input. Probably never a practical problem, since the backup state is most likely guaranteed to be empty before uninit is performed, but still.
* command: change window-minimized/window-maximized to optionswm42019-11-292-0/+4
| | | | | Unfortunately, this breaks window state reporting for all VOs which supported it. This can be fixed later (for x11 in the next commit).
* player: change m_config to use new option handling mechanismswm42019-11-292-67/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of making m_config a special-case, it more or less uses the underlying m_config_cache/m_config_shadow APIs properly. This makes the player core a (relatively) equivalent user of the core option API. In particular, this means that other threads can change core options with m_config_cache_write_opt() calls (before this commit, this merely led to diverging option values). An important change is that before this commit, mpctx->opts contained the "master copy" of all option data. Now it's just another copy of the option data, and the shadow copy is considered the master. This is why whenever mpctx->opts is written, the change needs to be copied to the master (thus why this commits add a bunch of m_config_notify... calls). If another thread (e.g. a VO) changes an option, async_change_cb is now invoked, which funnels the change notification through the player's layers. The new self_notification parameter on mp_option_change_callback is so that m_config_notify... doesn't trigger recursion, and it's used in cases where the change was already "processed". It's still needed to trigger libmpv property updates. (I considered using an extra m_config_cache for that, but it'd only cause problems with no advantages.) I think the recent changes actually forgot to send libmpv property updates in some cases. This should fix this anyway. In some cases, property updates are reworked, and the potential for bugs should be lower (probably). The primary point of this change is to allow external updates, for example by a VO writing the fullscreen option if the window state is changed by the window manager (rather than mpv changing it). This is not used yet, but the following commits will.
* m_config: make m_config_cache_write_opt() check/return changeswm42019-11-292-8/+14
| | | | | | Goes in line with the recent changes to always checking for option value changes. The player core will use this to determine whether it should send additional change events.
* options: get rid of GLOBAL_CONFIG hackwm42019-11-294-36/+28
| | | | | | | Just an implementation detail that can be cleaned up now. Internally, m_config maintains a tree of m_sub_options structs, except for the root it was not defined explicitly. GLOBAL_CONFIG was a hack to get access to it anyway. Define it explicitly instead.
* m_config: untangle new and old code somewhatwm42019-11-291-75/+177
| | | | | | | | | | | | | | The original MPlayer m_config was essentially only responsible for handling some command line parsing details, handling profiles, and file-local options. And then there's the new mpv stuff (that stuff was regretfully written by me), which is mostly associated with making things thread-safe (includes things like making it all library-safe, instead of stuffing all option data into global variables). This commit tries to separate them some more. For example, m_config_shadow (the thread-safe thing) now does not need access to m_config anymore. m_config can hopefully be reduced to handling only the "old" mplayer-derived mechanisms.
* m_config: allow writing options through m_config_cachewm42019-11-292-0/+74
| | | | | | | | | | | | | | This will allow any other threads to write to the global option data in a safe way. The typical example for this is the fullscreen option, which needs to be written by VO (or even some other thing running completely separate from the main thread). We have a complicated and annoying contraption which gets the value updated on the main thread, and this function will help get rid of it. As of this commit, this doesn't really work yet, because he main thread uses its own weird copy of the option data.
* m_config: add fine-grained option reporting mechanismwm42019-11-292-34/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds m_config_cache_get_next_changed() and the change_flags field in m_config_cache. Both can be used to determine whether specific options changed (rather than the entire sub-group). Not sure if I'm very happy with that. The former rather compact update_options() is now a bit of a mess, because it needs to be incremental. m_config_cache_get_next_changed() will not be too nice to use, and change_flags still relies on global "allocation" of change flags (see UPDATE_* defines in m_option.h). If C weren't such a primitive language that smells like grandpa, it would be nice to define per-option change callbacks or so. This compares options by value to determine whether they have changed. This makes it slower in theory, but in practice it probably doesn't matter (options are rarely changed after initialization). The alternative would have been per-option change counters (wastes too much memory; not a practical problem but too ugly), or keep all m_config_caches in a global list and have bitmaps with per-option change bits (sounds complicated). I guess the current way is OK. Technically, this changes semantics slightly by ignoring setting an option to the same value. Technically this wasn't a no-op, although the effect was almost almost no-op. Some code would actually become cleaner by ignoring such redundant change events, and them being no-op is probably also what the user would normally assume.
* m_config: move stuff aroundwm42019-11-292-53/+77
| | | | | | | | | | Create a separate struct for internal fields of m_config_cache, so API users can't just mess with stuff they shouldn't access. Move the ts field out of m_config_data, so we don't need unnecessary atomics in one case. This is just preparation, and shouldn't change any behavior.
* m_option: remove an outdated ancient commentwm42019-11-291-7/+1
| | | | | | | The exact type name (m_obj_list_t) was removed in 2013. I don't think this stub comment helps much with understanding this complicated thing anyway (this code is for the --vf/--af options, and makes up almost half of m_option.c).
* m_option: add option comparisonwm42019-11-292-1/+156
| | | | | | Looks like this will be needed for fine-grained option change notifications. There are some other parts in the player which implement parts of this.
* options: remove options-to-property bridgewm42019-11-252-32/+3
| | | | | | | | The previous bunch of commits made this unnecessary, so this should be a purely internal change with no user impact. This may or may not open the way to future improvements. Even if not, at least the property/option interaction should now be much less buggy.
* options: pre-check filter names when using vf/af libavfilter bridgewm42019-11-252-1/+8
| | | | | | | | | | | | | Until now, using a filter not in mpv's builtin filter list would assume it's a libavfilter filter. If it wasn't, the option value was still accepted, but creating the filter simply failed. But since this happens after option parsing, so the result is confusing. Improve this slightly by checking filter names. This will reject truly unknown filters at option parsing time. Unfortunately, this still does not check filter arguments. This would be much more complex, because you'd have to create a dummy filter graph and allocate the filter. Maybe another time.
* m_config: discourage mp_read_option_raw()wm42019-11-251-0/+1
| | | | | | This function is dangerous, because it disables the already basic/week type checking the option system has at all. I'm tend towards thinking that all of its uses should be replaced.
* command, options: deprecate old --display-fps behaviorwm42019-11-251-1/+2
| | | | | | | See changelog and manpage changes. (So much effort to fix an ancient dumb mistake for an option nobody should use anyway.)
* command: shuffle some crap aroundwm42019-11-251-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | This is preparation to get rid of the option-to-property bridge (mp_on_set_option). This is a pretty insane thing that redirects accesses to options to properties. It was needed in the ever ongoing transition from something to... something else. A good example for the need of this bridge is applying profiles at runtime. This obviously goes through the config parser, but should also make all changes effective, for which traditionally the property layer is used. There isn't much left that needs this bridge. This commit changes a bunch of options (which also have a property implementation) to use option change notifications instead. Many of the properties are still left, but perform unrelated functions like OSD formatting. This should be mostly compatible. There may be some subtle behavior changes. For example, "hwdec" and "record-file" do not check for changes anymore before applying them, so writing the current value to them suddenly does something, while it was ignored before. DVB changes untested, but should work.
* options: remove deprecated --playlist-pos aliaswm42019-11-241-1/+0
| | | | | This causes problems because it has the same name as a property which behaves differently.
* player: Optionally validate st_mtime when restoring playback stateChris Down2019-11-202-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I often watch sporting events. On many occasions I get files with the same filename for each session. For example, for F1 I might have the following directory structure: F1/ FP1.mkv FP2.mkv FP3.mkv Qualification.mkv Race.mkv Since usually one simply watches one race after the other, I usually just rsync the new event's files over the old ones, so, for example, Race.mkv will be replaced from the file for the last event with the file from the new event. One problem with this is that I like to use --resume-playback for other kinds of media, so I have it on by default. That works great for, say, a movie, but doesn't work so well with this scheme, because you can trivially forget to pass --no-resume-playback on the command line and end up 2 hours in, watching spoilers as the race results scroll down the screen :-) This patch adds a new option, --resume-playback-check-mtime, which validates that the file's mtime hasn't changed since the watch_later configuration was saved. It does this by setting the watch_later configuration to have the same mtime as the file after it is saved. Switching back and forth between checking mtime and not checking mtime works fine, as we only choose whether to compare based on it, but we update the watch_later configuration mtime regardless of its value.
* options: deprecate --input-filewm42019-11-161-1/+2
| | | | | | I have no idea why this still exists, since we have --input-ipc-server. I think there was something about Windows, but the latter option is implemented even on Windows.
* options: remove M_SETOPT_RUNTIMEwm42019-11-101-3/+0
| | | | | | | Used to contain flags for "save" setting of options at runtime. Now there is nothing special needed anymore and it's 0. So drop it completely, and remove anything that distinguishes between runtime and initialization time.
* options: remove M_OPT_FIXEDwm42019-11-104-33/+20
| | | | | | | | | | | | | | | | | | | | | | | Options marked with this flag were changed to strictly read-only after initialization (mpv_initialize() in the client API, after option parsing and config file loading with the CLI player). This used to be necessary, because there was a single option struct that could be accessed by multiple threads. For example, --config-dir sets MPOpts.force_configdir, which was read whenever anything accessed the mpv config dir (which could be on different threads, e.g. font initialization tries to lookup fonts.conf from an arbitrary thread). This isn't needed anymore, because threads now access these in a thread safe way. In the case of --config-dir, the path is actually just copied on init. This M_OPT_FIXED mechanism is thus not strictly needed anymore. It still prevents writing to some options that cannot take effect at runtime, but even that can be dropped. In general, all mpv options can be changed any time at runtime, even if they never take effect, and there's no need to make an exception for a very low number of options. So just get rid of it.
* test: make tests part of the mpv binarywm42019-11-082-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, each .c file in test/ was built as separate, self-contained binary. Each binary could be run to execute the tests it contained. Change this and make them part of the normal mpv binary. Now the tests have to be invoked via the --unittest option. Do this for two reasons: - Tests now run within a "properly" initialized mpv instance, so all services are available. - Possibly simplifying the situation for future build systems. The first point is the main motivation. The mpv code is entangled with mp_log and the option system. It feels like a bad idea to duplicate some of the initialization of this just so you can call code using them. I'm also getting rid of cmocka. There wouldn't be any problem to keep it (it's a perfectly sane set of helpers), but NIH calls. I would have had to aggregate all tests into a CMUnitTest list, and I don't see how I'd get different types of entry points easily. Probably easily solvable, but since we made only pretty basic use of this library, NIH-ing this is actually easier (I needed a list of tests with custom metadata anyway, so all what was left was reimplement the assert_* helpers). Unit tests now don't output anything, and if they fail, they'll simply crash and leave a message that typically requires inspecting the test code to figure out what went wrong (and probably editing the test code to get more information). I even merged the various test functions into single ones. Sucks, but here you go. chmap_sel.c is merged into chmap.c, because I didn't see the point of this being separate. json.c drops the print_message() to go along with the new silent-by-default idea, also there's a memory leak fix unrelated to the rest of this commit. The new code is enabled with --enable-tests (--enable-test goes away). Due to waf's option parser, --enable-test still works, because it's a unique prefix to --enable-tests.
* stream: turn into a ring buffer, make size configurablewm42019-11-062-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some corner cases (see #6802), it can be beneficial to use a larger stream buffer size. Use this as argument to rewrite everything for no reason. Turn stream.c itself into a ring buffer, with configurable size. The latter would have been easily achievable with minimal changes, and the ring buffer is the hard part. There is no reason to have a ring buffer at all, except possibly if ffmpeg don't fix their awful mp4 demuxer, and some subtle issues with demux_mkv.c wanting to seek back by small offsets (the latter was handled with small stream_peek() calls, which are unneeded now). In addition, this turns small forward seeks into reads (where data is simply skipped). Before this commit, only stream_skip() did this (which also mean that stream_skip() simply calls stream_seek() now). Replace all stream_peek() calls with something else (usually stream_read_peek()). The function was a problem, because it returned a pointer to the internal buffer, which is now a ring buffer with wrapping. The new function just copies the data into a buffer, and in some cases requires callers to dynamically allocate memory. (The most common case, demux_lavf.c, required a separate buffer allocation anyway due to FFmpeg "idiosyncrasies".) This is the bulk of the demuxer_* changes. I'm not happy with this. There still isn't a good reason why there should be a ring buffer, that is complex, and most of the time just wastes half of the available memory. Maybe another rewrite soon. It also contains bugs; you're an alpha tester now.
* m_config: log applying profileswm42019-11-011-0/+1
|
* m_config: raise log level of setting options to verbosewm42019-11-011-2/+2
| | | | | | | | In 2017, we lowered this to debug level. But I think setting options is important enough that it should be logged even in verbose, at least compared to all the other dumb noise. This might be reduced again if verbose logging becomes much cleaner.
* m_option: remove an unused functionwm42019-10-312-12/+0
| | | | I think the last real use of this went away in 2014 or so.
* options: make --show-profile without parameters list all profileswm42019-10-312-8/+15
|
* sws_utils: shuffle around some shitwm42019-10-312-7/+8
| | | | | | | | | | | Purpose uncertain. I guess it's slightly better, maybe. The move of the sws/zimg options from VO opts (vo_opt_list) to the top-level option list is tricky. VO opts have some helper code in vo.c, that sends VOCTRL_SET_PANSCAN to the VO on every VO opts change. That's because updating certain VO options used to be this way (and not just the panscan option). This isn't needed anymore for sws/zimg options, so explicitly move them away.
* Replace uses of FFMIN/MAX with MPMIN/MAXwm42019-10-311-5/+4
| | | | And remove libavutil includes where possible.
* options: set correct range for --video-aspect-overridewm42019-10-251-3/+2
| | | | | It appears this option didn't have min/max enabled for quite a while (broken while it was still called --aspect).
* vo_gpu, options: don't return NaN through APIwm42019-10-252-9/+31
| |