The `current_frame` can be redrawn even if the remaining `num_vsync` is
equal to 0. In this scenario, the vsync offset would be incremented
beyond the target point.
It turns out that mpv will rewrite the entire cache file on every single
quit. It's not so great since after viewing a ton of files, your cache
can grow to massive sizes and slow down quitting the player to a
noticeable amount. Turn down the max size of both caches to 10 MiB for
now as a workaround until this gets improved later.
This filters out vastly inaccurate values from presentation feedback
that can happen shortly after restarting playback or seeking.
Makes estimated vsync converge almost instantly instead of waiting
until those outliers are dropped from the past samples.
In commit de6d57f0 libplacebo enabled drift compensation by default.
mpv already tracks error and adjust the speed by itself.
This commit fixes judder visible when slowing video a lot, ex. playing
back at 10% speed.
Set ideal vsync duration also when dropping frames, libplacebo estimate
currently own values anyway, will be useful later...
See: de6d57f021
The commit subject sounds reasonable except that frame redraws get
spammed in certain cases (still image with subtitles) all the time
regardless if the subtitle actually has changed or not. So this is
stupid and wasteful, but you'll always see subtitles. vo_gpu currently
has this behavior as well, so we're just matching it but later mpv's
core should be fixed so this works reasonably. Fixes#11335.
Fixes gpu-next completely ignoring any speed adjustment, either DS or
playback.
Frames in pl_queue have raw PTS values, so when querying them we have to
use the same time base. There was misunderstanding between mpv and
libplacebo, where the former was querying the frames based on display
vblank timeline, but this cannot work if the playback speed is adjusted
and display timeline is not aligned with video timelien. In which case
we have to schedule "video vsync" points that we want to display.
Previous code was working only when playback speed was 1.0x, but since
DS almost always changes the speed the interpolation was mostly not
timied correctly.
Relative to frame PTS timeline as oposed to display vblank.
Those values are relative to unadjusted video timeline. They will be
used by gpu-next where it expect virtual frame vsync, not display vblank
time.
Originally suggested by @haasn. Instead of awkwardly using a pts from
the previous render loop, we can just peek into pl_queue and use the pts
of the first frame instead. This eliminates a lot of weird artifacts
that can happen on discontinuities like seeking. Fixes#12355.
Several related things in regards to interpolation. Essentially this
adds more general sanity checking to bring it more in line with what
vo_gpu does.
- Add a can_interpolate bool which determines whether or not this frame
is allowed to interpolate.
- p->is_interpolated was sometimes lying and because you can have a mix
frames greater than 1 depending on the video and settings. Make sure
that vsync_offset is not 0 so we know if it's actually interpolated or
not. This prevents a redundant redraw for those edge cases when
pausing.
- When the vo wants a reset, i.e. some sort of discontinuity, don't try
to interpolate the frame. Interpolation is only valid for
monotonically increasing times.
This fixes#11519 because of the additional check to make sure that we
have more than 1 frame. The PTS clamping part is still not great. That
is for the next commit.
In the past, this worked by accident because the initial startup was
racy and sometimes the initial firing of handle_toplevel_config would
happen after reconfig. Since we now properly wait on all compositor
events we can save the initial size hint that is given to us and try to
use that as the window-size/geometry provided the --autofit/geometry
options aren't explictly set. Fixes#11134.
the OpenGL cocoa backend was deprecated in 0.29, it has lot of bugs, is
completely unmaintained and can't properly playback anything anymore on
the newest macOS. it is time to remove it.
the old displayName property via the IODisplay API is not working
anymore on ARM based macs and was broken in at least one other case.
instead we use the new localizedName property introduced in 10.15 of the
NSScreen. we don't need any backwards compatibility since 10.15 is the
oldest version we support now.
configs and scripts that use the options and properties fs-screen-name,
screen-name or display-names need to be adjusted since the names could
differ from the previous implementation via the IODisplay API.
Fixes#9697
this is apparently something that was added with swift 5.5, though it is
hard to find anything officially.
don't capture self in closure but explicitly access all variables by
prepending self.
Fixes#12653
Fixes a899e14b which changed clamp from 0 to 1 ms which effectivelly
introduced 1ms sleep always, even if requested until_time_ns is in the
past and should request 0 timeout.
While at it also fix mp_poll wrapper to respect negative timeout which
should mean infinite wait.
Also keep the 37d6604 behaviour for very short timeouts, but round only
the ones > 100us, anything else is 0.
Fixes: a899e14b
Most importantly, the wait_until addition was missed while doing the
unit conversions to nanoseconds which meant mpv woke up roughly every
second since not nearly enough time was added. It was meant to be 1000
seconds (1e9 in microseconds). Use a macro so it's more readable. Also
put some other wild 1e9 calculations inside of a macro as well.
Fixes a899e14bcc.
These have been build options since the waf build, but that doesn't
really make sense. The build can detect whatever macOS sdk version is
available and then use that information to determine whether to enable
the features or not. Potentially disabling multiple sdk versions doesn't
really make any sense. Because f5ca11e12b
effectively made macOS 10.15 the minimum supported version, we can drop
all of these checks and bump the required sdk version to 10.15. The rest
of the build simplifies from there.
Currently VOCTRL are completely unusable for frequent data query. Since
the HDR parameter addition to video-params, the parameters can change
each frame. In which case observe on those parameter would be triggered
constantly. The problem is that quering those parameters involves VOCTRL
which in turn involves whole render cycle of delay.
Instead update VO params on each draw_frame. This requires changes to VO
reconfiguration condition, but in practice it should only be triggered
when image size or data layout changes. In other cases it will be
handled internal by VO driver.
I'm not quite happy with this solution, but don't see better one without
changing observe/notify logic significantly. There is no good way
currently to handle VOCTRL that are constantly queried.
This adds unfortunate synchronization of player command with VO thread,
but there is not way around that and if too frequent queries of this
param becomes a problem we can thing of other solutions.
Changes the way to get data from VO driver added by a98c5328dc
Fixes: 84de84bFixes: #12825
windowrc in vo_w32_state is actually client size, for hit test we need
proper window size. When border is disabled those sizes are the same,
but when only title bar is disabled it is not.
Reduce the hit area to more sane values when the border is not
drawn to minimize amount of covered client area in borderless mode.
This was specifically special logic for drm. Before present_sync, it
would also clear out all of its vsync values like this. The old drm code
would save a bunch of samples which would confuse vo.c when unpausing
since it got old, bogus values. Since we make sure to match successive
vsync samples with the swapchain depth and that present sync samples
also match the swapchain depth, this is unneeded.
There's some geometry-related things that mpv has to calculate before
the window is actually mapped onto the screen in wayland. But there's no
way to know which output the window will end up on before it happens, so
it's possible to calculate it using the wrong values. mpv corrects
itself later when the surface event happens, but making the initial
guess work better can help in certain cases.
find_output is the only thing that needs to be changed here. Its main
purpose is to grab the right output based on user settings when we're
trying to full screen and giving a fallback in case we don't have
wl->current_output yet. The x11 code already does something similar, so
we're basically just copying it. Allow user settings like --screen and
--screen-name to influence the initial wl_output guess. Those options
won't actually place the window on that specific screen since we can't
do that in wayland, but if the user knows where the window will end up
beforehand it makes sense to listen to the arguments they pass. If
something goes wrong, then we just fallback to 0 like before.
A ton of code and drm-specific abstractions can be dropped with this.
One important thing to note is that the usage of sbc is completely
dropped here. The utility of that is not particularly clear since the
sbc value was manually incremented before the flip and it's not as if
the drm page flip event gives it to us like it does with the msec and
ust. It can be reintroduced later if there is a need. For drm, we also
add a present_sync_clear_values helper since all presentation feedback
needs to be cleared on pause/resume for it.
When this was originally written, the queuing/list approach was
deliberately removed since it adds more complication and xorg/wayland
don't really use it anyway. In practice, you only really have one frame
in flight with presentation timestamps. However, one slight annoyance is
that the drm code has its own thing which is almost exactly the same and
does its own calculations. Ideally, we'd port drm to this instead, but
the implementation there takes into account N-frames in flight which
probably does actually work. So we need to make present_sync smarter and
be able to handle this.
mpv does actually have its own linked list implementation already which
is a good fit for this. mp_present becomes the list and each
mp_present_entry has its own set of timestamps. During initialization,
we create all the entries we need and then simply treat it like a queue
during the lifecycle of the VO. When an entry is fully used
(present_sync_get_info), then we remove it from the list, zero it out,
and append it to the end for future use. This avoids needing to allocate
memory on every frame (which is what drm currently does) and allows for
a reasonable number of in flight frames at the same time as this should
never grow to some obscene number. The nice thing is that current users
of present_sync don't need to change anything besides the initialization
step.
This commit replaces all uses of sig_peak and maps all HDR metadata.
Form notable changes mixed usage of maxCLL and max_luma is resolved and
not always max_luma is used which makes vo_gpu and vo_gpu_next behave
the same way.
This change essentially removes mp_thread_self() and instead add
mp_thread_id to track threads and have ability to query current thread
id during runtime.
This will be useful for upcoming win32 implementation, where accessing
thread handle is different than on pthreads. Greatly reduces complexity.
Otherweis locked map of tid <-> handle is required which is completely
unnecessary for all mpv use-cases.
Note that this is the mp_thread_id, not to confuse with system tid. For
example on threads-posix implementation it is simply pthread_t.
The old one would actually crash if the libplacebo.cache file was
invalid. Additionally, set a max size of 1 GiB for icc cache and 50 MiB
for gpu shader cache. The per object size limit is removed which puts
mpv in line with plplay. Finally, a few memory leaks are also fixed
since several objects previously were not freed on uninit.
