Some users report visible black frames during window resize, this should
not happen in most cases. Let's just keep stale content as it is less
distracting. While still clearing on first window paint to avoid white
background.
Fixes: #12642
This is more stable in practice. Avoids switching between possibly
different hwdecs and avoids unnecessary init. Software decoding should be
more stable and possibly faster overall for decoding this small portion
of video needed for cropdetect.
Use mp_tags_move_from_av_dictionary() in place of
mp_tags_copy_from_av_dictionary().
This ensures that when lavf appends metadata
that occurs later in the stream,
it starts from empty each time.
Fixes: <https://github.com/mpv-player/mpv/issues/12559>
Abstracts a common pattern,
in which the av dictionary is cleared
immediately after copying to mp tags,
so that additional tags later in the stream
get appended to empty tags,
instead of being appended to existing tags
that were already copied.
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.
Some ffmpeg hwcontexts do not implement frame constraints. That means
they cannot report which formats are support for given configurations.
My previous changes to make hwupload more capable relies on the
constraints to be provided to accurately describe what combinations are
supported, so we will currently see a bunch of errors failing to
configure the hwupload filter on platforms such as v4l2 SoCs with
drmprime. This doesn't break playback, but it's confusing.
To bridge the gap, this change uses the static format metadata that we
include for hwdecs to build a fake constraints struct to keep all the
other code working.
Homebrew has finally given up supporting macOS 11, and all updated
dependencies are being built locally. Additionally, python3.12 - being
a dependency of libass in Homebrew - seems to completely fail under
cairo's meson usage on macOS 11, even if we let it build.
Thus, finally remove macOS 11 from our macOS build matrix, leaving
12 and 13.
ref: Homebrew/brew#16019
With the previous series of commits, all internal usage has been
replaced by the nanosecond functions. There's not really any point in
keeping these around anymore plus there are macros for unit conversions
now so we can just axe them. It's worth noting that mpv_get_time_us()
obviously still needs to work for API reasons, but we can just divide
mp_time_ns() by 1000 to get the same thing.
Pull AOs work off of a callback that relies on mpv's internal timer. So
like with the related video changes, convert all of these to nanoseconds
instead. In many cases, the underlying audio API does actually provide
nanosecond resolution as well.
There's a lot of wild 1e6, 1000, etc. lying around in the code. A macro
is much easier to read and understand at a glance. Add some helpers for
this. We don't need to convert everything now but there's some simple
things that can be done so they are included in this commit.
The whole mess with setting the option value explictly and saving the
old stop_play value only needs to happen if we're at the end of file.
Doing it in general is unneccessary and breaks other things.
Fixes#12424.
These are ancient and have existed since before stats.lua lived in the
mpv repository. We don't need to worry about ancient mpv versions
anymore, so remove these.
Why a bigger search-interval is required:
scaletempo2 doesn't do a good job when the signal contains frequencies
less then 1/search_interval. With a search interval of 30ms that means
anything below 33.333Hz sounds bad.
Depending on the genre it's very for music to contain frequencies down
to 30Hz, and sometimes even a little bit below that. Therefore a higher
default value is needed to handle such cases.
Based on that an argument can be made for a value of 50, as that should
work down to 20Hz, or something even higher because movies sometimes
have some infrasonic content.
However the downside of big search intervals is increased CPU usage and
intelligibility at higher speeds, as it effectively leads to parts of
the audio being skipped.
A value of 40 can handle frequencies down to 25Hz, enough for all music
except very rare edge cases, while still providing decent
intelligibility.
Why a smaller window-size is required:
Large values reduce intelligibility at high speeds and therefore small
values are preferred.
However when values get too small it starts to sound weird
(similar to librubberband).
In my testing a value of 10 already works well, but adding a small
safety margin seems like a good idea, especially since it made no
noticeable difference to intelligibility, which is why 12 was chosen.
The text didn't line up with with the percentages above it because it
didn't use a monospace font.
Instead insert the text at the same position in the template as the
percentages and convert one o.prefix_sep from the percentages into hard
coded \h\h to ensure alignment even when the user changes o.prefix_sep.
add support for vulkan through metal and a translation layer like
MoltenVK. also add the possibility to use different render timing modes
for testing.
i still consider this experimental atm.
add an animation lock to the window to prevent the window from closing
while animating. if this is done while the fs animation is running the
dock will stay hidden. this is not used yet, because it's unnecessary
for cocoa-cb but will be for new vo backends.
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.
- rename prefix to `Framerate:`
- if both estimated and specified values are the same display fps once
- skip the suffix if both the estimated and specified values agrees
Source video parameters are interesting, but we mix them with video
output/target parameters. Which will differ. Add "Display" showing
true output params from VO, including HDR passthrough info and
everything. This makes much more consistent output and alows to quickly
diagnose how is source video translated to target display.
Not both of them. Formating it as `<name> (<desc>)` produced arguably
silly string like `hevc (HEVC (High Efficiency Video Coding))`. Unpack
this to show only description if available or name otherwise. Produces
way nicer results in stats.lua and similar places where this name is
printed.
Kacper Michajłow
Claude Heiland-Allen
Dudemanguy
Guido Cella
Philip Langdale
Jan Ekström
llyyr
Christoph Heinrich
der richter