| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Fixes #9325
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a result of the work I did the explicitly check for formats
supported by the vo in the f_autoconvert logic, I introduced a
regression in the handling of the rpi4_8 and rpi4_10 formats. These
require special handling because they only exist in the rpi forks and
not upstream ffmpeg, which means they don't have stable pix fmt values
that we can use directly.
Previously, we simply didn't declare them as supported, which was ok,
as nothing was really enforcing the list of supported formats, but that
has changed.
As we still can't simply use the pix fmts, I had to do a slightly
ridiculous dance to look them up by name, and if they exist, then
register them as supported.
Good times.
|
|
|
|
|
| |
57367377505b6b2edc87004fa3192d831d515aa5 mistakenly changed the mode
from 644 to 755. Change it back.
|
| |
|
|
|
|
| |
returns the NSWindow
|
| |
|
|
|
|
|
|
|
| |
The dragging hack can cause unwanted aero shake activation.
Prevent this by saving the window arrangement state before dragging,
temporarily disable it while dragging hack is active, and restore to
the original state after dragging ends.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The mouse down handler checks w32->current_fs to determine whether
to begin the dragging hack. Unfortunately, the w32->current_fs value
is stale, because the input is handled asynchronously, and we cannot
wait for an up-to-date value if dragging needs to be kept resonsive.
As a result, when the fullscreen state changes after the dragging
model loop is entered, the opposite value is used, so the window stays
draggable after entering fullscreen, and becomes undraggable after
exiting fullscreen.
With the resonsiveness and model loop constraints, the up-to-date
state must be queried inside WM_MOVING messages which are sent while
dragging. The message handler now checks if the dragging hack is active
while the window is in fullscreen, and overrides the new window position
with the current one, in effect prevents the window from being moved.
The old check is also removed, so the window is now draggable after
exiting fullscreen while dragging hack is active.
|
|
|
|
|
|
|
|
|
|
|
| |
Compose key doesn't function in X11 because XFilterEvent() isn't called,
and XNInputStyle is set to a wrong value. This results in KeyPress events
for the separate keyboard inputs in the compose key input sequence
instead of the composed character, making it impossible to input certain
characters which require compose key.
Fix this by calling the required XFilterEvent() and set XNInputStyle
to the correct value.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to MS documentation, an application should return TRUE from
WM_XBUTTONUP and WM_XBUTTONDOWN if it processes these messages.
DefWindowProc generates the WM_APPCOMMAND message when it processes the
WM_XBUTTONUP message, so if an application properly handles WM_XBUTTONUP
messages, extra WM_APPCOMMAND messages won't be generated.
Because mpv doesn't properly handle these messages,
WM_XBUTTONUP causes APPCOMMAND_BROWSER_BACKWARD to be generated, resulting
in duplicated keys and improper fix 438ead7a, which prevents the processing
of the appcommand from sources other than mouse clicks.
Fix this by following the documentation, and the back and forward
appcommands can be added.
|
|
|
|
|
|
|
|
|
| |
XF86Back and XF86Forward are mostly used to navigate file and web browsers
to go back/forward in history. XF86Forward isn't recognized right now,
so add it.
Because XF86AudioForward already takes the "FORWARD" name, rename the
browse keys to GO_BACK and GO_FORWARD instead.
|
|
|
|
|
| |
Also change the example to crf=23. crf=32 is pretty bad quality, don't
give users bad usage ideas.
|
|
|
|
|
|
|
| |
Fixes chroma location for screenshots.
Also set the crop to full frame to not trip mp_image_params_equal check
if not necessary.
|
|
|
|
| |
It is useful information, not only for debugging.
|
|
|
|
| |
--screenshot-avif-pixfmt no longer defaults to yuv420p.
|
|
|
|
|
|
| |
modifier keys weren't reported when using the trackpad to scroll.
Fixes #11195
|
|
|
|
|
|
|
|
|
|
|
|
| |
in the case the window was already set to a maximized size via geometry
or related options (100%x100%) the maximize function would try to
maximize the window again. this reset the position and slightly
increased the size further.
to prevent this only maximize on init if we really want to maximize. in
the reverse case make a noop call by passing the current zoom state.
Fixes #11193
|
|
|
|
|
|
|
|
| |
281b1d89994e3e3a9950d32fc451dff990c2320d 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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
- read directly to bstr
- use talloc for OOM checks
- don't parent temporary allocation
- don't check for NULL buffer after already writting to it
|
|
|
|
| |
No longer needed after 079f67268f6f5a2ecfd12277b246b1937493c092.
|
| |
|
| |
|
|
|
|
| |
Make it easier on compiler, no need to alloca and copy things around.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
ctx->destroy_native_ctx is guarded, but this early exit was not.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Useful for logging
|
|
|
|
| |
To be able to reuse them in other parts of code.
|
|
|
|
| |
There is nothing d3d11 about those adapters.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
left wheel and right wheel was swapped. this was copied from the old
cocoa backend. a delta <0 is a right scroll, >0 is a left scroll.
Fixes #12899
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Backwards compatibility wrapper can be bumped once sufficient libplacebo
version is a minimum dependency.
See-Also: https://github.com/mpv-player/mpv/pull/12902
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
talloc_free is safe to call with NULL.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This is mainly for debugging purposes, as it should't happen in normal
use. If it does, it needs fixing.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
It is valid to disable interpolation on resets and when the vsync error
exceeds the duration of the frames that we have available.
|
|
|
|
|
| |
We can possibly have all the frames needed for interpolation, even after
a reset, so there's no need to prevent that.
|
|
|
|
|
| |
On reset, we would ignore all the frames that were seen before. This is
incorrect and would drop valid frames that should be rendered.
|
|
|
|
|
|
| |
This information is already there, but speed adjusted. To avoid
duplicating the calculation of frame duration, it's kept in the
vo_frame structure.
|
|
|
|
|
|
| |
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 only registers 1 mouse wheel event per 10 physical mouse wheel clicks.
|
|
|
|
|
| |
Otherwise you can get "error: comparison between pointer and integer"
while compiling in some cases.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
If multiple instances of mpv are closed at the same time, they will
write to the same temporary file. Fix that by using unique temporary
file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: https://code.videolan.org/videolan/libplacebo/-/commit/de6d57f021e2336851f51b1a8538aa1484c56607
|
|
|
|
|
|
|
|
|
| |
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.
|