summaryrefslogtreecommitdiffstats
path: root/options/m_option.c
Commit message (Collapse)AuthorAgeFilesLines
* options: do not accept ":" as separator anymore in key/value listswm42020-08-221-1/+1
| | | | | | | | | | | | | | | | | | Accepting ":" in addition to "," seems confusing and dumb. It only causing problems when you want to pass a value that contains ":". Remove support for ":", it is now treated like any other normal character. This affects all options that are listed as "Key/value list" in the option list. It's possible that this breaks for someone who happened to use ":" as separator. But this was undocumented, and never recommended. Originally, the option treated many other characters in a special way, but this was changed in commit a3d561f950e74fe. I'm, not sure why ":" was explicitly included. Maybe because -the absurd -vf/--af syntax uses ":" as list separator. But "," was always recommended and used in examples for key/value options. Fixes: #8021 (if you consider it a bug)
* x11: add option to make window appear on a specific workspacewm42020-07-121-2/+13
| | | | | | | | | Mess this into the --geometry option, because I like to be irresponsible. I considered adding a separate option, but at least this allows me to defer the question how the hell this should work as property (geometry simply and inherently does not). Tested on IceWM only. Option equality test and string output not tested.
* options: cleanup .min use for OPT_CHANNELSwm42020-04-091-2/+1
| | | | | | | | Replace use of .min==1 with a proper flag. This is a good idea, because it has nothing to do with numeric limits (also see commit 9d32d62b61547 for how this can go wrong). With this, m_option.min/max are strictly used for numeric limits.
* options: make imgfmt options always accept "no"wm42020-04-091-5/+2
| | | | | | | | This was optional, with the intention that normally such options require a valid format. But there is no reason for this (at least not anymore), and it's actually more logical to accept "no" in all situations this option type is used. This also gets rid of the weird min field special use.
* options: fix ab-loop-* propertieswm42020-04-091-1/+1
| | | | | | | | | | | These used ".min = MP_NOPTS_VALUE" to indicate certain exceptions. This broke with the recent change to how min/max are handled, which made setting min or max mean that a value range is used, thus setting max=0. Fix this by not using magic a value in .min; replace it with a proper flag. Fixes: #7596
* m_option: attempt to fix two rounding issueswm42020-03-181-5/+5
| | | | | | | | | | | | Since double has a mantissa too small to hold INT64_MAX in full precision, converting INT64_MAX to double rounds up. Insert some casts to silence corresponding warnings (as shown by clang 11). Also, the comparison in multiply_int64() was incorrect (I think...), because if v==(double)INT64_MAX, then v==(1<<64), which cannot be represented as int64_t. There are probably better ways to solve this.
* m_option: remove debug codewm42020-03-141-3/+0
| | | | | | | Forgot to remove this. Here you see my confusion and realization how casting INT64_MAX to double becomes INT64_MAX+1 (due to mantissa precision and rounding), so some things seemed not to make sense at first.
* options: introduce bool option type, use it for --fullscreenwm42020-03-141-7/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The option code is very old and was added to MPlayer in the early 2000s, when C99 was still new. MPlayer did not use the "bool" type anywhere,l and the logical option equivalent to bool, the "flag" option type, used int, with the convention that only the values 0 and 1 are allowed. mpv may have hammered many, many additional tentacles to the option code, but some of the basics never changed, and m_option_type_flag still uses int. This seems a bit weird, since mpv uses bool for booleans. So finally introduce an m_option_type_bool. To avoid duplicating too much code, change the flag code to bool, and "reimplement" m_option_type_flag on top of m_option_type_bool. As a "demonstration", change the --fullscreen option to this new type. Ideally, all options would be changed too bool, and m_option_type_flag would be removed. But that is a lot of monotonous thankless work, so I'm not doing it, and making it a painful years long transition. At the same time, I'm introducing a new concept for option declarations. Instead of OPT_BOOL(), which define the full m_option struct contents, there's OPTF_BOOL(), which only takes the option field name itself. The name is provided via a normal struct field initializer. Other fields (such as flags) can be provided via designated initializers. The advantage of this is that we don't need tons of nested vararg macros. We also don't need to deal with 0-sized varargs being a pain (and in fact they are not a thing in standard C99 and probably C11). There is no need to provide a mandatory flags argument either, which is the reason why so many OPT_ macros are used with a "0" argument. (The flag argument seems to confuse other developers; they either don't immediately recognize what it is, and sometimes it's supposed to be the option's default value.) Not having to mess with the flag argument in such option macros is also a reason for the removal of M_OPT_RANGE etc., for the better or worse. The only place that special-cased the _flag option type was in command.c; change it to use something effectively very similar that automatically includes the new _bool option type. Everything else should be transparent to the change. The fullscreen option change should be transparent too, as C99 bool is basically an integer type that is clamped to 0/1 (except in Swift, Swift sucks).
* options: change how option range min/max is handledwm42020-03-131-41/+70
| | | | | | | | | | | | | | | | | Before this commit, option declarations used M_OPT_MIN/M_OPT_MAX (and some other identifiers based on these) to signal whether an option had min/max values. Remove these flags, and make it use a range implicitly on the condition if min<max is true. This requires care in all cases when only M_OPT_MIN or M_OPT_MAX were set (instead of both). Generally, the commit replaces all these instances with using DBL_MAX/DBL_MIN for the "unset" part of the range. This also happens to fix some cases where you could pass over-large values to integer options, which were silently truncated, but now cause an error. This commit has some higher potential for regressions.
* options: split m_config.c/hwm42020-03-131-1/+1
| | | | | | | | | | | | | | | | | Move the "old" mostly command line parsing and option management related code to m_config_frontend.c/h. Move the the code that enables other part of the player to access options to m_config_core.c/h. "frontend" is out of lack of creativity for a better name. Unfortunately, the separation isn't quite clean yet. m_config_frontend.c still references some m_config_core.c implementation details, and m_config_new() is even left in m_config_core.c for now. There some odd functions that should be removed as well (marked as "Bad functions"). Fixing these things requires more changes and will be done separately. struct m_config is left with the current name to reduce diff noise. Also, since there are a _lot_ source files that include m_config.h, add a replacement m_config.h that "redirects" to m_config_core.h.
* options: remove intpair option typewm42020-03-131-53/+0
| | | | | | | | | | | This was mostly unused, and has certain problems. Just get rid of it. It was still used in CDDA (--cdda-span) and a debug option for OpenGL (--opengl-check-pattern). Replace both of these with 2 options, where each sets the start/end values of the former span. Both were undocumented somehow (normally we require all options to be documented), so I'm not caring about compatibility, and not bothering to add it to the API changelog.
* options: remove min/max support from strings and string listswm42020-03-131-27/+1
| | | | | We don't really use this anymore. Only --playlist and vf_lavfi filter names did (to error on empty parameters), but it doesn't really matter.
* 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.
* 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-181-17/+15
| | | | | | | | | | | 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.
* 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.
* m_option: add option comparisonwm42019-11-291-1/+136
| | | | | | 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: pre-check filter names when using vf/af libavfilter bridgewm42019-11-251-1/+5
| | | | | | | | | | | | | 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_option: remove an unused functionwm42019-10-311-9/+0
| | | | I think the last real use of this went away in 2014 or so.
* Replace uses of FFMIN/MAX with MPMIN/MAXwm42019-10-311-5/+4
| | | | And remove libavutil includes where possible.
* vo_gpu, options: don't return NaN through APIwm42019-10-251-9/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | Internally, vo_gpu uses NaN for some options to indicate a default value that is different depending on the context (e.g. different scalers). There are 2 problems with this: 1. you couldn't reset the options to their defaults 2. NaN is a damn mess and shouldn't be part of the API The option parser already rejected NaN explicitly, which is why 1. didn't work. Regarding 2., JSON might be a good example, and actually caused a bug report. Fix this by mapping NaN to the special value "default". I think I'd prefer other mechanisms (maybe just having every scaler expose separate options?), but for now this will do. See you in a future commit, which painfully deprecates this and replaces it with something else. I refrained from using "no" (my favorite magic value for "unset" etc.) because then I'd have e.g. make --no-scale-param1 work, which in addition to a lot of effort looks dumb and nobody will use it. Here's also an apology for the shitty added test script. Fixes: #6691
* m_option: add "B" suffix to human-readable byte numberswm42019-09-191-3/+5
| | | | | | | | | | The conversion to string as the pretty printer returns it is sometimes used on OSD. I think it's pretty odd that quantities below 1 KB are shown as number without suffix. So use "B" for them. For orthogonality, allow the same for parsing. (Although strictly speaking, this is not a requirement of the option API. Option parsers don't need to accept pretty-printed strings.)
* m_option: remove an unused fieldwm42018-05-311-9/+0
|
* encode: get rid of AVDictionary setter helperwm42018-04-291-0/+3
| | | | | | | | | | | | Removes a good hunk of weird code. This loses qscale "emulation", some logging, and the fact that duplicate keys for values starting with +/- were added with AV_DICT_APPEND. I don't assign those any importance, even if they are user-visible changes. The new M_OPT_ flag is just so that nothing weird happens for other key-value options, which do not interpret a "help" key specially.
* m_option: remove unneded compatibility featureswm42018-02-281-8/+1
| | | | | Aliases that set old options are not needed anymore. Also extend the total size of the aliases array for one of the following commits.
* options: minor cleanup to --no-... handlingwm42018-02-131-2/+4
| | | | | | | | Most options starting with --no-<name> are automatically translated to --<name>=no. Make the code slightly nicer by using a flag instead of explicitly comparing option types. Also fix an issue that made the option parser print nonsense error messages for if --no-... was used for options which don't support it.
* options: slightly improve filter help output for lavfi bridgewm42018-02-031-1/+9
| | | | | | | | | | | | | | --vf=help will now list libavfilter filters, and e.g. --vf=yadif=help will list libavfilter filter options. The latter is rather bare, because the AVOption API is really awful (holy shit how is it so bad), and would require us to handle _every_ option type manually. Alternatively we could call av_opt_show2(), which ffmpeg uses for help output in its CLI tools and which is much more detailed. But it's rather foreign and forces output through av_log(), so I don't really want to use it.
* options: add string list -toggle actionwm42018-01-251-0/+24
|
* m_option: remove string list -append action code duplicationwm42018-01-251-15/+6
| | | | | | | | Instead of duplicating the append code, reimplement it using the existing code. The difference between -add and -append is that -append does not take multiple items (thus removing the need for escaping), but -append can reuse all code for -add by pretending the separator is never found.
* options: add an option type for byte sizeswm42018-01-251-0/+95
| | | | | | And use it for 2 demuxer options. It could be used for more options later. (Though the --cache options can not use this, because they use KB as base unit.)
* m_option: add missing print callbackswm42018-01-251-5/+35
| | | | | | | | | | | Add the print callback to all option types (except pseudo option types which don't represent values). This makes it less confusing for client API users (no strange properties that can't be read), and also lists the default properly with --list-options. Fix the option type for audio formats - they use int, not uint32_t. Fix some identation cosmetic issues.
* m_option: add print callback to color typeOlivier Perret2018-01-221-0/+7
| | | | This lets scripts query the value of 'background' and similar properties
* m_option: add print callback to start/end/lengthRicardo Constantino2018-01-031-0/+18
|
* options: add -add/-append actions to key/value listswm42017-12-261-4/+30
| | | | Requested.
* options: rename 'error' labels to 'exit' where appropriatepavelxdd2017-12-161-13/+13
|
* options: don't report errors on help value for OPT_SIZE_BOXpavelxdd2017-12-161-4/+10
| | | | | | The same idea as in 3723e61 but for OPT_SIZE_BOX now. Affects options `autofit`, `autofit-larger` and `autofit-smaller`.
* options: don't report errors on help value for OPT_GEOMETRYpavelxdd2017-12-111-4/+11
| | | | The same idea as in 3723e61 but for OPT_GEOMETRY now.
* options: don't report errors on help value for OPT_COLORpavelxdd2017-12-111-6/+12
| | | | | The same idea as in 3723e61 but for OPT_COLOR now. Added missing closing bracket in the help message.
* options: don't report errors on help value for OPT_FLAGpavelxdd2017-12-111-4/+9
| | | | The same idea as in 3723e61 but for OPT_FLAG now.
* options: don't report errors on help value for OPT_CHOICEpavelxdd2017-12-081-4/+15
| | | | | | | 'help' is a valid value for a lot of mpv options, such as `hwdec` or `vo` for printing available values, so this change makes the output of OPT_CHOICE options like `--video-sync=help` more consistent by not reporting an error about invalid value 'help'.
* options: add --start=none to reset previously set start timeAman Gupta2017-12-061-0/+5
| | | | | | | | | | | | | Previously when using a libmpv instance to play multiple videos, once --start was set there was no clear way to unset it. You could use --start=0, but 0 does not always mean the beginning of the file (especially when using --rebase-start-time=no). Looking up the start timestamp and passing that in also does not always work, particularly when the first timestamp is negative (since negative values to --start have a special meaning). This commit adds a new "none" value which maps to the internal REL_TIME_NONE, matching the default value of the play_start option.
* options: rename empty string special case for option valueswm42017-12-011-3/+0
| | | | | "--bla" behaved differently from "--bla=". Change this, in line with how options have been changed in general over the last few years.
* m_option: pretty print mpv_node for OSDwm42017-10-301-0/+11
| | | | | | Somewhat useful for debugging. Unfortunately libass (or something else) strips leading whitespace, making it look slightly more ugly than necessary. Still an improvement.
* build: add preliminary LGPL modewm42017-09-211-9/+7
| | | | | | | See "Copyright" file for caveats. This changes the remaining "almost LGPL" files to LGPL, because we think that the conditions the author set for these was finally fulfilled.
* m_option: deprecate multiple items for -add etc.wm42017-07-021-2/+10
| | | | | | | | This is more confusing than it helps, and forces escaping more stuff. For example, for string lists we could remove all need for escaling with -add and -pre. The user can simply use multiple of those options.
* options: change everything againwm42017-07-021-28/+5
| | | | Fucking bullshit.
* m_option: remove unused error codewm42017-07-021-5/+0
| | | | | The situation in the str_list_* functions can never happen, and they were the only users of this error code.
* m_option: remove redundant indirectionswm42017-07-021-2/+2
| | | | | | Remove the various redundant m_config_set_option* calls, rename the remaining one to m_config_set_option_cli(), and merge the m_config_parse_option() function.
* options: change path list options, and document list optionswm42017-06-301-3/+3
| | | | | | | | | | | | | | | | | | | | | | | The changes to path list options is basically getting rid of the need to pass multiple paths to a single option. Instead, you can use the option multiple times. The old behavior can be used by using the -set suffix with the option. Change some options to path lists. For example --script is now append by default, and if you use --script-set, you need to use ":"/";" as separator instead of ",". --sub-paths/--audio-file-paths is a deprecated alias now, and will break if the user tries to pass multiple paths to it. I'm assuming that if these are used, most users will pass only 1 path anyway. --opengl-shaders has more compatibility handling, since it's probably rather common that users pass multiple options to it. Also document all that in the manpage. I'll probably regret this later, as it somewhat increases the complexity of the option parser, rather than increasing it.