Elements are not parented to the add list, as they are directly copied
to the target list. Therefore, we need to clean them up manually.
Fixes: 1f5a67d8fa
c4e8c36071 made any usage of --geometry
implicitly center the window on the screen after a resize even if the
user did not pass any x/y arguments to the option. At the time, this was
probably wanted since --geometry was primarily a startup option and
likely the window wouldn't be centered on x11 without moving
coordinates. Times have changed since then and we support full runtime
--geometry changes on all the relevant platforms but it comes with this
automatic window centering behavior (except on wayland of course hah).
It's better to make such window centering optional and user controllable
since it is entirely reasonable that someone wants --geometry=50% to
just resize and not move anything. It's already trivial for a person
that does want to move the window to just add their coordinates to the
--geometry command so there's no reason to continue to force this
behavior since it is less flexible.
Instead, move the window centering stuff out of m_geometry_apply into
vo_calc_window_geometry. We give the power to the caller to whether or
not to force centering the window here and all usage of the function is
updated to simply call it with false for now. Additionally,
--force-window-position being set will also center the window like
before. All that is left is for the windowing code to take advantage of
this. See subsequent commits.
It makes sense to allow the first part of the list. There are
warnings about excessive elements already. This also allows overriding
elements with the same label.
Limit list entries to 100. obj_settings_list is not designed to hold
more items, and it quickly starts taking ages to add all items. 100 is
more than enough.
Fixes 30s timeout on OSS-Fuzz and generally fixes possible DoS on mpv.
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.
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.
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.
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.
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.
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.
5f74ed5828 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.
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.
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.
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.
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.
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.
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.
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 07545657bf.
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.
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>
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>
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>
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.
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.
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 a3d561f950. 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)
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.
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 9d32d62b61
for how this can go wrong).
With this, m_option.min/max are strictly used for numeric limits.
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.
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
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.
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.
