summaryrefslogtreecommitdiffstats
path: root/options
Commit message (Collapse)AuthorAgeFilesLines
* mac: always include the macOS config when cocoa is availableder richter2020-02-091-1/+1
| | | | | | | | | | the macOS config was only used in cocoa-cb before and only included when it was available. since this config is meant for general macOS options and backend independent options we include it when cocoa is available. one of the options is already used in the old cocoa backend, which broke using it when build without swift or cocoa-cb support. Fixes #7449
* player: add ab-loop-count option/propertywm42020-02-082-0/+4
| | | | | | | | | | | | As requested I guess. It behaves quite similar to the --loop* options. Not quite happy with the idea that 1) the option is mutated on each operation (but at least it's consistent with --loop* and doesn't require more properties), and 2) the ab-loop command will do nothing once all loop iterations are done. As a concession, the OSD shows something about "disabled". Fixes: #7360
* options: disable vsfilter blur compat by defaultwm42020-02-071-1/+1
| | | | | | | | | | | | | | | | | | | See #7435 and related for context. Basically, it seems that while the original vsfilter processed subtitles like with this option set to "yes", many current players (mpc-hc default, vlc, probably most libass users) treat them like with "no". In the linked issue, this makes rendering severely slower, and can consume a lot of memory (or just overflow libass memory calculations). It seems that changing this to "no" will lead to more good than bad, especially because newer subtitles may be authored for the "no" behavior. Most libass users seem to use "no" exactly because they do not call ass_set_storage_size() at all. This API was needed because the scaling of the subtitles depends on the video size (vsfilter bugs, or something). In addition, it's my personal opinion that rendering should not depend on the video at all, so I like setting the default of this to "no".
* path: add mp_path_is_absolute()wm42020-02-062-10/+21
| | | | Just move it from mp_path_join_bstr() to this new function.
* path: change win32 semantics for joining drive-relative pathswm42020-02-061-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | win32 is a cursed abomination which has "drive letters" at the root of the filesystem namespace for no reason. This requires special handling beyond tolerating the idiotic "\" path separator. Even more cursed is the fact that a path starting with a drive letter can be a relative path. For example, "c:billsucks" is actually a relative path to the current working directory of the C drive. So for example if the current working directory is "c:/windowsphone", then "c:billsucks" would reference "c:/windowsphone/billsucks". You should realize that win32 is a ridiculous satanic trash fire by the point you realize that win32 has at least 26 current working directories, one for each drive letter. Anyway, the actual problem is that mpv's mp_path_join() function would return a relative path if an absolute relative path is joined with a drive-relative path. This should never happen; I bet it breaks a lot of assumptions (maybe even some security or safety relevant ones, but probably not). Since relative drive paths are such a fucked up shit idea, don't try to support them "properly", and just solve the problem at hand. The solution produces a path that should be invalid on win32. Joining two relative paths still behaves the same; this is probably OK (maybe). The change isn't very minimal due to me rewriting parts of it without strict need, but I don't care. Note that the Python os.path.join() function (after which the mpv function was apparently modeled) has the same problem.
* options: stop hiding deprecated optionswm42020-02-042-7/+3
| | | | | I think this was annoying. It shouldn't be dishonest about which options exist. List them as "[deprecated]" instead.
* options: remove unused set_defaults callbackwm42020-02-012-6/+0
| | | | | Was only needed for an ancient version of af_lavfrresample, which is gone now.
* options: merge split_opt functionswm42020-01-291-30/+18
| | | | | | | | | | | There wasn't really much of a reason to keep split_opt and splot_opt_silent apart. It made sense before the latter also had a log call (which was silenced by using mp_null_log if necessary). Just merge them back into one, and always rely on mp_null_log to silence unwanted output. Shouldn't have any functional changes.
* options: suggest not using the syntax that was recently disabledwm42020-01-291-0/+4
|
* Revert "options: move cursor autohiding opts to mp_vo_opts"dudemanguy2020-01-122-7/+6
| | | | This reverts commit 65a317436df05000366af2738bdbb834e95e33db.
* options: change option parsing when using a single dashwm42020-01-071-3/+9
| | | | | | | | | | | | | Addresses dumb things like accidentally overwriting a media file with e.g. "mpv --log-file test.mkv" (when the user thought that --log-file was a flag option, when it actually takes a filename). This example will now print an error. It still works with "-log-file overwritten.mkv", but prints a warning. Not sure if I'm being too careful or not "radical" enough. In any case, both the syntax that stops working and the syntax that produces a warning now have been discouraged and were called legacy for almost a decade.
* command: make sub-step command actually apply sub-delay change properlywm42020-01-042-2/+18
| | | | | | | | | The change was not propagated to the OSD/subtitle code, since that still uses an "old" method. Change it so that the propagation is actually performed. (One could argue the OSD/subtitle code should use other ways to update the options, but that would probably be more effort for now.)
* options: add mechanism to add sub-options from component listswm42020-01-042-0/+15
| | | | | | | | | | | | | There are a lot of ad-hoc component lists in mpv: for example the stream and demuxer lists. It doesn't seem to make sense to add any abstractions around it since they are completely trivial and have very specific probing mechanisms and so on, so they will remain ad-hoc. This commits add a way to let these add arbitrary per-component options, without giving up the ad-hoc way, and without having to dump them into options.c with lots of ifdeffery (like it was done until now). Also see next commit.
* playlist: change from linked list to an arraywm42019-12-281-4/+5
| | | | | | | | | | | | | | | | | | | Although a linked list was ideal at first, there are cases where it sucks, and became increasingly awkward (with the mpv command API preferring integer indexes to access the list). In future, we probably want to add more playlist-related functionality, so better change it to an array now. An array isn't always ideal either. Since playlist entries are still separate objects (because in some cases you need a stable "iterator" to it), but you still need to efficiently get the next/previous playlist entry, there's a pl_index field, that needs to be maintained. E.g. adding an entry at the start of the playlist => update the pl_index field for all other entries. Well, it's not really worth to do something more complicated to avoid these things. This commit is probably buggy as shit. It's not like I bothered to test everything. That's _your_ role.
* 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
| | | | | |