It makes it more usable to virtually move dst rect instead of scaled
src.
The issue with the latter is that it is affected by video-zoom
paramters. For example if we do `--video-pan-x=-0.5` in normal case it
will move video -50%, but if we apply video-zoom/scale the video will
float towards the middle in unintuitive way. Extreme case is when one do
--video-zoom-x=0.01, now it is impossible to move video unless you
specify huge video-pan-x value, but it is limited to [-3, 3]. So you
cannot do anything.
With this changes regardless of video scale/zoom, video-pan will keep
center of scaled video in one place.
It doesn't make sense to have zero here and it breaks, logic below.
Width was still campled to 1, but with broken offset.
This fixes things like video-scale-x=0
- uninit gl before the VO
- destroy EGL surface before context: reverse of the creation order.
I also checked other code which doesn't even call this and leaves
it up to eglTerminate, which frees everything anyway. But this
seems more correct since we're destroying the gbm surface afterwards.
- check against at EGL_NO_DISPLAY instead of 0: there is probably no
EGL implementation where this makes a difference, it is more correct
regardless
- remove pointless eglDestroyContext call
- check render_fd before close
mpv was taking focus when being started with "--window-minimized=yes". This change stops mpv from taking focus when this option is used.
Resolves: #9641
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
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 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: 1c464baaf4
See-Also: 83af2d4ebd
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.
*: 72da004b3e/protocol/wayland.xml (L2449)
Introduced by 1f8013ff3f. 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
(fbccddb48b). 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
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.
983e8f0100 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.
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: d295b6b693/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.
