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.
This was wrongly assuming that playlist_path is always set for the
current playlist entry, but it's only set when a file was added by
expanding a playlist.
The crash in playlist_get_first_in_next_playlist can be reproduced with
mpv foo.mkv foo.zip, playlist-next, playlist-prev,
playlist-next-playlist. You need to run playlist-next, playlist-prev
first because foo.zip's playlist_path is NULL until you do that, which
makes playlist_get_first_in_next_playlist return immediately.
The crash in cmd_playlist_next_prev_playlist can be replicated with mpv
--loop-playlist foo.zip foo.mkv, running playlist-next until foo.mkv,
and playlist-play-next. Again, you need to open foo.zip first or its
playlist_path is NULL which skips running strcmp(entry->playlist_path,
mpctx->playlist->current->playlist_path).
Fixes https://github.com/mpv-player/mpv/issues/12495#issuecomment-1760968608
there are currently some silly data-races in the stop/cont sighandler
due to the fact that the signal handler might get invoked in a different
thread.
this changes those sighandlers to a pipe-based approach similar to the
existing "quit" sighandler.
tio_orig and tio_orig_set are being touched inside of signal handler
which might be invoked from another thread - which makes this a data
race.
there's no real reason to set tio_orig inside of do_activate_getch2()
which is registered as a signal handler. just set it once, in
terminal_init(), before any signal handlers come in play.
this also allows removing the tio_orig_set variable completely.
do_deactivate_getch2() touches some global variables which *might have*
been fine if the terminal thread was the one that received the signal
but AFAIK which thread will handle the signal is not well defined.
in my case, when quitting mpv with CTRL+C the main thread receives the
signal rather than the terminal thread and touches those globals without
synchronization. caught by ThreadSanitizer.
the solution is to move the do_deactivate_getch2() call outside of the
signal handler.
Use EDL for single tracks with metadata to set the uploader, channel url
and description metadata with --ytdl-format=best. Currently, these are
only set with the other ytdl formats with video and audio in different
streams.
The uploader tag is commonly available in sites other than Youtube too,
so it may be simpler to always use EDL with single tracks.
Added to the functions `mp.add_timeout` and `mp.add_periodic_timer`.
If the `disabled` argument is set to `true` or a truthy value, the
timer will wait to be manually started with a call to its `resume()`
method.
Only vpdau-copy works with EGL. 2d1d815cc7 already added this to
manpage, and 1c8d2246bf removed it again, but that seems to be a mistake
because I can only get vdpau to work with GLX, and another user also
reported that only vdpau-copy was working for him with the default EGL.
Several window resizing operations (i.e., --auto-window-resize,
border dragging with --keep-aspect-window, Alt+0/1/2) cause the
window to detach from the snapped borders. This patch resolves
this by recording to which borders the window is snapped, and
using this info to determine how the window should be placed after
resizing.
Closes https://github.com/mpv-player/mpv/issues/6588
Allows higher resolution sleeps than Sleep which has milliseconds
resolution. In practice Windows kernel does not really go below 0.5ms,
but we don't have to limit ourselves on API side of things and do the
best we can.
Linux and macOS already use nanosecond resolution for their sleep
functions. It was just being converted from microseconds before. Since
we have mp_time_ns now, go ahead and bump the precision here. The timer
for windows uses some timeBeginPeriod thing which I'm not sure what it
does really but whatever just convert the units to ms like they were
doing before. There's really no reason to keep the mp_sleep_us helper
around. A multiplication by 1000 is trivial and underlying OS clocks
have nanosecond precision.
9606c3fca9 added mp_time_ns(). Since we
apparently expose the mp_time_us() to clients already, there's no reason
to not also expose the new nanosecond one.
On linux, several platforms poll for events over a fd. This has ms
accuracy, but mpv's timer is in ns now so lots of precision is lost. We
can use an mp_poll wrapper to use ppoll instead which takes a timespec
directly with nanosecond precision. On systems without ppoll this falls
back to old poll behavior. On wayland, we don't actually use this
because ppoll completely messes up the event loop for some unknown
reason.
Originally, this was added as purely a shim for macOS. However since we
want to do high resolution polling which is not neccesarily available on
all platforms, making this a generic wrapper for poll functions is
useful so rename it.
In many cases, this is purely cosmetic because poll still only accepts
microseconds. There's still a gain here however since
pthread_cond_timedwait can take a realtime ts now.
Additionally, 37d6604d70 changed the value
added to timeout_ms in X11 and Wayland to ensure that it would never be
0 and rounded up. This was both incomplete, several other parts of the
player have this same problem like drm, and not really needed. Instead
the MPCLAMP is just adjusted to have a min of 1.
Dudemanguy
llyyr
Christoph Heinrich
der richter
Kacper Michajłow
Guido Cella
NRK
Mike Will
sunpenghao