The software renderer backend is not capable of using any of the VO
capabilities set globally by vo_libmpv. This can lead to assertion
errors when trying to render a video with 90 degree rotation metadata.
Instead use the ctx->renderer->driver_caps value so the source frame
doesn't have its params rotated when it's not desired.
Ideally we would properly log this with mp_log but the plumbing for that
was deemed too ugly and not really worth it for just this one mysterious
edge case. So instead, drop the fprintf business since we really
shouldn't be doing that.
If we are redrawing on a still image (e.g. ass events), then the pl
queue will hit the PL_QUEUE_MORE case which is fine but there's no need
to spam the log here. The information may be useful for when an actual
video is being played, but when a frame is still (e.g. paused or only a
single image) it's just noise.
Fixes#17840.
We have this annoying situation here during the initial window
configuration where sometimes we have to update certain values and other
times they need to be ignored. 45324ce682
made sure to parse the toplevel state before we checked the initial
compositor values which is correct. But it's not enough because mpv can
have its own initial state (e.g. --fullscreen) and by moving it here it
would get overwritten in the toplevel state check and thus ignored. So
to have our cake and eat it too, we need to only update the internal
state values if we know mpv is in a valid state in the first place. So
either we've set the initial geometry already or the compositor has
given us some specific initial state to work with. Fixes#17819.
Previous commit fixes the issue when doing state changes but I never
actually tested just normal reconfigs (i.e. advancing a file in a
playlist). Override it in this case too. Fixes#17755.
If the window is fullscreen or maximized and the user sets some geometry
or window scale, we should apply it when the state transitions back to
windowed mode. This was being missed and the surface local coordinates
were being used.
We don't want to be using the coordinates from the compositor in this
case since it can't know that the new surface has a totally different
aspect ratio. Also remove the early return so that the state is always
updated regardless if it's determined we need to resize or not.
Fixes#17710.
Since 1301fdb2ec we try to directly use
surface local coordinates however it is valid for compositors to send us
0s in either the width or height. In that case, it means mpv should
choose its geometry so we should calculate out our own coordinates.
Previously this was incidentally handled, but we should be more explicit
here and set the bool.
There's no way this coordinate can ever work so don't force callers to
waste time checking for it, so just MPMAX at 1. Fixes a crash in certain
cases if you do --autofit=1x1.
Using vo_vaapi has already been heavily discouraged for years since
years since 5c313f1f59. More importantly,
it's just fundamentally broken on most hardware, serves no real purpose,
and well we shouldn't just ship broken stuff. vo_vaapi largely only ever
worked correctly on some intel hardware. The VO relies on certain API
calls that other vendors never implemented so things like the OSD and
subtitles are just never going to work. This largely has no reason to
exist either. If you're looking for efficient playback, you can use
vo_gpu/vo_gpu_next in dumb mode with vaapi decoding. You can also use
vo_dmabuf_wayland with vaapi as well to avoid even more GPU to CPU
copies and theoretically be even more efficient.
Previously, we calculated out the value for simplicity but there can be
a mismatch due to round where what we calculate as the viewport
width/height is not what surface local coordinates the compositor gave
us. Note that we don't always want to use these values directly (e.g.
whenever we set our own geometry), so some notion of overriding has to
be added.
Decoupling fullscreen behavior from the generalized border logic
increases the complexity and also inherently changes the behavior in a
way that is not neccesarily desirable. People in IRC notably were
confused about the window controls not being shown in fullscreen because
of this change. We could default the option to yes, but then there will
likely be people confused as to why they suddenly now have the controls
when it wasn't there previously. The best way to avoid all this is just
undo it. If someone wants special fullscreen behavior with
windowcontrols, this can be done with auto profiles already. There's not
much utility in having a separate option.
This reverts commit 3b66428152.
Depending on the state being true before advancing through frames works
but it's error prone and leads to various edge cases you have to account
for (e.g. like 339ac9b305). It's better
invert it so that setting color management is the special case that sets
the boolean to true to stall the playloop. The logic can then be
simplified, and the vo_wayland_handle_color call is moved up to be
directly after we create the buffer.
Anything related color management gets complex and there is a lot of
platform-specific code that gets called in relation to this. Currently,
this stuff gets called in various places in the render loop which mostly
works but it's prone to "off by 1 frame" errors and also isn't clean.
Introduce this helper to hopefully unify all this kind of stuff under
one umbrella. For integration with vo_gpu_next, this needs to be called
before flip_page and we should stop abusing target_params for this
purpose. The next couple of commits will implement this in two places.
For the drm context, we can use the target_csp so vo_gpu_next knows what
colorspace to output to. We just need to be sure the monitor is able to
display bt2020. For now, all we detect on the EDID side is either pq or
hlg so ensure at least one of those works before we send back something
to vo_gpu_next to use for target_csp.
This was originally added way back when specifically for drm so it can
play nice with libplacebo for HDR. This is pretty ugly though and a bit
hacky. There's a better way to integrate this with target_csp. So drop
the pass_colorspace stuff in this commit and we'll change the
implementation in the next commit.
Scripts and things using the client API can load up playlists in a
specific order and choose what file to start playing on by using the
loadfile or loadlist commands with the play argument. However if
starting from idle mode, it is possible to send these commands before
all scripts finish initializing. mpv's core then does a prepare_playlist
call on its own for startup which will nuke the current playlist entry
set by the API user and lead to an unexpected item being played. Fix
this by not unconditionally setting pl->current to NULL allow callers to
optionally always overwrite it by getting the first item in the playlist
(e.g. if it's called after startup anywhere else in the code). Other
options like --playlist-start or --shuffle are allowed to win if they
happen to be set.
If you switch TTYs while mpv is playing, wlroots compositors will remove
all outputs from the registry. This segfaults when you switch back since
we try to access cleared memory. Rework this so wl->current_output is
given null when appropriate and properly guarded. You still need at
least one output to initially place the surface, but in general they can
all disappear during runtime and it should work. Change the log to
verbose because that becomes just noise in this case (switching TTYs).
The surface entrance event happens later and should get all the proper
parameters.
27a78276eb almost got it but it should be
an and condition not an or. When we unlock VO to draw the core, the OSD
can update after we flip the page and the player can also pause itself
in that time. That means that we will clear the redraw request but due
to the OSD update it actually needs to draw again. Because the player
paused itself in that time frame, this redraw gets lost and you have the
mismatch. The simplest way to avoid that case is to only clear the
redraw_request while mpv is playing. The paused case will always get
handled later in do_redraw so it does not get missed. The slight
downside is that it's technically possible to do a redundant redraw
(e.g. what if you pause before draw_frame), but this theoretical
inefficiency is deemed not really relevant or important enough to add
more confusing code to avoid. Fixes#17288.
730062b510 fixed the problem with mouse
buttons but unfortunately we forgot to include repeated commands in the
condition. This effectively made any variant of "frame-step X seek"
unrepeatable even though it was supposed to be. So just allow those in
add_step_frame too.
Fixes#17348.
Commits 8854c74271 and
5ae0e0ff9a eliminated the external
swapchain API that the render backend (vo_libmpv) was previously using.
However, it was missed that this was being used to skip the
gl->FenceSync calls and that logic change was not properly accounted
for. This meant that vo_libmpv would leak fences since
ra_gl_ctx_swap_buffers is never called to clean them up.
Fix this by making sure the ra_ctx_params have swap_buffers defined
before calling gl->FenceSync. All platforms are required to implement
this anyway with the exception of vo_libmpv since it's a funny special
case. Fixes#17217.
It's a pretty niche case, but if you start a file with no video with
animated ass subtitles and then turned on the video later, the subtitles
would not actually be rendered animated. This because the subtitles were
already decoded, and we do not do a check for animations expect in the
specific case of an image being played back on the video since the check
can be quite expensive. To fix this edge case, we just need to reset the
ass before doing the track switch in the case where we go from no video
to a track that's an image. SD_CTRL_RESET_SOFT is added as a a sub_ctrl
to accomplish this. Fixes#17268.
This is essentially for vo_dmabuf_wayland, but there is a race condition
during initialization where we should wait on an event from the
compositor to set the appropriate description for the image (namely for
color management) before flipping the page. Previously, there was an
off-by-one frame difference which resulted in the initial frame not
being appropriately color managed. Fix this by telling the core render
loop that it is not ready for the next frame. This keeps the frame queue
from advancing and allows the backend to process events appropriately
until it signals that it is ready.
It's the future and well contributions of this nature aren't going to
disappear. Might as well address it in the contribute.md hope that maybe
a would-be vibe coder out there does a slightly better job before
sending anything our way.
We should have done this ages ago. These commands essentially consist of
a combination of a load action and whether or not playback should be
started. The old `-play` aliases are kept for backwards compatibility.
When this was originally implemented, there was a dependency on waiting
for certain events from the compositor so it was placed after the
original roundtrip. Since b3abe3975b
removed the need for most of these conditions, we can more logically
place the creation of the color_surface and color_surface_feedback
earlier in the process and leave the wl_display_roundtrip as the true
final call for the wayland init process.
Sometimes the VMs that these run in spin forever so it's good to have
some timeout. 30 minutes is way longer than what we need. When these are
successful, they complete in under 10 minutes (especially freebsd which
is very fast). If we're at the 15 minute mark, the VM is stuck spinning
forever so just abort.
This is mainly for better, more descriptive logging when something goes
wrong and fails. Common operations that manipulate properties and
commands go through shared functions that do better detailed logging.
Also it means we don't need check_api_error around anymore so get rid of
that. libmpv_lifetime is left untouched since that one is a bit special
and works a little differently.
c958990833 was supposed to implement this,
but it got forgotten and the placeholder code which just
created/destroyed every buffer for every frame was left. Oops. Finally
fix this a couple of years later.
Fixes#16863.
There is some race condition where MPV_EVENT_PROPERTY_CHANGE sometimes
gives us sub-text with an empty string which is unwanted and causes the
test to fail. Avoid this by starting the file at 1 second and paused
which hopefully avoids this. Do some additional checking on the actual
MPV_EVENT_PROPERTY_CHANGE as well to make sure we don't try to read
something we shouldn't.
xdg-user-dirs is basically the standard for defining user desktop
directories on linux/bsd. To account for locales and languages, we
basically have to parse the config file (~/.config/user-dirs.dirs)
directly. That or call xdg-user-dir. Either way, it's a little more
complicated than the others, but still doable enough.
It would be nice to expand all path arguments for free in the option
code, but life isn't so simple. Because of string list options, we have
to expand at parsing time. Because of libmpv, mpv_global has to be
passed around a million places. Even after doing all that, there's still
a drawback where anything defined in builtin.conf (used for setting
default profiles and such) will be unable to correctly resolve paths if
the user uses --config-dir. Nothing currently defined in builtin.conf
would be subject to that and it's not likely that anyone would add
anything that would be, but it's a limitation that can't be changed
because this has to be parsed before the user's command line and before
mpv_global is set. There's also another problem of pretty printing paths
which are now always full paths instead of relative ones. It's not so
nice if the user's home path is something very long. This could be dealt
with by saving an unexpanded path in some field in the opt somewhere and
then doing that for pretty printing but with all this extra
complication, it's questionable if there's really any net gain at the
end of the day. Calling mp_get_user_path on some opt->whatever is a lot
simpler and always works. So this commit goes back to the old model
along with the following reverts/reapplies.
This reverts commit 9b7374ea40.
These functions could be useful for any libmpv test and in fact
check_string was already duplicated in a couple of places. Inline them
in libmpv_common.
This lets users specify any possible pair of characters to remote text
from in the SDH filter as opposed to the old way which would
automatically map ( to ) internally.
Additionally, this fixes#16597 because the old implementation relied on
looping over a single string using strlen for matching chars. That
doesn't work because strlen loops over bytes and non-ASCII characters
can have multiple bytes leading to false positives since the bytes could
match. There's various ways to deal with this, but simply using mpv's
internal stringlist type sidesteps that problem.
There's no reason for the string to live forever for the lifetime of
mpv. We can free it when we're done. Calling the current-watch-later-dir
property could technically grow memory forever previously.
Since the option system now handles all the path expansion
automatically, these recent changes can be reverted for simplicity.
This reverts commit be15be3a83.
Because the previous commit started using mp_get_user_path in core
m_option files, various tests failed with undefined references due to
these two files not being included. Add them to the common list of
test_utils files.
Unfortunately, I've already done most of the legwork on expanding paths
manually in the code everytime we encounter one of these options, but it
is completely possible to do it during the option parsing/copying. All
option value setting should go through m_config_set_option_raw at some
point, so this is a good target place to put this logic. Additionally,
the M_OPT_FILE flag already exists for any option that is meant to be
have path values as arguments, so we just needed to add an m_option
method to do this. Fundamentally, this is exactly the same as
m_option_copy except that we potentially expand the value string. A new
expand function pointer is now added and we implement it for the two
option types where this is relevant: OPT_STRING and OPT_PATHLIST.
Furthermore, a m_option_copy_and_expand wrapper is added to handle which
function pointer should be used. With this change, this means that all
path values located in any opt->value pointer should automatically be
expanded and users of the value no longer have to manually do this
themselves. Of course, that means that there's now a ton of redundancy
in the code that can be eliminated. That will be cleaned up in the next
commits.
38ad1ed03b was supposed to normalize all
path names, but the path from the libarchive demuxer works differently.
We need to normalize it within the demuxer itself so you get something
like "archive://<absolute path to archive>" in the property.
Fixes#16247.
During the original PR, that was true but mp_normalize_path was changed
in 0755edb327 to allow NULL talloc_ctx.
Deleting the comment was forgotten since it was never true when the
commits were merged, so do it now.
This code got shuffled around over the years but fundamentally it was
first introduced in 2c22fcd350 to fix a
parsing issue with specifically the af and vf options. Syntax like af*
and vf* used to be valid and this was part of dealing with that case.
Later 50008adf4a completely changed this
and ripped out support for the wildcard behavior. But these few lines to
deal with the special case were never removed. The token splitting has
been unnecessary for years and is confusing, so clean this up and
finally remove it.
Like the previous commit, this has a conditional that matches exactly
what this helper function is supposed to do. For logging reasons, we
can't completely remove the val->format comparison, but it can be
simplified to be cleaner.
There is a usage of m_option_parse which exactly mirrors the intention
of the helper function m_option_set_node_or_string. Instead of
duplicating the logic, just call the m_option_set_node_or_string
instead.
It's easier for potential callers of this to convert char to bstr than
vice versa. Internally, the function uses bstr anyway so just eliminate
the conversion and let callers do it. The next commit will add another
caller of this where the bstr param is preferable.
This probably didn't do anything previously, but technically SDR
transfers could theoretically have HDR metadata and we would set them.
This isn't worth supporting so skip this step for SDR.
1a70de259d added some sanity checking to
these values to avoid throwing a protocol error (which are fatal) since
the wayland protocol is very strict about the ranges of these values.
Let's tighten up the checks just a little bit to be on the safe side. If
the min_luma is not less than max_luma, consider this a hard error. We
won't set any hdr metadata at all if this happens. For max_fall and
max_cll, we leave mostly the same as before where the value gets set to
0 if it doesn't pass the wayland protocol specification. For the case
where max_fall is greater than max_cll, consider this invalid and set
both values to 0.
0ab3184526 introduced most of the stuff
being removed here. The idea is that when doing encoding the core should
wait until everything is initialized. This is true, but the old
implementation is overly complicated and confusing. What we need is for
both the AO to be initialized and the VO to be reconfigured for encoding
to start. Because of the way initialization works, the VO reconfig
always happens first. Changing the order in playloop would of course
break this assumption, but we can trust that nobody would arbitrarily do
that. So all that needs to be done here is that write_video should wait
until the AO is up before pushing frames. And that only applies in
encoding mode and if there is a selected audio stream in the first
place. This is a simple check.
With that in place, all of this extra junk can be dropped. We don't need
special booleans or events for the simple task of making sure the AO and
VO are both up.
fd4e3af740 originally started installing
it, and we've been doing it ever since then. The value of having all of
these encoding profiles predefined by default is pretty dubious since a
lot of them are pretty old ('MP4 for Nokia N900' being a shining
example) and mpv is not really a good encoding tool anyways. Let's treat
it like the other conf files in etc and install it in the data directory
for reference. If someone really uses these, they can copy the file over
locally to their mpv config directory and it'll still work fine.
This is yet another color-related protocol for wayland. It's pretty
simple compared to the color-management protocol, and there's no real
reason to not advertise the color representation to compositors that
might find it useful.
Relevant for the forced subtitle case where we want a regional audio
language like en-US to match eng language subtitles. The general
matching logic is covered in the language test already.
For matching the audio language with the track subtitle language,
strcasecmp is insufficient since it only allows exact matches and misses
the language regional variant. Fix this by simply using mp_match_lang
instead.
Fixes#16461.
The locked_size restriction also prevents dragging from working on
maximized and tiled windows. A compositor may choose to restrict this
anyway (esp. tiling window managers), but there's no harm in sending the
request if it supports it. The only thing we really need to block here
is the fullscreen case. Fixes#16338.
The old way of setting it during init isn't really accurate. It's
possible for a VADisplay to exist, but for some other hwdec to be
desired (e.g. like vulkan). It mostly worked OK because vaapi and
drmprime are generally exclusive but to be more correct we can simply
check the imgfmt in reconfig instead to correctly determine the type.
The previous way of loading hardware decoding via image formats actually
loaded more things than needed such as cuda. This is because things like
cuda do actually support IMGFMT_VAAPI so the request would try to probe
it and it would fail. Instead of doing that, we can just specifically
request the only two drivers that we actually care about: vaapi and
drmprime.
Evidently it is possible for some compositors to trigger an external
resize before the very first initial reconfig. This can't work and will
fail in various ways. Check this case and bail out. Fixes#16202.
We used to deal more directly with drm-specific things, but that has all
since been removed and is known to not be needed. We can relax the build
requirements some more since vo_dmabuf_wayland will simply error out if
no hwdec backend is available at init.
In retrospect, this isn't so great because not neccesarily everyone
would want the mouse to show with the menu and said menu can be
navigated with the keyboard anyway.
This reverts commit a8f5beb5a3.
There's no good explanation, but I can no longer reproduce the issue
described in the commit. The code as is can cause a "File descriptor in
bad state" message when looping or advancing in a playlist because it
jumps a bit too early to the eof part. Perhaps something in alsa somehow
changed, but the non-gapless audio freezing thing doesn't happen
anymore. The audio state correctly updates on play/pause without these
lines. Since this is known to cause problems elsewhere, just revert it
for now. If the alsa problem crops up again in the future, we can
revisit it then.
This reverts commit d33e54250e.
This relaxes what bbac628a1b introduced.
Although it is rare, there may be scripts out there that depend on the
old timing. We'd still like to process config files in a sane manner and
not cause OOMs so keep the general coalescing mechanism in place but use
it selectively. There is one special case with the --input-commands
option. We want this coalesced as well so some special handling needs to
be added for that.
There's a weird mix and match of ways to set special things about a VO
so let's consolidate it all to use VO_CAP bits. More importantly this
fixes do_redraw not being properly ignored/skipped in the untimed VO
case. This was intended in 8657b8e1f3 but
later the code got reorganized/moved around to make it no longer a no-op
but we just got lucky and there were not any known problems with the
broken logic until 5338f4ba70.
It's not actually possible to truly know the hwdec-current value until
after this event is successfully signalled. Add some special handling to
the pretty printing of hwdec to delay it until we get the video reconfig
event in command_event and then do the pretty print there if
appropriate.
a3823ce0e0 made this request a special
case because of all the threading considerations. Unfortunately, the
implementation made it so that VDCTRL_GET_HWDEC always would return
CONTROL_UNKNOWN when using mp_decoder_wrapper_control. This didn't
matter because VDCTRL_GET_HWDEC in vd_lavc would always succeed, but in
reality it shouldn't. It takes some time before we actually know what
the hwdec is and if you query during that time, you'll could get some
bogus value (e.g. during hwdec auto probing). So fix that by returning
false in vd_lavc if hwdec_notified isn't there yet and adjust the
wrapper control logic to take this into account.
Setting the mouse position always updates the cursor visibility state in
the core, but that's not always desired by the caller. Make it optional.
In practice, this is for wayland. Fixes#15967.
Added in 56616b0b01. Note that it was
called osd_draw then and not osd_render. Anyways, this line doesn't make
any sense today because vo_gpu_next in fact does not call osd_draw (or
any similar API) after this. Resetting the bool here instead seems to
cause redraws to be missed. For the other handful of VOs that use this,
there is no difference. They all use the mp_draw_sub_overlay call and
the playloop appropriately takes care of the redraw notification value.
Fixes#15963.
Dudemanguy