See the previous commit for the full explanation. Basically, luajit 2.0
has a bad pc file on macos that causes libmpv to fail during build. The
workaround was, if the os was darwin and luajit was found, to save a
full luajit dep and a partial luajit dep with the link args removed. The
partial dep was used for compiling libmpv, and the full dep was used for
the actual mpv executable. This worked and was needed for the CI to pass
but it sucked. Since the previous commit now makes the CI grab lua 5.1,
we don't need all this crap anymore. Just delete it and treat the
dependency normally.
This does effectively mean that building libmpv with luajit 2.0 on macOS
will no longer work with the meson build. However libraries not being
built correctly is not a mpv-specific issue. The waf build will succeed
for some reason, but it has known issues and it would be better if it
just failed honestly. An upstream developer said years ago that that
macOS users should use the 2.1 branch (and there's no release of
course). In any case, no macOS user should be building mpv with luajit
2.0, so we shouldn't be going out of our way to support this.
https://github.com/mpv-player/mpv/issues/7512https://github.com/LuaJIT/LuaJIT/issues/521#issuecomment-562999247
LuaJIT is still actively developed, but upstream is allergic to making
new releases for whatever reason. The last tagged release was in May of
2017, so we probably shouldn't expect a new release anytime soon. Now
for mpv, this doesn't really matter except in the case of macOS where
2.0.5 is actually a bit broken (and of course the CI uses luajit). More
specifically, the 2.0.5 pc is broken and has a "-pagezero_size 10000"
flag which causes libmpv to fail (only executables are allowed to use
this). This magically works on waf. It's possible that it just happens
to ignore the link arguments. However on the meson build, this is broken
and led to a really ugly hack using a partial dependency so both mpv and
libmpv succeed. Fortunately, the 2.1 luajit branch fixes this.
Unfortunately, there's no actual release.
Instead, just use Lua 5.1. Note that lua 5.1 is technically deprecated
in homebrew, but the chances of this going away is pretty slim since
everyone knows that new lua versions are not backwards compatible.
Anyways, using 5.1 works fine and lets us get rid of a terrible hack in
the meson build. People really shouldn't be using 2.0 LuaJIT anyway.
We have a few examples with vf=rotate=90, but libavfilter's rotate
accepts radians - not degrees, so a value of 90 is valid but misleading
because it's not 90 degrees.
Change the value of 90 at those examples.
Also replace "vf-add=hflip" with "vf add hflip", since that example
lists commands, not options, to run.
Drag and drop in wayland is weird and it seems everyone does this
slightly differently (fun). In the past, there was a crash that
occured (fixed by 700f4ef5fa) which
involved using the wl_data_offer_finish in an incorrect way that
triggered a protocol error (always fatal). The fix involved moving the
function call to data_device_handle_drop which seemingly works, but it
has an unfortunate side effect. It appears like GTK applications (or at
least firefox) close the pipe after this function is called which makes
it impossible for mpv to read data from the fd (well you could force it
open again in theory but let's not do that). Who knows if that was the
case when that commit was made (probably not because I'd think I would
have noticed; could just be a dummy though), but obviously having broken
dnd for a major application isn't so fun (this works with QT and
chromium anyway).
Ideally one would just simply check the pipe in data_device_handle_drop,
but this doesn't work because it doesn't seem the compositor actually
sends mpv the data by then. There's not actually a defined event when
you're supposed to be able to read data from this pipe, so we wait for
the usual event checking loop later for this. In that case,
wl_data_offer_finish needs to go back into check_dnd_fd, but we have to
be careful when calling it otherwise we'd just commit protocol errors
like before. We check to make sure we even have a valid wl->dnd_offer
before trying to indicate that it is finished and additionally make sure
there is a valid dnd_action (after checking the fd, it's always set back
to -1).
This doesn't fix everything though. Specifically, sway with
focus_follows_mouse (the default) and GTK as the data source still
doesn't work. The reason is that when you do a drag and drop in sway
with that option on, a new wl_data_device.data_offer event is sent out
instantly after the drop event. This happens before any data is sent
across the fd and before mpv even has a chance to check it. What GTK
does, when getting this new data_offer event, is close the pipe
(POLLHUP). This means mpv can't read it when we reach the event loop and
thus no data is ever read and broken drag and drop. From the client
side, this isn't really fixable since the wayland protocol doesn't have
a clear indication of when clients are supposed to read from the fd and
both the compositor and data source are doing things totally out of our
control. So we'll consider this weird case, "not our bug" at least. The
rest should work.
By receiving the graphics API-specific contexts from the generic
pl_gpu instance, it is not necessary to store them separately.
As the current priv struct stores nothing else, this allows its
removal. This removal cleans up related compiler warnings regarding
unused variables in case of opengl and d3d11 being disabled in
mpv/libplacebo.
Functions to receive the underlying vulkan,gl,d3d11 structure were
added in libplacebo version 4.182. Our current requirement for
gpu-next is 4.190, and thus we can freely utilize these helper
functions.
We only wish to touch actual video frames, which should have an
allocated image attached to them, so just check the frame type
early, and exit by passing through such non-video frames to further
filters in the chain without attempting to process them.
Fixes a crash in case of non-video (EOF/NONE) frames being passed
onto the filter when the dovi option was set to false since
05ccc51d53 .
While testing support for the exotic formats used by Intel vaapi for
4:2:2 and 4:4:4 surfaces, I realised that we were enumerating all
endpoints and checking formats for them. The problem with this is
that decoding (VLD) endpoints are only a subset of what vaapi exposes.
All the encoding endpoints are there too, and there is also the
None profile that we don't care about, but which generates ffmpeg
warnings if you try and examine it.
So, let's only look at VLD endpoints. This will speed things up a
little bit and make the logging less noisy.
This speeds up chapter name access while hovering the seekbar:
- Fetch the chapter-list property using observation rather than on
every render while hovering the bar. Property access, especially
with potentially lots of values (chapters), can be expensive-ish,
and can involve locking, so the less per-render the better.
- Sort the list once (on change) to simplify the iteration logic when
searching the chapter which matches the mouse position. It's still
O(N) (no binary search currently), but with less work.
The cached sorted list is stored at the state. While there are other
places which access this property and could use this cache, for now we
don't touch them, because they're not performance-critical (on init
for the chapter markers, on ch_{prev,next} button click for OSD).
Caching properties using observation instead of using mp.get_property
can indeed speedup other places too, but it should be part of a system
rather than implemented per-property. Maybe some day.
When utils.get_user_path was added, the expand-path command didn't
exist. Now it does, so remove the C code, make it a trivial wrapper.
Keep this function for backward compat to not break scripts, but
technically it's not required anymore.
This has been the latest stable release for about half a year now. This
version in particular lets us get rid of all the deprecation warnings in
the older code. (See the following commits)
The wayland backend contains logic to detect if the window is hidden. If
so, we skip rendering as an optimization. However, if we receive
multiple resize events in rapid succession, we will send the compositor
new buffers faster than the refresh rate of the monitor. Therefore the
compositor will not send us frame events which we incorrectly interpret
as the window being hidden.
Once the last buffer has actually been rendered, the compositor sends us
a frame event. However, if at that point playback is paused, there is no
logic to restart rendering of frames that we skipped due to the above
optimization. Therefore we never send the compositor new buffers
corresponding to the new size of the window and the surface will either
be too small or too large.
The simplest solution is to always render a few frames after we receive
a resize event.
vo_gpu_next and libplacebo expect swapchain images to be able to be
blitted to, which for libplacebo on FL11_0 and up means they have to
have DXGI_USAGE_UNORDERED_ACCESS, since libplacebo uses a compute shader
to emulate certain kinds of blits. For libplacebo's benefit, set all
applicable usage flags on swapchain images.
The docs specify that the +-X+-Y geometry values position the content.
This used to work correctly but got broken at 8fb4fd9a .
Geometry size is unaffected - this only concerns position.
Commit 8fb4fd9a made it center the window rather than the content by
taking the borders into account during positioning, but forgot to make
an exception when a position is specified explicitly.
This commit adds this exception, and now if a specific position is
requested then the borders are ignored, and the content is positioned
correctly.
The code assumed that the value of the profile-restore field is
"default" for such profiles, but the C implementation is such
that the field is intentionally omitted in such case.
This resulted in incorrectly trying to restore such profiles. However,
there are no stored values with profile-restore=default, so it only
resulted in a harmless warning, but otherwise behaved correctly (i.e.
nothing is restored).
Fix the condition by taking into account that missing field means
"default", so that it doesn't try to restore in such case, and
avoid the warning.
Currently the profile-restore field is intentionally omitted if it
holds the default value (i.e. no values are stored for the profile,
and trying to restore would only warn).
See m_config_get_profiles at command.c .
a02901cae7 changed how mpv was handling
wl_surface_set_buffer_scale. It's correct in that constantly setting the
surface scale on every resize (which mpv was previously doing) is
unneccessary and not right. However, it introduced a slight regression
if someone moved a surface to a new monitor with the same resolution but
a different scale. It did not trigger a resize and thus the video would
have incorrect dimensions. A later refactor changed how things looked
inside here, but this regression wasn't fixed. A resize should always be
triggered if the scale changes in this surface event. Fixes#9426.
Mouse button event codes above `BTN_EXTRA` (the ones currently defined
in `input-event-codes.h` are `BTN_FORWARD`, `BTN_BACK`, and `BTN_TASK`)
are mapped to `MP_MBTN9` and up. (Reminder that due to historical
reasons, the names `BTN_FORWARD` and `BTN_BACK` are completely
misleading; the real forward and back buttons are `BTN_SIDE` and
`BTN_EXTRA` and are already mapped correctly by mpv.)
This functionality is analogous to what the X11 backend supports in
`video/out/x11_common.c` and what the Cocoa backend supports in
`video/out/cocoa/events_view.m`.
According to the xdg-shell protocol spec, a 0x0 size from the compositor
means that "the client should decide its own window dimension". We were
not doing this correctly. What should happen is that mpv should simply
reuse the old window size if it is not maximized or fullscreened. This
should work on all (reasonably recent) versions of mutter and an
compositor that follows the spec.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml#L1050
So actually according to the xdg-shell spec, a 0x0 resize is meant to
indicate that "the client should decide its own window dimension".
Previously, this just accidentally worked. In mutter 41.3, they changed
how 0x0 resizes were sent and what actually happened was that mpv tried
to resize itself to 0x0. This was obviously broken, so the reverted
commit naively just ignored 0x0. It actually seemed to work, but it
ended up breaking older versions of mutter. It's also not exactly the
correct fix so it deserves a revert.
This reverts commit d16defac27.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml#L1050
This define was always just a stopgap for that two month period (August
2021 - October 2021) where the bytes_read field in ffmpeg was completely
missing. Before that time, it was a private member in a struct (which
mpv used). Afterwards, it officially became public. Fortunately, the
lack of this field never actually made it into a release, so it could
have only possibly affected people building from the master branch.
Since ffmpeg 5.0 came out recently, and it's been plenty of months since
that two month window, we can go ahead and drop this check. This
finishes up the work done in 78cfeee2b9.
Sidenote: the cached ffmpeg version in the mingw ci were from that time
period when the bytes_read field was missing. The N in the workflow is
bumped to force a full rebuild and fresh clone of ffmpeg.
Both _NET_WM_NAME and _NET_WM_ICON_NAME (part of Extended Window Manager
Hints) require that the string is UTF-8*. mpv was not doing this and
thus violating the spec. Just sanitize the title for these two atoms.
Note that XA_WM_NAME and XA_WM_ICON_NAME have no such requirement so
those atoms are left the same. Fixes#8812.
*: https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html
Apparently mutter can send us 0x0 resizes* for whatever reason. Probably
there's some interal reason why this occurs, but for us trying to resize
to 0x0 is obviously terrible and results in all kinds of brokenness.
Just ignore any 0 values. Fixes#9748.
*: https://gitlab.gnome.org/GNOME/mutter/-/issues/2091
Changes:
* fixed hangups in the loop function and in some other cases
* refactoring according to @michaelforney's recommendations in #8314
* a few minor and/or cosmetic changes
* ability to build ao_sndio using meson
Changes:
- rewrite to use new internal MPV API;
- code refactoring;
- fix buffers size calculations;
- buffer set to auto;
- reset() - clean/reinit device only after errors;
Previously, the sub-visibility option changed the visibility of all
subtitles including secondary ones. This meant that it was not possible
to only display secondary subtitles while hiding the primary ones. This
modifies the sub-visibility option so that it only affects primary
subtitles which allows only secondary subtitles to be displayed.
This reverts commit 04f0b0abe4.
It's not a good idea to unify the names only for visibility, while
keeping secondary-* for everything else.
This needs a bit more thought before we allow secondary sub to be
visible on its own.
Adds --sub-visibility choices 'primary-only' for only displaying the
primary subtitle track, and 'secondary-only' for only displaying
secondary subtitle track.
Removes --secondary-sub-visibility and displays a message telling the
user to use --sub-visibility=yes/primary-only instead.
These changes make it so that the default 'sub-visibility' bind 'v'
cycles through all the 'sub-visibility' choices, 'no', 'yes',
'primary-only', and 'secondary-only'.
Was tripping -Wparantheses as the && after the || was not explicitly
wrapped. However, due to operator precedence the intended effect was
still correct.
