Historically, we have not attempted to support hw->hw format conversion
in the autoconvert logic. If a user needed to do these kinds of
conversions, they needed to manually insert the hw format's conversion
filter manually (eg: scale_vaapi).
This was usually fine because the general rule is that any format
supported by the hardware can be used as well as any other. ie: You
would only need to do conversion if you have a specific goal in mind.
However, we now have two situations where we can find ourselves with a
hardware format being produced by a decoder that cannot be accepted by
a VO via hwdec-interop:
* dmabuf-wayland can only accept formats that the Wayland compositor
accepts. In the case of GNOME, it can only accept a handful of RGB
formats.
* When decoding via VAAPI on Intel hardware, some of the more unusual
video encodings (4:2:2, 10bit 4:4:4) lead to packed frame formats
which gpu-next cannot handle, causing rendering to fail.
In both these cases (at least when using VAAPI with dmabuf-wayland), if
we could detect the failure case and insert a `scale_vaapi` filter, we
could get successful output automatically. For `hwdec=drm`, there is
currently no conversion filter, so dmabuf-wayland is still out of luck
there.
The basic approach to implementing this is to detect the case where we
are evaluating a hardware format where the VO can accept the hardware
format itself, but may not accept the underlying sw format. In the
current code, we bypass autoconvert as soon as we see the hardware
format is compatible.
My first observation was that we actually have logic in autoconvert to
detect when the input sw format is not in the list of allowed sw
formats passed into the autoconverter. Unfortunately, we never populate
this list, and the way you would expect to do that is vo-query-format
returning sw format information, which it does not. We could define an
extended vo-query-format-2, but we'd still need to implement the
probing logic to fill it in.
On the other hand, we already have the probing logic in the hwupload
filter - and most recently I used that logic to implement conversion
on upload. So if we could leverage that, we could both detect when
hw->hw conversion is required, and pick the best target format.
This exercise is then primarily one of detecting when we are in this
case and letting that code run in a useful way. The hwupload filter is
a bit awkward to work with today, and so I refactored a bunch of the
set up code to actually make it more encapsulated. Now, instead of the
caller instantiating it and then triggering the probe, we probe on
creation and instantiate the correct underlying filter (hwupload vs
conversion) automatically.
--audio-file-auto, --cover-art-auto, and --sub-auto all work by using an
internally hardcoded list that determine what file extensions get
recognized. This is fine and people periodically update it, but we can
actually expose this as a stringlist option instead. This way users can
add or remove any file extension for any type. For the most part, this
is pretty pretty easy and involves making sub_exts, etc. the defaults
for the new options (--audio-file-auto-exts, --cover-art-auto-exts, and
--sub-auto-exts). There's actually one slight complication however. The
input code uses mp_might_be_subtitle_file which guesses if the file drag
and dropped file is a subtitle. The input ctx has no access to mpctx so
we have to be clever here.
For this, the trick is to recognize that we can leverage the
m_option_change_callback. We add a new flag, UPDATE_SUB_EXTS, which
fires when the player starts up. Then in the callback, we can set the
value of sub_exts in external_files to opts->sub_auto_exts. Whenever the
option updates, the callback is fired again and sub_exts updates. That
way mp_might_be_subtitle_file can just operate off of this global
variable instead of trying to mess with the core mpv state directly.
Fixes#12000.
We should account for ao queue when setting playback position on EOF,
previously we were using the pts value corresponding to the start of
the ao queue, rather than the currently playing audio.
This fixes time-remaining being a negative number when mpv seeks to EOF
while playback is paused.
So far all the keypad keys except for `0` and `,` mapped to the same
MP_KEY_* independent of numlock state, even though different key codes
are received.
Now all the alternative functions map to appropriate MP_KEY_* defines,
with missing ones added.
There's some cdecl / stdcall linking nonsense breaking the build
which I'm not inclined to debug this Sunday at all.
32-bit is not important anyway, so just disable it there.
On the plus side the new functional structure makes this very painless.
If someone wants to use the CI artifacts for day-to-day usage
or even for certain tests it can be useful to take screenshots
and use e.g. DShow (--disable-devices option), so enable those.
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.
