This older image has been deprecated and will be removed in December.
The images have also already had planned outages during which the CI
flow has been affected. Thus it feels like a good idea to clean
this up at this point.
Ref: actions/runner-images#5583
It turns out, even xy-VSFilter and XySubFilter do not
mangle colours if the video is native RGB regardless of
the sub's YCbCr header. libass' docs were also updated
to reflect this.
Deduplicate history like the fish shell. So for example
entering "cmd 1" then "cmd 2" then "cmd 3" then "cmd 1"
would result in a history of
[cmd 2][cmd 3][cmd 1]
instead of
[cmd 1][cmd 2][cmd 3][cmd 1]
Adds a function `history_add` to replace directly adding to history.
Adds an option `history_dedup` to activate the deduplication.
Defaults to on.
This was only needed because the mingw CI used to run on Ubuntu 20.04
which had a version of meson too old for mpv. This hasn't been the case
since we switched to 22.04 in f7164fcfac
and can now just use the package manager version.
Only matters when configuring ytdl_hook with `all_formats=yes`.
So far the tracks were ordered from worst to best quality.
Web players with quality selection always show the highest quality
option at the top. Since tracks are usually listed with the first
track at the top, that should also be the highest quality one.
yt-dlp/youtube-dl sorts it's formats from worst to best.
Iterate in reverse to get best track first.
This patch adds support for two extra WAVEFORMATEXTENSIBLE GUID tags
that can appear inside RIFF headers. It also adds support for extra
codec IDs that may appear as their own unique wSubFormats inside RIFF
headers, such as ATRAC9 inside matroska, as one example.
Fixes#10757.
I was confused in d3a28f12c9 why it
actually even worked, but after not being stupid, it's quite obviously
just a dangling pointer. The reason it only happens with
wp_presentation_feedback is because the object and listener actually
created in frame_callback not the presentation events itself (for vsync
timing reasons). So it is possible to free the object, but not
immediately recreate it again before quitting (unlike with the frame
callback). The actual comment is moved into feedback_presented (which is
first) but as of this commit it doesn't have the NULL setting logic
(that's the next one).
964692ad4c added some code to destroy
presentation_feedback we get in the presentation_discarded event. This
is the correct thing to do since the compositor could send us this
instead of feedback_presented. Without that change, mutter could
potentially leak memory on every frame.
Unfortunately, life is not so simple and wlroots and weston act
differently. These compositors only send one presentation_discarded
event if the mpv window is hidden. Not on every single missed frame like
mutter. Now in theory this shouldn't matter, but it also turns out that
mpv attempts to free the presentation feedback twice if you quit it
while it is hidden away (on weston and wlroots compositors only). The
inital wp_presentation_feedback_destroy in feedback_discarded fires, but
then the function goes off again in vo_wayland_uninit because
wl->feedback is apparently not NULL for some reason. Possibly, this is
some race condition but we can't just get rid of what's in
feedback_discarded since mutter needs this line. Instead, just hack it
by explicitly setting wl->feedback to NULL in feedback_discarded after we
destroy the presentation feedback. Some valgrind testing in mutter,
sway, and weston shows that this works correctly on all of those
compositors with various combinations of mpv being visible or not while
quitting. feedback_presented doesn't appear to exhibit this behavior so
we just leave that as-is.
666cb91cf1 added dmabuf_feedback, but it
was never actually free'd on uninit. Because this function requires
wayland protocols 1.24, we have to wrap it in an #if. Also throw in some
minor cosmetic changes in here.
This mapping isn't actually relevant until we have the Vulkan interop
merged, and it requires a newer version of libavutil than our minimum
requirement. So I'm going to remove it from master and put it in the
interop PR.
Fixes#10813
666cb91cf1 added support for v4 of the
dmabuf protocol. This was meant to be optional and the fallback support
for the old v2 (dates back to 2017[0] well before the 1.15
wayland-protocol version we depend on) was maintained. However, v4 added
several new functions and structs that of course aren't defined in old
protocol versions so naturally this breaks the build on those systems.
Since this is just a niche feature and not really critical to overall
wayland support in mpv, just give in and add another check in the build
system and #if out the newer stuff in wayland_common. v4 of linux-dmabuf
depends on wayland protocols 1-24[1], so go ahead and make that our new
check. Fixes#10807.
[0]: a840b3634a
[1]: 8a5cd28a0e
mpv has a CONFIGURATION define which is defined at configure time in
both build systems and printed out when you use verbose flags. In waf,
this is line is exactly what the user passes on cli at configure time.
In meson, there's currently no way to do that (someone did recently open
up a PR that would make this possible), so we just hardcode the prefix
and call it a day. This is a bit of a tangent, but the build also
copies waf and sets an optimize variable (true or false) that is also
printed out on verbose output. For waf, this makes some sense because
the build has a specific --optimize option (internally all it does is
pass -O2). In meson, optimizing is a built-in option and we just set
anything that's not -O0 as "optimize". Furthermore, there is a new
optimization option added in meson 0.64 called "plain" which passes no
flags at all* so this logic would need to be updated to account for
this.
In retrospect, this is all just stupid though. optimization is not a
boolean value and there's no real use for treating it like one just
because that's what waf does. Let's remove it from the features array.
Instead, we can expose this information in the CONFIGURATION variable
along with the prefix option so we know exactly what optimization was
used in the compiled executable. For good measure, let's also throw in
buildtype since it's related.
*: a590cfde0c
Meson's master branch helpfully prints out a warning here now saying
that "find_library('libdl') starting in "lib" only works by accident
and is not portable". We'll go ahead and trust them and instead change
this to dl which works with no issues.
The old "meson build" build command was actually deprecated a few months
ago*. It turns out that you're supposed to use "meson setup build"
instead which has been around for years. Go ahead and be a good citizen
and update this in the CI. Also replace any mention of "meson build"
with "meson setup build" in the documentation as well and change the one
random hardcoded string we have in meson.build to "meson configure
build" (might as well).
*: 3c7ab542c0
Console already respected the bottom margin to not overlap with the
bottom bar from the OSC, but it would still overlap with the window
decorations from the OSC.
Now everything is clipped above the top margin and no superfluous lines
are drawn.
vo_dmabuf_wayland has its own ra and context so it can handle all the
different hwdec correctly. Unfortunately, this API was pretty clearly
designed with vo_gpu/vo_gpu_next in mind and has a lot of concepts that
don't make sense for vo_dmabuf_wayland. We still want to bolt on a
ra_ctx, but instead let's rework the ra_ctx logic a little bit. First,
this introduces a hidden bool within the ra_ctx_fns that is used to hide
the wldmabuf context from users as an option (unlike the other usual
contexts). We also want to make sure that hidden contexts wouldn't be
autoprobed in the usual ra_ctx_create, so we be sure to skip those in
that function. Additionally, let's create a new ra_ctx_create_by_name
function which does exactly what says. It specifically selects a context
based on a passed string. This function has no probing or option logic
is simplified just for what vo_dmabuf_wayland needs. The api/context
validations functions are modified just a little bit to make sure hidden
contexts are skipped and the documentation is updated to remove this
entries. Fixes#10793.
vo_gpu and vo_gpu_next typically load hwdec interops on demand and
vo_dmabuf_wayland naively copied this logic. This is actually wrong
however since draw_frame in the VO always inherently relies on hwdec
being fully loaded. This can lead to a race condition during startup
which happens with --force-window=immediate. Avoid this by simply always
loading all the interops. In the case of vo_dmabuf_wayland, this is not
really a big deal since there's only vaapi and drmprime to load. Also
fixes#10791 (the other half).
We really need two roundtrips in the init function. The first one is for
running the registry and then second one is for ensuring the xdg_surface
and other potential wayland objects are configured at least once before
mpv does anything. We've been getting away with only doing the first for
a while via luck, but really we should do at least one more wait on the
compositor. Fixes#10791 (half of it).
Despite being run in a VM, the workflow actually copies the files back
to the host. We can then explictly print the error logs on failure in
their own separate section for visibility instead of it being hidden
within all the vm output.
Building on DRM platform without VAAPI broke because of misuse of
HAVE_VAAPI with #ifdef in place of #if. Also, the hwcontext_drm.h
header is not required for VAAPI builds, only DRM builds.
Originally, I considered warning once to be useful for figuring
out whether the change in logic regarding resetting requested
mode actually fixed the reported issue or not, but alas not everyone
was happy with that decision. Thus the log level will always be
debug. This enables us to lose one level of indent as well as a
variable, which is always positive.
Additionally, make the message more explicit regarding what could
possibly be implied by the mismatch, as it seems like this was
not always clear.
Otherwise mpv and the compositor can end up in an eternal loop where
mpv requests one mode, and compositor tells that the mode is not
that (and will most likely not change).
Additionally, log these mismatches - first time as a warning, and
later as debug logging.
It is verbose, but makes it more explicit that requested_decoration
takes in three values:
* 0: no specific mode requested by mpv
* ZXDG_TOPLEVEL_DECORATION_V1_MODE_CLIENT_SIDE: (!border)
* ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE: (border)
Pulled from https://github.com/mpv-player/mpv/pull/10382
The zwp_linux_dmabuf_v1 protocol version 4 provides a file descriptor
containing both formats and modifiers, which makes it possible for the
compositor to import the buffers onto planes using explicit modifiers.
This is an extremely important efficiency improvement, as the 3D
hardware can be left powered off altogether, the vaapi buffer being sent
directly from the video hardware to the display controller.
It could be possible to support zwp_linux_dmabuf_v1 version 3 as well,
but there is no reason beyond compatibility with old stacks. I would
recommend to ditch version 2 as well, as modifier-less formats aren’t
very useful nowadays.
Wayland VO that can display images from either vaapi or drm hwdec
The PR adds the following changes:
1. a context_wldmabuf context with no gl dependencies
2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects
no-op because there is no need to map/unmap the drmprime buffer,
and there is no need to manage any textures.
Tested on both x86_64 and rk3399 AArch64
dmabuf-wayland vo supports both DRMPRIME and VAAPI formats.
If upload filter is needed, we want to try VAAPI hwdec first
since most users will be using VAAPI, and there is a several second
delay when DRMPRIME hwdec is tried and fails.
Pushing E (aka Shift+e) cycles through Editions for containers
that support editions, such as Matroska, although this feature was not
documented before this commit.
The AO is feature-complete now.
As PipeWire also provides compatibility with PulseAudio, ALSA and Jack
we should put it before those for the autodetection to work.
The pure presence of PipeWire does not mean that it is actually driving
the audio session. For example it could only be meant for video.
Currently there is no proper API to detect this (see [0]), so we check
for the presence of audio sinks.
As soon as a proper API exists, we should use that.
[0] https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1835
Jan Ekström
Oneric
Dudemanguy
Christoph Heinrich
Niklas Haas
sfan5
Leo Izen
Lynne
Philip Langdale
rcombs
Natural-Harmonia-Gropius
Dave Craig
Thomas Weißschuh
Emmanuel Gil Peyrot
Aaron Boxer
dyphire
Cœur