summaryrefslogtreecommitdiffstats
path: root/options/m_option.c
Commit message (Collapse)AuthorAgeFilesLines
* m_option: change confusing error messages for obj_settings_listnanahi11 hours1-7/+7
| | | | | | | | | This option type is not used only by filter options: they're already used by --ao, --vo, and --gpu-context. Replace the mentions of "filter" to "item" instead, and changes some languages to improve clarity. Also change the documentation on "Filter options" to describe what it really is, and fix a typo.
* m_property: add `>` for fixed precision floating-point expansionKacper Michajłow2024-03-211-14/+8
| | | | | | | | | | | | | | This enhancement makes it easier to create constant width property expansions, useful for the `--term-status-msg`. Additionally, it changes to `%f` printing with manual zero trimming, which is easier to control than `%g`. With this method, we can directly specify precision, not just significant numbers. This approach also avoids overly high precision for values less than 1, which is not necessary for a generic floating-point print function. A new print helper function is added, which can be used with adjusted precision for specific cases where a different default is needed. This also unifies the code slightly.
* various: use static assertions where appropriatesfan52024-03-171-1/+1
|
* various: avoid function pointer castsKacper Michajłow2024-02-281-5/+0
| | | | | | | | | | | | | The opt validator functions are casted to generic validator, which has erased type for value. Calling function by pointer of different definition is an UB. Avoid that by generating wrapper function that does proper argument type conversion and calls validator function. Type erased functions have mangled type in the name. Fixes UBSAN failures on Clang 17, which enabled fsanitize=function by default.
* m_option: fix memory leak in parse_obj_settings_listKacper Michajłow2024-02-151-3/+10
| | | | Found by fuzzing.
* options/m_option: suppress warning about validate function callKacper Michajłow2024-01-261-0/+5
| | | | | | | It is expected. Last argument of validate functions is always a pointer, but not always void* which triggers UBSAN warning. meson since 1.3.1 halts on UBSAN errors in tests, which is good thing.
* m_option: respect pathlist seperator when printingllyyr2023-12-041-1/+2
| | | | Apparently we never did this
* m_option: remove leftovers of del actionGuido Cella2023-11-121-8/+2
| | | | | | | | | | b56e63e2a9 removed -del for list options but it is still listed in the list structs, which means that it is still tab completed on the CLI like the other actions, and seems to behave like -set. Remove it so it is no longer tab completed. Also remove the description of -del from the help output of object settings lists --(ao|vo|af|vf)-help, and update a comment.
* m_option: don't try to remove all filter matchesDudemanguy2023-11-011-8/+6
| | | | | | | | | | | | Probably should have actually tested the filter changes but I didn't. This was the wrong spot anyway since labels are unique. Something like this should have been done further down when finding it by content. On second thought, having multiple filters with the same content does have a usecase (e.g. stacking multiple rotations) so removing all of them at once probably isn't great. There's no practical usecase for having duplicates in a string list, so we'll leave that change alone. Fixes #12791.
* m_option: drop support for -del for list optionsDudemanguy2023-10-301-101/+11
| | | | | | 5f74ed58286a1339412554932f31844ec1b64280 deprecated this many years ago. The utility is questionable at best given that -remove exists and is more natural to use. Free up some code and drop it.
* m_option: remove all matches when using -removeDudemanguy2023-10-301-13/+22
| | | | | | | | When using -remove with list options, it previously only removed the first match. Technically, it is possible for there to be more than entry with the same name. They should all be removed. key/value lists specifically only allow unique keys so we don't need to do anything there.
* player/command: truncate anything < 1e-4 in pretty printerKacper Michajłow2023-10-181-1/+6
| | | | | | | | To avoid switching to scientific notation. Apparently it is "jarring" for some users. This preserves status quo from before 9dddfc4f where pretty printer were truncated to 3 decimal places.
* player/command: change how floating point number are printedKacper Michajłow2023-10-141-5/+5
| | | | | | | | Use "%.7g" to show 7 significant digits. Removes the trailing zeros, and in general makes it more readable, than fixed 3 decimal digits. For avsync use "%+.2g" to add plus sign, similar to display-sync values.
* options: make video-crop validation more strictKacper Michajłow2023-09-201-7/+9
|
* m_option: return empty rect when no width/height is availableKacper Michajłow2023-09-081-0/+2
|
* m_option: make m_rect_apply center basedKacper Michajłow2023-09-081-9/+5
| | | | | | | | | This makes it easier to apply crops without need to manually calc the offset. I wanted for it to be top-left corner based, but maybe it was not that good idea in retrospect. Also rename scrw/scrh, since they don't refer to screen. It was copied form m_geometry apply.
* m_option: add OPT_RECTKacper Michajłow2023-08-311-0/+58
| | | | Parsed as WxH+X+Y to mp_rect. Allows also WxH without the offset.
* m_option: change m_option_type_aspect to doubleDudemanguy2023-08-091-26/+26
| | | | | | | | | | | | | This specific option type is only used for the video aspect. The underlying type was a float to represent the inputted value, but it's actually not precise enough. When using something like 4:3, the values of the incorrect digits are actually significant enough to make av_d2q return a very funky numerator and denominator which is close to 4/3 but not quite. This leads to some "off by one pixel" errors. Weirdly, mpv's actual calculations for this were already being done as double, but then converted to floats for this specific type. Just drop the conversion step and leave it all as double which has the precision we need (i.e. AVRational is now 4/3 for the this case). Fixes #8190.
* options: fix relative time parsingm154k12023-08-061-0/+11
| | | | | | | | | | Currently relative time parsing is buggy when any of the non-leading units are non zero. For example, "-1:30" should result in -90 but currently it results in -30 (as a result of `-60 + 30`). Also reject timestamps where non-leading units are out of range. E.g. "1:100" would be rejected, but "100" will still be accepted as 100 seconds.
* options: rename variables in parse_timestringm154k12023-08-061-9/+10
|
* various: fix typosHarri Nieminen2023-03-281-3/+3
| | | | Found by codespell
* Partially revert "options: remove OPT_FLAG"Christoph Heinrich2023-02-271-0/+63
| | | | | | | | | | | The m_option_type_flag is still needed for the CONF_TYPE_FLAG (next commit). Add a comment that m_option_type_flag shouldn't be used. ref. #11373 This partially reverts commit 07545657bf73ebb4da38e26950d5203466298ec1.
* options: remove OPT_FLAGChristoph Heinrich2023-02-211-62/+0
|
* options/m_option: support duplicating MPV_FORMAT_BYTE_ARRAY nodesrcombs2023-01-281-0/+10
|
* various: replace abort() with MP_ASSERT_UNREACHABLE() where appropriatesfan52023-01-121-1/+1
| | | | | | | | In debug mode the macro causes an assertion failure. In release mode it works differently and tells the compiler that it can assume the codepath will never execute. For this reason I was conversative in replacing it, e.g. in mpv-internal code that exhausts all valid values of an enum or when a condition is clear from directly preceding code.
* options: const annotate all m_opt_choice_alternatives accessorsEmil Velikov2021-11-151-14/+15
| | | | | | | Constant data, most accessors are good but some were missing the explicit notation. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* options: const annotate m_obj_list accessorsEmil Velikov2021-11-151-1/+1
| | | | | | | Nearly all the code base correctly references the data as constant. But a couple of instances - fix those. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* options: remove always true m_obj_list::allow_unknown_entriesEmil Velikov2021-11-151-3/+1
| | | | | | | Ever instance of m_obj_list is a constant and for all of them, the field is true. Just remove the field all together. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* options: add missing dash in msg-level help messageEmil Velikov2021-10-031-1/+1
| | | | | | | | Currently using mpv --msg-level=help, shows an instance of --msglevel (missing dash). Seems like the help message was only partially updated with the -msglevel -> --msg-level transition. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* options: add watch-later-optionsGuido Cella2021-07-211-1/+1
| | | | | | | | | | This allows configuring which options are saved by quit-watch-later. Fixes #4126, #4641 and #5567. Toggling a video or audio filter twice would treat the option as changed because the backup value is NULL, and the current value of vf/af is a list with one empty item, so obj_settings_list_equal had to be changed.
* options: Make validation and help possible for all option typesPhilip Langdale2021-03-281-7/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Today, validation is only possible for string type options. But there's no particular reason why it needs to be restricted in this way, and there are potential uses, to allow other options to be validated without forcing the option to have to reimplement parsing from scratch. The first part, simply making the validation function an explicit field instead of overloading priv is simple enough. But if we only do that, then the validation function still needs to deal with the raw pre-parsed string. Instead, we want to allow the value to be parsed before it is validated. That in turn leads to us having validator functions that should be type aware. Unfortunately, that means we need to keep the explicit macro like OPT_STRING_VALIDATE() as a way to enforce the correct typing of the function. Otherwise, we'd have to have the validator take a void * and hope the implementation can cast it correctly. For help, we don't have this problem, as help doesn't look at the value. Then, we turn validators that are really help generators into explicit help functions and where a validator is help + validation, we split them into two parts. I have, however, left functions that need to query information for both help and validation as single functions to avoid code duplication. In this change, I have not added an other OPT_FOO_VALIDATE() macros as they are not needed, but I will add some in a separate change to illustrate the pattern.
* 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 bridge<