281b1d8999 introduced a stack use after
scope because dest_fbo can be reassigned a new pointer and then be used
by pass_draw_to_screen outside of that scope where the pointer is no
longer valid. Fix this by rearranging the variables so the assignment is
done in the same scope as the pass_draw_to_screen call instead.
The info provided for libva might be useful. Specifically on Windows it
seems to not use the error callback for what should be logged as error.
[ 0.080][v][vaapi] libva: VA-API version 1.20.0
[ 0.080][v][vaapi] libva: Trying to open <path>/vaon12_drv_video.dll
[ 0.080][v][vaapi] libva: va_openDriver() returns -1
[ 0.080][e][vaapi] Failed to initialize VAAPI: unknown libva error
As we can see only the "unknown" error is printed to the error callback
and important information is printed on the info callback. Print it to
verbose log to make it easier to find.
the title is updated on the main thread (mandatory with cocoa)
asynchronously, because otherwise it would either deadlock when done
synchronously, lead to undefined behaviour or just crashes. the problem
here is that the c string was only copied to an NSString within that
asynchronous call, which potentially would access the pointer when it
is accessed, modified or freed by another thread. it is only safe to
access this pointer as long as the control callback wasn't returned yet.
to fix this we move the copying and creation of the String from the
c string pointer outside of the asynchronous call where the conversion
of an untyped pointer to a typed pointer is done too. since the
resulting String is a copy it's safe to be used in the asynchronous
call.
also reverting ee6ad40, since the problem was most likely an SDK problem
or the very same problem as mentioned here. i retested the crash case
again und can't reproduce it anymore. using a swift String again instead
of an NSSstring.
Fixes#12935
- Don't define _GNU_SOURCE on Windows, no need
- Define WIN32_LEAN_AND_MEAN to strip some unneded headers from
windows.h
- Define NOMINMAX and _USE_MATH_DEFINES as they are common for Windows
headers
We prefer to fail fast rather than degrade in unpredictable ways.
The example in sub/ is particularly egregious because the code just
skips the work it's meant to do when an allocation fails.
This mostly is added to resolve player command synchronization with VO
thread discussed in 477a0f83.
The current uses does not necessarily need this as they are all managed
by playloop. But for future use with other params that will be handy.
Those params are mostly to observe current state of VO and does not
necessarly need to be locked along with frame drawing, that changes the
params once at the end.
Only vaapi-copy variant as nothing can map D3D12 resources currently.
And even if we would add resource sharing to D3D11 it would invoke copy
at some point, so there is no point really. Maybe in the future when
libplacebo get smarter about resource sharing on Windows, but practical
advantages are really small. I've tested it with Vulkan <-> D3D11
sharing and GPU <-> GPU copy is still invoked. Better than CPU memcpy,
something for the future.
Up to 2x playback rate is the most we can offer currently. Should work
fine for most kernels with radius <= 2.
This avoids limitation of hwdecs number of frames in-flight.
Fixes: #12927
there is 1px border at the top of the window that is not covered by our
title bar and the video below is visible. this broke in some newer macOS
version even so the calculation of size and position of the title bar is
still correct. add 1px the the height of the title bar to cover up the
unwanted border.
These are less likely to be modified from run to run, and with the
avoidance of redundant re-saving we can get away with a larger size.
This is enough to save 10 3DLUTs at typical sizes.
I have no idea why this code is such a convoluted mess of options and
possibilities. First of all, why is dumping both caches to a single file
even a supported use case? Why is the cache path generated multiple
times, once for saving and once for loading, instead of just generated
once and stored? Why even create a pl_cache if you're not going to
save/load it? Why so much code duplication?
I don't know. But I rewrote it in a way that makes far more sense to me.
This change prevents unwanted adjustments. Generally, screenshots
shouldn't invoke pl_queue_update, as this action could cull the already
mapped frames in the queue.
If !display_synced, some values may not be correct or zeroed. Therefore,
it makes no sense to interpolate in this case.
For a non-moving frame, we always want to show an uninterpolated frame.
libplacebo requires additional frames when VPS is lower than FPS and
anti-aliasing is enabled. Supports up to a 1/4 ratio. VO has a limit of
10 frames, so in practice, not many more can fit.
Note that the internal libplacebo mixing limit is 16 frames.
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.
