A bad person (AKA me) merged this stuff without paying close enough
attention to the code style. Reformat this to be in-line with the rest
of the wayland code and general mpv style (braces for functions on the
next line, horizontally aligning arguments, some cosmetic cleanups for
wayland_common.h, etc.).
So it turns out that mpv already has an mp_tag_str which makes a
readable string out of fourccs (drm formats are these).
drm_format_string, on the other hand, has a ton of baggage with having
to check different libdrm versions for certain headers, adding
compile-time defines (because there are no version defines in the libdrm
headers), etc. It's a lot simpler to just use what mpv already has and
it returns what you actually care about: i.e. is this format supported
or not. Fixes https://github.com/mpv-player/mpv-build/issues/184
This driver makes use of dmabuffer and viewporter interfaces
to enable efficient display of vaapi surfaces, avoiding
any unnecessary colour space conversion, and avoiding scaling
or colour conversion using GPU shader resources.
If the player is started with --idle and the osc-tracklist script-message
is called then the tracks_osc table will be nil,
which caused the OSC to crash due to attempting to index a nil value.
This appears to be because the osc_tracklist variable is both
initialised and updated by (ultimately) the render() function, which
is not run when the player is idling.
Rather than mess with the existing OSC logic it's easier to either
add this single check, or alternatively to initialise the the tracks_osc
table somewhere before this.
Both mpv's main function and the client API use mp_initialize to start
up. In general, these work the same however the client API had one
slight, unnecessary limitation: you can't start it up with idle=no. In
practice, the libmpv profile (used with the client API) sets idle to
yes, so it's rarely encountered, but there's no particular reason why
this policy needs to be enforced. It turns out that mp_initialize does a
quick check to see if there are any entries in the playlist and if idle
mode is set. If not, it prints the help message and exits. Basically,
it's just the part that handles the terminal message when you type "mpv"
with no arguments. Unfortunately with idle=no, the client API also hits
this code path, exits prematurely with 1 and thus returns an API error.
Fortunately, the fix is very simple. If the client API is used instead
of the "normal" mpv executable, then the mp_initialize function gets a
NULL for the options argument. When starting mpv from the terminal (when
you would want to see the before mentioned help text), there will always
be at least an argv[0] (the mpv executable name itself) so we can
reliably distinguish between the two. The other case where there could
be no argv is if the pseudo-gui profile is used, but this always
enforces idle so we don't have to worry about it either. In other words,
with this combination of conditions (options, no idle, and no playlist
entries), we can be sure this is from a user calling mpv in the terminal
with no arguments. Therefore, other cases can be allowed which means
client API users can initialize with idle=no. Fixes#10162.
Normally with the keep-open option, mpv is supposed to set the
eof-reached property to true so clients can possibly do interesting
things at this step. However, there was actually an edge case where this
property notification did not occur. If you use keep-open and then seek
in the file past the end (so mpv stops), property notification is not
actually sent in this case. Internally, mpv does a very exact seek at
this step which also ends playback, but it does not set STATUS_EOF to
the ao and vo before the core idle state is updated. To fix this edge
case, it's simply just a matter of explictly setting STATUS_EOF after
seek_to_last_frame in handle_keep_open. This logic will only ever
trigger if keep-open is being used and the seek goes past the end of the
file, so we know that there will always be an EOF here.
5774ce759a added the new output name event
and used them for the --fs-screen-name option. It turns out that the
display-names property could also make use of these names, so go ahead
and use output->name in this case if we have them. If not, fallback to
output->model like before.
Windows is weird and symbols weren't actually being exported. This is
because __GNUC__ is defined and picked up in the conditional, but
__attribute__((visibility("default"))) doesn't actually export anything
to the dll. Instead, just check if we have win32 defined first and then
always set __declspec(dllexport). Fixes#10171.
ffmpeg 5.1 adds support for IPFS (the ipns:// and ipfs:// protocols).
This patch enables those protocols to be fist-class citizens in mpv.
Thus allowing for playing IPFS resources on mpv like:
"mpv ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T"
Some compiler flags were passed to mpv in order to get it to build as a
gui application on windows. However on the meson build, this always
resulted in mpv being built as a console application. This is because
the function for making executables in meson specifically has a kwarg
called win_subsystem* which defaults to 'console'. That always added
link arguments at the end which compiled mpv.exe as a console
application. The correct thing to do is to remove all of the
subsystem-related flags in the meson build and use the win_subsystem
kwarg as intended by setting it to 'windows,6.0'. For mpv.com, we can
remove the -Wl,--subsystem,console flag since meson will set this by
default in that executable. This makes mpv.exe function correctly and
open with the pseudo-gui while mpv.com acts as a console wrapper.
1a0603835e
These values and options were simply never looked at in the drm egl
context. This pretty much is just a copy and paste of what is in vo_drm.
Fixes#10157.
09ea3a424f moved the console above the OSC when it is visible so they
don't overlap, but only changed the first ass:pos() call and forgot to
update the second one, which redraws the cursor on top of the text, so
when both the OSC and the console are visible, a second cursor is drawn
on the OSC. You have to type past where the buttons are to notice it.
This commit synchronizes the position of the 2 ASS events.
Allow screenshot-high-bit-depth=yes to work with JPEG XL
screenshots when screenshot-sw=no is set. They already work
as expected when screenshot-sw=yes is set, but this allows
the hardware screenshots to work this way too.
Since 2018, wl_surface_damage_buffer has been explicitly preferred and
recommended over wl_surface_damage*. mpv was still using the old
function in a couple of spots. The only difference is that we need to
pass buffer coordinates instead of surface coordinates. In vo_wlshm,
this is done by using vo->dwidth/vo->dheight since that is always used
whenever wl_buffers are created. In the case of the cursor surfaace, we
actually already passed buffer coordinates to it (img->width/height)
which was probablly technically wrong with wl_surface_damage, but it
doesn't really matter in practice. This requires bumping wl_compositor
to version 4 which is no problem since this dates back to 2015*.
921d0548033384f69ecf
Add Jpeg XL as a possible output format for screenshots, which
should make it possible to take fast screenshots with much better
quality than JPEG, or take lossless high-bit-depth screenshots
with lower file sizes than PNG.
It is possible for vo_gpu_next to attempt a resize before the windowing
backend is fully initialized. In practice, this can happen on wayland
which means libplacebo attempts a 0x0 resize. Depending on the API, a
0x0 resize may be allowed (vulkan or d3d11), but libplacebo just returns
a 0 in this case which mpv doesn't do anything with anyway. In the case
of opengl, this usage is explictly forbidden and will result in a
warning which may confuse users. Solve this by just not trying a resize
if dwidth and dheight in the vo are not available. Fixes#10083.
Recently, git patched a CVE which makes it much more strict about
different users operating on directories they don't own. For us, this
causes breakage with version.sh and version.py since they both run a git
describe command to fetch the commit hash. Currently, this only affects
the tumbleweed container (likely because it was recently changed) and
thus the git describe command always errors out. Workaround this by just
explictly adding the mpv directory as a safe directory for git.
- Say built-in which is more common than builtin
- Move "By default" because only the key to open the console is
customizable, and fix the punctuation and case of the sentence
- ` opens the console, not ´
- Remove the sentences that explains which user script console.lua is
based on since it's no longer relevant now that the console has been
part of mpv for over 2 years.
Now that a separate --cover-art-whitelist option exists, files like
cover.jpg are loaded even without setting --cover-art-auto to fuzzy, so
only load files that have exactly the media filename by default, since
fuzzy loading is probably more likely to load unwanted images than to
load cover art that the user intended to display, especially if you play
audio files with a short filename like a.mp3.
This allows more fine grained control over which cover art to load. With
--cover-art-auto=exact and --cover-art-whitelist=yes, you can now load
cover art with the exact media filename and the whitelisted filenames,
but not cover art that contains the media filename
(--cover-art-auto=fuzzy).
This adds a section to the documentation to explain how resuming
playback works, and in particular it explains how it affects which
playlist entry mpv starts playing from, since this feature was only
implied in the --playlist-start documentation.
It also groups the documentation of the watch later options together to
make them easier to find.
draw_image is an old API that was deprecated long ago. However when
wlshm was originally added, it used draw_image. There's no particular
reason for this and it can trivially be switched to draw_frame instead.
This has some real advantages (notably --vo=wlshm --idle --force-window
actually works).
This fixes build failures with avcodec 58.113.100 or before,
matching FFmpeg release versions 4.0 to 4.3.
This flag was added in between avcodec 58.113.100 and 58.114.100
during the FFmpeg 4.4 development cycle. It lacks its own version bump,
so instead a check for the define is utilized instead.
Additionally, warn the user if they request GPU film grain with
too old of an FFmpeg.
Fixes#10088
The VO is available during decoder initialization mostly for direct
rendering purposes, so if f.ex. a complex filter chain is utilized,
there is no video renderer information available via
mp_filter_find_stream_info during creation of the decoder filter.
Thus, check for whether the VO is available before attempting to
check the capabilities flag from it.
Additionally - to simplify logic - makes explicitly requesting GPU
film grain to always disable decoder film grain functionality. The
warning is still shown if the VO is available and no support for
film grain application is available.
Fixes#10079
In wayland 1.20.0, a couple of new events, name and description, were
added to the interface. Description is not particularly useful, but name
returns back nice names for the output like "DP-1" and so on. It makes
sense to use these for fs-screen-name and prefer them over the model
name (old way of doing it) if they are available. The only problem is
that 1.20.0 is pretty new so old distros aren't going to have it anytime
soon. Deal with this by adding some defines.
Because wayland is a special snowflake, mpv wound up incorporating a lot
of logic into its render loop where visibilty checks are performed
before rendering anything (in the name of efficiency of course). Only
wayland actually uses this, but there's no reason why other backends
(x11 in this commit) can't be smarter. It's far easier on xorg since we
can just query _NET_WM_STATE_HIDDEN directly and not have to do silly
callback dances.
The function, vo_x11_check_net_wm_state_change, already tracks net wm
changes, including _NET_WM_STATE_HIDDEN. There is an already existing
window_hidden variable but that is actually just for checking if the
window was mapped and has nothing to do with this particular atom. mpv
also currently assumes that a _NET_WM_STATE_HIDDEN is exactly the same
as being minimized but according to the spec, that's not neccesarily
true (in practice, it's likely that these are the same though). Anyways,
just keep track of this state in a new variable (hidden) and use that
for determing if mpv should render or not.
There is one catch though: this cannot work if a display sync mode is
used. This is why the previous commit is needed. The display sync modes
in mpv require a blocking vsync implementation since its render loop is
directly driven by vsync. In xorg, if nothing is actually rendered, then
there's nothing for eglSwapBuffers (or FIFO for vulkan) to block on so
it returns immediately. This, of course, results in completely broken
video. We just need to check to make sure that we aren't in a display
sync mode before trying to be smart about rendering. Display sync is
power inefficient anyways, so no one is really being hurt here. As an
aside, this happens to work in wayland because there's basically a
custom (and ugly) vsync blocking function + timeout but that's off
topic.
The video sync logic for mpv lies completely within its core at
essentially the highest layer of abstraction. The problem with this is
that it is impossible for VOs to know what video sync mode mpv is
currently using since it has no access to the opts. Because different
video sync modes completely changes how mpv's render loop operates, it's
reasonable that a VO may want to change how it renders based on the
current mode (see the next commit for an example).
Let's just move the video sync option to mp_vo_opts. MPContext, of
course, can still access the value of the option so it only requires
minor changes in player/video.c. Additionally, move the VS_IS_DISP
define from to player/core.h to common/common.h. All VOs already have
access to common/common.h, and there's no need for them to gain access
to everything that's in player/core.h.
A bit of a personal pet peeve. vulkan, opengl, and wlshm all had
different methods for doing wayland's "check for visibility before
drawing" thing. The specific backend doesn't matter in this case and the
logic should all be shared. Additionally, the external swapchain that
the opengl code on wayland uses is done away with and it instead copies
vulkan by using a param. This keeps things looking more uniform across
backends and also makes it easier to extend to other platforms (see the
next couple of commits).
This lets us remap various messages which might now be happening at
each frame onto the trace level, thus unaffecting the initial debug
log level.
Additionally - thanks to this ability - the previously globally denied
message queue abandonment messages can now be handled and mapped to
trace log level, as on that log level they may be of use.
Recommended by rossy and based on his libplacebo commit
6d72f6445566eddb0493447d0bda72d98a99d40c .
Instead of always having the reference outside of calling resize,
request a backbuffer at start and relieve the backbuffer at
submission for presentation.
Aaron Boxer
Dudemanguy
Julian Orth
Emanuele Torre
CogentRedTester
Guido Cella
Mark Gaiser
Jan Ekström
Leo Izen
datasone
Jakub Wilk
Cœur
hooke007
hooke007
Mia Herkt