| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
It's possible for systems to have multiple cards, and the first capable
card to not have a connected output. Skip such cards and continue
iterating until we find one with a connected output.
|
|
|
|
|
|
|
| |
Without doing this, --fs --fs-screen=1 wouldn't actually end up on the
desired screen since the sizehint was never sent. Also check the
screen-name variants for an empty string as well so the option can
properly "undo" itself (not sure if this has any practical effect).
|
|
|
|
|
|
|
|
|
|
|
| |
mpv mixes xinerama and randr usage together which gets kind of
confusing and is also pretty stupid. Xinerama is completely unneccesary
today since randr can do everything it can do and much more. Remove it.
This reworks a lot of the window/geometry handling stuff to be centered
completely around xrandr_display plus some other tweaks to the geometry
handling. An important concept is that current_icc_screen is changed
into current_screen and used more generously since it is useful for
things besides just icc profiles.
|
|
|
|
|
|
| |
There really is no reason to not just hard require randr 1.4. xorg added
1.4 support in 2012 and someone somehow using an xorg server older than
that today surely has several other problems.
|
|
|
|
|
|
|
| |
If we failed to create a gbm surface, we would call drm_egl_uninit
to free up any state we had allocated. However, we would segfault if we
tried to cleanup properties there were never initialized. Null checks
have been added to guard against this.
|
|
|
|
|
|
|
|
| |
Before d208284, this was implicitly reset back to 0 at the start of
every update_options(). But we no longer explicitly reset par->params,
so we need to do it manually here for the hooks.
Fixes: https://github.com/mpv-player/mpv/issues/12203
|
|
|
|
|
|
|
| |
Undefined behavior (bad initializer). Somehow didn't trigger a warning
on my end...
Fixes: a8192eda6cfc909fc9f5f62e36523b53c0300eff
|
|
|
|
| |
To help test not-yet-exposed options, and for debugging purposes.
|
|
|
|
| |
This is already set by map_scaler, just disable it if unwanted.
|
|
|
|
| |
No need to override this so late in the general (non-screenshot) code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With a backwards compatibility shim for older versions of libplacebo in
which we simply define the relevant subset of this struct ourselves and
initialize it to known-good values, to be able to continue using our
options assigning code.
It's worth pointing out that our use of scalers deviates from how
pl_options was intended to be used, as a consequence of backwards
compatibility with pre-308 versions of libplacebo. But this should work
fine in practice, since we don't care about serializing these custom
scalers correctly. Users can still override them using the built-in
pl_options scalers when loading custom scalers via --libplacebo-options.
(To be added in the next commit)
|
|
|
|
|
|
| |
This was already correctly freed when acquiring a new profile, but never
freed on uninit. Fix by reparenting the profile onto `p`, which is what
vo_gpu also does.
|
|
|
|
|
| |
This header is installed unconditionally starting with libplacebo
v4.208.0, so we are safe to remove the check.
|
|
|
|
|
| |
Instead copy the data on-demand when VOCTRL_PERFORMANCE_DATA is
requested.
|
| |
|
| |
|
|
|
|
| |
v6.292 implied by minimum dependency.
|
|
|
|
| |
Now implied by the minimum libplacebo version.
|
|
|
|
| |
LIBPLACEBO_NEXT is now implied by libplacebo being available
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This completely disables all smoothing. Despite what the manual claims,
a decay rate of 1.0 does *not*.
It's worth pointing out that this depends on the following commit to
work properly in --vo=gpu-next, but I don't think working around such a
minor detail is worth the trouble, considering people building nightly
mpv are probably also building nightly libplacebo it should just work
(tm).
See-Also: https://github.com/haasn/libplacebo/commit/1c464baaf4c6228dcfac87f19db1dafc22e328c8
See-Also: https://github.com/haasn/libplacebo/commit/83af2d4ebd5086a56f7b1a2f86628ada3612ee7c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libplacebo doesn't like it when the queue_params PTS is less than the
actual PTS of the frame for the first frame and skips mixing it during
interpolation. This can happen if you seek while paused because mpv will
always keep the vsync_offset value as if it was still playing. So in
some cases, this can be a negative value and thus the PTS will end up
decreasing and libplacebo interprets this frame as a first frame. This
skips mixing the frame and thus you get a black screen. To fix this
this, just realize that vsync timings are completely meaninglessly in
while paused. If you are not actively pushing frames, there's no reason
to care about vsync_offset. So just clear it and make it zero when the
VO's internal state is paused and we're trying to render a frame. Makes
libplacebo happy and fixes #11958.
|
|
|
|
|
|
|
| |
It was actually always wrong, and no one ever noticed. This currently
returns the size of the entire display area and not one actual monitor.
Fix this by calling get_monitor_info and then doing the appropriate
subtractions. Checked by @CrendKing and fixes #12172.
|
|
|
|
|
|
|
|
| |
There was no known problem with this, but according to the wayland
spec*, "After this event client must assume that no keys are
pressed...", so go ahead and do that.
*: https://gitlab.freedesktop.org/wayland/wayland/-/blob/72da004b3eed19a94265d564f1fa59276ceb4340/protocol/wayland.xml#L2449
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduced by 1f8013ff3fddd788a517656e09f5ce5d7efd928d. We try to save
the mpkey so it can be used in the modifier event that comes next if
appropriate and also clear it when needed. The problem is that the
condition for clearing is too strict and things like mismatched cases
and so on can make mpkey on the corresponding key release event not
match the saved mpkey even though in reality they were the same key.
Loosen the check by simply always clearing the saved mpkey as long as
there was some key found and the state is up. We don't handle multiple
keys at the same time anyways (they're interpreted in a sequence), so it
should be hopefully OK.
|
|
|
|
|
|
|
|
|
| |
During initialization, the mpv window was not available and wayland
simply just reported nothing. But this can be a nuisance and there are
cases where having a values is better than nothing (vapoursynth). So if
current->output isn't available yet, fallback to find_output instead.
This is influenced by what is set by options like --screen and
--screen-name, but we'll consider that a feature not a bug.
|
|
|
|
|
|
|
|
|
|
| |
This deliberately wasn't being done when mpv was embedded
(fbccddb48b4c71c18300b092ef7a3860be2a659a). There are some applications
that would benefit from mpv setting a title since they don't do so
themselves (such as tabbed), but at the same time some others would
probably rather not have this behavior (like smplayer). Add an option
that allows an embedded mpv to set the title if the user wishes.
Fixes #11528.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mpv has a generic method for getting the display resolution, so we can
save it in vf_vapoursynth without too much trouble. Unfortunately, the
resolution won't actually be available in many cases (like my own)
because the windowing backend doesn't actually know it yet. It looks
like at least windows always returns the default monitor (maybe we
should do something similar for x11 and wayland), so there's at least
some value. Of course, this still has a bunch of pitfalls like not being
able to cope with multi monitor setups at all but so does display_fps.
As an aside, the vapoursynth API this uses apparently requires R26 (an
ancient version anyway), so bump the build to compensate for this.
Fixes #11510
|
|
|
|
| |
similar to free(), XFree() is a no-op if argument is NULL
|
|
|
|
|
|
|
|
| |
XDestroyWindow() is called immediately after, which also unmaps window
if needed. according to the manpage:
> If the window specified by the w argument is mapped, it is unmapped
> automatically.
|
|
|
|
|
|
|
|
|
|
|
| |
983e8f0100b98bd8aed48e5fe86dd5682174b04e resulted in the correct
dimensions, but it was not actually right because vo_gpu_next still had
the src and dst rects the same. This just needs to work like how vo_gpu
does where the src is the image params and the dst is desired output. So
basically, just copy that code over here. Fixes #12108 and as a bonus,
overriding the aspect ratio now results in correct screenshots
(previously didn't work at now and then with the above commit it had
correct dimensions but still incorrect output).
|
|
|
|
|
|
| |
Using the width and height params directly doesn't actually work if PAR
is something other than 1. Instead, use mp_image_params_get_dsize and
calculate the correct dimensions which matches the vo_gpu behavior.
|
|
|
|
| |
Closes: https://github.com/mpv-player/mpv/issues/12093
|
|
|
|
|
|
|
|
|
|
|
| |
ffmpeg does not tag yuv levels for GRAY formats, but apparently they
should be infered as full range. Instead of defaulting to limited range
always. Fixes (M)JPEG playback.
This mimic ffmpeg's behaviour.
See: https://github.com/FFmpeg/FFmpeg/blob/d295b6b6936c9c691a4871851fdaec04d407e54b/libswscale/utils.c#L926-L962
Fixes: #12089
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1 is not enough to prevent PL_QUEUE_MORE, because the pl_queue is
designed to always know the next frame (in addition to the current).
Before haasn/libplacebo@112bb886, this was was (wrongly) silently
omitted by the pl_queue code, but that fix exposed this.
While it's technically API misuse on mpv side, due to the mpv vo code
having its own internal queueing and timing control, it shouldn't
actually make any difference in practice (and likely, the error message
showing up is the only meaningful bug here - the issue is entirely
cosmetic).
Fixes: https://github.com/mpv-player/mpv/issues/12101
|
|
|
|
|
|
|
|
|
|
| |
Configuration of filter parameters was moved from pl_filter_function (of
which the user had to make a copy) to pl_filter_config, with the
pl_filter_function remaining immutable.
Implement this new logic in a way that can reasonably exist side-by-side
with the old configuration API. Once we drop support for PL_API_VER
below 303, we can drastically simplify this code.
|
|
|
|
|
|
|
| |
The win32 code already updates itself on dpi changes. However, it never
signalled mpv's core when this happened which meant that the
display-hidpi-scale property never changed. Simply send the
VO_EVENT_DPI event when appropriate. Fixes #12081.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the same way that fallback in receive_frame() needs to be repeated
until we get a working decoder, we have to do the same thing in
reinit(). Calling force_fallback() only once can still yield a non
functional decoder.
The reason why we have these multiple paths which each require their
own fallback logic is that we can fail at different stages:
* hwdec init
* decoder init <- repeated fallback was missing here
* frame decoding
Fixes #12084
|
|
|
|
|
|
|
|
|
| |
The manual currently says that if dscale is unset, --scale will be
applied. However, this only works at init time. If you change the dscale
filter to be empty later, vo_gpu will segfault and vo_gpu_next will
throw an error and refuse the changes. That's because when the option is
unset at runtime, the value becomes "" not NULL and the vo's never
accounted for this. Fixes #12031.
|
| |
|
| |
|
|
|
|
|
| |
Debian 12 is out, with 2.4.114, and Ubuntu 22.04 has 2.4.110, this
#ifdef is no longer needed
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This only existed as essentially a workaround for meson's behavior and
to maintain compatibility with the waf build. Since waf put everything
in a generated subdirectory, we had to put make a subdirectory called
"generated" in the source for meson so stuff could go to the right
place. Well now we don't need to do that anymore. Move the meson.build
files around so they go in the appropriate place in the subdirectory of
the source tree and change the paths of the headers accordingly. A
couple of important things to note.
1. mpv.com now gets made in build/player/mpv.com (necessary because of
a meson limitation)
2. The macos icon generation path is shortened to
TOOLS/osxbundle/icon.icns.inc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is yet another unfortunate side effect of the width % SLICE_W == 0
special case. While looping through these rectangles, the rc->x1 value
on the final loop can be greater than the actual total width. This will
cause a buffer overflow if using the mp_draw_sub_overlay API. 2 of the
current VOs that use that work around it by adjusting the values
returned, but the better fix is to correct what's actually given in the
rectangles so you can safely use the values. As for the fix, it's simply
ensuring that rc->x1 doesn't extend beyond p->w with a MPCLAMP.
Previously, the code would always naively add SLICE_W (256) to rc->x0
which would easily extend past the actual width in many cases. The
adjustments in vo_vaapi and vo_dmabuf_wayland are dropped and in theory
vo_direct3d should work now since we can just trust the values given to
us in the rectangles. How nice.
|
|
|
|
|
|
|
| |
This code failed to handle the case of the swapchain submission being
skipped because the window was invisible.
Fixes: f9dc695b580c394bf4f9833d36e91b7fcbe009ea
|
|
|
|
| |
Presents frames at the correct time when DS is disabled.
|
|
|
|
|
|
| |
reproduction steps: take any lossy WebP screenshot and check the colors
(or JPEG without libjpeg support, or AVIF with tag-colorspace=no)
fixes: 6d9e72cd89652aaf73fa5a8256c439221e86b94a
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We make the assumption that there is more buffer available
than indicated, this needs to be considered in this specific
location too as mp_image_crop understandably checks whether
we're about to do something unsafe.
minimal reproducer: mpv av://lavfi:testsrc -vf crop=320:239,format=yuv420p -o test.png
fixes #10469
|
|
|
|
|
|
|
|
|
| |
In 1f8013ff3fddd788a517656e09f5ce5d7efd928d, I mistakenly thought this
was only used for modifier presses way back in the commit it was
introduced in, but it actually also handles non-english keys/letters.
Instead of returning early, we should try xkb_keysym_to_utf8 first and
then return if that doesn't do anything so the modifier can then be
handled in the appropriate event. Fixes #12009.
|
|
|
|
|
|
| |
This has always been a pet peeve of mine and in fact I named the option
in meson "egl-wayland" with the intention of finally doing this. We call
everything that's egl "egl-foo" internally except for wayland.
|
|
|
|
|
|
|
|
| |
We wanted to preserve the libplacebo v5.264.0 requirement for gpu_next
for this release, since this is the what most Linux distributions are shipping.
The VLC 3 <-> libplacebo v6 situation is an additional reason distros are not
likely to ship the newest libplacebo release soon.
This reverts commit b73d96776cfee61f88bf60b27315baab32a2115d.
|
|
|
|
|
|
|
|
|
| |
Since this works by mpctx giving us a dummy image, we can be reasonably
be confident that when we receive a matching imgfmt with no underlying
hw_subfmt that this is simply force window from the player. Just allow
this to go through the usual wayland logic and skip the hwdec checking.
When we get the real image later, it will still error out on the
compositors that don't have proper support.
|
|
|
|
|
|
|
|
|
|
|
| |
It's a bit of an edge case, but since we now allow the disabling of the
software fallback it's possible to have a situation where hwdec
completely fails and the mpv window is still lingering from the previous
item in the playlist. What needs to happen is simply that the vo_chain
should uninit itself and handle force_window if needed. In order to do
that, a new VDCTRL is added that checks vd_lavc if force_eof was set.
player/video will then start the uninit process if needed after getting
this.
|
|
|
|
|
|
|
|
|
|
| |
There's an option that's supposed to stop mpv from falling back to
software decoding if hardware decoding fails. Except that it doesn't
work and can fallback to software decoding anyway. Correct this by
checking if all possible hwdec failed after the loop in
select_and_set_hwdec and that we have this option. If so, flag a bool to
force eof. In decode_frame afterwards, we then simply immediately return
an EOF.
|
|
|
| |
Commit e50db42 changed how hwdec interop works. Adjust vo_vaapi accordingly by setting the appropriate image format.
|
|
|
|
|
|
| |
When video width is not a multiple of slice size, the last slice will overflow. Fix this by adjusting the width of the last slice to fit within the video.
Fixes issue #10436
|
|
|
|
|
| |
With the generic screenshot window implemented, this is no longer
needed since vo_drm already uses software scaling.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In sum there were three issues:
1. nominal_peak_luminance is an output parameter, not input
2. mpv internally uses MP_REF_WHITE which we need to scale by
3. the value should be left at its default for SDR
Together with the last change this means mpv can sucessfully
take HDR screenshots with --screenshot-sw without resulting
in a brightly colored mess. Though note that zimg does not
perform proper tonemapping.
|
|
|
|
|
|
|
| |
This ensures the sRGB fallback to happen in all situations involving
the image writer code, notably --screenshot-sw.
fixes: cbbe2e52210d9885a0897e9c7833267a60456c56
|
|
|
|
|