1fa6669bc0 misinterpreted the example and
changed the pixel value from 128 to 168 (thinking that it meant pixels
after scaling), but likely the original calculation was correct because
the line specifically says "of the source video". This is just confusing
not really useful information so instead change the example to a more
common resolution (1920x1080) and remove any references to the source
video resolution. Also mention video-pan-y while we're at it.
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
The idea behind period_size is that it's the minimum amount of data
that your audio subsystem wants to fetch.
For PulseAudio, this is given by the minreq buffer attribute, which
is in bytes for all channels. Hence the divisions.
This change sets the device_buffer member of the ao struct for
the JACK ao to whatever value we read during init.
While JACK allows changing the audio buffer size on-the-fly
(you can do this for example through DBus), having it somehow
reconfigure the entire audio buffer logic of mpv that depends
on device_buffer in some way when that happens only leads to
audio dropout and weird code. device_buffer's role is mostly for
prebuffer from what I understand, which means that simply setting
it to its current value in the init function is fine.
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
In addition to the patch, appropriate additions to the mpv.conf file
will of course be needed for this to work. For example on my system:
audio-device=oss//dev/dsp4
audio-spdif=ac3,dts,dts-hd,eac3,truehd
This has been tested using recent FreeBSD-13.1-stable, using external
surround processors (both a Trinnov Altitude 16 and an LG OLED that
supports Dolby Atmos, and connected with HDMI to an NVidia RTX 2070).
Author and tester: David G Lawrence <dg1007@dglawrence.com>
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
It turns out this already exists for sd_ass and is being used there. We
can make use of this arbitrary threshold instead for overlapping
subtitle durations to avoid the weird flashing behavior with some
pgs subtitles.
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)
Under the current file loading logic, a video file and an external
audio track next to it will both be added to the playlist, which
most users don't wish to happen. Having an option that tells the
script to load only one type of files (video, audio, or image)
can avoid this problem. It may also come in handy for people who
have different types of files mixed in a folder but wish to consume
only one type of media at a time.
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
There are a number of ways one can craft a playlist file that refers to
itself or cleverly goes around in a loop to other playlist files. There
is obviously no use for this, but mpv spins around forever trying to
load the files so you have to just SIGTERM/SIGKILL it. We can be smarter
about this and attempt to detect it. The condition for detecting this is
surprisingly simple: the filename of the first entry in the playlist
must match a previous playlist path we stored. If we get this, we can
then log an error and stop playback. If there is a "real" file loaded at
any point in time, then we know it's not an infinite loop and clear out
the saved playlist paths. Fixes#3967.
sfan5
Niklas Haas
Dudemanguy
Kacper Michajłow
Zenos
Nicolas F
Jan Ekström
mwalmer
rim
llyyr
Philip Langdale
Arthur Williams
Christoph Heinrich
sunpenghao