The purpose of this test is mostly to verify that matching the OS
language is not wrongly prioritized over other things (like the forced
flag, matching the audio language, etc).
This is a copy of the existing locale test, but with forced flag added
to all tracks. The forced flag should not affect language selection in
this case.
When autoload-files=no, external files are never selected. Simplify the
logic by excluding them up front instead of removing them afterwards.
This doesn't change the outcome of track selection, apart from edge
cases that are already broken because compare_track is not transitive.
This fixes the problem that a subtitle track that normally wouldn't be
selected if it were the only track available could end up being selected
after a different candidate track was selected first.
Use track->forced_select instead. The value would be assigned there
anyway after the track is selected and the field is not used for any
other purpose.
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.
Before 17551b2d43 keep_open was needed to make nested mp.input calls.
Even after that change it is still better to pass it to not show the
console quickly closing and reopening to the user, so recommend it.
Co-authored-by: CogentRedTester <[email protected]>
If `{d,c}scale` is not specified the scaling kernel is inherited from
`scale`. This made all `{c,d}scale-*` options not work, as they were
silently ignored.
This commits inherits scale options, only if `{c,d}scale` options were
not adjusted in the config.
homebrew slimmed down their ffmpeg formula and stripping it off some
essential functionality.
https://github.com/Homebrew/homebrew-core/pull/261303
use ffmpeg-full instead. this is keg only formula and not automatically
symlinked system wide. make sure ffmpeg is not installed in parallel and
install ffmpeg-full system wide.
In 5871ba8f3e I took the language from the filename when reloading
tracks noting "that backing up t->lang and restoring it if nt->lang is
NULL would work incorrectly when lang is in the stream and it is removed
before reloading", but actually external tracks don't have language in
the stream, it is set in the container, and reload commands only affect
external tracks. So just back up the language before reloading and then
restore the old language.
This preserves the language after reloading when it is not in the
filename but it was specified manually in an add command, e.g. sub-add
foo.srt '' '' en.
Hearing impaired, forced and default flags were already being set from
their values from before reloading the track, so setting them again from
the filename only caused the same issue that they would get unset if
they were manually added with add commands.
We still don't restore the old language if nt->lang is already set for
the edge case of doing something like sub-add foo.mkv and changing the
foo.mkv's sub track language before reloading.
If you do sub-add foo.en.srt, it doesn't set lang=en.
Fix this by extracting the language from the filename, along with
hearing impaired, forced and default flags.
If a language is explicitly passed to sub-add and related commands, that
takes priority.
This commit modifies the log methods in mp.input to always send the id
of the latest `input.get()` request with log entries.
Previously, the log methods applied to whichever input request happened
to be open when the log message was received. Even when scripts used
these methods correctly, there was the risk of sending a log to the
wrong log buffer if the active input request changed while the log
message was in transit; a race condition.
Now the id of the latest `input.get()` request is sent alongside the log
messages, preventing data races between scripts while also preventing
those logs from being discarded.
It was previously possible for completion messages to be received by a
new input request, if one was created while the message was in transit.
Since it is trivial to avoid this by passing the script name and
existing handle_id value, we may as well do so and guarantee that there
will not be any data races.
This commit ensures that `input.terminate()` can only close input
requests made by the same script, and prevents any in-transit events
for old input requests from being processed.
Previously, there was no way to guarantee that the input request being
terminated was the one intended; the asynchronous nature of the API
meant that it was always possible (though unlikely) that another client
may have activated its own input request while the termination request
was in transit.
This commit removes the race condition between different scripts calling
`input.terminate()` by sending the script name alongside the termination
message.
In addition, when a script overwrites one of its own input requests,
there may be incoming events still in transit. Some of these events may
have a decent chance of calling `input.terminate()` if they are
processed (e.g., `submit`). This commit avoids this issue by only
processing `closed` requests once a new `input.get()` request is made.
This makes changes to mp.input and console.lua so that every input.get
request uses a unique script-message to handle input events.
Previously, making new input.get requests shortly after the termination
of a previous request made by the same script could cause a race
condition where the input handler was closed but the new request
was still being drawn in the UI. This was caused by the `closed` event
for the previous request being received only after the new request was
registered, hence closing the event handler for the new request instead.
In addition, this commit makes the behaviour of calling input.get while
another request is active more consistent. When a new request is
received it overwrites the in-progress request, sending a `closed`
event. However, previously, the `closed` event could not be sent if both
requests came from the same script, as the new request would have
overwritten the event handler. Now, the `closed` event is called
regardless of where the new request comes from.
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.
Before this commit, deinterlace=auto and deinterlace=yes had the same
exact behavior for d3d11 and vaapi, the only difference being that
`auto` would create/destroy the deinterlacing filter on every frame that
changed the deinterlace flag and with `yes`, we left that the
responsibility to determine whether to deinterlace or not to d3d11vpp
and vavpp and the filters were always inserted.
Inserting and removing filters on every frame the interlaced flag changes
is expensive and it will be more efficient to let the deinterlacing
filters handle this distinction instead.
With this change, `yes` works as it should: the filter is inserted
always and deinterlacing is forced regardless of the frame flag. `auto`
will insert the deinterlacing filter only when mpv sees the first
interlaced frame, and the filter will only deinterlace the frames marked
as interlaced. Note that perfect detection of interlaced frames is not
possible, and in such cases the user has to set `yes` manually.
One downside of this change is that we don't know if the filter is
actually deinterlacing or not, we can only guess that if the filter is
inserted and the frame is interlaced then it should be deinterlacing.
It's possible for it to fail for whatever reason, and it's also possible
future changes to ffmpeg (since bwdif implementation lives in ffmpeg),
might make the logic more complicated than this check. However, for now
this is good enough.
The system preferred language is the language used during Windows
install. It doesn't have much purpose except that it is the backend
language for core Windows internals. All user facing dialogs and text
should follow the user preferred language, as this is what the user
selected and uses on daily basis.
It makes no sense to include system language in track selection.
a74a324b98 returned responsibility of video
redraw back to playloop. The playloop is only run if something wakes up
the core.
However, the logic for VO requested redraw only wakes up the core when
in->want_redraw is false, which is only resetted by vo_redraw, called
from the core. This creates a situation where it can never wake up the
core, so redrawing never happens even when VO requests it.
efc44d05ff caused the issue to surface
because it also throttles VO requested redraws, and in some cases results
in the above behavior.
Fix this by always waking up core when the VO requests redraw.
vo_wayland_preferred_description_info is destroyed after info_done, so
obviously we can't store it here. This causes a use-after-free.
Embarrassing mistake
Fixes: 7a7d871d0a
Just to catch uninitialized variables early. Build all three unint/zero/pattern to compare the results between them and we don't accidentally depend on implicit initialization in tests.
Commit baf2fd2f28 fixed this for 2nd call
to GetSystemPreferredUILanguages(), but apparently regressed the 1st
call, duh.
To retrieve the size both buffer has to be NULL and size 0.
Memory has a lot of zeros, because it has been working quite
consistently on CI.
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.
With `node.always-process` mpv will force pipewire to continuously keep
driving the source node, even when paused, which causes a relatively
significant increase in power consumption due to frequent CPU wakeups.
I have tested mpv with this option disabled, both for music and video,
pausing and seeking around in various ways and could not notice any
problems with this option disabled. And with it disabled pipewire
properly becomes idle a couple seconds after video/audio is paused.
Pipewire documentation suggests that this option is largely useful for
JACK clients, which `mpv` isn't. Using GitHub-wide search it seems like
the other two notable uses of this property are really just SDL and
OpenAL. All other applications I use work well without this property
being set as well.
Note that this change does not affect the output devices differently as
far as I can tell. Both with and without `always-process` pipewire will
suspend the output device after some idle time and in case
`always-process` is enabled, it will redirect `mpv` to `Dummy-Driver`
instead.
The language hint is required for *correct* handling of RTL in srv3 so
provide the best-effort guess from the subtitle track.
Without this hint some RTL paragraphs are going to be wrongly assumed
LTR and reorder incorrectly. Additionally, subrandr may soon start
treating srv3 segments as `inline-block`s which means guessing is not
going to be possible anymore (at least as part of unicode bidi algorithm).
The instanced API allows a lot of work to be offloaded to the GPU and
makes software rasterization tolerable performance-wise in most cases.
This is similar to sd_ass but there are some substantial differences:
- It uses a BGRA atlas to allow drawing bitmap emoji.
- De-duplicates images internally to significantly reduce atlas size by
reusing the same atlas image for different instances.
- Exploits bilinear interpolation to further reduce atlas size of some
primitives. For example this allows reducing background boxes to one
very stretched pixel.
Bumps subrandr requirement to `v1.1` since this API is not present in
earlier versions.
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.
This reverts commit ee05804bfa. Only the
select.lua part since osc.lua list formatting was removed.
Since playlist/N/filename is now normalized, it is never going to have
trailing slashes so there is no need to strip them.
Since the previous commit normalized playlist filenames when they are
stored, the code normalizing them can be simplified back to how it was
before implementing normalization.
This normalizes the playlist/N/filename sub-property, making it
consistent with path. As a consequence playlist-path and stream-path are
also normalized.
This will allow simplifying the code by not normalizing playlist
filenames in several places, similar to 23b57e9f7f for tracks.
If the current working directory or the realpath could not be retrieved,
return the path as it was passed to mp_normalize_path() to avoid
guarding the return value. This is also makes it consistent with what
the Windows code was doing.
Filip Hejsek