| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 a899e14bccb667af243f8fce454160e17ae45c2a.
|
|
|
|
|
| |
we stopped supporting macOS older than 10.15 and hence can remove all
the unnecessary runtime checks and compatibility layers.
|
|
|
|
|
|
|
|
|
|
|
| |
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 f5ca11e12bc55d14bd6895b619c4abfd470c6452
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: 84de84b
Fixes: #12825
|
|
|
|
| |
Fixes: https://github.com/mpv-player/mpv/issues/12777
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
To make sure that present_sync is in line with the vsync timings here.
|
|
|
|
|
|
| |
Saving more than the swapchain depth is just wasteful. We can just save
a copy of the vo_opts here and check the value whenever we're updating
values.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This had to have been a mistake. It was just confusing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 reverts commit 640c07fb19b7ea11f1a97784e517c38449f816d0.
This commit isn't needed anymore after the previous commit.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Note this commit does not change all uses of sig-peak, this is for
future refactoring.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This was deprecated in api version 322 which earlier than the current
6.338 version that mpv depends on. So remove it.
|
|
|
|
|
| |
Since the minimum required libplacebo version is 6.338, all of these
checks are unneeded.
|
|
|
|
|
|
| |
Fixes rotating image by --video-rotate when filtering.
Fixes: #12771
|
|
|
|
|
| |
Add more refresh rates for get_refresh_rate_from_gdi() now (Nov 2023) that
165 Hz is common, 240 Hz is on the rise, and 120 * N Hz is the future.
|
|
|
|
| |
In case new default parameters are added later.
|
|
|
|
|
|
|
|
| |
Vapoursynth does not provide crop metadata and input one is likely to be
invalidated during filtering. Set crop to full frame if image dimensions
were changed during filtering.
Fixes: #12780
|
| |
|
|
|
|
|
|
|
|
| |
I'd like some names to be more descriptive, but to work with 15 chars
limit we have to make some sacrifice.
Also because of the limit, remove the `mpv/` prefix and prioritize
actuall thread name.
|
|
|
|
|
|
|
|
|
|
|
| |
ffmpeg is again setting the frame dimensions to the coded size, so we
need to reintroduce our work-around to get the logical frame dimensions
from the frames_ctx rather than the frame itself.
ffmpeg commit:
* https://github.com/FFmpeg/FFmpeg/commit/9ee4f47c94083b4fe38d4e217a7d65055d3ad53f
This reverts commit c40bd888729212f698156b57e49391d3b51f8f07.
|
| |
|
|
|
|
|
|
| |
Other similar options are in the form of --foo-override not
--override-foo. The display-fps one was backwards so flip it around the
other way for consistency reasons.
|
|
|
|
|
|
| |
Peak detection greatly increases HDR experience. Performance hit of
non-delayed detection is not that significant and is in line with
current default settings.
|
|
|
|
|
|
|
| |
Make it not possible to build mpv without the latest libplacebo anymore.
This will allow for less code duplication between mpv and libplacebo,
and in the future also let us delete legacy ifdefs and track libplacebo
better.
|
|
|
|
| |
Also sanitize vsync values, just in case.
|
| |
|
|
|
|
| |
Improves averaging on high refresh rate displays.
|
| |
|
|
|
|
| |
these are defined in osdep/endian.h already
|
|
|
|
| |
the variable `w` is unused as a whole.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
since i was going to fix the include order of stdatomic, might as well
sort the surrouding includes in accordance with the project's coding
style.
some headers can sometime require specific include order. standard
library headers usually don't. but mpv might "hack into" the standard
headers (e.g pthreads) so that complicates things a bit more.
hopefully nothing breaks. if it does, the style guide is to blame.
|
|
|
|
|
|
|
|
|
|
|
| |
the fallback needed it due to the struct wrapper. but the fallback is
now removed so it's no longer needed.
as for standard atomics, it was never really needed either, was useless
and then made obsolete in C17 and removed in C23.
ref: https://gustedt.wordpress.com/2018/08/06/c17-obsoletes-atomic_var_init/
ref: https://en.cppreference.com/w/c/atomic/ATOMIC_VAR_INIT
|
|
|
|
|
|
|
| |
replace it with <stdatomic.h> and replace the mp_atomic_* typedefs with
explicit _Atomic qualified types.
also add missing config.h includes on some files.
|
|
|
|
| |
So it is not lost after filtering.
|
|
|
|
|
| |
May increase performance, especially when using DR with a dedicated
transfer queue.
|
|
|
|
| |
Fixes: https://github.com/mpv-player/mpv/issues/12672
|
|
|
|
| |
Needed for odd formats like rgb24.
|
| |
|
| |
|
|
|
|
|
| |
Both buffers have the same size (32) and if the source is not null
terminated it should be fixed there. Copy whole buffer.
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Since the previous commit unbreaks the timeout, this now actually works.
Imagine that.
|
|
|
|
|
|
| |
Added in 58a7d81dc55835fb0f5cc6a3f14288d722f83c91. Nobody touched it
since then, so it's probably useless. libplacebo has its own dithering
stuff anyways.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Fixes type mismatch after recent changes.
Fixes: 59dd7d94af7651baf7e60966c5f8e7d52959d958
|
|
|
|
|
| |
While the video playing, it's not actually needed and can cause
unnecessary redraws. Fixes #12623.
|
|
|
|
| |
same rationale as last commit
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|