We wanted to preserve the libplacebo v5.264.0 requirement for gpu_next
for this release, since this is the what most Linux distributions are shipping.
The VLC 3 <-> libplacebo v6 situation is an additional reason distros are not
likely to ship the newest libplacebo release soon.
This reverts commit b73d96776c.
Doing a pw_thread_loop_wait() without checking conditions is invalid.
The thread loop could be signalled for other reasons and in this case
the wait needs to continue.
PipeWire added such additional signaling in
commit 33be898130f0 ("thread-loop: signal when started").
This meant that for_each_sink would return before the callbacks have
fired and session_has_sink() would incorrectly return "false", failing
the initialization of ao_pipewire.
Fixes#11995
Make it clearer that you should be using --hwdec with this VO. Also make
some comments about the things that are required for this to work
correctly (i.e. working drivers/GPU and the right compositor).
Since this works by mpctx giving us a dummy image, we can be reasonably
be confident that when we receive a matching imgfmt with no underlying
hw_subfmt that this is simply force window from the player. Just allow
this to go through the usual wayland logic and skip the hwdec checking.
When we get the real image later, it will still error out on the
compositors that don't have proper support.
It's a bit of an edge case, but since we now allow the disabling of the
software fallback it's possible to have a situation where hwdec
completely fails and the mpv window is still lingering from the previous
item in the playlist. What needs to happen is simply that the vo_chain
should uninit itself and handle force_window if needed. In order to do
that, a new VDCTRL is added that checks vd_lavc if force_eof was set.
player/video will then start the uninit process if needed after getting
this.
There's an option that's supposed to stop mpv from falling back to
software decoding if hardware decoding fails. Except that it doesn't
work and can fallback to software decoding anyway. Correct this by
checking if all possible hwdec failed after the loop in
select_and_set_hwdec and that we have this option. If so, flag a bool to
force eof. In decode_frame afterwards, we then simply immediately return
an EOF.
When video width is not a multiple of slice size, the last slice will overflow. Fix this by adjusting the width of the last slice to fit within the video.
Fixes issue #10436
Currently, the osc will add a margin of (osc_height / 2) to the
deadzonesize for the window controls, the topbar and the bottombar,
i.e. when osc-deadzonesize=1, the osc will show up even if the cursor
is only hovering (osc_height / 2) pixels above or below it. This is not
what this option is supposed to do according to the manual, instead
osc-deadzonesize=1 should result in the osc only appearing when it is
directly hovered. The user can simply set osc-deadzonesize=0.9 or so if
such a margin is desired, instead make the option work as advertised by
removing this margin.
It should be noted that osc-layout=box does not share this behavior,
and it already works as advertised in the manual.
mpv already has a bunch of software scaling utils. Instead of forcing
every VO to implement this, we can just grab the frame and scale it in
software in one central place. Fixes#11968.
We should always be trying hardware screenshots (VOCTRL_SCREENSHOT and
VOCTRL_SCREENSHOT_WIN) before software ones. Rearrange all the logic
here to hopefully make this clearer. The mode is passed to add_osd
(renamed since it will also be used to add the osd) which will be used
more in the next commit.
Reading the config when we're just interested in the option list
(not sure why mpv does that anyway) only has the potential to mess
this process up when it prints errors or the user has funny options
like msg-level or log-file set, so avoid doing so.
In sum there were three issues:
1. nominal_peak_luminance is an output parameter, not input
2. mpv internally uses MP_REF_WHITE which we need to scale by
3. the value should be left at its default for SDR
Together with the last change this means mpv can sucessfully
take HDR screenshots with --screenshot-sw without resulting
in a brightly colored mess. Though note that zimg does not
perform proper tonemapping.
As a consequence:
- write_avif now respects tag-colorspace=no
- write_lavc additionally sets colorspace and chroma_location
(of no consequence for png or jpeg)
mpv has historically always treated the various tiled states in
xdg-shell as maximized (probably because it was easier). Well it turns
out that there are some tiling compositors (hyprland) that allow tiled
windows to maximize themselves. This can lead to some scenarios where
mpv ends up doing a maximize on hyprland which actually works since it's
not a no-op like on sway. Fix this by separating out the tiled state
from maximize. It works mostly the same, but the main difference is that
there's no request to tile yourself like there is with maximize. Should
fix#11954.
There's a lot of checks that are along the lines of !maximized &&
!minimized or vice versa. Make a locked_size boolean and store the
value of this in here to avoid writing long lines since the next commit
will add yet another condition to this.
There is an additional failure path I didn't account for in my previous
work. While I ensured that a late hwdec failure in receive_frame can be
recovered from by trying the next hwdec, there is a specific
combination where if an hwdec fails in receive_frame, and the next
hwdec is a full decoder (eg: v4l2m2m), and that also fails, we are left
with no decoder and so the entire decoding process ends and playback is
stopped.
Basically, we must keep re-attempting the fallback in receive_frame
until we get a valid decoder (software or hardware). This edge case
will rarely be encountered as there are only a couple of decoder based
hwdecs.
Fixes#11947
I don't know why we've been doing this wrong for so long or how I didn't
notice until now. Wayland specifically has an event for handling
modifiers. We even named it "keyboard_handle_modifiers" in the code.
What we should do is just get the modifier and save it after the xkb
state is updated. Then later if the user does something else (press
another key or clicks the mouse button), the saved modifier key is
applied. If you let go of the modifier at any point, the xkb will just
update its state again and we save a 0 again here (i.e. no modifier).
There is one bit of an edge case however. If a key is pressed BEFORE the
modifier, then we have to handle the mp_input_put_key in the modifier
event instead since the ordering is not guarenteed. What we do here is
keep track of the mpkey as well as the mpmod. However if we are unable
to find a matching mpkey and the key state is pressed down, assume it's
a modifery key that was pressed and don't update mpkey. That way
whenever the modifier event does happen, it can correctly handle this
and we know that the keys must be pressed down if we end up there in the
code path.
As another fun historical note, the xkb_keysym_to_utf8 line was actually
written by wm4 himself in 460ef9c7a4
nearly 10 years ago. As the commit shows, it was clearly intended to
handle modifiers (if lookupkey finds nothing, then try to find a mod
instead). Of course, this is extremely dated and wayland hasn't worked
like that in ages. This branch never actually did anything, and thus
we'll remove it here along with modifier lookup changes.
This solves bizarre issues with modifiers not working with random keys
while working fine with others (don't ask me why). Fixes#10286 and
fixes#11945.
When using lavfi-complex, no single track populates current_track for audio.
We work around this by iterating over the list of tracks and using the first
non-null language from a selected track. If multiple tracks are selected
(i.e. used by the filter) and have conflicting language tags, we'll ignore
them all and maintain the previous behavior (null).
828dd65ef8 started this and put it in the
most common place, but any resize mpv is doing should be accompanied by
that function call to correctly inform the compositor of the window
bounds. Since we also have to set VO_EVENT_RESIZE at the same time, it
makes sense to just put these in the same function. A slight thing to
note is that xdg_surface_set_window_geometry uses surface local
coordinates which means they are divided by the wl->scaling factor. If
possible, we should use surface local coordinates directly if available
(like in the toplevel config) to avoid potential rounding errors.
Otherwise, just calculate it out. The linked commit actually broke
some weston resizes in weird ways (window disappearing or completely
freezing). Don't ask me why and I didn't attempt to find out why either,
but with this it all appears to work normally again (the other
compositors don't appear to be any different, and they shouldn't be), so
we'll go with this since it fixes soemthing and it also is more
conceptually correct.
Libass commit f08f8ea5 (between 0.16 and 0.17) changed how PlayResX
affects some aspects of rendering.
The libass change fixes a VSFilter compatibility issue which existed
for about two decades, and there are no libass plans to support the
previous behavior, so ultimately we have to adjust the mpv code, and
we can't guarantee to restore the old behavior in all cases.
Starting at this commit, vector drawing coords, font spacing, border
and shadow widths are all affected by PlayResX (specifically, by
the aspect), while previously they were unaffected by PlayResX.
This changed converted sub border and shadow widths in mpv, because
ffmpeg generates the ass with fixed PlayResX of 384 (aspect of 4:3),
and with libass 0.17, if this doesn't match the display aspect, then
borders and shadow were too wide - because most clips aspect is more
than 4:3.
The fact that ffmpeg uses fixed PlayResX of 384 could be considered
an issue, but for now we have no control over it, and ffmpeg doesn't
have the video resolution when it converts an srt source to ass.
So here we adjust PlayResX accordingly so that border/shadows are
now rendered with correct width.
However, regardless of that commit, changing PlayResX also affects
the margin value, so to compensate, we adjust sub-margins-x too.
According to libass devs, this should cover basic srt-to-ass
conversion by ffmpeg to work correctly with libass 0.17.
However, there could be srt extensions which use more complex ass,
and/or ffmpeg conversion of other sub formats (such as aribb24,
aribcaption and movtext), where more things need adjustments.
As of now we don't know what these are, and so we don't really know
what else might remain broken or get broken.
dbc5d7b7db seems to have originally
introduced this behavior. At the time, wm4 simply reconfigured ass on
every frame in order to accommodate runtime changes in sub options. This
certainly works, but these libass API calls are not free and there is at
least one known performance regression due to a change in libass*.
Regardless of whether or not the libass change is good/bad, there is no
need for mpv to constantly reconfigure this. When wm4 made that commit,
there was no notification mechanism for options changing that could
easily be used so he didn't really have any other choice. But it's
nearly 10 years later now and internally we have all the necessary
pieces to only configure ass again when we need to: on option changes or
resizes. So go ahead and implement that in this commit which simply uses
the already existing SD_CTRL_UPDATE_OPTS and compares osd_res sizes to
determine whether or not an ass configure is needed.
*: https://github.com/libass/libass/issues/698
4502522a7a implemented cache directories
but only on linux which meant other OSes continued to save this stuff in
their config directory. Since we turned on cache by default, people are
getting cache files in there which is understandably causing some
confusion. Let's go ahead and implement a separate cache directory for
windows since there seems to be some established conventions for this
already. For people using the portable_path, the cache is saved in a
subdirectory within the portable_path since the idea is for that to be
completely self contained.
To remain consistent with our belief that `auto-safe` should be the
recommended mode when turning on hw decoding, let's remap `yes` from
`auto` to `auto-safe`.
We have supported `hwdec=drm` for some time now, and on devices where
this method is present, it is the preferred, and only, method
available. Combine that with the fact that software decoding on
embedded devices will not turn out well, and it's clear that we should
put `drm` and `drm-copy` on the `auto-safe` list to maximise usability
in simple configurations.
It has been odd that ctrl+h toggles `auto` for hwdecs even though we
always recommend people start with `auto-safe`, and `auto` will attempt
various hwdecs that can fail so badly we can't fall back to software
decoding.
With the change to more exhaustively attempt to use hwdecs, it is now
easier to get into situations where these fragile hwdecs will get
attempted in basic scenarios, like pressing ctrl+h.
So it is high time to default to `auto-safe`.
Today, if hwdec initialisation succeeds, we move on to attempting
decoding, and if decoding fails, we enter a fallback path that will
only do software decoding.
This is suboptimal because some hwdecs and codec combinations can
pass hwdec init, but then fail at hwaccel init, or even frame decoding.
In these situations, we will never attempt other hwdecs in the `auto`
or manually specified lists which might work.
One good example is someone tries to use `vulkan,auto` and tries to
play av1 content. The vulkan decoding will fail at hwaccel init time,
and then fallback to software instead of going through the auto list
which would allow vaapi, nvdec, etc to play the file.
Instead, let's not give up immediately, and try the next hwdec after
a failure, just like we do if hwdec init fails.
The key part of this change is to keep track of the hwdecs we have
tried, so that each time we run through hwdec selection, we don't try
the same one over and over again. If we really get through the whole
list with no success, we will then fall back to software decoding.
Fixes#11865
This was never implemented so in cases where the compositor didn't have
support for the underlying format, the window would just be black and
quite unhelpful. Well it turns out that fixing this is actually really
easy because mpv has reconfig2 which returns the entire mp_image on
every reconfig. We can just use that mp_image to try and obtain the
format and modifier pair and then use that to check against what we know
the compositor supports. If there are any problems, error out
gracefully. Some code duplication with the vaapi/drmprime importers, but
it's probably better to keep these separate. Fixes#11198 and fixes#11664
It makes more sense as an option at this point. Also libdrm is not
optional at all. You have to get a drm format and modifier for this to
even work (the VO will just fail without DRM). Just hard require it and
remove the guards. vaapi can remain optional.
6a365b258a broke deleting redirect entries for resuming playback. If you
do mpv dir1 dir2, quit-watch-later on a file in dir1, then later
quit-watch-later on a file in dir2, mpv dir1 dir2 would not resume from
dir2 because the redirect entry for dir1 is never deleted.
Fix this by deleting watch later config files for directory/playlist
entries.
mpv has never used this because we never really seemed to need it, but
it actually has a purpose. This informs the compositor of the actual
dimensions of the mpv window and avoids errors with sizes not matching
(particularly with weston). It's a better way to fix the "maximizing
causing an error on weston" issue since it also works for dmabuf-wayland
(which always had this problem).
The original reason for this commit was to prevent a compositor error on
weston when going into the maximized state. The configured dimensions of
mpv didn't match its actual size and Weston is super strict about this
so it threw a compositor error which is fatal. It only happened in
opengl and this seemed like an OK workaround, so I went with this.
However, there's actually a far easier way to solve this problem and we
don't need this anymore. This has the benefit of avoiding a harmless
warning message that appears with gpu-next on opengl. The next commit is
the proper solution. Closes#10324.
This reverts commit 661b5542de.
The implementation was copied from vo_gpu/vo_gpu_next but fundamentally
it doesn't make sense for this VO. Hardware decoding is not optional in
vo_dmabuf_wayland. We should be sure to request and load all supported
formats in the preinit and fail if there are any problems. There should
be no functional change from before, but it's more conceptually correct
this way.
Essentially the same as d1d2370d07 except
for clear_rgba_overlay. From some empirical testing, the s->x1 value is
either 0 or SLICE_W (256). In the case where it is 256 and s->x0 is 0,
then it writes memory. For most slices, this is fine. However for the
very last slice in the loop, it is possible for the width here to exceed
the total width of the line (p->w). If that occurs, the memset triggers
a buffer overflow. This last case needs to be guarded in the same way as
the previously mentioned commit (total width - SLICE_W * x) and with
MPMIN in case s->x1 is 0 here to preserve the old behavior. It's unknown
if anything other than dmabuf-wayland can possibly hit this, but it's
definitely a problem within mp_draw_sub_overlay itself.
This adds osd support via shm buffers using a similar approach that the
normal buffers do, but it differs in a few key areas. One thing to note
is that sway and weston actually handle this extremely differently which
required all the abstractions here. In particular, weston does not cope
well with destroying the wl_buffer from shm outside of the release
handler at all (i.e. it segfaults). The workaround here is to simply
attach a NULL to the osd surface and do a surface commit before we
destroy the buffers. This is reasonable enough and seems to work well
although it's pretty weird. Sway is more straightforward although it
actually releases the osd buffer when the window goes out of sight.
Also, I found that it doesn't always release every buffer before you
close it unlike weston seems to do which is part of the reason all this
bookkeeping is required. I don't know if there's any other compositor
out there that can possibly handle vo_dmabuf_wayland right now, but
suffering through these two is good enough for now I think.
Otherwise, we could fail and skip to uninit without initalizing this
which then will segfault because the list is null and accessed while
trying to destroy buffers.
It's entirely pointless. Not having viewport is already a fatal error
for this VO as it cannot possibly work without that protocol. Just drop
all these redundant if's.
make sure that fwrite is error checked. and if any data was still
remaining on the buffer, it will be flushed - and errors checked - via
the fclose() call below.
mpv already guesses when the window is hidden so plugging in a proper
event that actually tells us this is really trivial. Note that there's
some redundancy with setting wl->hidden in a few spots, but nothing can
really be done about that as long as the crappy hack is still in place.
This protocol no longer requires us to draw a separate cursor surface
and all of that horrible stuff. We can just ask the compositor for the
default cursor instead since that's literally all mpv cares about.
In case there are no packets from demuxer we cannot send EAGAIN, because
we will not proceed and get stuck with one frame in queue and never
output it. Just respect avcodec_receive_frame ret code and act
accordingly. The only case to care about is EOF when we have to drain
already queued frames.
Fixes playback of 1-2 frame videos.
It can happen during initialization and of course nothing good will
happen if we let this go through (i.e. segfault). Return and wait for
geometry to finish setting up in the wayland stuff before doing the
initial resize.
Very dumb. I can't remember if it was always like this or if I broke it
at some point, but clearly each wl_output should just be freed in
remove_output. Freeing it if it happens to be wl->current_output only
works for that one monitor, so remove that whole line. This has to
happen before we close the wayland connection so reorder the uninit a
little bit.
Currently, mpv immediately deletes the watch_later file after an attempt
at playing the file is made. This is not really ideal because the file
may fail to load for a variety of reasons (including not even existing),
but the state is cleared anyway unconditionally. Instead, just wait
until after playback is successfully initialized before deleting it.
This way silly mistakes like forgetting to mount the drive doesn't
result in deleting your watch_later data. Fixes#3427.
the reason for checking `EBADF|EINVAL` specifically is unknown. but it's
clearly not working as intended since it can cause issues like #11795.
instead of checking for "bad errors" check for known "good errors" where
we might not want to break out. this includes:
* EINTR: which can happen if read() is interrupted by some signal.
* EAGAIN: which happens if a non-blocking fd would block. `tty_in` is
_not_ non-blocking, so EAGAIN should never occur here. but it's added
just in case that changes in the future.
Fixes: https://github.com/mpv-player/mpv/issues/11795
Closes: https://github.com/mpv-player/mpv/pull/11805
d3cef97ad3 changed the way the command
line was parsed and syntax like "--foo value" stopped being considered
valid. This old script still was using the old syntax and thus was
broken. Update it to "--msg-level=ffmpeg=v" which is the recommended
syntax. Fixes#11892.
Directories were always loaded recursively, which can be slow
(e.g. one of the subdirectories is a mounting point to a slow device)
and can unexpectedly expand into a massive playlist.
Due to the problems described in 503dada42f,
this defaults to recursive loading.
ref. https://github.com/mpv-player/mpv/issues/9652
--no-config should prevent loading user files of any type: configs,
cache, etc. For cache files, this case wasn't properly handled and it
was assumed they would always get something. vo_gpu's shader cache
actually already handles this, so it was left untouched. In theory,
demuxer cache should never have this issue because saving it to disk is
disabled by default (and likely that will never change), but go ahead
and change it for consistency's sake. Fixes some segfaults with
--no-config and various combinations of settings (particularly
--vo=gpu-next).
4502522a7a changed the way mpv handled and
saved cached files. In particular, it made a separate boolean option for
actually enabling cache and left the *-dir options as purely just a path
(i.e. having a dir set didn't mean you save cache). This technically
regressed people's configs, so let's just turn the cache on by default.
Linux users already expect random stuff in ~/.cache and well everyone
else can just live with some files possibly appearing in their config
directory.
Add an option for allowing pointer events to pass through the mpv
window. This could be useful in cases where a user wants to display
transparent images/video with mpv and interact with applications beneath
the window. This commit implements this functionality for x11 and
wayland. Note that whether or not this actually works likely depends on
your window manager and/or compositor. E.g. sway ignores pointer events
but the entire window becomes draggable when you float it (nothing under
the mpv window receives events). Weston behaves as expected however so
that is a compositor bug. Excuse the couple of completely unrelated
style fixes (both were originally done by me).
We used to sort the playlist with playlist-move after every loadfile.
Instead, append all files in order and call playlist-move once to move
the only entry we don't control the position of.
Don't fetch every playlist item separately, reuse native property.
We used to pick up on new files added to the directory, but only when
playing an entry at the edge of the playlist due to an early return.
New files are now added to the playlist on every file change.
This still works as expected and doesn't load duplicate files on
shuffled playlists or playlists with files manually added after autoload
33% faster on average for my test directory with 1371 files.
Notes:
- converts the (image) write() api to filenames, because using avio
with FILE* is a pain.
- adds more debug logs for screenshots.
build: rename av1 dependency to avif_muxer
wscript: unify lavf dependency with meson
the reason for these casts are unknown but they were presumably to
silence warnings 9 years ago. but it doesn't seem to be necessary
nowadays, so just drop the casts and also drop the `const` from the
compound literal type.
some small technical notes:
1. while string literals aren't `const` in C, writing to them is
undefined (do not ask me why). and so compilers will typically put
string literals into read only section anyways, regardless of
weather `const` was used in the source or not. so this shouldn't make
any difference codegen wise.
2. making the array of pointers `const` on the other hand might affect
codegen, eg: `(char *const []){...}`. however, that'd trigger a lot
of discarded qualifier warnings.
shorter and more robust this way instead of inserting at an index by
manually counting.
the surrounding code also uses `[STREAM_*] = ..` so it's more consistent
as well.
Today, the only way to make mpv consider multiple hwdecs and pick the
first one that works is to use one of the `auto` modes. But the list
that is considered in those cases is hard-coded. If the user wants to
provide their own list, they are out of luck.
And I think that there is now a significant reason to support this -
the new Vulkan hwdec is definitely not ready to be in the auto list,
but if you want to use it by default, it will not work with many codecs
that are normally hardware decodable (only h.264, hevc and av1 if you
are very lucky). Everything else will fall back to software decoding.
Instead, what you really want to say is: use Vulkan for whatever it
supports, and fall back to my old hwdec for everything else.
One side-effect of this implementation is that you can freely mix
hwdec names and special values like `auto` and `no`. The behaviour will
be correct, so I didn't try and prohibit any combinations. However,
some combinations will be silly - eg: sticking any further values after
`no` will result in them being ignored. On the other hand, a
combination like `vulkan,auto` could be very useful as that will use
Vulkan if possible, and if not, run the normal auto routine.
Fixes#11797
first of all, POLLERR is supposed to be ignored in `.events` and only
returned in `.revents`.
secondly select()'s exceptfds does not have a 1:1 correspondence with
POLLERR. thankfully, the only caller of this function (in terminal-unix)
never set the POLLERR flag so the errorfds were unused anyways.
so go ahead and remove it entirely instead of pretending we can emulate
something that's not possible.
this changes mp_image_new_ref() to handle allocation failure itself
instead of doing it at its many call-sites (some of which never checked
for failure at all).
also remove MP_HANDLE_OOM() from the call sites since this is not
necessary anymore.
not all the call-sites have been touched, since some of the caller might
be relying on `mp_image_new_ref(NULL)` returning NULL.
Fixes: https://github.com/mpv-player/mpv/issues/11840
in the first iteration, *out will be null and thus the steal and the
strdup both sets the parent to NULL - leaking the allocation later on
(caught via LeakSanitizer).
let append_lang() take care of setting the parent instead.
when vo_drm_init() fails inside of preinit(), uninit() will be called as
part of cleanup with vo->drm being NULL and thus `drm->fd` would lead to
null dereference.
and since vo_drm_uninit() closes drm->fd, destroy_framebuffer() ends up
using a closed fd.
according to the drm-gem manpage [0]:
> If you close the DRM file-descriptor, all open dumb-buffers are
> automatically destroyed.
so remove the destroy_framebuffer() loop entirely, which fixes both the
issues.
[0]: https://www.systutorials.com/docs/linux/man/7-drm-gem/
I originally left `drmprime_overlay` as higher priority because
`drmprime` was new, and because I didn't have any hardware where both
worked (only one or the other) so I couldn't compare relative
performance, and if only one worked, the priority didn't matter.
But with time and more usage, we've reached a point where we can say we
would recommend using `drmprime` in situations where both work, and
we've also been able to identify hardware where both do indeed work and
it seems that `drmprime` is more reliable.
So, let's flip them.
Now that Debian 12 is release bump the minium required version to what
is provided in Ubuntu Jammy (22.04).
The same as has been done for the wayland dependencies.
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
Instead of brute forcing the name until it is set, without any error
checking and expecting it would start to work, fallback to client name
if initial request fails.
Fixes player going into infinite loop with very long title names. The
API rejects unreasonably long names, which make sense.
As for alleged "weird race condition in the IAudioSessionControl itself"
I cannot comment. It works on my end and even if it fails, it is not a
critical error or even something that we should care about... and
obviously not hang the whole player for that.
Fixes: #11803
If demux_open_lavf fails between calling avformat_alloc_context() and
assigning the context to priv->avfc, it will never be properly freed.
Fixes#11793.
It was done once before but later reverted for testing reasons. This
time it's permanent though since I can test this VO on ARM and with an
up to date system.
When using a display-* video-sync mode, it is possible for buffers with
a matching id to already have an image associated with them (i.e. the
compositor hasn't released it yet). Previously, it was thought that we
could just unref, return null, and make a new buffer but this eventually
leads to a fatal error that originates from libwayland itself which
stops playback. Admittedly, the reason for the error is a bit nebulous
but likely it seems to be some kind of mismatch between dmabuf params
and the associated image with the buffer.
However, we can simplify this process greatly. Instead when the
previously mentioned edge case happens, the old image can simply be
freed and we give the buffer the new image. This saves creating a new
buffer and also avoids that nasty libwayland error. A nice win-win all
around. Fixes#11773.
vo_dmabuf_wayland has a pool of wl_buffers that it cycles through when
drawing frame. There needs to be at least some minimum number otherwise
a flickering artifact occurs where old frames are mistakenly repeated.
When using display-resample and other similar modes, it seems more
buffers are required (more drawing happens so it makes sense) and the
current minimum of 8 isn't good enough. Let's just bump this to 15. It's
also a random ad hoc number, but as far as I know there's not really a
way to predict how many buffers a random video may need. From testing,
it works fine and overall 15 is still a tiny amount of objects to create
considering the lifetime of a video, so we'll just go with this.
Some platforms (wayland) apparently have a lot of trouble with drag and
drop. The default behavior is still the same which is basically obeying
what we get from the window manager/compositor, but the --drag-and-drop
option allows forcibly overriding the drag and drop behavior. i.e. you
can force it to always replace the playlist or append at the end. This
only implements this in X11 and Wayland but in theory windows and macos
could find this option useful (both hardcode the shift key for
appending). Patches welcome.
In data_offer_actions, it's possible to get the
WL_DATA_DEVICE_MANAGER_DND_ACTION_NONE action which would set
wl->dnd_action to DND_APPEND (did nothing in practice) but also log a
message which is confusing and misleading. Instead, just ignore and
don't do anything when we get this case.
To avoid building against stale version of dependencies. In particular
libplacebo is moving target and as we can see the build has been broken
few times recently, so let the CI validate it for us.
The time to build everything is under 30 minutes, which is acceptable in
my opinion, not much longer than macos build.
It is worth adding this example because it has been asked multiple times
in the issue tracker and the IRC channel.
string.find() is used because it's 20 times faster than string.match().
519e56f caused an attempt to get the language even if the file name
didn't start with the movie title. However, detecting a language when
fuzz >= 1 or the language is known, caused prio to be non-zero which
caused the file to be included regardless of its name. This shouldn't be
the behavior when sub-auto != all.
Now all the prio updates that depend on lang will only happen if the
file in question starts with the movie name. Since language was never
detected before if this wasn't true, the behavior should be the same as
before 519e56f when sub-auto != all.
Closes: #11749
We're moving to using timeline semaphores for synchronisation between
cuda and vulkan. It's only required with libplacebo-next right now,
but eventually our baseline libplacebo requirement will increase, so we
will need new enough nvidia headers that include the necessary
declarations.
This is not technically necessary, because we never touch the fd again
after passing to cuda, but having it there could lead to future code
accidentally using it.
All hwdecs should respect the probing flag and demote their lgoging to
verbose level, so that initialisation failures during probing do not
spam the user. I forgot to do this for the Vulkan hwdec.
The dmabuf-wayland vo has a stub ra implementation that doesn't
have a swapchain. That means that it's currently not safe to call
ra_vk_ctx_get on that ra_ctx, but it must be safe to call on all ra
implementations as this is how we discover if it is a vulkan ra.
This hasn't been an issue before because no Vulkan code paths would be
triggered when using dmabuf-wayland, but with the new vulkan hwdec, it
becomes possible to trigger when hwdecs are probed.
The libplacebo sync abstraction is deprecated and we should be using
the more explicit Vulkan semaphore helpers instead. This means that
more of the book keeping moves to our side, but it's not too bad.
There are two main things going on here:
1. After a lot of back and forth, I decided to write the new code with
timeline semaphores to streamline things, and that also means all
the variables are separate - which makes the #ifdefs easier to read.
Which is important because:
2. While pl_sync owned the exported fd/handle, pl_vulkan_sem does not,
so we are responsible for managing them. That means reversing the
previous logic - we now can pass an original fd to CUDA and never
think about it again, while we have to clean up a Win32 Handle
because CUDA will not take ownership.
Finding the prefix in the key is not enough, the key has to actually
start with the prefix. Otherwise a key like `uosc-font_scale` will not
only match the `uosc-` prefix, but also the `osc-` prefix, resulting
in a logged warning about `-font_scale` being an unknown key.
AV1 support in Vulkan is extremely bleeding edge - to the point that
the extension is not present in official Khronos releases, but it has
a reserved identifier and we can look it up with a string literal for
now.
This will be skipped and ignored if the driver doesn't support it, so
it's safe if/when the name changes later (it'll just never be activated
in that case).
I originally wrote this trying to avoid doing an explicit version check
on the headers, but it just makes things more confusing, and the
requirements harder to understand.
So, Vulkan interop now takes a dependency on the header release where
they finalised the video decode headers. VK_EXT_descriptor_buffer was
added in 1.3.235, so that's covered as well.
Along the way I fixed a bug in the waf build where it was depending
on libplacebo-next instead of libplacebo-decode.
ffmpeg was previously allocating images for frames as the code size,
rather than the presentation one (1088 vs 1080 in the most common
example). Using the coded size when wrapping images for libplacebo
resulted in incorrect scaling from 1088 -> 1080, but even using the
presentation size wasn't perfect, as discussed in the original
commit.
However, ffmpeg has now been updated to use the presentation size for
the frame images, after discussions that concluded this must be done
because there is no way for a frame consumer to fix the dimensions
without copying the frame.
With that ffmpeg change, we can just use the normal layout information
like all the other hwdecs.
Although we can support vulkan multiplane images, cuda lacks any such
support, and so cannot natively import such images for interop. It's
possible that we can do separate exports for each plane in the image
and have it work, but for now, we can selectively disable multiplane
when we know that we'll be consuming cuda frames.
As a reminder, even though cuda is the frame source, interop is one way
so the vulkan images have to be imported to cuda before we copy the
frame contents over.
This logic here is slightly more complex than I'd like but you can't
just set the flag blindly, as it will cause hwframes ctx creation to
fail if the format is packed or if it's planar rgb. Oh well.
Vulkan hwdec interop with the ffmpeg 6.1 vulkan code will require
additional features beyond those activated by libplacebo by default.
Enabling these features requires both requesting the features'
extensions and then explicitly turning on the features. libplacebo
handles detecting unsupported features and dropping them, to avoid
failing to create the vulkan device.
We then leave it to ffmpeg to decide if any missing features are
required for functionality, and error out if necessary.
As ffmpeg requires at least one bleeding edge extension (descriptor
buffers), all of this logic is gated on the presence of sufficiently
new Vulkan headers.
Vulkan Video Decoding has finally become a reality, as it's now
showing up in shipping drivers, and the ffmpeg support has been
merged.
With that in mind, this change introduces HW interop support for
ffmpeg Vulkan frames. The implementation is functionally complete - it
can display frames produced by hardware decoding, and it can work with
ffmpeg vulkan filters. There are still various caveats due to gaps and
bugs in drivers, so YMMV, as always.
Primary testing has been done on Intel, AMD, and nvidia hardware on
Linux with basic Windows testing on nvidia.
Notable caveats:
* Due to driver bugs, video decoding on nvidia does not work right now,
unless you use the Vulkan Beta driver. It can be worked around, but
requires ffmpeg changes that are not considered acceptable to merge.
* Even if those work-arounds are applied, Vulkan filters will not work
on video that was decoded by Vulkan, due to additional bugs in the
nvidia drivers. The filters do work correctly on content decoded some
other way, and then uploaded to Vulkan (eg: Decode with nvdec, upload
with --vf=format=vulkan)
* Vulkan filters can only be used with drivers that support
VK_EXT_descriptor_buffer which doesn't include Intel ANV as yet.
There is an MR outstanding for this.
* When dealing with 1080p content, there may be some visual distortion
in the bottom lines of frames due to chroma scaling incorporating the
extra hidden lines at the bottom of the frame (1080p content is
actually stored as 1088 lines), depending on the hardware/driver
combination and the scaling algorithm. This cannot be easily
addressed as the mechanical fix for it violates the Vulkan spec, and
probably requires a spec change to resolve properly.
All of these caveats will be fixed in either drivers or ffmpeg, and so
will not require mpv changes (unless something unexpected happens)
If you want to run on nvidia with the non-beta drivers, you can this
ffmpeg tree with the work-around patches:
* https://github.com/philipl/FFmpeg/tree/vulkan-nvidia-workarounds
We will need the full ra_ctx to be able to look up all the state
required to initialise an ffmpeg vulkan hwcontext, so pass let's
pass the ra_ctx instead of just the ra.
This is motivated by a need to access it from vo_gpu_next's opengl
wrapping code, and justified by it being an inherent property of the GL
context itself,
It was unsafe to return pointer to memory that was freed on another
thread, just copy the string to caller owned sturcture.
Fixes crashes when displaying passes stats with gpu-next.
vo_dmabuf_wayland worked by allocating entries to a pool and then having
a lot of complex logic dealing with releasing buffers, pending entries,
etc. along with some other not so nice things. Instead, we can rewrite
this logic so that the wl_buffers created by the imported dmabuf is
instead stored in a linked list, wl_list. We can simply append our
buffers to the list when needed and destroy everything at the end. On
every frame, we can check the ids of our surfaces and reuse existing
buffers, so in practice there will only ever be a handful at a time.
Some other small changes were made in an attempt to organize the
vaapi/drmprime code a little better as well.
An important change is to always enforce at least a minimum number of
buffers. Certain formats would not make enough unique buffers, and this
results in flickering/artifacts occuring. The old way to attempt to deal
with this was to clear out all the existing buffers and remake them, but
this gets complicated and also didn't always work. An easy solution to
this is just create more buffers which appears to solve this problem.
The actual number needed is not really based on anything solid, but 8
is a reasonable number to create for the lifetime of a file and it seems
to do the trick.
Additionally, seeking/loading new files can result in flicker artificts
due to buffers being reused when they shouldn't. When that happens, we
flip a bool so all the buffers get destroyed in draw_frame to avoid any
visual glitches.
This just replaces the API calls to get rid of deprecation warnings, it
doesn't yet expand the enum, nor replace them by the proper options.
The translation from tone map modes to hybrid mix parameters is taken
from the libplacebo source code.
Previously, if vo_drm_init failed at the start of drm_egl_init it
caused a use-after-free in drm_egl_uninit when it tried to access the
non-existant drm context. At that point vo_drm_uninit had already been
called resulting in two different null pointer dereference. In this
situation the DRM private context had also not been allocated.
This matches the behaviour that libmpv API clients expect better and
prevents silent regressons with watch_later suddenly appearing in
an entirely different path (or none at all in case of weird platforms*).
Also added some comments for easier understanding.
* Android
Previously, we'd only attempt to call guess_lang_from_filename if the
external file name matched the video name ignoring the extensions. So if
they didn't match, we'd just report the language as "unknown". And since
the name will never match for urls, the language would always be treated
as unknown.
Now we'll always try to guess the language from the filename regardless
of its similarity to the video file name.
Closes#10348
Filtering globally D3D11_MESSAGE_ID_CREATETEXTURE2D_INVALIDDIMENSIONS is
suboptimal, because can also hide other invalid usages. In the same time
it is not enough, because not only this message is emitted, but also one
about E_INVALIDARG. Just flush queue before and clear messages after to
ignore this part of code.
As a side note, I don't believe this texture size lookup is in fact
useful, but since it is there and is relatively harmless, let's leave
it as is.
The current implementation is order dependent and assumes that getting
keyboard input happens before the toplevel is activated. This isn't
necessarily the case and indeed mutter activates the toplevel first.
Improve this by simply spinning off the check to a function and calling
it in the three places where it would be needed: the toplevel
configuration event, keyboard entering, and keyboard leaving. This
fixes#11694.
Pass "dummy.m3u8" filename to work around FFmpeg commit
6b1f68ccb04d791f0250e05687c346a99ff47ea1 which broke their HLS demuxer
and its ability to probe.
Since the above commit, libavformat will check the filename of the file
to be probed and reject it if it doesn't end with a valid HLS extension
i.e. m3u8,hls,m3u (never mind that .hls is not a valid HLS extension).
In addition to a bug with query strings, this also breaks mpv
functionality as mpv explicitly doesn't tell libavformat the filename
when probing, in order to properly detect the file based only on their
contents.
The [HLS specification](https://www.rfc-editor.org/rfc/rfc8216.txt) aka
RFC 8216, specifies in section 4 that "Each Playlist file MUST be
identifiable either by the path component of its URI or by HTTP
Content-Type." Notably, it does not require both, so this FFmpeg commit
is noncompliant. We work around this noncompliance by checking the MIME
type ourselves. If the mimetype matches one of the valid HLS mimetypes
(and also application/x-mpegurl, a legacy pre-standardization type),
then we pass "dummy.m3u8" to libavformat in order to work around its
overly strict checking of filenames.
Without this patch, we are unable to play many HLS streams, including a
few from the ytdl hook. This patch restores those ability to play those
streams when built against FFmpeg master. Do note that if the server
sends an invalid content-type header then we cannot implement this
workaround so those streams will still fail to play.
This adds cache as a possible path for mpv to internally pick
(~/.cache/mpv for non-darwin unix-like systems, the usual config
directory for everyone else). For gpu shader cache and icc cache,
controlling whether or not to write such files is done with the new
--gpu-shader-cache and --icc-cache options respectively. Additionally,
--cache-on-disk no longer requires explicitly setting the --cache-dir
option. The old options, --cache-dir, --gpu-shader-cache-dir, and
--icc-cache-dir simply set an override for the directory to save cache
files. If unset, then the cache is saved in XDG_CACHE_HOME.
A pain point for some users is the fact that watch_later is stored in
the ~/.config directory when it's really not configuration data. Roughly
2 years ago, XDG_STATE_DIR was added to the XDG Base Directory
Specification[0] and its description, user-specific state data, actually
perfectly matches what watch_later data is for. Let's go ahead and use
this directory as the default for watch_later. This change only affects
non-darwin unix-like systems (i.e. Linux, BSDs, etc.). The directory
doesn't move for anyone else.
Internally, quite a few things change with regards to the path
selection. If the platform in question does not have a statedir concept,
then the path selection will simply return "home" instead (old
behavior). Fixes#9147.
[0]: https://gitlab.freedesktop.org/xdg/xdg-specs/-/commit/4f2884e16db35f2962d9b64312917c81be5cb54b
Currently, nothing new is actually implemented but the idea is simply to
just pass a type string all the way up from mp_find_user_file down to
actually getting the platform path. This allows for selecting different
directories besides the user's native config directory. See the next
commit for an implementation.
macOS really has completely different path conventions that mpv doesn't
take into account and it treats it just like any other old unix-like
system. This means mpv enforces certain conventions on it (like all the
XDG stuff) that doesn't really apply. Since we'd like to use more of
this but at the same time not distrupt mac users even more, let's just
copy and paste the current code to a new file, update the build and call
it a day. This way, the paths of these two platforms can more freely
diverge.
If mp_iconv_to_utf8 was given an empty string to convert in the buf
parameter it would corrupt memory when writing a null into outbuf
before returning it to the caller. This happened when streaming from a
URL that ends in a slash. For such a URL the method mp_basename returns
an empty string. The method append_dir_subtitles passes the result
returned from mp_basename to mp_iconv_to_utf8 which then corrupts
memory. This was detected using Guard Malloc. The fix changes
mp_iconv_to_utf8 check up front if buf is empty and if it is return
buf as the result in compliance with the documented behavior of the
method when no conversion is needed.
Fixes#11626
Upon an option update with an UPDATE_SUB_HARD flag,
the ass_track that stores all the decoded
subtitle packets/events is destroyed and recreated, which means
the packets need to be read and decoded again to refill
the ass_track. This caused issues (no subs displayed) in 2 cases:
1. external sub files
Previously, external sub files were read and decoded only
once when loaded. Since this meant all decoded events were lost
forever when recreating the ass_track, we need to change this
and trigger a new preload during sub reinits.
2. converted subs (non-ASS text subs like srt)
For converted subs, we maintain a list of previously
seen packets to avoid decoding and adding duplicate events
to the ass_track. Previously this list wasn’t synchronized with
the corresponding ass_track, so the sub decoder would reject
any previously seen sub packets, usually meaning only subs sometime
after the current pts would be displayed after sub reinits.
Fix this by resetting the list upon ass_track recreation.
HEVC hardware decode with drm wasn't working on the RPi 4. Mpv would
report the image format (rpi4_8 for 8-bit and rpi4_10 for 10-bit) wasn't
supported. The change to hwdec_drmprime.c identifies these two formats
as NV12 because it functions exactly the same. The change to
dmabuf_interop_gl.c adds support for P030 which rpi4_10 uses. These
changes were tested on a Pi 4 with this fork of ffmpeg:
https://github.com/jc-kynesim/rpi-ffmpeg.
Signed-off-by: EmperorPenguin18 <60635017+EmperorPenguin18@users.noreply.github.com>
This finally allows us to put any user defined options into the
CONFIGURATION variable like what waf does. The arbitrary hardcoded
fallback is left in place for old meson versions. Also update the
documentation in regards to the mpv-configuration variable to be
relevant to meson.
If --screenshot-tag-csp=no, then there won't be any color tags in the
output space, so PNG and JXL screenshots should be written as sRGB
rather than the native space of the input video.
As the Dolby Vision metadata is only supported for vo_gpu_next, the check
whether to use the metadata is now handled by `mp_map_dovi_metadata_to_pl`.
It doesn't hurt to keep the metadata in `mp_image`, and might be useful to
library users.
6e4a76db08 attemped to reject invalid
properties and print an error for users so they actually know that
something is going wrong. This worked by simply checking if the property
not found error is returned, but it is actually perfectly possible for a
property to not be found (different than being unavailable just to be
clear here) at first and then show up later. An example would be
user-data which can be created at any time. It's also possible with
subproperties of things like track-list where a new track could be added
later.
In light of this, let's soften the error checking logic here with a
simple trick. mpv already keeps track of all toplevel properties and it
can be easily retrieved with the "property-list" property, so just cache
that. When we get a property not found error, instead of rejecting it,
try to match it something in the property-list first. If we have a
match, then consider the property valid and allow the script to behavior
normally. If not, we reject it. This approach means property names that
are obviously wrong like "fake-property-here" will reliably get rejected
and something like "user-data/test" works as usual. The downside is that
errors in the subproperty level are not caught, so something like
"track-list/0/fake-property" would still be considered valid and the
user gets no warning that this won't work. We'll just accept the
compromise and hope this isn't too common.
Fixes#11550.
Instead of erroring when values returned by profile-cond expressions
aren't booleans, apply the relative profiles as long as the return
values are truthy. This allows shortening conditions like
profile-cond=path:match('foo') ~= nil
to
profile-cond=path:match('foo')
The idle logo could appear on the left side of the window for a split
second after starting.
That is because when osd dimensions can be reported as 0 at the very beginning.
Since the width gets calculated based on a fixed height and the aspect ratio,
which is 0, that results in a width of 0 until the next update.
Microsoft documented how to enable dark mode for title bar:
https://learn.microsoft.com/windows/apps/desktop/modernize/apply-windows-themeshttps://learn.microsoft.com/windows/win32/api/dwmapi/ne-dwmapi-dwmwindowattribute
Documentation says to set the DWMWA_USE_IMMERSIVE_DARK_MODE attribute to
TRUE to honor dark mode for the window, FALSE to always use light mode.
While in fact setting it to TRUE causes dark mode to be always enabled,
regardless of the settings. Since it is quite unlikely that it will be
fixed, just use UxTheme API to check if dark mode should be applied and
while at it enable it fully. Ideally this function should only call the
DwmSetWindowAttribute(), but it just doesn't work as documented.
Fixes: #6901
This better follows the actual required bits, and makes sure that
a file not part of standard EGL headers is available, as the
handle type is part of standard EGL extensions header.
Previously, it just silently didn't do anything which is not very
intuitive. Since the lua api returns an error string, check to see if
it matches the "property not found" case and print an error message.
Additionally, don't add the fake property to the internal
cached_properties list or try to observe it. This avoids redundant
evaluate calls which will never actually succeed. We do still mark it
under watched_properties however. This avoids having to call
mp.get_property_native multiple times.
`io_close2` was introduced as a superior replacement for `io_close` in
ffmpeg 5.0, and then deprecated in 6.0. The difference is that
`io_close2` can return errors. In our case, we're just calling through
to the original function anyway, so we don't need to do more than pass
the return value back.
This is the latest stable release, and what we should use for
libplacebo-next per haasn's recommendation.
The previous 202 version wasn't even a release.
The playlist title only got set when it was specified in the playlist
file.
If there is a title after opening a file, that should also be reflected
in the playlist.
As it turns out that approach was suboptimal.
The playlist title would only ever get set when media-title actually
gets read, which depending on the configuration and usage might never
happen.
The next commit reimplements that feature in a different way.
This reverts commit 048d4d8b75 except for
the input.rst change.
It turns out that you actually have to add failure() to each condition
otherwise a default status check of success() is applied (thanks
github). Looks redundant but whatever. Thanks to @kasper93 for actually
reading the documentation.
This way we receive such minor details as the profile (necessary for
ARIB captions, among others) during init. This enables decoders
to switch between ARIB caption profile A and profile C streams.
They should not be modifying the argument, so clearly marking it
as const makes sure we don't do it in the future as well as allows
for read-only optimizations.
libplacebo v6.265.0 removed v4 deprecations. We already require
PL_API_VER >= 202, so we don't need to wrap
pl_tex_transfer_params.row_pitch around a conditional, which exists
since PL_API_VER >= 168. However, pl_source_frame.duration does not exist until
PL_API_VER >= 219, so we should use a conditional directive.
While adding fractional scale support, the coordinates for wayland
changed to always include the scaling parameter. The pointer stuff
actually did too. However, the check_for_resize function used the
unscaled, local surface coordinates. Likely, it was neccesary at the
time since wl->geometry used to report unscaled coordinates. In light of
that, we can just simply use mouse_x/y instead for this function to make
it work correctly with the right/bottom edges. mouse_unscaled becomes
completely unneccesary, so just drop it.
Some minor style changes included just because.
`xdg_toplevel_decoration` exists on SSD compositors independent of if
there is a border or not, so resizing didn't work on those.
Checking the border option makes more sense and also works on such
compositors.
Screenshots using the hardware renderer should now include color tags
that map directly from the libplacebo tags, so the if/else logic only
needs to be included once.
mp_trc_to_pl, mp_prim_to_pl, and mp_levels_to_pl have forward but not
inverse mappings. This commit adds mp_trc_from_pl, mp_prim_from_pl, and
mp_levels_from_pl inverse mapping functions, which just map the enums
in the other direction.
By making the data thread realtime it is able to serve requests faster
and more reliable reducing crackling in certain situations.
As the mpv callbacks that are running on the data thread are all
non-blocking and very short this should be safe.
The same mechanism is also used by pw-cat and the alsa plugin shipped by
pipewire.
In raw OTA MPEGTS, different programs can be entirely different virtual channels.
In web streams, different programs can be different variant bitrates,
so using streams from different programs can waste large amounts of bandwidth.
An error indicates that something doesn't work, but as long as a
safe url is available, playback is still expected to work.
Thus reduce logging level of MP4 DASH without fragments message and
add a new error message for when there is no safe url available either.
Also adds a missing space.
With dash the first fragment was always considered an init fragment if
there wasn't a duration. However that only makes sense when there are
also other fragments, so check if there are other fragments in addition
to the lack of a duration.
There is a very subtle race in vo that can manifest itself on pause
events. In the renderloop, render_frame, unsurprisingly, does the heavy
lifting of actually queuing up and flipping the frames. This is called
during normal playback. Sometimes various parts of the player can make a
redraw request which will latter trigger another render of the frame
later down in the loop (do_redraw). Because these requests can happen at
essentially anytime, sometimes the redraw request will happen *before*
do_redraw and it'll be caught in render_frame. When this happens,
the existing render_frame run works perfectly fine as a redraw so it
clears out the request which is sensible. Normally this is all locked of
course, but there's one catch. render_frame has to unlock itself when
propagating down into specific VOs/backends. That's what causes this
bug.
While render_frame is unlocked, other parts of the player can send
redraw requests which will cause in->request_redraw to become true. The
logic in the code always clears out this parameter after a successful
render, but this isn't correct. When in->request_become becomes true in
the middle of render_frame, there needs to be one more draw afterwards
to reflect whatever actually changed (usually the OSD). Instead, this
gets simply discarded. If you rapidly spam pause while rendering things
to the OSD at the same time, it's possible to for the last render to
be behind a frame and appear as if your osd event was ignored.
Once you realize what is happening, the fix is quite simple. Just store
the initial value of in->request_redraw before the unlock step. After we
do the render step and unlock again, only set in->request_redraw to
false if there was an initial redraw request. We just finished doing a
redraw, so it is safe to clear. Otherwise, leave in->request_redraw
alone. If it is initially false, then it will still be false and nothing
changes. However if it updated to true in the middle of the rendering,
this value is now preserved so we can go and call do_redraw later and
show what that last frame was meant to be when you pause. One
unfortunate thing about this design is that it is technically possible
for other internal things in vo to update during that unlocked period.
Hopefully, that doesn't actually happen and only redraw requests work
like this.
Fixes#8172 and #8350.
Instead of running the test directly in the build script, we can make a
separate step in the workflow so it looks a little prettier. For running
the actual tests, we skip mingw since they will never be run (cross
compiled). Additionally, improve the github workflow logic a bit so that
way logs on failure are only shown when that specific step fails. The
freebsd job still has to be less elegant since it's in a weird vm
thingy.
Not really related but the location of various build directories
(particularly waf) are corrected as well (might as well).
This reworks all of mpv's unit tests so they are compiled as separate
executables (optional) and run via meson test. Because most of the tests
are dependant on mpv's internals, existing compiled objects are
leveraged to create static libs and used when necessary. As an aside, a
function was moved into video/out/gpu/utils for sanity's sake (otherwise
most of vo would have been needed). As a plus, meson multithreads
running tests automatically and also the output no longer pollutes the
source directory. There are tests that can break due to ffmpeg changes,
so they require a specific minimum libavutil version to be built.
Since meson has its own unit testing system, let's rework mpv's tests so
they integrate nicely with this. To prepare for this, start off by
dropping the unittest option. Of course, this means that tests will no
longer be supported in the waf build at all but it will be dropped
anyway. Note that the tests option is preserved for the meson build. We
will still make use of this in the future commits.
A few formats were added recently, some were removed, and some flags
were changed. Maybe this should be better, but just update for now so
the tests stop failing.
There is no good reason to do so, both zimg and swscale supports full
range output. If downstream something expects limited range yuv always,
it needs to be comunicated in different way.
mpv's window resizing logic always automatically resized the window
whenever the video resolution changed (i.e. advancing forward in a
playlist). This simply introduces the option to make this behavior
configurable. Every windowing backend would need to implement this
behavior in their code since a reconfigure event must always be a
resize. The params of the frame changed so you either have to resize the
window to the new size of the params or make the params the same size as
the window. This commit implements it for wayland, win32, and x11.
This came up in #9828. According to the header comments, creating a 1D
ra_tex requires height and depth to be set to 1. For a 2D texture, it
requires depth be set to 1. There were a couple of spots in mpv's code
where this wasn't being followed. Although there was no known bug from
this, the rest of the code works like this so it was a good idea to go
ahead and sync it up. As a followup, let's just add some simple asserts
to ra.c to enforce this so it doesn't go unnoticed in the future.
These options make it possible to specify the directory that will be
passed to ass_set_fonts_dir(), akin to VLC's `--ssa-fontsdir` and
FFmpeg's `fontsdir`.
Fixes#8338
Which is wl->video_surface for vo_dmabuf_wayland.
Listening on wl->surface results in freezes if it is occluded and
culled by the compositor. Which mutter does, and the wl_surface::frame
spec warns about:
> A server should avoid signaling the frame callbacks if the
> surface is not visible in any way, e.g. the surface is off-screen,
> or completely obscured by other opaque surfaces.
ra_ctx_opts.want_alpha and vo_wayland_set_opaque_region's alpha
argument are only used as bool but both are ints. Particularly for the
function argument, passing a 0 or 1 is confusing - at first glance it
looks like you're specifying an alpha value of 0 or 1.
Since they're only used as bools, make them bools.
The console.lua check is still kind of dumb since we check an
environment variable to distinguish between wayland and x11, but
otherwise it should be better in theory.
This returns the value of the target OS that mpv was built on as
reported by the build system. It is quite conceivable that script
writers and API users would need to make OS-dependent choices in some
cases. Such people end up writing boilerplate/hacks to guess what OS
they are on. Assuming you trust the build system (if you don't, we're in
really deep trouble), then mpv actually knows exactly what OS it was
built on. Simply take this information at configuration time, make it a
define, and let mp_property_platform return the value.
Note that mpv has two build systems (waf and meson), so the names of the
detected OSes may not be exactly the same. Since meson is the newer
build system, the value of this property follows meson's naming
conventions*. In the waf build, there is a small function to map known
naming deviations to match meson (i.e. changing "win32" to "windows").
waf's documentation is a nightmare to follow, but it seems to simply
take the output of sys.platform in python and strip away any trailing
numbers if they exist (exception being win32 and os2)*.
*: https://mesonbuild.com/Reference-tables.html#operating-system-names
*: https://waf.io/apidocs/Utils.html#waflib.Utils.unversioned_sys_platform
ytdl_hook always set force-media-title, making users unable to force
a media-title via options.
To prevent that, check if force-media-title is already set to avoid
overwriting it.
A better solution would be to use tags like is already done for some
metadata, however that doesn't work when `all_formats=yes` is used.
See cbb8f534b0
A comment was added to hint at why it isn't done via tags.
ref.
https://github.com/mpv-player/mpv/pull/10453#issuecomment-1445277496
This refactors exec to only return the result of the subprocess command,
and makes the rest of run_ytdl_hook use the fields of this result,
because specifying all those return values multiple times is unwieldy
now that exec is called several times, and this is easier to read
anyway.
I removed the line
err = string.format("%s returned '%d'", err, es)
altogether instead of updating the es variable, because there was no
chance of it being executed since it would only happen when
result.killed_by_us is true, but run_ytdl_hook returns early when it is.
This reorders some code and checks the image track-list sub-property
instead of the albumart one, so that when playing audio without enough
playtime-remaining and images, the "autocrop only works for videos."
warning is logged instead of the "Not enough time to detect crop." one.
It also avoids repeating this warning twice in the code.
As of e16d0dd15d current-tracks returns a video track even when
lavfi-complex is used, so the track-list loop in is_cropable can be
replaced with just checking current-tracks/video while still cropping
videos with lavfi-complex.
Changing the CONF_TYPE_FLAG was a bad idea because mpv_node.u.flag
continues to be an int, leading to a mismatch in type sizes which can
lead to problems with memcpy().
ref. #11373
This partially reverts commit 17d91b9d4d.
The m_option_type_flag is still needed for the CONF_TYPE_FLAG
(next commit).
Add a comment that m_option_type_flag shouldn't be used.
ref. #11373
This partially reverts commit 07545657bf.
The playlist title only got set when it was specified in the
playlist file.
If there is a title after opening a file, that should also be reflected
in the playlist.
ref. #4780
For hwdecs without devices we can't get instant feedback during probing
whether the hwdec can possibly work or not, so we definitely want to try them last.
Independently this would also have solved the issue addressed by the previous commit.
This fixes an issue where mpv would try mediacodec (which may not
be available depending on Android version) and pick v4l2m2m next
which ends up failing even though mediacodec-copy would have been available.
c784820454 introduced a bool option type
as a replacement for the flag type, but didn't actually transition and
remove the flag type because it would have been too much mundane work.
This was originally dropped because it was thought to be unneeded at the
time, but at least some devices (rockchip) apparently are still on old
compositors that use linux-dmabuf v2. It's not much code, and for
testing purposes it's good to have around since it's hard to test
drmprime otherwise. Some minor additions are here to support the newly
added vaapi-format mapping in v2 of the protocol.
This reverts commit a5b9d529ee.
effort=4 has a significant increase in quality/bpp compared to effort=3
with a very minor increase in encoding time. It's worth the trade-off
as a default setting for lossy encoding.
Older versions of pipewire segfault when calling spa_hook_remove() on
hooks that are zeroed.
Add a backfill for the logic added by pipewire 0.3.57.
Being able to remove zeroed hooks makes errorhandling much easier.
See #11309
This allows the logic in `convert_image` to fast-path if the image
params are equal. Without this check, the image params are basically
never equal, because that path goes through `mp_image_params_guess_csp`
while the `mp_image` itself does not.
Force it here for consistency across VOs.
After commit c98e7353, we blindly pass the screenshot colorspace to the
image writer. But since we want to introduces the ability to save images
in HDR and other exotic formats, we should strip this for unsupported
formats.
See-Also: #10988
When taking window screenshots with a colorspace override, tag them
appropriately, based on the best-known colorspace info. Note that this
is imperfect, we should ideally also attach the output ICC profile if
one exists. But this is better than nothing.
Also force 1:1 PAR in this case. In all other cases, default to sRGB.
When taking an unscaled screenshot, always render to an unspecified
SDR-like space. (Subject to change) Apply output-specific options (ICC
profile, color space overrides, custom LUT) only in window screenshot
mode.
I decided to split this off from subsequent refactors because it is IMO
a bug fix deserving of its own commit.
Screenshots are currently always RGB. Subject to change, but needs to be
communicated clearly if changed. This commit is not a functional change,
it's merely for code clarity.
Based on the new upstream helper function `pl_map_hdr_metadata` and the
existing AV_FRAME_DATA_DYNAMIC_HDR_PLUS. This allows us to use SMPTE
2094-40 dynamic HDR tonemapping in mpv, albeit with the limitation of
requiring `--tone-mapping=auto` in order to pick this curve upstream.
PipeWire supports a global volume control for streams that works on top
of the per-channel volumes.
As mpv only supports a single volume with ao-volume it can make sense to
use the single global volume from PipeWire for it.
This allows the user to also specify per-channel volumes and not have
mpv trample over them.
This mode is not the default as pulseaudio does not support this
global volume control and all tooling controlling PipeWire via
pipewire-pulse (like pavucontrol) will not be able to see this channel.
The `osd-overlay` command didn't trigger a redraw when the overlay was
set to hidden.
This is fine when the overlay was already hidden before that, but
transitioning from not hidden to hidden requires a redraw.
This option is a bit obscure, but some people do use it and it can be
useful. The actual code that implements this is very simple, so there's
really no need to have a scary note in the docs about it possibly
changing or being removed.
3a9e661e92 officially made this video
filter deprecated roughly 6 years ago. Every other video filter in that
commit has actually been removed since then except for vf_sub. ffmpeg
does have its own subtitles filter, but it doesn't have the same control
over scale like vf_sub does. That's probably why wm4 never actually
removed it. Let's stop scaring users with a warning since this filter
probably won't ever get removed. Closes#9254.
With significant improvements to the color tagging support in various
screenshot formats, e.g. cICP in FFmpeg, and JPEG XL's generally robust
color support, it's safe to default this to yes.
As ao_pipewire is probed first if a user does not have PipeWire running
they will see a scary warning message even if another AO afterwards is
probed fine.
Tone down the error message so as not to confuse users.
The value of `sig-peak` is relative to the SDR peak. This is not
a problem when used inside the player, but the `HDR peak` in stats
should display human-readable information.
So change to return the actual nits value of HDR.
Closed https://github.com/mpv-player/mpv/issues/10127
Writing an image either with vo_image or with a screenshot will strip
the colorspace info because it allocates a new mp_image that contains
the same data as the old image after calling mp_image_params_guess_csp.
However, mp_image_params_guess_csp cannot always guess the appropriate
colorspace, so it picks a "sane default." Since this function also
changes parameters so the space always makes sense, this extra info
isn't harmful and allows screenshots and vo_image outs to be properly
tagged with the correct colorspace.
Fixes#10988.
Treat them as http:// and https:// respectively. This allows to play files
on webdav archives directly on KDE, avoiding the (extremely slow) local
copying performed by kio.
It turns out that there's a has_header check, and we should actually be
using that instead. We only care here if the header actually exists so
the pre-processor check is all that is needed. check_header depends on
what arguments the user passes among other things. That makes it more
complicated than necessary for our purposes.
Previously, this defaulted to yes and configure-bounds from the
compositor would always apply. In the case where the user explicitly set
autofit or geometry, this could be confusing because configure-bounds
would take precedence over it. Instead, let's add an auto choice and
make that the default. If we detect that the option is on auto and that
there is autofit/geometry being set, then ignore the event. This should
be more intuitive since someone who bothers to explicitly set mpv's
geometry would naturally expect that geometry to actually apply.
Semi-regression although this option never really did what the manual
said until recently. In the past, this option also controlled whether or
not mpv set the wayland buffer_scale to the value of the wl_output or
force it 1. This had varying effects depending on the exact compositor
configuration. That logic has now all been removed and this option now
only controls whether or not to scale the window with the hidpi scale
factor we get from the compositor. i.e. it actually does what the
manual says now.
Regressed from 879824a47f. The geometry
needs to be explictly recalculated now. Change up this function a little
bit also give it the ability to directly perform a resize after the
fact. This is a common workflow and we'll be using it in the next
commit.
This reverts:
3fb4140c lua/defaults: add user_data helpers
68a20e7a javascript/defaults: add user_data helpers
00510379 lua/js: fix user_data_del util function
As well as the lua/js parts of:
3ec2a098 docs: document new user-data property
user-data and its sub-properties can be set/get/observed/deleted
via the standard properties interface, so there's no need for
additional helpers specific to user-data, which only added maintenance
burden.
This will replace shared-script-properties in new usage. It can be used for all the same things, but is much more versatile.
Clients can create arbitrary sub-objects, and text expansion can access them.
For instance, if a script sets `user-data/my-script/property1` to "test", that value will be available by expanding ${user-data/my-script/property1}.
When building both cplayer and libmpv in the same build previously all
sources were built twice.
By reusing the objects from libmpv in cplayer we can thus save 50%
percent of the build steps.
ao-volume is represented in the code with a `struct ao_control_vol_t`
which contains volumes for two channels, left and right.
However the code implementing this property in command.c never treats
these values individually. They are always averaged together.
On the other hand the code in the AOs handling these values also has to
handle the case where *not* exactly two channels are handled.
So let's remove the `struct ao_control_vol_t` and replace it with a
simple float.
This makes the semantics clear to AO authors and allows us to drop some code from the AOs and command.c.
PresentNotifyMSC turns out to be not only redundant, but also harmful with
mesa-backed egl/glx/vulkan VOs because for all of them, mesa uses
PresentPixmap behind the scenes when DRI3 is available, which already
spawns a PresentCompleteNotify event when the buffer swap actually
finishes. This is important because without using the timing information
from these PresentCompleteKindPixmap events, there's no way for mpv to know
exactly when a frame becomes visible on the display.
By using PresentNotifyMSC in conjunction with DRI3-enabled mesa, two
problems are created:
1. mpv assumes that a vblank won't elapse (i.e., it assumes the current MSC
won't change) between the time when mesa enqueues the buffer swap and
the time when mpv calls PresentNotifyMSC to ask xorg for a notification
at the next MSC, relative to the current MSC at the time that xorg reads
it for the PresentNotifyMSC call. This means that mpv could get a
notification one or more vblanks later than it expects, since the
intention here is for mpv to get a notification at the MSC that the
buffer swap completes.
2. mpv assumes that a buffer swap always takes one vblank to complete,
which isn't always true. A buffer swap (i.e., a page flip) could take
longer than that depending on hardware conditions (if the GPU is running
slowly or needs to exit a low-power state), scheduling delays (under
heavy system or GPU load), or unfortunate timing (if the raster scan
line happens to be at one of the last few rows of pixels and a vblank
elapses just before the buffer swap is enqueued).
This causes mpv to have a faulty assumption of when frames become visible.
Since mpv already receives the PresentCompleteNotify events generated by
mesa's buffer swaps under the hood, the PresentNotifyMSC usage is unneeded
and just throws a wrench in mpv's vsync timing when xpresent is enabled.
Simply removing the PresentNotifyMSC usage from the egl, glx, and vulkan
VOs fixes the xpresent vsync timing.
This protocol is pretty important since it finally lets us solve the
longstanding issue of fractional scaling in wayland (no more mpv doing
rendering over the target resolution and then being scaled down). This
protocol also can completely replace the buffer_scale usage that we are
currently using for integer scaling so hopefully this can be removed
sometime in the future. Note that vo_dmabuf_wayland is omitted from the
fractional scale handling because we want the compositor to handle all
the scaling for that VO.
Fixes#9443.
This is in preparation for fractional scaling support. Basically, redo
all the coordinates in wayland so that wl->geometry is equal exactly to
what is being put out to the screen (no extra wl->scaling multiplication
required). The wl->vdparams variable is also eliminated for simplicity.
This changes mpv's behavior on wayland with hidpi scaling but that will
be addressed in more detail with the next commit.
For OpenGL, this is based on simply comparing GL_VENDOR strings against
a list of allowed vendors.
Co-authored-by: Nicolas F. <ovdev@fratti.ch>
Co-authored-by: Niklas Haas <git@haasn.dev>
--vd-lavc-dr defaulted to "yes", which caused issues on certain
hardware. Instead of disabling it, add a new "auto" value and
make it the default.
The "auto" choice will enable DR only when we can request host-cached
buffers (as signalled by the new VO_DR_FLAG_HOST_CACHED).
Co-authored-by: Nicolas F. <ovdev@fratti.ch>
Co-authored-by: Niklas Haas <git@haasn.dev>
Previously, if log-file was set not via a CLI option (e.g. set via
mpv.conf or other config file, or set from a script init phase),
then meaningful early log messages were thrown away because the log
file name was unknown initially.
Such early log messages include the command line arguments, any
options set from mpv.conf, and possibly more.
Now we store up to 5000 early messages before the log file name is
known, and flush them once/if it becomes known, or destroy this
buffer once mpv init is complete.
The implementation is similar and adjacent, but not identical, to an
existing early log system for mpv clients which request a log buffer.
A longstanding pain point of the drm VOs is the relative lack of state
sharing. While drm_common does provide some sharing, it's far less than
other platforms like x11 or wayland. What we do here is essentially copy
them by creating a new vo_drm_state struct and using it in vo_drm and
context_drm_egl. Much of the functionality that was essentially
duplicated in both VOs/contexts is now reduced simple functions in
drm_common. The usage of the term 'kms' was also mostly eliminated since
this is libdrm nowadays from a userspace perspective.
Core code should not use these features as it would mean that a libmpv
build could change an mpv executable and vice-versa.
Also changing one of them should not force a full recompile of the other
one through a change to config.h.
The libmpv feature should not have any impact on the built core code.
Otherwise a mpv executable compiled in a build together with libmpv has
different features than one from a build without.
The gl feature doesn't hurt, so always enable it.
This handle type was only needed for backwards compatibility with
windows 7. Dropping it allows us to simplify the code: there is no
longer a need for runtime checks, as the handle type can now be
statically assigned based on the platform.
The motivating usecase here, apart from code simplification, is a
desired switch to timeline semaphores, which (in the CUDA API) only
supports the non-KMT win32 handles.
It's worth pointing out that we need no runtime check for
IsWindows8OrGreater(), because the `export_caps.sync` check will already
fail on versions of windows not supporting PL_HANDLE_WIN32.
While the waf build has served us well for many years, it's time to
officially consider it deprecated. The meson build was added fully with
the intention to eventually replace waf and its current state is more
than good enough to do that. Let's start the deprecation period now to
give users a heads up to switch before we remove waf for good.
Currently filenames like `EP.1.v0.1080p.mp4` do not get sorted correctly
(e.g. episode 11 right after episode 1). That is caused by the `.` in
front of the episode number, making it get sorted as if it were
decimals.
The solution is to match the whole real number or integer instead of
matching the integer part and the fractional part separately.
This will regress sorting of numbers with multiple commas where the
length of the individual segments differs between filenames.
Since those are rather uncommon, that is unlikely to be a problem (for
anyone ever).
Officially, the most cursed part of the wayland code in mpv (third or
fourth try now?) This time, let's allocate a pool during init
(arbitrarily set to the maximum swapchain length mpv allows, 8; don't
even know if this actually works in wayland). Then we add/remove
feedbacks from the pool during the lifecycle of the VO, and clean it up
all at the end. Hopefully, this does the trick for good this time.
This ended up being a bad idea. The problem is that it introduces
ordering when destroying events (something we weren't worried about
before) and Lynne pointed out a problem with the callback not also being
destroyed before the surface in IRC. Just undo this and go with a
different approach (next commit). P.S. the wayland_dispatch_events name
change is kept though because I like that better.
This reverts commit aa8ddfcdf3.
I should have caught this during review but the feature was too cool and
I didn't really pay attention (sorry). For consistency with the rest of
the scripts here.
In debug mode the macro causes an assertion failure.
In release mode it works differently and tells the compiler that it can
assume the codepath will never execute. For this reason I was conversative
in replacing it, e.g. in mpv-internal code that exhausts all valid values
of an enum or when a condition is clear from directly preceding code.
The situation here is that HWND is always a 32-bit value but the
win32 API also accepts sign-extended values as valid. The trouble
starts when the numeric value is negative, as mpv ignores those.
Apparently this only happens after a while (related to uptime
or number of handles created), which meant this problem was rare.
addresses #10189
The only real reason this was ever supported is because it was
dramatically simpler than v4, so it was put in as an initial
implementation. Later, v4 support was added and we left v2 for
compatibility, but let's just drop it. Compositors all use v4 nowadays,
and v2 is significantly limited (no modifier support for example). It's
better to just remove this dead code for simplicity.
The watch-later mechanism has always unconditionally wrote start to
files to save the playback position. When this was later expanded to
watch-later-options, this logic was kept in place. But we don't actually
have to unconditionally write this and can allow users to remove the
option from the list if they want to. The start value still requires
some special handling; it should always be written if possible
regardless of the value changing. However, we can just place it within
the default set of options for watch-later-options so it can be removed
like any other.
So far there was no way to sync video to display and have audio sync to
video without changes in pitch.
With this option the audio does not get resampled (pitch change) and
instead the corrected audio speed is applied to audio filters.
Instead of choosing based on smallest deviation from set speed,
use the speed change from the smallest factor that does not
exceed `video-sync-max-video-change`.
Formatting the string on each comparison is wasteful.
Formatting strings beforehand and then comparing the already formatted
ones leads to a huge performance gain.
This was already returning true/false but the type was int. Also
simplify a few places in the wayland contexts where we can just return
the value of this function instead of doing redundant checks.
Instead of just returning true/false, it's better to have this function
cleanup itself. We can eliminate some redundant uninit calls elsewhere
in the code as well.
There's several functions that are used for initializing mpv on a
certain platform (x11, wayland, etc.). These currently are all int, but
they actually return 1 and 0 like a boolean. This gets a bit confusing
because actual vo preinit functions return 0 and -1 instead. Just make
these all bool instead and return true/false to make it clearer.
vk->surface is a handle and not a pointer, so assign VK_NULL_HANDLE.
This fixes the following build error on 32bit Windows when using clang for example,
which errors out when assigning a 32bit pointer to a 64bit integer:
../mpv-0.35.0/video/out/vulkan/utils.c:37:21:
error: incompatible pointer to integer conversion assigning to 'VkSurfaceKHR' (aka 'unsigned long long') from 'void *' [-Wint-conversion]
vk->surface = NULL;
^ ~~~~
This allows us to rebuild the manpages and html documentation only when
necessary. It is not necessary to manually keep the list of dependencies
up to date.
Unfortunately rst2pdf does not yet support this feature, see
https://github.com/rst2pdf/rst2pdf/issues/1108
In `new_demux_packet_from`, we initialise a new packet and allocate a
buffer which we copy the source data into. But I was then assigning
the original source pointer as the packet's buffer, rather than keeping
the newly allocated one. Whoops.
Without this change the same track encoded as Opus - which requires R128
tagging - and e.g. Vorbis with ReplayGain tagging have different volumes.
This is caused by ReplayGain 2 having a higher reference level of -18 dB
LUFS, while EBU R128 has a lower reference level of -23 dB LUFS.
For the results of gain application to match, the read EBU R128
values need to be boosted according to the difference in reference
levels.
Patch inspired by mpd's source code.
Similar to some other issues we've had with unprocessed compositor
events. When quitting mpv, there's two things we should be doing:
dispatching any last minute wayland events and then waiting for a
compositor reply. Luckily, there's already an internal helper for this
(renamed to wayland_dispatch_events for consistency) that we can use.
All of the special casing of wl->feedback becomes unneccesary and we can
remove this from vo_wayland_state with this method. Fixes#110022.
In the event of a failed wayland initalization, the display_fd is
actually 0 instead of -1 which would correctly indicate it doesn't
exist. Also move the fd check inside vo_wayland_dispatch_events since
that function shouldn't ever do anything if we don't actually have a
display fd.
We have a use_present bool that keeps track of whether or not to use
presentation time. However, the creation of the feedback listener
actually wasn't checking this and was instead checking for the existence
of wl->presentation. There's no point in always creating the
listener and feedback if mpv isn't actually going to use it. Just change
it to use_present instead.
e97819f88e corrected a special case
condition that lead to an out of bounds access if the total width
happened to be an integer multiple of SLICE_W (256) which could cause a
crash in software VOs. However, it turns out that the functions in this
file evaluate quite differently when using encoding mode (and presumably
libmpv as well according to reports although I could not independently
verify it).
The logic here gets complicated but what ends up happening is that, in
blend_overlay_with_video, the value of x + w can be greater than p->w in
certain cases in encoding mode. The x is the positional value of the
slice which remained unchanged from before, but w can take the full
value of SLICE_W (256) which is not necessarily correct. The width of
the final slice here should be the total remaining width. We can handle
this in mark_rect by simply always adjusting x1 of the last slice to be
equal to total width - SLICE_W * x so it can never extend beyond where
it should be. In practice, this value should be the maximum allowed
here. I'm not sure if the existing x1 value can possibly already be
lower than SLICE_W, but just MPMIN it to be on the safe side.
Fixes#10908.
[motivation]
Seeking on MacOS appears to be lagged when users connect
to wireless audio output (airpods for example).
This commit attempts to fixmpv-player/mpv#10270
[observation]
1. When using other media player (VLC to be exact) simultaneously,
the lagging on seek disappear. We could guess that the AudioDevice
is on some sort of "warm-up" state.
See mpv-player/mpv#9243 for detailed description.
2. `AudioOutputUnitStart` takes significant longer time after each seek
or pause/play when using wireless output devices compares to wired devices.
[rationale]
After investigate codes in ao_coreaudio.c, it appears that the the `stop`
function was used as `ao_driver.reset` function. Therefore every seek
and pause would call `AudioOutputUnitStop`.
It turns out that `ao_driver.reset` function is used in `ao_reset`.
And `ao_reset` function is used to clean up the state of current `ao`
so I think `AudioUnitReset` is more proper than `AudioOutputUnitStop`
under this semantics.
Since ao_coreaudio use pull base mechanism, audio playback behaviors
upon pause/seek could be handled by callback function
(streaming silence when paused) so there is no need to stop AudioUnit when resetting.
Therefore using `AudioUnitReset` as `ao_driver.reset` looks proper.
Additionally, after using proper reset, the AudioUnit that represents
hardware I/O devices doesn't need to be restart everytime seek/pause actions happen.
Restarting wireless devices simply takes longer in MacOS which is
the root cause of lagging observed by users when they seek or pause/play media.
[method]
Use `AudioUnitReset` for ao_driver.reset.
This change enables mpv to work in the WSL2 (WSLg) environment where
OpenGL is implemented on top of D3D12.
This reverts commit 149d98d244.
Mentioned OpenGL implementation (GDI Generic) in the original change
will be rejected by version check, so there is no need to handle it
manually.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Buffering ahead nonstop into the cache results in nonstop disk or network
activity to read stream data from wherever it may originate. Currently,
there's no way to configure the demuxer to back off once it's buffered
ahead enough data, since the cache limit will be perpetually not-reached as
a stream continues to play, until the entire stream is eventually buffered.
On a laptop with an i9-12900H with decoding performed by the iGPU,
watching a locally-saved 1080p video which hasn't been buffered into the
page cache consumes approximately 15 W even with caching enabled. When
configuring a hysteresis to make the demuxer back off, power consumption
drops to 9 W when watching the same video, resulting in a whopping 6 W of
power savings.
To make it possible to attain significant power savings via caching, add
a --demuxer-hysteresis-secs option to configure a hysteresis to make the
demuxer back off until there's only the configured number of seconds
remaining in the cache from the current playback position.
This feature is disabled by default.
mpv currently only recognizes jpg and png files named "AlbumArt",
"Album", "cover", etc. which are in the same folder as the audio files
as album/cover art and displays it when playing such audios.
This feature adds support for webp files following the same naming
scheme to be displayed as cover art for albums who have them.
Webp variations are lower in priority compared to jpg or png files.
Resolves: #11006
Since the modesetting driver now has TearFree support with integration into
xpresent, it's important that xpresent is used with the modesetting driver
to get the correct vsync timing when a frame is delayed by one vblank
interval due to a pending page-flip enqueued by a different entity. The
modesetting driver ensures that the xpresent extension reports the correct
presentation timing when TearFree is used; mpv just needs to listen to it.
Add the modesetting driver to the xpresent whitelist so mpv can get the
correct presentation completion timing when modesetting TearFree is used.
This is also helpful for when xpresent performs page flips directly in the
modesetting driver and a natural delay in the display pipeline causes a
page flip to be delayed by one vblank interval or more.
In the previous change, I replaced the callsites that used
`av_init_packet`, but there are a handful of places that use stack
allocated packets with no initialisation.
In one case, I just switched to heap allocation as it's only done once
per stream at most.
In the other case, I removed our usage of the AVPackets as a
convenience mechanism to transfer data into a heap allocated packet.
Instead, I inlined the data copying.
When a pull AO reaches reaches EOF then ao_read_data() will set
p->playing = false.
Because the ao is marked as not playing ao_set_pause(true) will not
reset the AO.
This keeps the output stream unintentionally open.
Fixes#9835
See https://sw.kovidgoyal.net/kitty/graphics-protocol/
This makes no attempt at querying terminal features or handling
terminal errors, as it would require mpv to pass the response codes
from the terminal to the vo instead of interpreting them as
keystrokes made by the user and acting very unpredictably.
Tested with kitty and konsole.
Fixes#9605
We ask users to freely share log files with us, which is usually
okay, unless a user has some unrelated and potentially embarrassing
files in their working directory. These would show up in the debug
level message output that --log-file enables.
Change the listing of potential external files to trace log level,
to save the users and the developers the embarrassment.
This new hwaccel flag was added to allow us to request that an hwaccel
decode not implicitly copy output frames before passing them out. The
only hwaccel that would implicitly copy frames is nvdec due to how it
has a small output pool that cannot be grown very much. However, we
already copy frames as soon as we get our hands on them (in our hwdec)
so we're already safe from pool exhaustion, and the extra copy doesn't
help us.
H264 hardware decode with v4l2m2m wasn't working on the RPi 4. Mpv would
report the image format (yuv420p) wasn't supported. The change to
hwdec_drmprime.c is to explicitly say that the format now is supported.
The change to dmabuf_interop_gl.c is to specify the colour format of the
planes before generating egl images. These changes were tested on a Pi 4
with this fork of ffmpeg: https://github.com/jc-kynesim/rpi-ffmpeg.
Signed-off-by: EmperorPenguin18 <60635017+EmperorPenguin18@users.noreply.github.com>
currently only supported on x11.
one practical use-case of this is wanting to embed something (such as
dmenu) into the mpv window to use as a menu/selection. there might be
other use-cases as well (e.g doing some shenanigans with `xdotool` or
whatnot).
it's currently possible to:
* listen for 'current-window-scale' change (to check if the
window has been created or not)
* call an external tool like `xdo` or `xdotool` and grab the xid
from mpv's pid.
however it adds unnecessary dependency on external tools when mpv is
fully capable of easily providing this information.
closes: #10918
This has been a long standing annoyance - ffmpeg is removing
sizeof(AVPacket) from the API which means you cannot stack-allocate
AVPacket anymore. However, that is something we take advantage of
because we use short-lived AVPackets to bridge from native mpv packets
in our main decoding paths.
We don't think that switching these to `av_packet_alloc` is desirable,
given the cost of heap allocation, so this change takes a different
approach - allocating a single packet in the relevant context and
reusing it over and over.
That's fairly straight-forward, with the main caveat being that
re-initialising the packet is unintuitive. There is no function that
does exactly what we need (what `av_init_packet` did). The closest is
`av_packet_unref`, which additionally frees buffers and side-data.
However, we don't copy those things - we just assign them in from our
own packet, so we have to explicitly clear the pointers before calling
`av_packet_unref`. But at least we can make a wrapper function for
that.
The weirdest part of the change is the handling of the vtt subtitle
conversion. This requires two packets, so I had to pre-allocate two in
the context struct. That sounds excessive, but if allocating the
primary packet is too expensive, then allocating the secondary one for
vtt subtitles must also be too expensive.
This change is not conditional as heap allocated AVPackets were
available for years and years before the deprecation.
Now that 0.35 has been released, we can consider increasing our minimum
required ffmpeg version. Currently, we think 4.4 is the most recent
version we can move to (from the current requirement of 4.0).
This allows us to remove a few conditionals. There are more that we
won't be able to remove unless we move further up to 5.1.
8300830951 rearranged/simplified some of
the wayland touch code mainly because what was there before was
completely broken on my machine in those days (dragging was unreliable,
resizing was really buggy, etc.). However, one user said that touch
input no longer worked for him after that change. I could not ever
reproduce it, but it seems the issue was putting down the key before
testing for resize/move in the code. Now who knows why this actually
matters, but apparently it works for the user in question and I don't
observe any unexpected behavior on my end when swapping the order. Like
the mouse/pointer code, we also now do a test for dragging before
actually trying a resize/move which is a little more consistent than
before. Fixes#9771.
Not sure when this actually started happening, but it's probably been
like this for years. Currently, the logic for the window-controls works
by simply checking if the osc is visible and then either enabling or
disabling the associated keybindings. The problem is that this can just
constantly spam mp.enable_keybindings/disable_key_bindings on every
single render call if the user disables the border at any point in time.
This does a lot of pointless work and also results in the logs being
spammed with lines like "disable-section". Clearly, this should just
work like the code for checking the input keybindings just above it.
Keep track of an internal state variable and check when it doesn't match
the osc visibility. In that case, we can then either enable or disable
the key bindings and just update the variable.
This allows us to more easily see the datapath from mpv to pipewire.
We know how often the callbacks are triggered, how big the buffers are
and how much data mpv provides to pipewire.
Flushing the cache is a hammer-for-a-screw operation, because it nukes
*all* renderer state, including the HDR peak detection state. When
enabling e.g. --hdr-compute-peak, or any other future methods of dynamic
tone mapping, this would lead to bad results (e.g. brightness
fluctuations) whenever the OSD state is updated.
Instead of flushing the cache to force an OSD re-render, instead just
update the frame signature directly whenever its osd_sync value changes.
This accomplishes effectively the same thing but without touching the
HDR state.
This is slightly violating the libplacebo abstraction in a way that
isn't publicly documented. To be on the safe side we could make a carbon
copy of the array before modifying it, but given that this is unlikely
to change upstream I'll probably just end up explicitly documenting it
instead of forcing the copy in mpv.
BSDs use compiler-rt instead of libatomic for atomic types. In this
case, we can handle it similar to how dl is detected. Check for the
library (allowing for it to fail), and then check for a header symbol
while linking latomic. Fixes#10906.
Currently, the lcms-related options are only defined when lcms2 is
enabled at build time. However, this causes issues (e.g. segfault) for
vo_gpu_next, which relies on the presence of these options (to forward
them to libplacebo).
(That libplacebo internally depends on lcms2 as well is an
implementation detail - compiling mpv *without* lcms against libplacebo
*with* lcms should be possible in principle)
Fixes: #10891Closes: #10856
The new single-pixel-buffer protocol is designed to optimize the case
for using a solid color as an underlay wl_surface. It works the same as
the wl_shm 1x1 pixel trick currently used, but it allows the compositor
to make optimizations with more certainty than the wl_shm trick.
This was previously implicitly included by the order of headers in
vo_dmabuf_wayland.c, but it is better to make it an explicit and reorder
the headers properly.
Meson uses the sysconfdir option for setting the global config
directory. This conveniently defaults to /etc if the prefix is set to
/usr which is nice for linux distros. BSDs tend to use /usr/local which
causes this value to become 'etc' by default which is not an absolute
path so you would need to set something like -Dsysconfdir=/usr/local/etc
as well in the configuration step. It turns out we can have our cake and
eat it too by just joining the paths of prefix and sysconfdir together.
In the case where -Dprefix=/usr, this still results in /etc/mpv as the
path since the path joining logic just drops the leading '/usr/'. For
the /usr/local case, it ends up as /usr/local/etc/mpv as expected. This
fixes#10882.
When the alpha channel is the first component, this code block gets
skipped by the continue, meaning the check for c==0 never passes.
Fix it by explicitly keeping track of whether bits have been set.
The legacy DRM API adds some complexity to the DRM code. There
are only 4 drivers that do not support the DRM Atomic API:
1. radeon (early GCN amd cards)
2. gma500 (ancient intel GPUs)
3. ast (ASPEED SoCs)
4. nouveau
Going forward, new DRM drivers will be guaranteed to support the atomic
API so this is a safe removal.
The content-type protocol allows mpv to send compositor a hint about the
type of content being displayed on its surface so it could potentially
make some sort of optimization. Fundamentally, this is pretty simple but
since this requires a very new wayland-protocols version (1.27), we have
to mess with the build to add a new define and add a bunch of if's in
here. The protocol itself exposes 4 different types of content: none,
photo, video, and game.
To do that, let's add a new option (wayland-content-type) that lets
users control what hint to send to the compossitor. Since the previous
commit adds a VOCTRL that notifies us about the content being displayed,
we can also add an auto value to this option. As you'd expect, the
compositor hint would be set to photo if mpv's core detects an image,
video for other things, and it is set to none for the special case of
forcing a window when there is not a video track. For completion's sake,
game is also allowed as a value for this option, but in practice there
shouldn't be a reason to use that.
mpv's core already keeps track of whether or not it thinks a track is an
image. Some VOs (i.e. wayland) would benefit from knowing if what is
currently being displayed is an image or not so add a new VOCTRL that
signals this anytime we load a new file with a VO. Additionally, let's
add a helper enum for signaling the kind of content that is being
displayed. There is now MP_CONTENT_NONE (strictly for force window being
used on a track with no image/video), MP_CONTENT_IMAGE, and
MP_CONTENT_VIDEO. See the next commit for the actual usage of this (with
wayland).
mpv has an internal optimization on a couple of platforms where it will
not render any frames if the window is minimized or hidden. There's at
least once possible use case for wanting to force a render anyway
(screensharing with pipeware) so let's just add a simple switch for
this that always forces mpv to render. Closes#10846.
Related issue: #10868. While most protocols are in theory optional, a
small amount of them are absolutely essential and nothing will work
without them. We should make sure to error out in those cases and not
try to actually do anything. For wayland support in general,
wl_compositor support is obviously required. If there is no wl_surface,
you can't do anything. Additionally, vo_wlshm quite obviously requires
wl_shm so mark that one as well. vo_dmabuf_wayland needs linux_dmabuf,
viewporter, wl_shm, and wl_subcompositor. In practice, these are all
very standard protocols and shouldn't be missing but the linked issue
above is at least one example where a compositor was stuck on an ancient
version of a wayland interface.
Loaded 100 of 383 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
sfan5