Currently, all fopen uses in mpv do not set cloexec flag, resulting
in fd leak whenever mpv creates a process.
This makes mpv use mp_fopen on all platforms, and always set O_CLOEXEC
on the opened fd. This is required because the "e" flag for fopen is
nonstandard and UB in C11, and unsupported on macOS.
This had been done similarly in other projects. e.g.
https://gitlab.com/graphviz/graphviz/-/merge_requests/3797
currently mouse processing only happens on mouse movement which
causes cases where going from never -> auto does not show the
osc even though the cursor might be in proximity.
move mouse processing code to a function and refresh it when
leaving visibility never to avoid such issues.
Fixes: https://github.com/mpv-player/mpv/pull/17954#discussion_r3286015305
currently hide_bar() bypasses set_visible when visibility was
changed to `never`, this can leave the thumbnail hanging.
instead of scattering disable_thumbnail() calls around, just
call set_visible(false) instead.
Fixes: 9ce79bcaa
this currently disables thumbnail even on set_visible(true)
calls which was causing flickering due when scrubbing through
the timeline. only disable thumbnail when hiding the osc.
Fixes: 9ce79bcaa
The name "Quit watch later" is hard to understand for users that don't
already know about the quit-watch-later command.
For what it's worth, this does also have some downsides:
1. It makes the context menu even wider, since "Quit watch later" was
already the longest option.
2. The meaning of the "Open > Watch later" option may now be slightly
less obvious to users. But this option does not work by default
anyway, so the user will need to read the manual either way before
using this option.
But these are fairly minor issues.
Rate-limit progress-only updates. The win32 backend forwards these to
the shell (explorer.exe), we don't want to spam it too much to avoid
performance issues, when stealing cpu time from the shell thread. In
normal playback, this doesn't update at all, but in live streams the
duration can change, even on every frame.
Fixes: #18053
Some demuxers like DASH and HLS, query the location through the
"location" av option, this is how http.c in lavf exposes it. Respect
this interface and expose effective url.
Fixes: https://github.com/mpv-player/mpv/pull/18044
queue->is_bof is set optimistically after a seek to start, assuming
demuxing began at the start of the file. That is wrong for streams
opened mid-content, which can happen in unfinished event HLS playlists,
which starts at live-edge, but the seekable range in the past is still
valid.
For full support this also require change in lavf [1] to fix the overall
duration of the stream and seeking.
[1] https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/6d98a9a2e8757d6eb616501ade06877389a31597Fixes: #11990
When FFmpeg is built with whisper.cpp, the libmpv-lifetime test fails
with `GGML_ASSERT(prev != ggml_uncaught_exception)`. Avoid this by
disabling the problematic backtrace code.
Drop the swr_set_channel_mapping() + transpose_order() + reorder_in[]
plumbing. Instead, build the swr input channel layout directly from the
mpv chmap as AV_CHANNEL_ORDER_CUSTOM, so the labels in the layout already
match the positions of the channels in the input data.
For all unknown map, we return all UNSPEC, so the swr expands to default
layout for this channel number.
Since 9ef614d6a3 this helper has been a no-op. fudge_layout_conversion()
returned the modified uint64_t channel-layout bitmask, but the new
AVChannelLayout path builds out_layout from the unfudged out_lavc and
feeds that to swr.
Even when it was wired up, libswresample handles the BL/BR <-> SL/SR
mapping if needed. SDL/SDR is not currently handled, but I would rather
patch the swr/rematrix.c for those too, instead of having custom glue
here.
Note that SDL/SDR are not that common in-practice.
The previous commit to dynamically load VapourSynth R74 would fail to work
for VapourSynth R73 and before on Linux due to load mode RTLD_LOCAL. To
make it work on all VapourSynth version, switch to use RTLD_GLOBAL mode.
Use floor(pts * 1000 + 1e-6) instead of llrint() for all timestamp
conversions to avoid floating-point precision errors causing early
subtitle presentation on boundry frames.
Fixes: #17453
Signed-off-by: Ricardo Fonseca <[email protected]>
We shouldn't default to no verification in current year. User can
opt-out if needed.
Keep it disable for builds without libcurl when libavformat is older
than 63.0.100. This is done to match ffmpeg's timeline for enabling
tls_verify by default in lavf, also to ensure we the default verify
locations will be loaded on such version.
This is another file where the slopbot identified a problem, but I was
surprised to see it fix it in a poor way and also miss an adjacement
problem.
`mapper_map` calls `mapper_unmap` with the intention of using it to clean
up partial failure after some planes are wrapped and released while others
are not. But the current code would actually segfault in that situation.
There are two fixes required:
* Ensure `p->vkf` is set by `mapper_map` early so that its available to
`mapper_unmap` in the error path
* Don't call `vkfc->unlock_frame` in the `mapper_map` error path, as
this will be called by `mapper_unmap`
Fixes#17977
The slopbot spam did find valid issues in the error paths in this code, and as
part of verifying them, I have additional fixes.
* ensure that the return value -1 from `cuda_init()` if `ext_init()` fails
* zero alloc the `ext_vk` and `ext_gl` structs so that we have a known initial
state
* explicitly initialise the `sem_handle.fd` to -1 to ensure we don't
accidentally close stdin in the error path. But also don't do this on
windows as an invalid Handle is 0.
* Don't do a double `cuCtxPopCurrent()` in the `ext_gl` init failure path
Fixes#17976, #17988, #17989
lavf's http demuxer exposes initial/final byte offsets as AVOptions.
Some demuxers, like lavf/hls.c assume it is always available, even for
custom IO. We need to use those values for correct demuxing.
Fixes: https://github.com/mpv-player/mpv/pull/17879#issuecomment-4468476976
loop_start starts a thread which immediately acquires the thread loop
lock. Locking the loop before loop_start can therefore deadlock the
newly created thread during initialization.
Locking the thread loop before loop_start was always incorrect, but
Pipewire commit fb49e0795c28* made the issue visible by switching
pw_thread_loop_lock to the underlying SPA loop lock.
To fix this, we just avoid starting the loop until after we're connected
to the server.
* https://github.com/PipeWire/pipewire/commit/fb49e0795c28c892116b03369785ba86c27c968d
The FILE field in a CUE sheet may contain a relative path with
subdirectories. It's not clear if this usecase is intended to be
supported, as none of the usual CD/DVD ripping tool generates this type
of FILE field in the CUE sheet. The specification is old and abandoned,
so this will likely never be clarified and it doesn't cost much to
support it so might as well...
this was initially part of draw-preview but was later moved to a
separate property because it was deemed useful outside of just
thumbnail preview. however this causes bugs when a thumbnailer
observes draw-request and the draw rectangle doesn't change (e.g
due to getting clamped around the border).
add back hover-sec which makes the draw-request more self
contained and removes this footgun.
Fixes: https://github.com/mpv-player/mpv/pull/17518#discussion_r3256017469
Unlike --term-playing-msg, the --term-title string is printed in an
escape sequence already. If we print other escapes during this sequence,
it will abort the sequence and dump the rest of the title string as a
visible string to the user, and possibly beep as well, since the title
string can end with a bel character.
Also updates the manpage to remove a comment about win32, since
terminal-win.c does handle OSC title sequences, calling SetConsoleTitleW.
Note that when the video params don't change, the check in
player/video.c does not call vo_reconfig2 and the _NET_ACTIVE_WINDOW
message is not sent. As far as I can tell, the same limitation is true
for the macOS implementation, but I can't test that.
Follow-up to #17926, addressing the four additional instances flagged
by @garoto:
- DOCS/man/options.rst: "output size size is limited" -> "output size is limited"
- DOCS/man/input.rst: "Called after after a file" -> "Called after a file"
- video/out/gpu/video.c: "target target that needs to be written" -> "target that needs to be written"
- video/out/x11_common.c: "enable DPMS only we we disabled it before" -> "enable DPMS only if we disabled it before"
(this one wasn't a pure duplicate — the first "we" was a typo for "if"; the comment now matches the conditional on the line above)
At the initial file open, the buffer may be populated with more data,
than later requested by decoder, but don't drop this data. This fixes
initial open to perform multiple reads of the area, especially for
images that are likelly fully read for probbing already.
Hook AVFormatContext.io_open so HLS/DASH segment fetches and other
nested FFmpeg I/O go through stream_http when libcurl is available.
This lets segments inherit the connection reuse, HTTP/2 multiplexing,
mid-stream resume and conditional compression of the top-level stream.
Falls back to FFmpeg's default I/O for non-HTTP URLs and when the curl
backend is not built in.
Introduces stream_http, an internal libcurl-driven backend for http://
and https:// URLs. Runs all transfers on a dedicated curl multi thread
with a producer-side ring buffer, and exposes HTTP/2 multiplexing,
QUIC/HTTP/3 (when libcurl supports it), HSTS and TCP keep-alive.
Should generally be more stable and faster than FFmpeg HTTP/1.1 impl,
additionally connections are kept-alive between files open, so if you
open playlist of network files and navigate through them, it will re-use
the same connection.
Build is gated on the new 'libcurl' meson option (auto). When disabled
or unavailable, mpv silently falls back to FFmpeg's HTTP implementation.
Pure typo fixes in user-facing manpages, interface changelog, and
source comments. No behavior change.
- DOCS/man/encode.rst: "copying of the the comment" -> "copying of the comment"
- DOCS/man/options.rst: "visible takes the the menu bar" -> "takes the menu bar"
- DOCS/interface-changes.rst: "rename the the lua-settings/" -> "rename the lua-settings/"
- video/out/present_sync.c: "requires that that caller" -> "requires that the caller"
- player/lua.c: "try to get by by filtering" -> "try to get by filtering"
44a2c33939 tried to do this in a cute way by unsetting the hwdev to
be used for hwdec, but this doesn't prevent -copy variants from being
probed. Instead explicitly disallow it for grouped streams
create_xdg_surface returns success/failure, so use bool instead of int
for its return type. Also invert the return values to better match the
style of the rest of the file, also adjust callers accordingly.
create_viewports returns success/failure, so use bool instead of int for
its return type. Also invert the return values to better match the style
of the rest of the file, also adjust callers accordingly.
spawn_cursor returns success/failure, so use bool instead of int for its
return type. Also invert the return values to better match the style of
the rest of the file, also adjust callers accordingly.
This allows playing tile grid images without manually disabling hardware
decoding. There is no other type of stream group known to support
hardware decoding so far.
Co-authored-by: Guido Cella <[email protected]>
This allows to spin N decoder of dependent streams, and merge them in
single output using a filter. Currently only lavfi is supported, and
should be set as a string in the stream group definition.
In the future more advance merging can be implemented in place of lavfi,
but the grouping of the streams should be similar.
This will be useful for tile merging or LCEVC style enchantment support.
May even be useful for DV EL, but this is often not a separate track.
Flush cache only if interpolation-preserve is off, or in paused state to
get immediate update.
Fixes unnecessary cache flushes when parameters of external hooks are
updated rapidly.
When setting properties via M_PROPERTY_SET_NODE, the property value
is limited by static declared range. However, some properties like
volume handle dynamic M_PROPERTY_GET_CONSTRICTED_TYPE requests and
return runtime determined limits. M_PROPERTY_SET_NODE in this case
does not respect that limit, and allows setting to a value out of
range.
Fix this by always trying to use M_PROPERTY_GET_CONSTRICTED_TYPE
first so that the dynamic limits will be used.
When decoder is not available or failed to initialize, just signal EOF
and allow player to close, instead of spinning waiting for frame that
will never arrive.
demux_edl allocates metadata track with type set to STREAM_TYPE_COUNT,
when counting track types this was not accounted for. Make room for this
"special" type of track. Add asserts while at it, just in case.
Note that other similar uses are gated behind track->selected, and
metadata track will never be marked as one.
This is not exploitable, as it was overriding only one integer value past
the allocated array, so worse thing that could happen is that we
misbehave during track selection or crash.
Side note, OSS-Fuzz was fuzzing this for few years now, and couldn't dig
into this specific case. I've validated that our fuzzer is in fact
reproducing this issue when provided the testcase, which I belive was a
basis for this report.
Fixes: GHSA-qpf4-42gw-f286
This vulnerability was discovered by Claude, Anthropic's AI assistant,
with OSS-Fuzz fuzzing and triaged by Ada Logics manually in
collaboration with Anthropic Research.
This has been deprecated for 9 years since
9eef41dec1.
With the previous commit, this can be replaced by conditional autoprofiles.
Add usage hint to the documentation.
This fixes stalled/slow resize when there's only an image being
displayed or no output at all. When there's a video playing, the video
implicitly causes a redraw but we need to redraw ourselves when there's
no video.
Fixes: https://github.com/mpv-player/mpv/issues/16744
Until now the pool only released its packets on shutdown or when the
cache size was reduced at runtime, so it kept growing across a session.
The amount of packets would be indirectly bound by demuxer cache size,
else the packets are reused. Still over long playback or switching
files, this may give impression of elevated memory usage, or even memory
leak. This was particularly visible with cache-on-disk, where users
reasonably expect RAM usage to stay low.
Pop now keeps the first POOL_HOT_RESERVE packets at the head of the
freelist for fast reuse, and frees up to POOL_GC_BATCH packets from
beyond that on each call. Bulk pushes (e.g. cache reset on file end)
remain no-work policy. The pool drains across subsequent allocations
rather than stalling on a single huge free. Self-balancing without any
size tracking.
This drains the pool in steady state. Note that on file switch we
effectively reuse only ~N / POOL_GC_BATCH packets from the old cache,
because each pop reuses just one packet while freeing up to
POOL_GC_BATCH. That's fine, both free and alloc calls are throttled to
the same per-pop rate, so allocator pressure stays bounded even though
not all packets get reused.
Fixes LSAN leak when tests call fail() and exit(1) is called. We have
mpv_destroy set for atexit but data.ctx was null parented, so it had no
parent to be freed by. Parent it to script_ctx instead so it gets
cleaned up by mpv_destroy.
LSAN output:
Direct leak of 400 byte(s) in 5 object(s) allocated from:
#\0 0x7f4c6c52c01f in malloc (/lib64/libasan.so.8+0x12c01f) (BuildId: db0aa5bf57ed53a5869a3a2cc49051292ceb6390)
#\1 0x7f4c6b276388 in ta_alloc_size ../ta/ta.c:139
#\2 0x7f4c6b2bf01f in script_autofree_trampoline ../player/lua.c:1310
#\3 0x7f4c69373b15 (/lib64/libluajit-5.1.so.2+0xbb15) (BuildId: 182622c63dea3dd74173bbd5a810051a76bcf4d9)
Improve the Dolby Vision metadata check to accept RPUs that indicate EL
usage (profiles 4 and 7) if the original bitstream and metadata are
MEL-only, instead of hardcoding a check for disable_residual_flag.
This needs libplacebo commit a4783f89 ("util/libav: do not bail on
MEL-only RPUs w/EL"), or libplacebo API version 359.
And make them actually async when copied from host ptr. The issue was
when we used DR buf upload, which is always async, it was not
synchronized in anyway.
Fixes: #13811
PA_SUBSCRIPTION_MASK_SINK is a pa_subscription_mask constant used when
registering with pa_context_subscribe(), not a
pa_subscription_event_type mask. Masking the event type with it would
never match PA_SUBSCRIPTION_EVENT_NEW or PA_SUBSCRIPTION_EVENT_REMOVE,
causing hotplug events to be silently dropped.
Fixes: e01750020d
This is only used to update the list for player internal sub ext matching.
Since this handling now lives in the dnd client, it can be removed from
core, which also eliminates a global variable.
This unifies --drag-and-drop handling to a single place. All platforms
currently only support normal drop (mapped to "replace") and shift click
drop (mapped to "append").
This adds dropped-file property which contains a list of dropped files
and the type of the drop. This allows clients to implement custom drag
and drop handling.
It is more expected from GUI application to stay open, even after
playback. Additionally this gives user a chance to inspect possible load
failures, while previously mpv would disappear.
Add adaptor for arrays of properties, this is not used as real option,
as those are always string list. But as a connector struct for creating
typed node arrays, in (sub)_properties.
Lavf exposes programs/renditions as a flat track list tagged with
program_id. We respect this metadata and group tracks into their
respective programs, as tracks from different programs may be completely
unrelated to each other.
This commits adds an option to flatten the editions and ignore the
grouping.
Fixes: https://github.com/mpv-player/mpv/issues/17836#issuecomment-4345930205
M_OPT_INVALID says "option parameter could not be parsed" which is
incorrect for some failures this parser might encounter. Instead print
something that might be useful for the user to debug.
Vulkan instance might fail to create if there's no vulkan drivers that
mpv can see, or devices might fail to enumerate for whatever reason
The retry path in wasapi_thread_init() used MP_TIME_US_TO_NS, giving a
total budget of ~15 us before MP_FATAL killed the audio thread. The
resulting log line "Retrying in 1000 ns" makes the unit confusion
obvious.
In practice AUDCLNT_E_DEVICE_INVALIDATED is most often hit right after
the system resumes from sleep, or when the default endpoint changes,
where the audio endpoint typically needs hundreds of milliseconds to
come back. The current budget never covers that window, so the first
playback after wake-up permanently fell back to "no audio" until the
user manually restarted playback.
Switch the retry schedule to milliseconds: start at 1 ms (~one Windows
timer tick, effectively an immediate yield), multiply by 10 each
iteration, and cap at 1 s -- i.e. 1/10/100/1000 ms, 4 retries, ~1.1 s
total. Use MP_TIME_NS_TO_MS for the warning so the unit in the log
matches reality.
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.
When the current edition supplies its own track of a given type
(e.g. yt-dlp muxed editions ship their audio paired with the video),
shared program_id == -1 tracks of that type are filtered out of
both the track list and auto-selection. Editions that don't ship
their own track (DASH video-only editions sharing the audio pool)
continue to see the program-agnostic tracks.
Extract the codec descriptor out of mp_format_track_metadata into a
shared demux_append_codec_desc() helper, and use it from a new
demux_compose_edition_title() composer that both demux_timeline.c and
demux_lavf.c call when building editions. Codec block is only added
when the program has exactly one stream of that kind, and fields
already present in the prefix (e.g. WxH from yt-dlp's format label)
are skipped to avoid duplication.
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.
There is no need to pipe things through shell and grep/awk, python is
perfectly fine word processor. This makes it simpler to reason what is
extracted and from where and also makes the script faster as we spawn
only single process directly, not shell with multiple children.
Currently the duration observer is toggled in multiple places to not
call request_init unecessarily. It is much simpler to always observe it
and call request_init conditionally in the callback. This also allows
reusing the cached value throughout the OSC.
Note that dividing by 0 is not an error in Lua so there is no need to
check for both 0 and nil.
This:
- Removes the dependency of ffmpeg in PATH - useful on Windows, macOS
(?), Flatpak.
- Will support subrandr.
- Avoids redownloading network subtitles.
- Avoids slow demuxing of large mkvs.
- But no longer returns future lines of embedded subtitles.
- No longer returns embedded lines of regions you seeked beyond without
playing them.
- Changing sub track drops cached subtitles.
Return all subtitle lines in memory with text, start and end.
I did not name this sub-all so it cannot be misinterpreted as referring
to all subtitle tracks.
Closes#12810.
100 is enough and avoids mistimed frames to affect long term stats. It
would be good to improve vsync estimation accuracy, but increasing
averaging size alone is not the best solution.
This reverts commit 4e44fe024c.
The old code had several interacting problems that prevented A/V from
reaching a steady state.
When the A/V difference was large, it applied the maximum allowed
compensation in one step. That was fine for catching up, but the value
was never re-evaluated, so audio speed routinely overshot the target.
Once the difference crossed zero (or re-entered the acceptable range) it
would run a linear regression over recent av_diff samples and snap the
audio speed to the estimated drift. The fatal flaw was that those
samples already included the controller's own compensation: even when
the underlying drift was zero, the controller would "detect" the drift
it had just induced and try to cancel it. Between these rare, sparse
updates audio speed stayed frozen, so in practice the controller was
introducing drift more than it was fixing it. On high fps outputs,
where the vsync range is tight, this degenerated into a ping-pong:
overshoot, snap back, overshoot again, never settling.
The new code replaces the bang-bang direction controller and one-shot
regression with a proportional controller driven by a low-pass-filtered
av_diff. The LP filter (1 s time constant) rejects per-frame vsync
jitter so the compensation no longer chases noise. The target then
decays av_diff exponentially toward zero with a 10 s recovery time.
Adaptive slew caps per-frame motion to the desired correction magnitude,
so large excursions are absorbed quickly while near-equilibrium motion
stays below audibility. The result is a continuous, gentle control loop
that actually reaches steady state and does so without audible
audio-speed modulation.
Those values are often very small, but it's still good information to
have how they are changing.
This brings those values closes to old `%+.05f%%` that were used here.
The previous commit to dynamically load VapourSynth R74 would fail to work
for VapourSynth R73 and before on Linux due to load mode RTLD_LOCAL. To
make it work on all VapourSynth version, switch to use RTLD_GLOBAL mode.
Add library handle closing in drv_vss_uninit for completeness.
Fix toplevel state being lost before geometry_configured is
configured. Previously, for a KWin rule that set fullscreen (apply
initially or forced) when a --geometry was also specified, mpv would
render at --geometry size even though the compositor was treating it as
fullscreen. This resulted in geometry-sized content anchored to the
top-right without a titlebar. This mismatch of what mpv thinks and what
actually is can also be seen similarly with a KWin rule that sets a
maximize state.
With this change, mpv starts in fullscreen _proper_ (ie --fullscreen).
Exiting fullscreen then results in a window size as specified by the
--geometry.
For the other states this handles, I'm honestly not sure as I wasn't
able to force them. It _should_ be fine based on what I see here and
_logically_ is correct as mpv's state should always match what the
compositor informs it to be.
If the compositor supports session management, the mpv window is always
added to a session. The user can manage multiple sessions by using
`--wayland-session=<human-readable-name>`. Human-readable names are
mapped to session ids via files under `~/.local/state/mpv/sessions`. The
file name is computed as a hash of XDG_CURRENT_DESKTOP and the
human-readable name.
If multiple mpv instances are started with the same session name, the
latter mpv instance takes over the session.
Upon session restoration, the mpv window is restored by the compositor
according to its state from the previous session. What that entails is
compositor policy.
With use_manifests=yes EDL is not used so metadata never gets set
through the tags mechanism. Thankfully the metadata property was
recently made writable so use that instead.
The existing metadata variable is inlined to fix linting.
Fixes https://github.com/mpv-player/mpv/pull/17761#issuecomment-4306070651
VapourSynth R74 changed two things relevant to mpv build process:
1) VSScript no longer has static library to link to, and only support runtime loading.
This is reflected on the new VSScript example in VapourSynth SDK.
2) The VSScript library name is changed from libvapoursynth-script to libvsscript for Linux
and MacOS.
The new VSScript initialization code is modified from their SDK example to utilize
mpv's mechanisms. Build dependency is also updated accordingly.
per actions/partner-runner-images#95, manually install and repair winget module in windows-11-arm runner to ensure it is available for following dependency step
The .strm format consists of a URI or local path as the sole contents
of a text file, this is parsed by software like Emby or Jellyfin to
treat remote streams or paths as if they are in the local filesystem.
This commit adds .strm to mpv's internal list of playlist file formats,
and points it to the handler for .m3u files as they should be
compatible. .strm doesn't need all the features of .m3u/.m3u8, but the
features do not cause issues with the relatively barebones playlist
format of .strm.
Dunno what wm4 was referring to here but all_formats=yes works just fine
and quickly for changing track at runtime. The only issue I see is that
it drops the video cache if you change audio track.
93fe7a5526 fixed the only problem with all_formats=yes, so make it the
default to allow changing tracks of ytdl_hook URLs at runtime without
re-invoking yt-dlp.
Closes#16872.
This adds _down_command support to bind_mouse_buttons so it can be
used to bind button down actions like mbtn_left_down, and let forward
and backward buttons use bind_mouse_buttons. This makes mouse button
down actions customizable.
The event responder must have up, down, or press suffix, but
940ab99055 removed it for frame stepping
function, making it unusable. Fix this by using the down suffix.
Fixes: 940ab99055
Previously this function would just count bytes which was very easily
broken by incantations like `Ő̶̧͍̹͔̮̮̦͌̈̌̂́̊͜K͖̮̼̯͖͆͋̓̀̕` which take up 52 bytes while being just
2 normal width characters visually.
`terminal_display_width` correctly counts `Ő̶̧͍̹͔̮̮̦͌̈̌̂́̊͜K͖̮̼̯͖͆͋̓̀̕` as 2 visual characters.
Note: GitHub strips all these in their web UI but there are many Unicode
combining characters after each letter of the `OK`s above that produce
a "cursed" text effect.
Fixes#17772
When 0197729949 added state.chapter_list this call was not updated to
use the cached value, but there is no reason not to use it, especially
now that more cached properties are used.
For properties that were already being observed but still retrieved over
and over, cache their values using the new observe_cached().
osd-dimensions observer said that if cached we may have to worry about
property ordering but it seems to work fine. It is nice to cache it
because it was the property retrieved the most frequently, in 5
different places.
Expose the terminal output sanitizer as mp_msg_sanitize() and use it in
term_osd_update_title() to sanitize the property-expanded term-title
string before it reaches mp_msg_set_term_title(). Without this, a
crafted media tag can break out of the OSC-0 sequence via embedded BEL
or ESC bytes when --term-title includes property expansions like
${media-title}.
Extend the sanitizer to cover two gaps:
- UTF-8 encoded C1 controls (U+0080-U+009F, bytes C2 80..C2 9F). xterm
in UTF-8 mode interprets these codepoints as C1 control functions
(U+009B as CSI, U+009D as OSC, U+009C as ST), allowing escape
sequence injection without any ESC or BEL bytes.
- DEL (0x7F), which was not previously filtered.
scRGB is basically intermediary format, but we don't really know what
would be the real target. And since we send floating-point buffer, we
can just expect the downstream will handle dithering and quantization at
some point.
Mark every filter window whose libplacebo counterpart is resizable as
resizable in mpv too.
This allows --tscale-radius to be used. Prior to this, vo=gpu
silently ignored the radius override while vo=gpu-next honored it,
producing different output for the same options.
When the effective filter bound (radius * blur) is smaller than the
smallest tap distance, mp_compute_weights produces all-zero weights and
the subsequent normalization divides by zero, producing NaN weights that
render as black. This can happen for resizable filters where the user
picks a radius below 0.5.
Detect sum == 0 and fall back to nearest-neighbor on the closest tap.
The comment about video backends not updating pointer position is only
true if no mouse button is being pressed. If mouse button is pressed on
mpv window and then moves out of window region without releasing the
button, some platforms (win32, Wayland, X11) "capture" the pointer and
still report the coordinates, while some other platforms (SDL) do not.
The value of mouse-pos/hover also differs between platforms in this case.
The value is true on win32 and Wayland, but false on X11.
Fix documentation to address them.
Similar to current-tracks, when the selected audio track is combined
with another one or with an ffmpeg filter, show the first selected track
id instead of "-".
This was requested by a user on IRC.
Also avoid fetching aid and sid on each render.
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.
this adds a "standard" api for ui scripts and thumbnailers to
communicate with each other, based on the simple thumbfast api
[0].
the api works as follows:
* To issue a thumbnail draw command, the UI script will set the
property `user-data/osc/draw-preview`.
* To clear the thumbnail, the UI script will set the previously
mentioned property to `nil`.
a more ideal api would make it so that the thumbnailer script
only generates the thumbnail and doesn't need to draw at all.
but such api is vastly more complex [4] and would require a lot
more work and maintenance on mpv's side.
this is a decent enough api that allows arbitrary thumbnailers
and ui scripts to communicate between each other and work
together, while being simple enough that it can be supported
without too much maintenance.
this change has been tested with work with thumbfast [1]. and
for demonstration that this api can be useful outside of osc, it
has also been tested to work on mfpbar's thumbnailer branch [2].
the code to determine thumbnail x,y is based on the osc fork
inside of thumbfast [3].
[0]: https://github.com/po5/thumbfast?tab=readme-ov-file#for-ui-developers-how-to-add-thumbfast-support-to-your-script
[1]: https://github.com/po5/thumbfast/pull/173
[2]: https://codeberg.org/NRK/mpv-toolbox/src/branch/thumbnailer/mfpbar
[3]: https://github.com/po5/thumbfast/tree/vanilla-osc
[4]: https://github.com/mpv-player/mpv/discussions/17654
can occur when a user shader sets a hook texture with more
components than supported. e.g overwriting LUMA with 3
component.
this does create a massive log spam when triggered, but that
seems consistent with the existing resize/realign error case.
Closes: https://github.com/mpv-player/mpv/issues/9863
93fe7a5526 made global_tags work with all_formats=yes, so do like
suggested in 8ea7aa5471 and set the title via tags.
This makes available in ${metadata/title}, even if you set
--force-media-title separately.
--force-media-title is also set when self_redirecting_url is true, but
tags seem not to be set in this case and I don't know where to find such
videos to test. It was originally added to close#5313, but the URL
linked there no longer loads.
Subtitles in general have constant brightness, but currently
--image-subs-hdr-peak=video uses detected peak value which is not synced
with scene and undesirable.
Add new modes that allow using static peak metadata or per-scene metadata.
704afb8968 assumed that HDR image
subtitles target SDR white. However, this is incorrect according to
UHD BD spec version 3.2:
> CLUTs of Presentation Graphics streams and Interactive Graphics streams
> are prepared by content author according to dynamic range property of
> the Primary video stream.
> If a Primary video stream is HDR, the Graphics streams have CLUTs
> expressed in BT.2020 color space primaries and ST2084 EOTF.
> If a Primary video stream is SDR, the Graphics streams have CLUTs
> expressed in BT.709 color space primaries and BT.1886 EOTF.
This means that PGS subtitles always have the same colorspace and HDR
dynamic range as the video, so the target peak should also be the same.
This is also supported by the BD-J spec (which displays PGS graphics):
> However the BD-ROM player does not support color space conversion nor
> dynamic range conversion of Java graphics and Background plane when
> mixing with video plane.
The Graphics model spec further states:
> The composited image on the graphics plane is transformed to full color
> and transparency by the CLUT module and then overlaid on the video
> image.
These sentences indicate that BD-ROM players simply overlay the decoded
graphics onto the video without any kind of conversion.
Change the default of image-subs-hdr-peak to 1000 to fix this.
This accommodates most HDR videos with a peak brightness of 1000 nits
and some bad HDR videos with 10000 nits peak brightness due to reencoding
and mixed with unmodified subtitles.
If there are compatibility issues, the option can be manually
set to sdr or video.
Fixes: 704afb8968
The delay_open mechanism used by
--script-opt=ytdl_hook-all_formats=yes breaks setting metadata with
global_tags because tl->track_layout is NULL. See adcf51dccdcbb8f534b08ea7aa5471.
Fix this by applying tags to the EDL timeline in this case.
Tags must still be applied to tl->track_layout when available for them
to work with local EDL files.
strchr() can return NULL when no newline is found. Computing end + 1
before the null check on end is undefined behaviour per C11 6.5.6.
Move the next assignment inside the else branch to avoid the UB.
This has been deprecated for 8 years, since 9eadc068fa, with a visible
warning. Removing it has the benefit of not spamming every log file with
lua-settings searches.
Since changing the width and alignment of buttons shrinks them or messes
up the layout, manually override the hitbox of buttons at the edges.
Fixes#9791.
Alpha blending is done in gamma light of the target, when the overlay is
drawn. Depending on VO and target format, the alpha value can act quite
differently.
Lower it a little to avoid excessive transparency in some cases. This
should be fixed or workaround in better way, but for now just adjust the
value.
This adds proper support for MPEG-TS programs and HLS variants. Now
program selection is exposed as editions and tracks are grouped under
such edition. If there are external tracks added, they are available in
all editions.
track-list/N is not required to match aid/vid. They are encoded as
track-list/N/id.
This fixes changes in 1a558bf5c2 where it
was asumed that track id is the same in track-list, which is not true,
in general sense.
Since cb56c2f888, the priority of
--cover-art-auto and --cover-art-whitelist is unclear. Depending on the
number of elements in --cover-art-whitelist, the priority of
--cover-art-whitelist files can be lower, equal, or higher than
--cover-art-auto matches, creating unpredictable behavior.
Fix this by making --cover-art-whitelist priority always between "fuzzy"
and "all" priority. test_cover_filename now uses bstr_find_in_list0 to
return a negative priority value depending on the position in list.
The "all" priority is set to INT_MIN. Modify filter_subidx to use 0
priority as removal marker, since all files in the external files list
already have non-zero priority.
The documentation says that the scripts are loaded in alphabetical order,
which indicates that the case is not sensitive. Use strcasecmp to satisfy
this requirement.
The dynamic allocation of this strings is completelly pointless. It adds
complexity with mp_exec_once to init aexit() to free the string, which
was leaked anyway, because the structure is thread_local and atexit only
data from the main thread was freed.
Remove all this, and just use static buffer.
Makes it nicer for speaker icon to not move around on different volume
levels. Also remove scaling, it was not needed.
This required to rewrite the exclamation mark drawing code, made it look
similar to old icon now.
when there's a flood of events causing the event queue to
overflow, the duplicated client-message payload gets dropped
without being released. free it on failure too.
discovered while trying to trigger #10110.
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.
There is an area between the 2 lines of bottombar and topbar that is not
clickable, e.g. between the menu and play_pause icons. Make it all
clickable so it's easier to click buttons.
This also allows clicking from the bottom in slimbottombar and from the
top in topbottombar.
Window controls are not clickable from the very top of the window, they
have a margin to the top that makes them harder to click. Make them
clickable also from the very top to make them easier to activate.
The close button with the default windowcontrols_alignment=right
specifically is already clickable from the rightmost part of the window.
Partial fix of #9791 (other buttons also need to be updated).
trying to autocreate playlist when the file is a fifo breaks
playback. the bug report is a special case of `/dev/fd/*` but
even for named fifos, opening and closing them can cause the
other end to stop writing.
Closes: https://github.com/mpv-player/mpv/issues/17682
Some commands have named arguments named "name", which conflict with
the "name" entry used to specify command name in mpv_command_node, so
they cannot be used with mpv_command_node.
These commands include:
set, del, change-list, add, cycle, multiply, enable-section,
disable-section, define-section, script-binding, keybind, keypress,
keydown, keyup, apply-profile.
This makes mpv_command_node accept command name as key "_name", so
"name" can be used to specify command arguments. For compatibility,
if "_name" entry does not exist, then "name" is used as fallback.
If --input-ipc-server path name starts with "@", then "@" is replaced
with a null character, which represents the abstract socket namespace
on Linux. Because abstract sockets have no file system presence, it
should not delete the file with the same name starting with "@".
Previous commit left the common %s format extension unresolved.
This implements the format in a platform independent way so it can be
used on all platforms, including on Windows where strftime does not
support %s.
The format specifier is controlled by the user that can be arbitrary
character. Using invalid specifier in strftime is UB. Fix this by only
accepting the specifiers recognized in C11.
Partial compatibility is provided for extension formats k, l, P by
translating them to the closest standard alternative.
mp_input_get_tablet_pos stores the address to an array that is protected
by lock, and the content is accessed without acquiring lock.
Fix this by writing the values to an array inside mp_input_get_tablet_pos.
Fixes: 0fbf20f057
When buttons > MP_MAX_TABLET_PAD_BUTTONS and the value is stored in
ictx->tablet_pad_buttons, the next mp_input_set_tablet_pad_focus call
will cause out of bound write, and mp_property_tablet_pos will cause
out of bound read.
Fix this by limiting ictx->tablet_pad_buttons range.
Fixes: 0fbf20f057
pass_upload_image currently stores the logical dimensions, which
in case of vulkan decoding may not match the physical one (e.g
1088 for 1080p). this mismatch results in glitches when using
polar scalers.
fix this by using the actual texture dimensions for hwdec plane
sizes.
Fixes: https://github.com/mpv-player/mpv/issues/14944
When XdndEnter advertises format without using XdndTypeList, some of
the atoms in the 3 fixed items may be None, which causes error in
XGetAtomName. Fix this by not resolving name when atom is None.
Fixes the following error message when dragging file on mpv window:
X11 error: BadAtom (invalid Atom parameter)
This allows using --licensedir. Meson then also generates and
installs a machine-readable manifest file at that location, which
would include the licenses of subprojects if we had any.
Add optional 'default-value' and 'choices' fields where appropriate
for command arguments in the 'command-list' property. Update
documentation to reflect the command-list schema change.
DOCS/interface-changes/command-list: add changes
These are ancient and not useful anymore.
The version notices are kept under:
overlay-add: handled by #17520
end-file's file_error: the notice should be removed when updating error
field like suggested there
time-start: this should just be removed
~/.mpv/: needed to understand why this is used
--aid: needed to understand the following paragraphs
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.
vo_wayland_handle_scale may be called from reconfig, even before we get
the first toplevel_configure. In this case, don't use the surface local
coordinates because they will be initialized as 0.
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.
Tablet input is more similar to mouse input than it is to touch input,
so it makes sens to use wayland-edge-pixels-pointer instead. Also
document that it's used for tablet input, previously this was completely
undocumented.
Using "mpv --directory-filter-types= dir" as an "empty" value doesn't
work, because that will create a list where the first value is an empty
string, so get_directory_filter() returns AUTO_NONE instead of AUTO_ANY.
You need to use --directory-filter-types-clr instead, to create a proper
empty list.
I suppose this is kind of obvious in hindsight, but it took me quite
some time and digging through the mpv source to figure this out –
initially I assumed it must be a bug of some sort.
So clarify what "empty list" means.
LLVM even in freestanding build required memset/memcpy/memmove to be
implemented. We don't use them directly but the calls are generated from
the code, which are later optimized away. Since this suppose to be small
utility application, we can always optimize it.
Fixes: #17664
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.
Replace order-dependent struct initialization of Wayland listener
structs with designated initializers.
Besides making it harder to make ordering mistakes while adding or
changing code, also makes it easier to grep for specific events because
our callback functions aren't necessarily named the same as the event
names (e.g. global_remove = registry_handle_remove).
It's still invalid for max_lum to be less than or equal to min_lum, so
do the check before set_luminances call. Also rename the function
because it does more than just check if it's valid, it also sanitizes
some invalid values.
Also changes the TRC_LINEAR case a bit, because min_luma == 0 isn't
exactly invalid, only min_luma >= max_luma is invalid which is covered
by the sanitize function
This fixes multiple overflows when passing huge values. Which causes
either invalid memory accesses when memory allocations are wrong size or
huge allocations leading to OOM.
Reported by: Trail of Bits
When force-window-position=no place window on requested position only on
init (when VO requests `force_pos`), except that keep existing
position on auto resizes.
This applies to both user provided geometry and default center
position.
Fixes: #17588
This util function uses the generic libavutil hash API to hash any data
with the specified algorithm to a bstr. It deduplicates multiple hash
routines used in mpv.
This fixes dynamic hwdec switching, which would often fails, because
hw decoder were feed data without context, which caused decoding errors,
which in turn disabled hwdec.
command.c does queue_seek() after decoder reinit, but it may already be
too late, by the time seek to keyframe finishes.
Fix this, by just discarding the data until we have safe point to start
decoding again. Limit this only for hwdec to avoid formats that may not
have ffmpeg parser and not give us keyframe information and limit to 96
frames, just as safety to not lock the player, but this shouldn't happen
in practice.
This should also fix cases, when media file is cut in a way that would
cause decoding errors at the start.
Fixes: #17484
in macOS 11 Apple changed AppKit to disallow use of the fullscreen
window style by custom full screen implementations, reserving this style
for their own implementation. mpv's custom implementation had to
workaround this by manually applying changes to the window to match the
fullscreen window style.
in macOS 26 Apple made changes to enhance visual depth. This
included making a window's shadow more pronounced. This revealed
the workaround was missing code to remove the window's shadow when in
full screen mode. This was especially visible when the macOS appearance
was set to dark and a dark video was played with --native-fs=no. The
window's shadow under macOS 26 was visible as a very thin white outline
around the screen.
this fix will enhance the workaround in the macOS custom full screen
implementation to toggle NSWindow.hasShadow when entering and exiting
full screen mode under macOS 11+.
Fixes: #17586
Fixes some corner cases when resizing window with keep aspect ratio
enabled. Limit correctly window to working area, also after adjusting
aspect ratio to avoid unexpected resizes and window not staying in
position. Use integer math to have consistent rounding, to avoid window
"drifting".
Fixes: #8728
This uses the update_data request for clipboard backends that require it.
When clipboard monitoring is disabled, the backends will no longer
fetch data when it detects data change, and will now only do that when
receiving the update_data request.
The client now needs to run this command to update the clipboard content,
otherwise the property value is outdated.
This makes sure that applications that depend on "paste once" behavior
work correctly.
This command runs in a separate worker thread so that it can be used
as a "blocking" way to update clipboard until the update notification
arrives without blocking the playback core. It accepts a maximum timeout
parameter. This uses the existing mp_cancel mechanism to make sure this
command can be aborted and the worker threads will not stall the player
too much when quitting mpv.
For backends that do not support update_data, this command does nothing.
There is no reason to create and destroy this storage. They can be
zeroed instead when destroyed. This simplifies some logic and prepares
for the next commit.
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.
This version contains critical fixes to swapchain selection, correct
mapping of sRGB TRC as well as fix for gpu hangs on anv. Bump the
minimum version because the mpv experience with previous version
shouldn't be endorsed or be considered acceptable by upstream.
libavutil deprecated AVVulkanDeviceContext.lock/unlock_queue without
replacement [1]. This prevents us from using queue locking, as those
callback will be removed in lavu. Set those callbacks as long as they
are still present, they will be noop in libplacebo with
`VK_KHR_internally_synchronized_queues`.
It's unclear what will happen to devices that do not support
`VK_KHR_internally_synchronized_queues` when the lock/unlock_queue
callbacks are removed.
[1] https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/c102e89448a06d9920920923a4008fee3db4ea37
The keyword here is "try". mpv attempts to accept data offer on motion,
by using the time as the serial... which doesn't do anything. We already
accept data offers on data_device.enter so this doesn't do anything even
if we used the right serial.
Fixes: 68f9ee7e0b
This uses Fluent UI System Icons [1] as a source for icons. The glyps
are generated using `TOOLS/gen-fluent-glyphs.py` script, which downloads
Icon and convert for our mpv font to use. Glyphs are vendored in our
repository to avoid external dependency.
Script could be extended to add more icons/variants easily, currently
only filled version are imported.
[1] https://github.com/microsoft/fluentui-system-icons
There is concern that with certain user options or script the value of
`{sub,osd}-margin-y` value may be persisted or overwrite user option
when it's changed while OSD is visible and offset is applied.
Fix this by using dedicated option.
mmap in inherently crashy due to the file changing underneath
and requires esoteric SIGBUS handling [0] to use properly.
to reproduce, simply use "overlay-add" from a lua script with
invalid stride set and observe mpv crashing with SIGBUS.
here we're just copying the file content (introduced in
549a9ea) and munmaping it immediately so there's no real need
to be using mmap to begin with. avoid the issue entirely by just
reading the file directly with fseek+fread with optimization for
the common stride case.
one notable difference is that since dup-ed fds share same
offset, the source "fd" that's coming from client will now have
it's offset modified. `pread` could avoid this issue but it's
not supported on windows.
[0]: https://www.sublimetext.com/blog/articles/use-mmap-with-care
This allows to retain deadzone in the middle of the screen when both top
and bottom bars are enabled. We also doesn't have to show bars that
early before moving mouse down.
If `no-border` or `no-title-bar` was used, window controls would enable
also in fullscreen, this was inconsistent, as window decorations are not
visible ragardless of those options in fullscreen mode.
Those strings has to be owned by mp_codec_params, not decoder wrapper
priv.
Our assumption is that we set those strings here once on decoder init
and they will not be changes during the life time of the
mp_codec_params, hence why we need to make sure they are not deallocated
too soon, in case they happen to be in use.
Fixes, use after free in some cases, when tracks are deselected.
Those zones use input sections, but in OSC we allow them to overlap. So,
we might switch to the other section, after which point we won't get
mouse_leave event that would hide the bar for the other section.
This makes hidding/showing WC and OSC more consistent.
Packet pool is useful to avoid work and additional allocations when
switching files, going to idle should free the pool as those packets may
not be used for some time.
Fixes: #17525
Currently, there is no hook which happens when the playback actually
starts. The on_preloaded hook is insufficient for many cases, as many
track information are unavailable at that stage. This makes it impossible
to act on certain track metadata before the media is shown to the user,
so the user will see the media before action for a brief moment before the
properties are notified and options are changed.
This adds the on_loaded hook which allows the mentioned information
available.
This commit allows a table of script-opt overrides to be passed to
`mp.input.get()` and `mp.input.select()`, which console.lua will use
instead of the its own.
To minimise required changes, metatables are used to allow console.lua
to seamlessly fall back on the original script-opts if the client does
not provide an override.
To prevent exceptions, the incoming opts must be of the same type.
wl_display_roundtrip performs one roundtrip one the queue, but there's
no guarantee that the callback will be invoked within that roundtrip.
Instead of hoping one roundtrip is enough, dispatch the queue until the
pending flag is cleared explicitly.
There are at least two users of this functionality, the filename/no-ext
property and the screenshot template %F specifier. The latter uses a
buggy private version. So split out what the former does, so it can be
reused.
Co-authored-by: Guido Cella <[email protected]>
The detection for leading dots was in the wrong place, in case path was
not already a basename. Fixed by acting on basename. Also all leading
dots are now getting skipped, otherwise the root of `path/to/...ext`
could end up as `path/to/..` which in the wrong place/context would mean
directory traversal.
Additionally, since we act on the basename there is no longer a need to
test for trailing path separators. The previous check also did not
account for Windows paths with \ separators.
Co-authored-by: Guido Cella <[email protected]>
There is no reason to create the screenshot dir separately, because the
final path starts with it. So defer creating directories to the last
possible moment with all the information necessary.
URLs can end with trailing slashes (/) which in turn results in GNU
basename[1] returning the empty string, i.e. when the filename property
is queried. Instead use the whole path for everything that ends with /.
Subsequent path sanitation takes care of translating invalid path
component chars.
Issue reproduction steps:
```
mpv \
--screenshot-dir=$HOME/mpv-shots \
--screenshot-template='%f/%P' \
https://example.org/video/
```
This would result in %f expanding to '' and thus render
screenshot-template an absolute path which, for some reason, would in
turn take precedence of screenshot-dir and hence result in a
non-writeable path, i.e. `/timestamp.ext`.
With this new approach the resulting path looks like this:
`/home/user/mpv-shots/http:__example.org_video_/timestamp.ext`
[1] https://github.com/mpv-player/mpv/pull/14635#issuecomment-2269456187
Co-authored-by: Guido Cella <[email protected]>
set_color conceptually is a swapchain command, but in Wayland it's
implemented in ra_ctx, so we have one jump of indirection. Having
`set_color` defined for context_vulkan doesn't mean that all ra contexts
support it. Add a bool to mitigate this.
This could be structured differently, but should be fine.
Fixes: #17487
It is unclear why this should be recommended. If it were recommended it
would be the default. The consensus is that centered justification looks
better.
Document more shared fields with input.get().
I originally omitted them because they didn't seem useful for
input.select(), but now opened can be used to override keybindings, and
default_text = "'" can be used to default to exact search (which I do
for history in my build).
closed, default_text and cursor_position may be used to remember the
last input line for the next call.
get_virt_mouse_pos() can return dummy -1, -1 in some cases, for example
when mouse is not considered "in" the area. render() is called
immediately and sets the initial mouse position to -1, -1 when the first
tick happens.
When starting player and mouse is already on the window but not moved,
then move the mouse, the mouse_move handler thinks that the mouse moved
from -1, -1 to the current position, triggering showing even when the
amount moved is less than osc-minmousemove.
Fix this by not letting render() init mouse position if the position is
dummy -1.
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.
Some sites throttle requests, but throttling can be avoided with many
small range requests. yt-dlp implements a "http_chunk_size" key in its
-J output to inform us of the ideal size.
https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21703 has just been merged,
which allows use the http_chunk_size to greatly speed up how fast
YouTube videos get loaded into the cache by mpv.
Should the FFmpeg that mpv is built against lack the request_size
AVOption, then this will silently not do anything new, so no version
checks are needed.
Specifying multiple_requests=1 like suggested in
https://github.com/mpv-player/mpv/issues/8655#issuecomment-3872689494
does not seem necessary.
Fixes#8655.
Supersedes #15612.
Co-authored-by: Nicolas F <[email protected]>
This commit should remove any unexpected behaviour or crashes
that
may be caused by users passing unexpected values to mp.input functions.
String and numerical options are now explicitly converted to strings and
numbers. Values which should be tables are set to empty tables, and
warning messages are printed to inform the user.
All but one of these guards should never be tripped
if people are using the mp.input
module. However, it could happen if non-lua/js clients were to use the
JSON API directly.
Currently, without these guards, calling these script messages with
incorrect arguments will almost certainly crash `console.lua`, hence
preventing any client from requesting input.
An error message has also been added for each guard to provide some
feedback as to why the arguments were invalid.
If you set file-local-options/foo at runtime and run playlist-play-index
current or playlist-play-index $current_pos, file-local-options/foo is
reset. Add a flag to make it preserve file-local-options.
The advantage of this change is that it allows binding Ctrl+r set
file-local-options/start ${=time-pos}; playlist-play-index current yes
to reload the current file while preserving all options, independently
of --no-config, --watch-later-options or --reset-on-next-file, and
without writing watch later files to disk. It also preserves
file-local-options set on the CLI unlike loadfile.
most of the time not doing so will still work since ffmpeg has
some heuristics in place to detect if the url is percent encoded
already or not. but these heuristics are not foolproof and so
document this quirk explicitly.
At the issue templates "tested with the latest version" checkbox, make
that a link to the latest version, revise the text slightly, and add
"or newer".
At the linux issue template, also note that if the distro does not
provide the latest version, then the issue should be reported to them.
This commit flags when console.lua is waiting for completions, and
disables the completion cycle key until up-to-date completions are
received.
While this is happening, completions are not printed when in terminal
output mode. In normal OSD mode, the completions are still printed, but
at reduced opacity. This is to avoid distracting and ugly flickering
from completions being rapidly erased and redrawn.
The completion results are only dimmed after a short (sub-second) delay.
This is to avoid distracting flickers from the opacity
rapidly changing for clients that return completions almost immediately,
e.g., commands.lua.
Previously, completion responses from the same client would be displayed
even if the user had since changed the input, as long as a newer
complete event had already been sent. This meant that, if clients took a
sufficiently long time to return completions, then
console.lua would display completions for previous versions of the line
which were no longer valid.
This commit has the client send back the version of the line their
completions apply to, ensuring that `console.lua` displays the
correct completions.
Updates to use the new response function passed to
`complete` events to send completions back to `console.lua`. This is to
pre-empt the old return value method being deprecated.
Previously, it was impossible to generate a list of completions for an
`input.get()` request asynchronously, as the values had to be returned
by the callback function.
This commit provides a way to send completions asynchronously by passing
a second argument to the complete callback; a function which can be
passed the return values to respond to the complete event.
This undocumented option was used by `stats.lua` to prevent the page
scroll keys from being overridden by `console.lua`. The previous commits
have removed the need for this hack, so it is now safe to remove.
This commit uses the opened event to ensure that the page scroll keys
(`UP`/`DOWN` by default) override the mp.input bindings,
without overriding any other mp.input keys.
This is much safer than the previous method, which required an
undocumented option to be passed to `mp.input`, and was hardcoded to the
default scroll keys.
This commit uses the undocumented `mp.flush_keybindings()` method
to ensure that all `console.lua` keybinds are set before
sending the `opened` event to `mp.input` clients.
Previously, the keybinds would only be flushed when `console.lua` went
idle. As the `opened` event is sent before this happens, clients
processing the event may end up flushing their own keybinds before this
happens. This makes it unreliable to use the `opened` event to override
keybinds set by `console.lua`; for example, adding different
behaviour to `input.select` when using `Shift+Enter` instead of `Enter`.
This commit allows the `opened` callback to be used to safely override
`console.lua` keybinds.
.luacheckrc: move flush_keybindings to globals
This incorrectly used clamp_double function after 0e7f9c39dc when it
should've always used clamp_float instead. Use clamp_float instead
Fixes: 0e7f9c39dc ("m_option: correctly clamp OPT_FLOAT values")
This allows to use DXGI enums for color spaces, which supports PQ
transfers and so on. Old D3D11_VIDEO_PROCESSOR_COLOR_SPACE is limited
and doesn't support HDR formats.
This is needed for ra_get_imgfmt_desc() which otherwise would not allow
rgba10_a2 format, because it doesn't have all components with the same
size. However it's nativelly supported by d3d11, so we add it to special
formats, same as opengl does.
The optimal way would be to use custom rate based on telecine cadence,
but it's not supported by any driver in practice. So instead, allow
driver to field match and output with duplicated frames, which can be
removed using decimate filter.
Note that in practice all GPU vendors uses single video processor for
all deinterlacing, so IVTC will be done even if mode is not explicitly
selected. At least the field matching part, because correct rate output
is not supported. The main difference is that when selecting more we
output at video frame rate, not field rate.
There were multiple issues in API usage, not setting correct
OutputIndex, lying about frame field parity to make it work without
OutputIndex. Not passing reference frames which forced BOB mode always.
Fix all issues and allow forcing BLEND/BOB mode by not passing frames.
Blend mode also sets half rate output. Half rate could be separate
option too, but there is not much gain from it except for debugging
really.
Fixes: #15197
This was a typo. Although this changes the user option name, this
filter, especially this option, is so niche that I fix it without a
deprecation period.
Since we call bstr0 on the string anyway, might as well use it for
printing which implicitly includes a null check that gcc can see so it
doesn't produce the warning as seen in the next commit anymore
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.
Waiting for color management from the compositor doesn't make sense in
other cases and this breaks --force-window since the playloop doesn't
advance. Fixes#17391.
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.
This was a mistake. It's too situational and it's not worth complicating
the API and every mp.input client with it. It made some sense before I
implemented input.select() because you could use input.get() to input a
choice and validate it, but in general for input.get() clients it's
better to show an error with input.set_log() instead of adding new lines
to the log everytime. This is what e.g.
https://framagit.org/Midgard/mpv-subber/-/blob/master/subber.lua does.
So this is only marginally useful for REPL scripts that keep adding
lines to the log, and the only such scripts are commands.lua and my
lua-repl.lua. commands.lua never used it and I already removed it from
lua-repl.lua. Cloning all scripts in the wiki reveals that **nobody** is
using log_error(), confirming that it is safe to deprecate.
Any errors when opening the display are now logged.
The WAYLAND_DISPLAY check now also logs and applies only when probing.
This means explicitly setting a wayland `--gpu-context` will always
try to open the display instead of "helpfully" refusing (in some cases).
see also: f6f1721101
extends f3c1dcf7a1 for all lines not just
the last. This avoid unnecessary write every line and fixes a buffer
overflow for small enough images (for example 78x64).
Move PathCchRemoveFileSpec after actually getting the file size. It must
have been swapped at some point by accident.
Also use correct unit for the size.
Fixes: #17375
try to define a `[foo \ "bar"]` profile in mpv.conf, the command
to apply it in context-menu is `apply-profile foo \ "bar"`,
which is obviously incorrect, the correct command should be
`apply-profile "foo \\ \"bar\""`.
for string arguments that may contain spaces or some special
characters, we need to quote and escape them in JSON-style,
fortunately, `utils.format_json` can do this very well.
Fixes a deadlock when switching vo before a frame is displayed (e.g.
with auto profiles) where we'd end up in a state where wait_on_vo is set
to true for the first frame and then draw_frame is never called again so
its value never changes even once dmabuf-wayland is ready to advance
frame
Fixes: 468d34c9bd ("vo: allow VOs to request waiting before advancing frames")
As per Samillion's suggestion, reduce the contrast between separators
and the background to match other context menus. Using the already
defined disabled_color works for this and seems to be what GTK and Qt
do at a glance.
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.
The playlist submenu does not update in this edge case:
- Have a playlist-count > 99 on the first vo-configured. This makes
playlist() return before observing --osd-playlist-entry.
- Remove playlist entries until the count is < 100
- Change --osd-playlist-entry
- Show the playlist submenu before changing the playlist
Currently, if some log lines have very long text that actually
renders across multiple lines, even if you scroll to the top,
the topmost content will be pushed out of the screen by these
lines and will never be visible.
In STATS page 2/4/5/0, you can scroll down until there is one
line left on the screen, we can keep the scrolling behavior of
the log consistent with it.
Observing playlist-pos and playlist-count is not enough to update it
after playlist-move, but we can observe any playlist property with type
none to get notified of every MP_EVENT_CHANGE_PLAYLIST, even if the
property has not changed.
This is similar to the
mp.observe_property("vsync-jitter", "none", recorder) hack used by
stats.lua to replicate the deprecated tick event.
Fixes https://github.com/mpv-player/mpv/pull/16816#discussion_r2727498518
Rebind MENU to show the context menu. Shift+F10 is also bound because it
is a standard context menu binding.
MENU is not added to restore-old-bindings.conf because it is uncommon.
Make select.lua parse menu.conf on the first vo-configured and fill
menu-data with the properties referenced in menu.conf change. This is
disabled in the libmpv profile.
This is done from select.lua to reuse functions to format the data and
retrieve key bindings.
There is also a script-binding that opens the correct context menu
depending on --load-context-menu.
While the context menu is scrollable, for the playlist it is better to
start from around the current entry rather than from the beginning, and
since menu-data has no way to specify where to start, when there are
more than 25 items playlist items this adds … entries that open the
scrollable console menu when clicked.
input-bindings is parsed to show the shortcuts bound to commands. Since
it is not observable, it just uses the bindings from the first time the
context menu is opened.
Multimedia and numpad keys are also not shown to reduce clutter.
The old Context Menu section of the docs is merged in the more detailed
context_menu.rst to not repeat the same information.
Avoid showing forced key bindings by modal scripts that temporarily
overwrite keybindings, like console and stats. These have section
input_forced_$scriptName. Unfortunately this skips all keybindings added
with mp.add_forced_key_binding even if you may want to show them.
Also skip the OSC sections "input" and "window-controls"; these sections
are not called input_forced_osc because the OSC uses
mp.enable_key_bindings() directly instead of mp.add_key_binding().
This mainly benefits the shortcuts in the context menu that the next
commit will add, but is also useful select/select-binding.
Add a default context menu definition in etc/menu.conf. It will be used
to populate the context menu.
The format is meant to be easily readable with just tabs as separators
and submenus denoted by indentation. It avoids complicating the builtin
input.conf like similar scripts do.
By not defining the shortcut keys in the builtin input.conf, menu
entries won't be associated to wrong shortcuts when the user's
input.conf changes key bindings without redefining the menu. Note that
external scripts don't have this issue.
I used 3+ spaces as separators at first but then realized that since we
have Windows users tabs will look better in editors with proportional
fonts like notepad, though it still won't be perfectly aligned depending
on the font. But I am still not sure what is better.
On a curious note, etc/menu.conf already existed in the past as mplayer
used to have a menu. git log -p etc/menu.conf will show commits from
2002 to 2011.
The formatting of input.conf commands is totally inconsistent. At least
for the commands that will be used in the context menu, make it
consistent. The next commit will define the context menu commands, and
the keys bound to these commands will be shown in the menu only when
they match exactly, so this avoids copy pasting commands with
inconsistent formatting just to make them match.
When a character in an item's title is preceded by &, underline it and
activate the item when pressing the character.
Cycling between multiple items with the same hint is not supported.
&& escapes & so it works like the Windows context menu.
Hints after &&&, or greater odd numbers of &, are not supported since
Lua patterns don't support {n,m} quantifiers.
Don't reset system menu state, when menu data is empty, just disable the
items as needed. Fixes erratic behavior of system menu.
Fixes: 861908c70fFixes: #17290
Common layer should alter target params anymore, it's on specific VO to
set correct params. Also this should be noop anyway, after
dmabuf_wayland fix in previous commits.
This will do a little bit more than only setting max_luma. Also will
fallback to bt.709/bt.1886, but that's fine. We would do it anyway
later.
If params goes through guess_csp, they shouldn't have "unknown" fields
anymore.
Currently, we prefer selecting a track that matches the video program
ID, but can fall back on a track with a different program ID when there
is no such track or when no such track matches subs-fallback criteria.
Change this to instead select no track when only tracks with wrong PID
are available. Program ID will now act as a filter, not as a preference,
and only files with either matching or unset PID will be considered for
autoselect.
Also, ignore the program ID of external tracks, as it doesn't make much
sense to compare PIDs from different files.
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.
Currently entries in playlist files like m3u are first added to the
playlist, and then if they were relative paths the playlist file's
dirname is prepended to them.
Change it to directly add entries with the correct path. This will be
needed to normalize playlist entries as soon as they are added, else
normalization would prepend the working directory to entries with
relative paths.
demux_cue, demux_edl and demux_mkv_timeline don't need to be modified to
work with the next commit.
We need to acquire in->lock first before setting this flag, but if we
take this path then request_redraw is true already. So fix the data race
by just not re-setting the value.
This fixes data race detected with checking in->request_redraw value in
vo_redraw detected with TSAN
Add a missing variable initialization. The variable is only conditionally set
later. Then there is a check for a NULL if no CTA block was found, but the
value is instead uninitialized memory. There would then be a segfault when the
pointer is de-referenced.
the default value of isOpaque is false and it was always assumed that
underlaying content needs to be rendered and blended in some way.
make it dependent on the layer's isOpaque property, which theoretically
could increase render performance.
this adds support for possible transparent rendering by setting the
window and layer background to transparent.
NOTE: atm only possible with libplacebo master.
github.head_ref is only defined for pull_request event, so only those
will be grouped, the rest will fallback to unique run_id, so we neither
cancel them or serialize.
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.
In f914947dda we implemented a hack to
force 8bpc dithering for SDR playback, because at the time nothing in
the pipeline was doing dithering. mpv would pick 16bpc swapchain, dither
down to 16bpc, then it'd be presented to the user's display as-is and
result in banding. There is no way to detect the real on-the-wire bpc,
so we told users to configure dither-depth manually.
However, it seems most compositors that do color management now handle
10-16bpc input just fine without any banding, so instead implement
color_depth to effectively set dither-depth=auto for compositors that
support expose color_manager and keep the 8bpc hard default for others.
Fixes: https://github.com/mpv-player/mpv/issues/17222
Since with the new horizontal scrolling the end of lines can be visible,
ensure not to clip lines in the middle of UTF-8 characters to not show
mojibake, also adding … to show when items are clipped.
Also replace the existing use of ⋯ with …
Bind Shift+LEFT, Shift+RIGHT, Shift+WHEEL_DOWN, Shift+WHEEL_UP,
WHEEL_LEFT, WHEEL_RIGHT to scroll the menu horizontally.
This lets you see long items that get clipped, like long history entries
and key bindings.
We don't know how many log lines wrap, so scrolling the log with page up
and down with wrapped lines would skip lines, and those are also already
bound to history navigation.
This therefore only implements scrolling of one item at a time. While
not perfect because when the item is wrapped it scrolls multiple lines,
it is usable.
The number of log lines kept in memory is increased from 100 to 10000.
Closes https://github.com/mpv-player/mpv/discussions/14718.
with `scale_with_window=no` script option, `first_match_to_print`
increases when shrinking the window and no longer decreases when
expanding the window, causing empty lines at the bottom of menu
and a chain reaction of the script crashing due to the mouse wheel
scrolling up.
this commit trys to decrease `first_match_to_print` when its value
is abnormal.
Closes#16682
813c112329 moved force window to option
callback. This happens before the loading of the file has finished
(which is supposed to trigger handle_force_window) so it is too early to
handle certain cases, such as loading of album art failed and therefore
window will never be created because there is no video track.
Adding force window check in playloop to make sure window is always
initialized after file loading is complete.
Fixes: 813c112329
Wrap subrandr build process into meson custom target.
Meson's custom target allow only file output (without path component),
so additionall copy step is added to get the library. Dummy stamp file
is used to connect custom target to dependency, the file is actually not
created, so target will be called each time, but it's fine, because
cargo will resolve it's own dependencies this way and build if needed.
This is glued only for static lib, this is what we need for our CI
script.
Sanitize the remaining control codes to mitigate malicious files or
scripts that could manipulate the terminal in unintended ways, such as
clearing the screen or changing the terminal title. While the
surface-level impact may seem minimal, control codes can be a vector for
exploiting vulnerabilities in the terminal emulator itself. This can
occur without user interaction, since file tags are displayed by default
in mpv.
Reported by: zefr0x
add libbluray, libarchive, libcaca, libcdio-paranoia, libdvdnav,
rubberband and zimg to macOS builds for consistency with other platforms
and detection tests.
adding IDs to the fields makes them pre-fillable with a URL query.
adds the possibility to procedural generate links to pre-fill specific
data. for example, mpv/library version or platform version data.
possible application, menu entries or CLI output to submit bug reports.
42660a8c23 renamed selected_color and selected_back_color to
focused_color and focused_back_color. The new names have been in a
release so remove the backwards compatibility check.
Some platforms (like macOS) may have multiple Vulkan drivers installed,
so the device list can contain devices with the same name.
Adding driver name to the list of devices can help with identification.
This fixes a race condition where if a non-chapter seek is queued
immediately after a chapter seek is queued, the chapter property may
become unavailable until a new file is loaded.
If multiple seeks are queued within the same playloop iteration, only
the last seek is executed. Because the chapter seek is never executed,
last_chapter_flag remains set and last_chapter_seek becomes -2, which
causes get_current_chapter to return -2, which makes the chapter
property unavailable.
Unset this (and also last_chapter_seek) immediately rather than
wait for seek execution, like chapter seeks set these immediately.
Fixes: 233f1e46f6 ("playloop: make chapter property more accurate when seeking chapters")
When the "new" API for OpenGL VO backends was created 10 years ago in
df97c30e0e, it was expected that any
"driver" that fails to init to clean up themselves (the "old" API always
called mpgl_uninit() to clean up on failure).
However, when switching Wayland to the "new" API, this was forgotten.
Wayland VO will never be cleaned up when EGL init fails.
With commit a310a65d35, this issue was
exposed when a leftover Wayland context pointer, which results from a
successful Wayland context init but with failed EGL init, triggers an
assertion in the X11 context init code, which expects the pointer to be
NULL.
Fix this by uninit Wayland context when EGL init fails.
Fixes: bd87598af9
Subtitle extraction preserves empty lines in LRC subtitles because they
are useful for separating verses and choruses. 036fae317c changed their
sub codec from subrip to text, so update select.lua accordingly.
compute_bounds doesn't return any field if the rectangle is empty: its
docs say "If set to true, attempt to determine bounds and write them to
the command's result value as x0, x1, y0, y1 rectangle (default:
false). If the rectangle is empty, not known, or somehow degenerate, it
is not set.". So shrinking mpv as much as possible with a menu open
caused a crash.
This doesn't happen on Xorg because of these lines in video/out/x11_common.c:
// Set minimum height/width to 4 to avoid off-by-one errors.
hint->flags |= PMinSize;
hint->min_width = hint->min_height = 4;
nor on macOS because of
minSize = NSSize(width: 160, height: 90)
in video/out/mac/window.swift.
But this is needed on Wayland and Windows.
Fixes#16682 along with the diff posted there.
D3D11 only for now. Documentation says that only D3D11 and D3D12 is
supported, but it looks like Vulkan is possible too. But I realized this
after implementing this version. Vulan may be added later.
Fixes: #16613
subrandr is a subtitle rendering library which aims to render
SRV3 (YouTube) subtitles and WebVTT subtitles accurately.
Currently in mpv WebVTT subs are rendered via ffmpeg conversion to ASS
which throws away a lot of the style and completely disregards
the WebVTT non-region-cue positioning algorithm. Furthermore if
one wants to render some more complex SRV3 subtitles one has to
resort to external converters since it's not even supported by ffmpeg.
However subrandr is able to render SRV3 subtitles natively with support
for the most commonly used features. It can render ruby text without
relying on font metrics during conversion which is obviously fragile,
and it can perform correct scaling using the exact calculations used by
YouTube instead of making up ASS approximations. Similarly it follows
the WebVTT spec for the features of WebVTT that it supports (mostly).
It's not perfect of course and there's still many things it doesn't do
or does wrong but those are things that can be incrementally improved
outside of mpv.
duration and position properties were observed as double which lead to a
lot of updates per second (high granularity). it is recommended to not
update the position of the touchbar too frequently, why we had a manual
1 second rate limit.
instead of manually rate limiting the property, just observe it as int64
which only updates every second. it also causes a bit less pressure for
our core.
duration and position properties were observed as double which lead to
a lot of updates per second (high granularity). it is recommended to not
update the position of the remote command center to frequently, why we
had a manual 1 second rate limit.
instead of manually rate limiting the property, just observe it as int64
which only updates every second. it also causes a bit less pressure for
our core.
generated with the Icon Composer project:
actool ./icon.icon \
--compile ./ \
--app-icon icon \
--enable-on-demand-resources NO \
--development-region en \
--target-device mac \
--platform macosx \
--include-all-app-icons \
--minimum-deployment-target 10.15 \
--output-partial-info-plist /dev/null \
--standalone-icon-behavior all
actool will generate an Assets.car file which is compatible with all the
new Theme variants of macOS 26 (default, dark, monochrome, tinted, etc).
it also generates an old icns file as a fallback, only default style.
since the new Assets.car file can't be used from cocoa directly, without
using private APIs, we still use the icns file when used from CLI.
this also means that from CLI only the default icon is used and the
macOS theming doesn't have any effect.
the macOS theming mechanism only works with the bundle and a Assets.car
file. all icons are generated on the fly depending on the Theme. this
generation has no public API and the mechanism would need to be
replicated by hand. to replicate this behaviour at least three different
icns would need to be generated, tinting needs to be implemented,
several system events need to be subscribed, and this wouldn't guarantee
the same look as the system mechanism. also none of the tools make it
possible to generate macOS 26 compatible icns file, besides for the
default file, since it at least is missing the necessary padding.
This reverts commit e9c43258b8.
yt-dlp implemented its own parsing to extract chapters from the
descriptions of videos without chapter markers in the player over 3
years ago in https://github.com/yt-dlp/yt-dlp/commit/0fe51254 (the PR is
even inspired by mpv). Actually it was present even earlier in
youtube-dl but was removed for unknown reasons in
https://github.com/ytdl-org/youtube-dl/commit/67299f23d8b1894120e875edf97440de87e22308.
So we can remove our parsing code, as it is dead code that never runs if
yt-dlp's JSON already contains chapters.
And it seems that such videos without chapter markers are rare or
non-existing by now anyway - we can't find any.
https://www.youtube.com/watch?v=1v_4dL8l8pQ is linked from the yt-dlp PR
with the above commit, but now yt-dlp returns the Key moments as
chapters, so it can't be used for testing.
Our parsing was actually worse than yt-dlp's, because #16085 added an
option to disable it to fix the misdetection reported in #16081, but
yt-dlp correctly returns no chapter for that video
(https://www.youtube.com/watch?v=1v_4dL8l8pQ). So this code branch was
only running for misdetections, and by removing it that option is not
needed.
This adds option `--audio-set-media-role` to configure whether mpv
should set media roles to supported audio APIs or not. Disabled by
default.
By default, WirePlumber restores the volume of each application to
whatever the last application with the same media role used. This is
completely insane behavior, and I couldn’t find any way for a user to
opt out of it on my end. The `state-stream.lua` script responsible for
this mess only uses media.role if the property is present, so the only
reliable workaround is simply not to set one at all.
This WirePlumber behavior is inherited from PulseAudio, which also
exhibits the same behavior to this day.
This commit also mirrors the same change made to ao_pulse in 2015:
b7325b2f64
See also: https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/489
since we have a mapping layer between vulkan and metal (MoltenVK) we
don't actually know when the layer is opaque and direct-to-display is
possible.
log opaque state.
since we have a mapping layer between vulkan and metal (MoltenVK) we
don't actually know which EDR data is used/mapped to.
log EDR data changes to actually see which EDR data was chosen.
since we have a mapping layer between vulkan and metal (MoltenVK) we
don't actually know which colorspace is used/mapped to.
log colorspace changes to actually see which colorspace was chosen.
since we have a mapping layer between vulkan and metal (MoltenVK) we
don't actually know which pixel format is used/mapped to.
log pixel format changes to actually see which format was chosen. only
those 9 formats are valid for a CAMetalLayer.
https://developer.apple.com/documentation/quartzcore/cametallayer/pixelformat
playlist-remove has a required index argument, as indicated by the
documentation. However, in 332907e1d7
MP_CMD_OPT_ARG was mistakenly added, making it optional.
The effect of not specifying the argument is defaulting the index to 0
and always removing the first element in the playlist, which is not
expected.
Fix this by making the argument required.
Fixes: 332907e1d7
Unfortunately we don't have control over libplacebo and cannot
synchronize such changes, so just return `<unknown>` to be forward
compatible with any possible changed.
Note that this should be updated ASAP to support new values.
Previously this would be called on every frame presented, this only
needs to be called if display sync was active for the last frame but
isn't active anymore.
This hid the bug mentioned in #16947 if VO was active.
The previous method used in 2b38b382cf doesn't properly determine the
original depth. We use image->params.repr.bits.color_depth to determine
that now.
Fixes#16398.
Signed-off-by: Leo Izen <[email protected]>
This paragraph was added 10 years ago in f8dc5db315. Hooks are now
commonly used both in internal (ytdl_hook, auto_profiles) and external
scripts (e.g. https://github.com/mpv-player/mpv/issues?q=mp.add_hook).
They are the only way to handle events synchronously and nobody is just
going to change the API and break all scripts at this point, so remove
the warning.
This clears packets from the pool, that would never be reused under new
settings. Note that depending on demuxer state this clears only unused
packets, in some cases demuxer may still hold more packets than the new
limit. Fox example demuxer doesn't forcefully clear forward cache when
reducing the size.
Also keep packet pool, even if current file is not cached, this is
useful for all sorts of things and may be useful for next file.
This act only on user options values, regardless of internal demuxer
caching state, which can vary depending on track type or source.
This fixes options like --audio-file=- and avoids returning $PWD/- as
path and stream-open-filename when playing from standard input.
It will also allow storing playlist filenames as normalized without
checking for - at the caller.
Fixes 23b57e9f7f.
We need both a color surface and parametric support to attempt to apply
image description, not either one.
Fixes: 0a32f988ba ("wayland: move initial color management setup earlier in the init")
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.
Compositor will probably give us a parametric description anyway, but
mpv can handle icc files if it gives us one so allow compositors to give
us an icc file.
If we used get_preferred_parametric to get this image description, then
it is guaranteed to be parametric. If we used get_preferred to get this
image description, then it may or may not be parametric depending on the
compositor. If we receive an icc_file event, then the image description
is not parametric.
The only part of the protocol that is behind this feature is the
create_icc_creator which we don't use. We also seem to confuse the
presence of this feature to mean that the compositor will always give us
non-parametric image descriptions but these two things have no relation
with each other. Remove the feature check and use
`wl->supports_parametric` to decide if we want to use `get_preferred` or
`get_preferred_parametric` instead.
This also removes error messages for when the compositor doesn't support
parametric descriptions or when the compositor doesn't support
icc_v2_v4.
The user needs to set `icc-profile-auto` for the icc_file path to work
properly which isn't ideal but I'm not sure what to do about this and
likely won't make any big changes right before a release.
in a13a674363 we set the default category
for the bundle to games, to get certain benefits like better rendering
timing, better bluetooth latency, better threading, etc (bundle only).
though this also prevents low power modes and wrongly categories the app
for spotlight search etc.
set the default category to video and add an option to set the category
to games if one wishes to.
It produces some bogus warnings when UBSAN is enabled:
../demux/demux_mf.c:103:22: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
Which is clearly not possible at this point.
We want to have symmetry on the input and output. Also outputting sRGB
encoded image to gamma 2.2 display is clipping blacks. 2.2 displays are
more common and are reference sRGB display, which is what we should
target.
osxbundle.py currently reads the version number from MPV_VERSION, while
Meson first tries git describe before falling back to MPV_VERSION.
Update osxbundle.py to try reading the version number from version.h
before falling back to MPV_VERSION. This ensures that the version number
in the bundle matches the output of mpv --version.
on multi monitor setups the position of the window was wrongly computed
when the position was forced, eg the calculated rectangle was screen
relative but the function expected absolute coordinates.
this is a regression from 50042f5ee0 and
#15500, where support for --force-window-position was introduced. this
worked in simple one monitor setups and in some cases on multi monitor
setups by sheer coincidence.
calculate the absolute position of the window by taking the screen into
account when needed.
Fixes#16929
If you open the menu at startup, e.g. with --input-commands, it rarely
clips items completely because OSD dimensions are still 0, or as if they
were 100 because those are the default values before receiving property
notifications. Avoid this.
I previously tried to enable sdl2-gamepad by default and the CI turned all red.
In detail:
- SDL_config.h has macros that conflict with ours
- memory leaks caused the tests to fail
- main=SDL_main redefinition broke MSYS builds
The options remain disabled by default, but lets warn our users a bit.
handle_force_window() is called in play_current_file() and
run_playloop(), so it is never triggered if you do mpv --idle and then
change force-window at runtime. Move the playloop call to the option
callbacks to fix this.
Fixes https://github.com/mpv-player/mpv/discussions/16956.
Giving the UPDATE_VO flag to --force-window would not fix this due to it
having no effect if there's isn't already a window, which prevents the
bug described in 544240c829. It would also reinit the VO unnecessarily
when cycling between force-window yes and immediate.
On Wayland envitonments with Xwayland available but without
ext-data-control-v1, mpv will fall back to the X11 backend instead of
VO backend. This may result in clipboard not working properly between
mpv and native Wayland clients.
Fix this by disabling X11 backend on Wayland envitonments by default
and adding the --clipboard-xwayland option for manual override.
Logs produced with the terminal output method do not have timestamps
logged by default, unlike --log-file.
Add --msg-time to the instruction to retain this information.
Unlike all other codecs, ProRes RAW is pretty much guaranteed to be slow
as hell on the CPU, always having thousands of tiles. And even on a very
slow GPU, a CPU decode won't be anywhere near to usable to make a difference.
Fixes panning the video while it's paused and the OSD isn't redrawing.
wayland_common since c25129339d requests
redraw when there is a resize event so there was no issue with xdg
resizing but that isn't applicable to resizing due to panscan options
changing.
A demux_flush can cause corruption and a slight A/V desync, whereas
without it the angle will simply change on the next keyframe, as is
intended for seamless branching. If users want an instant angle change
they can still restart playback and seek to the current position
through Lua.
OLEDs report min luminance of 0.0002 nits, while we couldn't set this
with options due to limit. Set limit, so that we cannot exceed the hdr
black value used in libplacebo in worst case scenario of target peak 10
nits.
Fix crashes that won't happen in regular usage:
- If you open the menu with an empty menu-data and use keybindings
- If you open the menu with menu-data only containing hidden items
- If you invoke script-message-to context_menu select with the menu
closed
Could also be set to unknown, but let's keep it center, so any fallbacks
in other places wouldn't trigger. In practice it shouldn't be used for
non-subsampled formats.
Fix regression introduced in 90e3e104d9,
where all non-chroma subsampled formats (e.g. rgb8 or yuv444p) will
trigger a protocol error and get disconnected by the compositor due to
setting the chroma location on the color representation object.
GNOME-Shell 49 will emit this protocol error otherwise:
```
wp_color_representation_surface_v1#54: error 3: Commit contains a color representation with chroma location set and a buffer with a pixel format which is not 4:2:0 subsampled
```
How to reproduce:
- Run gnome-shell 49
- Run `mpv --vo=dmabuf-wayland some-image.png`
The video viewport source rectangle is prevented from being set while
force_window, but we should also unset it because it will be set if a
video is played before entering force_window. Fixes out_of_buffer error
from Weston and wlroots in this scenario.
Currently, screenshot being scaled and the presence of OSD and subtitles
cannot be independently controlled. This adds osd and scaled flags to
screenshot commands that make it possible to e.g. take screenshots with
only OSD without subtitles, or take screenshots at scaled resolution
without OSD or subtitles.
The "window" flag is now an alias of scaled+subtitles+osd, and is kept
for convenience.
Instead of hardcoding the threshold and keep duration in a header,
expose them as options for users to configure and set old hardcoded
values as the new defaults for those options.
We currently force PQ output when target_csp() is not available, to
preserve compatibility with backends that do not support it and to
enable HDR on them. However, for SDR transfers we can safely skip this
and simply use the source mode instead.
Ultimately, this "force PQ" mode needs to be removed, but target_csp()
is still not implemented for all relevant backends.
This ensures that we test format string for the actual impl that is
being used. Depending if UCRT is used and if __USE_MINGW_ANSI_STDIO is
defined the implementation capabilities may differ.
Note that we don't explicitly define __USE_MINGW_ANSI_STDIO anymore,
this is defined implicitly in mingw headers, if needed. We don't support
ancient mingw versions that does not define it correctly for c11.
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.
BT.1886 is mostly limited to TV production which is almost exclusively
limited range. sRGB for full range is better guess, if no better
information is available.
set_image_description replaces the old image description, so we don't
need to call unset_image_description unconditionally. Only call it if we
couldn't set an image description.
This helps with the lack of synchronization between VO pageflips and
wayland protocol events mentioned in the previous commit.
Calling `pl_color_space_infer` on `wl->target_param` can cause the
`pl_color_space_equal` check to fail on every frame if any values were
changed by `pl_color_space_infer`. This will cause us to believe
target_params get changed on every frame, and we'll end up in a state
where wayland events happen in the following order indefinitely:
-> wp_color_management_surface_v1#45.set_image_description(...)
-> wp_color_management_surface_v1#45.unset_image_description()
-> wl_surface#9.commit()
-> wp_color_management_surface_v1#45.set_image_description(...)
-> wp_color_management_surface_v1#45.unset_image_description()
-> wl_surface#9.commit()
Since image_description is double buffered, we always queue an unset to
the pending state before each commit. As a result, no commit ever
carries a valid image_description.
Taking the sample file in the issue as an example, we end up in this
state because the file has `min_luma == 0` but `pl_color_space_infer`
normalizes this value to `min_luma == 0.000001`. This makes it so that
we store a different `target_param` to `vo_wayland_state` on every frame
than the one received from `vo_get_target_params`. So we end up setting
image description on every frame in this case.
The key problem here is that `set_color_management` isn't blocking the
thread until `set_image_description is called`, so vo->driver->flip_page
is called before this finishes.
This commit fixes the problem by doing any operations that could change
`wl->target_param` first before doing any equality checks to skip
changing to image description pointlessly.
This fixes the problem in the issue that image_description is never set
on such files. The synchronization problem is fixed in a later commit,
because otherwise setting image_description on every frame could have
adverse frame time effects
Fixes: https://github.com/mpv-player/mpv/issues/16825
Some protocols may not exist, add them so the mapping to url handler
works correctly. Note that protocols are not removed, only the handler
is. They will remain unassociated, after unregister.
Fixes: #16832
It's enough to not wait for the flip and start with next frame and in
the same time minimized latency which helps display-sync modes, that are
not aware about swapchain depth.
Allows to not wait for flip. Instead of forcing depth for display-sync
modes we will reduce default value instead.
This reverts commit d7495e4ea6.
Fixes: #16823
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.
Those are controlled by the `--swapchain-depth` option and is already
set to 3 by default. There is no need to add hardcoded hidden frame of
"slack". Users can adjust depth by changing the config.
All the math and interpolation assumes immediate presentation of the
frame. VO is driven by VSYNC and it is expected that current frame that
we render will be displayed on current present call, without delay.
Add script bindings to edit mpv.conf and input.conf, and add them to the
menu. These are useful as shortcuts, but the main motivation is that new
users often ask why they can't find mpv.conf and input.conf, so this
creates them if they don't exist.
only meant for testing the oldest macOS target we support, currently
10.15, to catch possible usages of features that are not supported and
not properly guarded.
since dependencies are not build for that taget it will lead to a
partially broken build.
since macOS 13 is now unsupported and homebrew also dropped support for
it too, the macOS 13 bottle downloads were removed. leading to either
a broken or very long dependency installation (build from source).
to fix, pin the last known working homebrew version for macOS 13 where
the bottle download links weren't removed yet. for this to work we need
to disable (auto) update of homebrew.
This implements a ASS context menu to be used on platforms other than
Windows.
The select script message will allow selecting an item with a single
click when releasing a mouse button, like in native context menus. This
is mainly useful to cycle pause with one click.
it doesn't make sense to build the swift parts without cocoa because
the swift bridge would be missing and it's impossible to interact
with the swift parts from obj-c, swift depends on cocoa/appkit/etc, and
the cocoa main function/main loop is missing making anything
cocoa/appkit/GUI crash on use.
like this it is possible to build mpv on macOS without cocoa, it will
fallback to the unix main function and mpv can run in 'headless' mode,
eg you can use it from CLI, it won't spawn any App icon/menu/etc, and
you can use everything that isn't related to cocoa/appkit/GUI like audio
playback. anything other will make mpv segfault, for example sdl2 and
its vo, since it tries to spawn a window.
path-mac.c was not properly set as path_source for macOS. it didn't lead
to any errors because it was added to the normal source files. though
in the case of tests and for certain setups the mac path symbols were
not found.
to fix that properly add path-mac.c to path_source (additional to
path_darwin.c), remove it from the normal source files and don't
overwrite it later with the posix or darwin path.
this was overlooked in 9db8182 and #11374
UniformTypeIdentifiers is only available since macOS 11.
added in 6b0e4f7 and #15859.
guard the allowedContentTypes UTType property of the NSOpenPanel and
add a dummy struct UTType and dummy allowedContentTypes property on
macOS versions that don't have those available.
currently we use the withLock function with NSCondition and NSLock,
which are not available on swift versions lower than 5.7. we only added
compatibility fallbacks for NSCondition though. introduced in 1364c80
and #14334.
instead of only adding the fallback to a specific class add it to the
whole protocol all the locking classes use, similar to the actual
implementation.
with commit 8d20b72 and PR #15442 we switched to the recommended swiftc
compiler for building our swift code. this lead to some
incompatibilities with swift versions prior to 5.8, where a new linker
was introduced.
work around that problem by using the old swift frontend build for older
swift versions. this can be removed when we remove the support for those
old versions.
Fixes#15591
1-index angles to be consistent with DVD angles in mpv and with the
1-indexing in other applications like libbluray's example programs.
The three existing calls to bd_get_title_info all only access the
duration, the playlist, and the number of angles, which do not depend on
the passed angle, so they can keep being called with angle 0 for
simplicity.
Documentation taken from before
35e8b6c1e6.
Fixes#5012.
On Linux, we have `mpv.desktop`, and on macOS, we have `osxbundle`, both
of which handle file associations and protocol registration in the
system environment.
On Windows, this information is stored in the registry, so this commit
adds support for it.
It registers the application, supported file types, and supported
protocols, and adds an uninstall entry so users can remove all
registrations via the control panel. Note that this does not remove the
binary itself.
The implementation is fully portable. There are no external installers,
as mpv handles everything automatically. This should improve usability
when moving binaries and so on.
- `mpv --register` registers mpv (see verbose output for a list of actions).
- `mpv --unregister` reverts all changes made during installation.
- `mpv --register-rpath <string>` allows specifying a string to be
prepended to `PATH` before running mpv. This is useful when using
external dependencies that shouldn't be added globally to `PATH`.
The current handling tries to handle the edge case where the current key
in a combo key is -, but when the current key is not - and the next key
is -, it misdetects - as separator and fails to parse correctly.
Fix this by restricting the handling to situations where the current key
is -.
Fixes: ce2367725e
Were brought up recently in the user channel, and seemed like an
easy enough win. Unfortunately `sh_stream` currently lacks other
fields, so the rest of the flags will be added as the player's
functionality gets extended further.
Ref: https://datatracker.ietf.org/doc/rfc9559/
Similar to X11, this makes mpv attach to the desktop wallpaper window
(make the system create one if it does not yet exist) as parent,
which makes mpv display as desktop wallpaper behind desktop icons.
Lika an actual wallpaper, mpv will not receive any keyboard or mouse
input in this mode. It can still be controlled through terminal and IPC.
when the window is snapped to a position by dragging the title bar the
corresponding left mouse up event is prevented by the system snap event,
which leads to the window moving state not being reset and no mouse
position changes being reported. which makes UI elements unresponsive.
explicitly subscribe to left mouse up events for the whole app instead
of the mouse events from the title bar and reset the moving state.
Fixes#16732
The first completion is automatically inserted when Tab was not pressed,
but this is unwanted when you already typed one of the completions which
is not the first one, move back the cursor and press Enter.
e.g. if the line is "set vid", you place the cursor before "v" and press
Enter, it runs "set ab-loop-avid".
Fix this by aborting when the text in front of the cursor matches one of
the completions.
In reproducible builds, meson.current_source_dir() also leaks absolute paths, so it's better to use files() instead
ref: https://mesonbuild.com/Reference-manual_builtin_meson.html#mesoncurrent_source_dir
> You do not need to use this function!
> When passing files from the current source directory to a function since that is the default. Also, you can use the files() function to refer to files in the current or any other source directory instead of constructing paths manually with meson.current_source_dir().
since commit 5010c24 the initial window always shows a black frame
instead of the actual first rendered frame of the video, since the
visibility of the window for the initial render is always false. in the
worst case the first shown frame wasn't the intended first rendered
frame.
to prevent this, initial always allow rendering till the window is shown
or minimised. afterwards it will respect the occlusion state as before.
in the case of slow render pipeline initialisation and no frame being
ready to be rendered, it will still show a black frame.
add event handler for when window's occlusion state changes and now
indicates some or all of the window is visible.
handling of the event is needed due to the addition of a visibility
check for rendering that was added in commit 5010c24.
Fixes#16693
VOCTRL_CHECK_EVENTS is used to handle input and redraw events, so it is
necessary to check the input events from the windows system when this is
called. X11 already does this, and win32 does not need to do this since
the input events are processed in the UI thread, not VO thread.
However, this is not done on wayland. On wayland, input events are only
processed in vo_wayland_wait_frame and vo_wayland_wait_events.
If Vulkan gpu api is used, then vo_wayland_wait_frame is only called in
wayland_vk_swap_buffers, and only when using the internal vsync, and not
when fifo protocol is being used.
vo_wayland_wait_events is only called in wait_vo. However, unlike
VOCTRL_CHECK_EVENTS which is sent on every VO render loop, wait_vo is not
called when the VO has a frame to redraw immediately, which can happen
often in display-sync modes. In the worst case, this is never called.
All of the above result in situations where inputs and other wayland
events not being handled in time while not rendering, or rapid rendering
with wayland internal vsync disabled.
Fix this by checking wayland events in VOCTRL_CHECK_EVENTS, similar to X11,
to make sure these events are handled.
This second set of additional features are ones from extensions that were
incorporated into Vulkan eventually. As we do not require Vulkan to be newer
than 1.2, we must request the 1.3 and 1.4 features via their original
original extensions, while the others can use the core feature structs.
This change assumes that libplacebo can correctly merge features using their
old extensions or using the core feature structs.
Over time, the list of requested extensions and features has diverged from
ffmpeg (libhwcontext_vulkan), and while this isn't guaranteed to cause
problems, as it depends on driver behaviour, it definitely makes it hard to
compare validation errors between the two implementations.
This change requests the extensions/features which have not been incorporated
into any Vulkan version.
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.
Let us fallback fully to software decoder. There is an issue in ffmpeg
where if we return software format here for hwdec threading context it
will be assumed to be usable, but not accelerated, which would be fine,
but later it causes assertion failure when copying avctx context
between decoding threads in ffmpeg.
Avoid this issue, but returing NONE format after we failed.
No reason to not enable threads if lavc supports them, same as for
software decoding. Might help with pipelining of decoding and filtering.
Performance difference may vary, but in my testing everything is working
as expected and I didn't notice any regressions.
Set to 2 threads by default as conservative value that should resolve
stalling issue, while also not spawn too many cpu threads, which won't
help with hwdec anyway and only can cause too deep queue of hardware
surfaces.
Fixes: #16578
When using more than one threads, the callback can be called from
different thread from sibling avctx, we cannot use our main one to query
codec/hw_frames paramters.
Use context provided in callback arg to fix that.
When ICC profile is applied, use it also in hint to ensure correct
target colorspace configuration. ICC profile takes precedence over
anything else, to make sure libplacebo internally interpret it the same.
Fixes: #16646
We don't know which colorspace the profile were created from. We could
set hint to ICC target colorspace, but it would be ambiguous, because it
doesn't say which colorspace were configured in practice.
Additionally on Wayland with all the color management the client side
ICC correction is not supported, because we cannot set pass-through
mode.
Conceptually we should use VK_COLOR_SPACE_PASS_THROUGH_EXT to get
"direct" access to display response, but while this may work on macOS,
on Wayland it means "don't configure csp", instead of "configure to
pass-through", which means colorspace would have to be configured
externally, which is also not possible, see [1].
You can also see [2] for more discussion on the topic.
For now let's not hint any colospace and leave libplacebo in default
selection. Which restores previous status quo. This can be improved in
future, but for now this fixes use of ICC profiles in default mpv
config.
[1] https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/27
[2] https://github.com/haasn/libplacebo/issues/324Fixes: #16646
If p->mpa = NULL due to an error during a seek or fill_buffer, then when
archive_entry_seek(), if newpos != s->pos, reopen_archive() ->
mp_archive_new() -> mp_archive_probe(), which asserts stream_tell(src)
== 0. This won't be the case if the previous mpa left the source stream
seeked in the middle of the file.
For example, in samples in archives where avformat_find_stream_info
takes a long time, if playback is aborted while the demuxer is doing
that, reading from the source stream will stop working due to cancels
being triggered. When archive_entry_seek() and newpos != s->pos,
reopen_archive() -> mp_archive_new_raw() -> archive_read_open1() fails
and returns with mpa == NULL due to reads not working. Then when another
seek happens, reopen_archive() -> mp_archive_new() -> mp_archive_probe()
-> assertion failed.
One solution is to have reopen_archive return STREAM_ERROR if the stream
is cancelled, since nothing useful can happen in this case. But there
are other situations where p->mpa could become NULL (fatal errors), and
it is supposed to be possible to seek back to a working area of the
archive.
Fixes: https://github.com/mpv-player/mpv/issues/15174
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.
It uses a more sophisticated heuristic for title selection. It not only
selects the longest title but also considers quality and chapters. Refer
to the libbluray source for details.
No documentation change, "longest" option will still look for the
longest, just may work better now.
Fixes selection of title on some discs.
This adds support for unsetting a LUT set by the target-lut or image-lut
property by setting the property to an empty string. Previously, this
would cause an attempt to read a file named ''.
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.
Allows to specify custom fontconfig sysroot. Useful for fuzzing
environments where we might use specific config, font or the system wide
config is not available.
Path normalization can introduce pipe characters from the current
working directory when opening relative paths, which will make the
stream split the path and entry name prematurely. Escape the normalized
path, not the other way around.
Fixes: 440f35a26d ("demux_libarchive: normalize the stream url path")
yt-dlp changed its default format from `bv+ba/b` to `bv*+ba/b`, which we want to follow
since it fixes the behavior with some streaming sites.
The note that "sometimes youtube-dl returns a format that mpv cannot use" was added in
43c13e5ea2 but it's not clear what it refers to.
fixes#16388
Opening paths that are detected as archives which contain
'%[0-9A-Fa-f][0-9A-Fa-f]' will fail, because such sequence is treated as
a percent-encoded value when the path gets unescaped causing the path to
be mangled. Escape '%' to prevent this from happening.
Fixes: 2b280f4522 ("stream: libarchive wrapper for reading compressed archives")
Since 38ad1ed03b path is normalized but stream-open-filename is not,
making the docs where it says that they are the same wrong, so normalize
stream-open-filename too.
Not needed anymore. After data sources are created, the next loop
iteration of clipboard_wayland_dispatch_events will immediately start
and flush display.
This reverts commit c399422722.
Currently, it is done in set_data which is called by core.
It was never meant to do so and it is not thread safe when data
sources are created while a seat is being added/removed.
Fix this by passing a message to clipboard thread instead so that
it is done in a thread safe way.
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.
The xdg-shell spec states: "If never set, the value is the full bounds
of the surface, including any subsurfaces. This updates dynamically on
every commit. This unset is meant for extremely simple clients"
mpv's window geometry is never anything other than the full bounds of
the surface, including any surfurfaces, so we don't need to set this
ourselves. This was added in 828dd65ef8 to
workaround a Weston bug, and isn't needed anymore.
Tested on wlroots compositors, kwin and weston.
If a card supports both DVB-T/T2 or DVB-S/S2, channels.conf.{sat,ter}
was always interpreted as DVB-T2 / DVB-S2 before this change.
After this change, using channels.conf.{sat1,ter1} will enforce
interpretation as DVB-S/T.
The superior VDR channel config format is still the recommended solution
for such cards as it allows to specify the delivery system variant per
channel, but enforcing T2/S2 for cards supporting it whenever the zap
format is used does not seem reasonable.
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.
WebVTT subtitles in WebM require special logic, and we signal that using
the "webvtt-webm" codec name, which is not part of FFmpeg. That worked
fine until commit 94859997b8 ("sub: update codec info") added a call
to mp_codec_info_from_av(), which overwrites our codec name with
FFmpeg's the first time the subtitle decoder is initialized. As a
result, WebM WebVTT subtitles are currently not rendered correctly after
switching subtitle tracks. Fix the issue by resetting the codec name
after calling mp_codec_info_from_av().
We originally took the codec name as a separate parameter, making this
talloc_strdup() good hygiene. But since commit 73779a8c70
("sub/lavc_conv: take sd context as a parameter for lavc_conv_create"),
we take the name from the sd context, whose other fields we already
reference. So it should be safe just to copy the pointer like we do in
sub/sd_lavc.c.
We want to add padding around the whole bitmap, not within it. Smaller
parts are rendered onto bigger bitmap. Remove leftover padding code.
Fixes: e2fc75434e
This ensures that we don't mix maxCLL if target already has max_luma.
This can be opt-in with mode=source and manual target-peak override. No
need to merge to much things.
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.
Upgrade tablet input to first class citizen similar like
touch input, but more simple since use case for now is
mouse emulation only.
Keep state for coordinates and in-proximity.
Introduce property for disabling tablet input.
Introduce Client-API property `tablet-pos`.
This ensures that tablet pad objects that belong to a group,
thus rings and strips, are all properly destroyed on removal
or shutdown.
Note that event listeners for ring a strip are not added
since we are not (yet) interested in them and they are not
needed for proper destroy.
Tablets require their own tablet manager and tablet
seats since multiple tablets/pens can be connected to
a single seat. So this is unfortunately a lot of
wiring.
The tablet protocol is supported in the current winimum
wayland-protocols version, so we can always build this.
Note that this is still the unstable version, once the
minimum required wayland-protocol version is 1.35, the
stable version of protocol can be included.
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.
We wait for timeout and stop fuzzing, but if there are events spammed
this timeout never fire, so instead limit the number of events after
playback reset.
This is raw option passed to lavf and can be used to inject complex
filters and so on, avoid this for fuzzing as it more fuzzing ffmpeg side
anyway and causes issues with timeouts for some big processing.
Useful for demux_edl where it is possible to have huge nested tree of
demuxers and they are added recursively, which causes stack overflow in
some cases.
Found by OSS-Fuzz.
Also cache last dxgi output, to avoid enumerating outputs, this is done
on every frame and we want to minimize impact of it.
While at it refactor and split loading libraries.
Instead of using IDXGISwapChain::GetContainingOutput create new DXGI
interface on each query. This may not be as efficient, but it solves the
issue where metadata is not updated after changing display settings.
DXGI caches parameters on swapchain creation and never updates it.
Also refactor it so it can be used from other contexts.
Note that DXGI is not D3D11, it's mixed in mpv code, may be cleaned in
the future.
Reword this paragraph making it clear that as long as a and a-b are not
bound, the a-b-c binding works even if b is bound.
The 4-key limit for sequences was raised to 16 by a5dbf34094, because
MP_MAX_KEY_DOWN is used for both the number of keys that can be held
down and for the key history size. Just remove the related sentence
since you're never going to need sequences longer than 16 keys.
If color space hint is enabled respect configured parameters of
swapchain. When color space hint is disabled, override output freely.
This fixes possible fallback or other decisions about output made during
the swapchain color space negotiation.
When targeting SDR on display with enabled HDR, compositor will have to
convert SDR to HDR transfer before sending this to display. Resulting in
most certainly wrong output.
To avoid this always convert SDR to target transfer function when
hinting, this way, we do the conversion in mpv and not defer it down the
pipeline.
Unfortunately it's not very portable to detect if we have HDR display
output and "guess" if what we send to display will be correctly
interpreted or not. But we do this when we can.
Also don't force target_peak value from auto detection, use value from
libplacebo.
This commit is based on incorrect information, see previous commit.
It also deletes the correct information the prefetch starts when the
current file is fully load.
The commit also misunderstood the comment about m3u8 urls. It refers to
the prefetching of file data inside the m3u8 stream manifest data, which
has nothing to do with mpv playlists when the m3u8 urls are opened as one
stream by ffmpeg.
The original comment was not very clear about this, so add more details
about this.
This reverts commit d4bf179e78.
The decision was based on incorrect assumption that this option
"only opens a connection to the next file, and the cache of the next
video starts empty", a prequisite of the assumption that this option
has no major drawbacks, including incurring unwanted network traffic.
The assumption can be proven incorrect by testing with networked files
in playlist. With log level set to debug, the following lines are shown
after the next file is prefetched, while monitoring of network traffic
shows constant network traffic after the currect file cache reading
reaches EOF, which triggers prefetching:
[cplayer] Opening done: <url to prefetched file>
[lavf] select track 0
[lavf] select track 1
[lavf] EOF reached.
[ffmpeg] AVIOContext: Statistics: 37139315 bytes read, 0 seeks
It is clear that saying "there is nothing to prefetch after the first
frame" is a complete lie: in fact, it fetches the whole file to the
demuxer cache, according to the demuxer cache settings. And when the next
file plays, it also starts with full cache rather than "an empty cache".
In fact, what this option really does is written in
556e204a11: --prefetch-playlist calls
demux_start_prefetch() which does the same thing as the
--demuxer-cache-wait option:
"Before starting playback, read data until either the end of the file was
reached, or the demuxer cache has reached maximum capacity."
This is exactly what is happening with the testing. This option will indeed
cause large amount of unwanted network traffic - a concern raised in the
discussion concerning this option.
Revert this commit since it's based on incorrect assumption, and subsequent
incorrect conclusions derived from it in the subsequent discussions.
This reverts commit 978b219889.
While testing larger inputs can be useful for uncovering bugs related to
processing large data or inefficiencies in memory allocation, it also
makes the fuzzing process slower and more fragile.
Beyond the obvious slowdown, there are OOM issues and even in libFuzzer.
Specifically, in fuzzer::InputCorpus::AddToCorpus, after a few hours of
fuzzing, we accumulate so many inputs that memory usage exceeds our
quota. This could be mitigated in other ways, such as dumping data early
or shortening the fuzzing run duration. However, in practice, these huge
inputs are often not very useful.
This change will also encourage the fuzzer to mutate existing data
rather than continually adding more bytes to input, because it give
higher coverage. Which in turn will produce higher quality corpus.
The 100 KiB limit could be reduced further. It's still quite large, let's
see how it performs. I believe even 10 KiB might be sufficient or less.
This issue is especially noticeable in the Matroska fuzzer, because we
add input data there, which is bigger and sets max_len high in fuzzer
itself.
In a perfect world, we wouldn't need to impose such limits, but in
reality, we face constraints in both memory and compute resources.
I'll monitor coverage and fuzzing results after this change and adjust
as needed. Unfortunately, this will discard all existing corpus entries
larger than the limit, but that's expected.
Make Ctrl+y copy the input line to the clipboard, or the currently
selected item in the menu.
The vi key to copy is used because Ctrl+c is already bound.
Alternative bindings are:
Ctrl+x to cut, but this also clears the line.
Ctrl+shift+c like in terminals, but this is harder to press, and this
commit works differently from terminals anyway since you don't manually
highlight characters, it just copies the whole line.
Alt+w, the emacs copy binding, but unless you use emacs this is weird
and unfamiliar.
Most users of this function doesn't expect it to return NULL, with
exception of Stereo-3D video mode. Which is a list directly linked to
Matroska specification, and used as value check in demux_mkv and also
when printing format.
There already was a MP_STEREO3D_NAME_DEF macro, so just promote this to
more generic function.
Fixes assert on invalid value found by OSS-Fuzz.
Fixes double evaluation in MP_STEREO3D_NAME_DEF macro.
Volume icon in the OSC did not update when mute toggled or
volume changed while playback was paused and mouse was idle.
This commit adds observers for mute and volume properties to
request_tick(), ensuring OSC updates immediately on mute or
volume changes, even if playback is paused and mouse is idle.
On some compositors, when all touch points disappear the compositors
reset the mouse position, which moves the mouse out of the osc element
trigger area so mouse up events do not happen.
Fix this by tracking the last touch position and use that as the virt
mouse position if the screen is recently touched.
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.
f676a9ff20 changed some append_property
calls to append, but append does not support the exclusion feature
which results in "HW: no" shown when no hwdec is active when this
was not displayed before.
Fix this by adding option to append_property to use get_property_cached.
Fixes: f676a9ff20
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.
This better matches other Unix tools.
Note that in practice the umask downgrades this to 0755 or 0775, so folders don't actually end up world-readable.
c7c09fdb8b made frame step with seek flag
ignore key ups. However, for commands with emit_on_up flag set, which can
happen with mouse buttons, command should only be triggered on key ups.
This results in frame-step command with seek flag triggered on mouse down
instead of mouse up, and frame-back-step command not working with mouse.
Fix this by making sure that step is triggered depending on the emit_on_up
flag.
Fixes: c7c09fdb8b
Rendering OSD on every frame draw is quite heavy, even if some of the
rendering parts are cached, it still takes significant amount of time,
depending of payload can take 8-10 ms just to do the text shaping.
Instead render only when we need it.
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 data source requests are prepared inside create_data_sources from a
different thread than the clipboard thread, so it is necessary to flush
here. Otherwise, if mpv is not already managing the current selection,
we'll have to wait until the clipboard thread reenters
clipboard_wayland_dispatch_events for the request to be sent to the
compositor and have the other clients be sent new the new selection,
which may take up to 10 seconds.
video/out/gpu/d3d11_helpers.c requires it as well, and it's possible to
have egl-angle-win32 enabled without d3d11.
Signed-off-by: Christopher Degawa <[email protected]>
Drop it to warning, even if -Werror is in effect. Interesting part is
that this makes this warning disappear completely. GCC diagnostics at
its finest.
sizeof(AVPacket) being part of an ABI is deprecated. This was the last
remaining stack usage, missed in previous related change.
Note that we still use sizeof(AVPacket) and sizeof(AVBufferRef) in
demux_packet_estimate_total_size(). But it's safe, the worse that can
happen is that we underestimate the size on mismatch.
Fixes: cb15bc4324
Fixes excessive memory usage with avdevice input. After [1] packets
returned from avdevice contains wrapped AVFrame. mpv estimates packet
size to limit how many of them are cached. The size were not correctly
calculated, because packed contained only AVFrame* and not the actual
data in buffer. Fix this by calculating wrapped size and add it to our
size estimation.
[1] https://github.com/FFmpeg/FFmpeg/commit/6ca43a9675d651d7ea47c7ba2fafb1bf831c4d0b
This populates the AVCodecContext->bits_per_raw_sample field value
when the pixel format of the screenshot being written doesn't match the
pixel format of the original video. For example, if the original video
was 10-bit and the screenshot is 16-bit, it populates this field so the
encoder can make use of it.
Currently libjxl and png encoders are known to accept this tag and set
the corresponding metadata (via BitDepthHeader, or sBIT).
This feature is only enabled if screenshot-sw=yes is enabled, because
screenshots from a hardware buffer are always natively at max-depth.
Signed-off-by: Leo Izen <[email protected]>
This adds clipboard writing support for the native Wayland clipboard
backend for the ext-data-control-v1 protocol. Both clipboard and
primary selection are supported.
I'd rather not argue about which is better so go back to status quo,
users can use the more sensible option of "simple" if it doesn't break
anything (which it won't).
Using simple has benefits of growing memory usage slower and much faster
OSD rendering when complex isn't needed.
Simple breaks rendering complex glyphs like Material font icons
Fixes: https://github.com/tomasklaen/uosc/issues/1086
Fixes: f24611980c ("sub/osd: add osd-shaper and set it to simple by default")
case_sensitive originally only affected Tab completion. It defaulted to
yes outside of Windows just to emulate the bad defaults of bash and zsh
(not fish, which has better defaults and defaults to case-insensitive
completion). This was already silly, but then it affected the fuzzy
autocompletion and case-sensitive fuzzy completion is even more silly.
And since 0b3cc3a167, it accidentally stopped affecting even that,
because the completion via script message never checked for the option.
Nobody even noticed this, meaning that nobody was relying on fuzzy
autocompletion being case-sensitive.
Just make case_sensitive only affect the new exact search, and make it
default to no on all platforms. Though IMO the search could just always
be case-insensitive.
Allow matching items exactly instead of fuzzily when prefixing the
search with ' (like in fzf) or with
--script-opt=console-exact_match=yes.
This is mainly useful to filter history entries chronologically.
You can also specify multiple search terms delimited by spaces. But '
makes every term an exact match, unlike fzf where you need to place it
before every word, since we can't hook into fzy's algorithm.
Closes#14587.
Disables perf graphs from stats.lua. They are relatively expensive to
render, causes a lot of memory to be used for caches which are never
reused because graph is rarely the same. And most importantly those
graphs are not that useful beyond quick visual inspection of jitter.
Can be enable in script-opt if needed. Cache graph is left enabled,
because it shows if cache readhead grows or not nicely.
This is a change in default for libass with harfbuzz enabled, previously
it would choose the best available shaper.
Harfbuzz isn't really needed for mpv's OSD and it comes with a
significant performance penalty, so use simple instead
A "hung up" fd only indicates that the other end of the pipe is closed.
This can happen when the other client has already sent some data into
the pipe and closed its end. This should not be treated as an error,
and reading data should proceed until read() returns 0 or -1.
Premuturely destroying offer in this case breaks getting selection
data. Change it so that the cleanup on error happens after the selection
data is read.
Fixes: d20ded876d
If Vulkan hwdec is exposed by the system, use this as it provides better
compatibility with native Vulkan rendering.
This avoid issues with importing VkImages through DMABUF interop from
nvdec or vaapi on drivers that doesn't support DMABUF.
Try native Vulkan hwdec first which will resolve compatibility issues if
available. If not it will fallback to using vaapi/nvdec like before.
Calling input.select() without a prompt argument was failing due to
attempting to concatenate a nil value.
Before mpv 0.40 the prompt defaulted to ">" so this is expected to
work as evident from the example code.
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.
Some languages actually require strings to be valid UTF-8, unlike C
which couldn't care less as long as it is NULL terminated.
Change triggered by Python support, but is also useful for Rust and Java.
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.
FreeBSD supports only two latest minor versions, since 14.3 has been
released, packages for 14.1 are not longer available. Bump to 14.2,
since action doesn't have images for 14.3 yet.
Unknown duration subtitle handling must be executed on every decode
call, because we are actually adjusting the duration value of subtitles
that are decoded in the past. It should not only execute when the
newest packet has an unknown duration.
C11 uses _Thread_local as the keyword, which thread_local macro
is defined to (inside of <threads.h>, which mpv doesn't use):
https://port70.net/~nsz/c/c11/n1570.html#7.26.1p3
C23 promotes thread_local to a keyword and marks _Thread_local
as obsolete and to be avoided in new code:
https://www.iso-9899.info/n3220.html#6.4.1p3
so just use thread_local directly, which is future-proof while
having a fallback define in osdep/threads.h for pre-C23 cases.
Clients run in detached threads and are waited to signal when they are
finished with self mpv_destroy() call. Problem is that after detached
thread calls this function, mpv consider this client to be done and can
do whatever. One example is when mpv exits and wait for scripts to
finish we got race condition, because mpv (main thread) can exit first
and the detached thread calls ta_free() which crashes, because we may
have already destroyed things that the thread depends on.
I've seen this crash on FreeBSD CI job (libmpv-lifetime test), where the
libmpv.so has been unloaded while the thread was still doing ta_free()
```
==5081==ERROR: AddressSanitizer: SEGV on unknoun address 0x000001111806 (pc 0x000001111806 bp 0x7fffdedf4e40 sp 0x7fffdedf4e08 T40)
==5081==The signal is caused by a READ memory access.
#0 0x1111806 (<unknown module>)
#1 0x803cd6900 in ta_free /home/runner/work/mpv/mpv/build/../ta/ta.c:243:5
#2 0x803a2fc87 in run_script /home/runner/work/mpv/mpv/build/../player/scripting.c:93:5
#3 0x803a2ffe0 in script_thread /home/runner/work/mpv/mpv/build/../player/scripting.c:99:5
#4 0x2c451a in asan_thread_start(void*) /usr/src/contrib/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:239:28
#5 0x80034fb04 (/lib/libthr.so.3+0x10b04)
```
Note the 0x1111806 jump which is completelly bogus.
Fix this by doing mpv_destroy() as a last step in detached threads.
removes awkward back-and-forth int -> double -> int conversion.
the last step also broke uniformity, though it likely doesn't
matter much in mpv's playlist shuffle context.
c365e2f7 added av_random_bytes() to avoid multiple
threads/processes getting the same seed. but the fallback case
still suffers from it.
also mix in a function pointer, which hopefully is randomized
per process due to ASLR (20+ years old technology) along with
the stack position which will be different on different threads.
splitmix was used since it's recommended by the official xoshiro
site [0] as a "radically different" PRNG to avoid correlation of
similar seeds. av_random_bytes() is cryptographically secure
and so we don't have to worry about that. so just use it to
initialize the whole state.
[0]: https://prng.di.unimi.it/
mutex itself was probably more costly than the PRNG itself. and
locking PRNGs is almost universally not recommended. simply add
a state parameter that the caller can hold to avoid locks.
CMake has been updated to 4.0 which breaks compatibility with all
project targeting version < 3.5. See for more user stories:
https://github.com/actions/runner-images/issues/11926
Remove 4.0 from path and use the one from VS installation which is
working for now. Generally we want to use only tools from VS
installation, but unfortunately Windows image provided by GHA have
polluted PATH which already causes issues in the past, that's why we
remove yet another directory from PATH.
The affected project in our case is https://github.com/webmproject/sjpeg
which is build as part of libjxl.
The buffer size were never set to 0, after first call. To retrive the
size both buffer has to be NULL and size 0. Otherwise it fails.
While at it refactor whole thing and use returned count as sanity limit.
The size of the buffer was never set so the Get*PreferredUILanguages()
were just returning ERROR_INSUFFICIENT_BUFFER.
Fix the buffer size and use the returned count as sanity limit.
Fixes the test.
Currently we check AV_FRAME_DATA_DISPLAYMATRIX for its rotation factor
but not for its flip factor, which could happen with some input files.
This commit adds and autovflip filter, which is applied before the
autorotate filter to flip vertically before rotating. It also changes
the displaymatrix reading code to output to mp_image->params.vflip so
it can be autoinserted as necessary.
Signed-off-by: Leo Izen <[email protected]>
The playlist demuxer won't propagate the protocol forward to its entries
if its protocol is on a whitelist, for example data:// or memory:// etc.
This commit adds fd:// to that list because that should not be expected
to work.
Signed-off-by: Leo Izen <[email protected]>
After removal of `MP_MUTEX_RECURSIVE` from vdpau.c there are no more
clients of recursive mutex. Remove all the code related to it. This
commit can be reverted if in the future it is needed again. For now
let's not keep dead code.
FFmpeg recently got a hardware accelerated decoder for FFv1.
The decoder has been tested on all major vendors and operating systems.
Intel support is currently disabled as all of their drivers have issues
with buffer device addresses.
Since its a software-defined implementation, internal issues can be fixed
and the overall implementation optimized further.
With that, I think it should be safe to enable it by default.
And eliminate recursive lock. This doesn't have to be guarded by mutex,
if for some reason preemption happens while we are handling preemption,
we remember the flag and do the dance gain. This is even nicer than
locking preemption callback.
- `priv` is used as `talloc_ctx`/`ta_parent` in `bstr_xappend_*` calls.
- `free_bufs` no longer frees `priv->cmd.start`.
- `bstr_*_passthrough` functions have been stripped off the `bstr_x`
prefix.
In the past `strlen` was used in the write function, which omitted the
trailing NULL byte, however with the addition of `bstr` API the NULL
byte produced by `av_base64_encode` in the output is also written to
stdout, this causes terminals (namely Ghostty) to not display the frame.
There was also an additional edge case where if the entire output is
less than 4096 bytes the finishing escape sequence `\033_Gm=0;` was
never emitted. Adding a check for this after the for loop fixes this
behavior.
Terminal multiplexers like (screen, tmux, ...) do not support the kitty
image protocol (as of yet), to go around this DCS escape sequences are
used (`\ePtmux;...\e\` for tmux, `\eP...\e\` for screen). This option
allows passing thorugh the kitty image escape sequences.
`\033\\` suffixes from `KITTY_ESC_IMG_SHM` and `KITTY_ESC_DELETE_ALL`
have been removed. This makes it easier to wrap the escape sequences in
a DCS control sequence since there will be no `\033` in them to escape
(as multiplexers require escaping the escapes within the DCS data
string). `DCS_GUARD_WRITE` and `DCS_GUARD_APPEND` macros have been added
to wrap escape sequences in DCS control sequence based on the
availability of the `priv->dcs_prefix` property.
`priv->cmd.start` is being freed in `reconfig` without being allocated
again this caused a segfault if `flip_page` was called after `reconfig`.
This segfault could be triggered by sending a SIGWINCH (resizing the
terminal).
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.
MP_EVENT_INPUT_PROCESSED is used to notify mouse and touch position
updates, but it is currently notified for all input commands even when
they have nothing to do with mouse position. This results in unnecessary
acquisition and comparision of mouse and touch positions for all commands.
Optimize this by checking whether the command is marked as requiring the
event notification, and only notify if that is true.
Some properties can take a long time to query, especially those which
require voctrl like current-window-scale and display-names.
Similar to d37521b5ef, make the script
observe these properties and cache the values to avoid querying them
on every refresh. This alleviates the issue when holding down "i" key
for a while and releasing it results in stats being stuck on display
for a long time because of the time required to query there properties.
The messages referred to "no" prefixes like --no-audio not working with
the client API. The language was removed in
b1ee92ad4a.
Remove the messages which are bogus and incorrect now.
This is a bare runner for mpv.exe. There is no need for a stack
protector here and when it is forced to be added by -fno-stack-protector
it complains about missing symbols, because we don't link any standard
libs here.
Fixes:
undefined symbol: __stack_chk_fail
undefined symbol: __stack_chk_guard
We could define those, but mpv.com wrapper doesn't need it.
When converting list options to strings and the value is empty, an
empty string is returned. This is true for key value list and object
settings list options. However, for string list options, there is an
edge case: if the list exists but has no element (which can happen
when using change-list command), it behaves as if the property does
not exist and returns "(error)". This causes confusing messages when
toggling glsl-shaders at runtime and seeing "(error)" printed as the
value when all shaders are toggled off, for example.
8461143ed7 attempted to fix it, which
fixed the case for unset string list, but not for a list with no
element.
Fix this by making sure an empty string is returned in this case.
With -v -v there was an infinite loop of log messages, because every new
logged script message to console triggers a new script message, which
gets logged again.
Sometimes when opening a YouTube video with chapters, the chapter-list
ended up having all the chapters twice, despite the json from yt-dlp only
containing them once. That must mean that sometimes add_single_video()
runs twice before the chapter_list table gets cleared in the
on_preloaded hook.
This can be avoided by replacing chapter_list with a new table before
adding entries to it.
It can be too easy to change the video position without a single way to
undo the change. Also, this is mostly useful for images. Binding can be
brought back in a better way with an image profile or another method
that is more resistant to accidental clicks.
This reverts commit e98d3b62ec.
Fixes VO thread busy looping in paused state for untimed VOs.
One example is vo_lavc (encoding mode), used commonly to extract
thumbnail by scripts.
Example command that was affected:
mpv --ovc=rawvideo --of=image2 --ofopts=update=1 --o=test --pause
file.ext
We have to update request_redraw value to not redraw again. This has
been skipped by early exit before.
This also fixes VO_CAP_NORETAIN case.
Fixes: 8798cec7fa
Added in https://github.com/FFmpeg/FFmpeg/commit/91d96dc8ddaebe0b6cb393f672085e6bfaf15a31
The user can still turn this on via demuxer-lavf-o=extension_picky=1 if
they want to.
This causes quite a few problems with many HLS sources where the codecs
are not known at probe time for whatever reason. Youtube for instance
transports aac audio inside ".ts" extension urls which are disallowed by
this option.
As an aside, the FFmpeg test is also buggy and leaks a nested
connection for any playlist item that fails the extension check. mpv
catches this and prints "Leaking 1 nested connections (FFmpeg bug)" for
every HLS stream that has at least one stream that fails the extension
check.
VK_KHR_video_maintenance2 was recently merged in FFmpeg. It significantly
speeds up some problematic HEVC samples, as it avoids needing to recreate
sequence parameters on each frame.
It also generally speeds up everything as it avoids needing to ask the
driver to allocate memory for parameters it sends on every frame anyway.
When the first chapter is not at the start of the file but after the
current time position, the chapter property is -1, which prevented
displaying any chapter.
Fixes#16073.
This matches the behavior of mpv's own drm backend when setting hdr
metadata, as well as Mesa's vulkan wsi's behavior when communicating
VK_EXT_hdr_metadata values to the compositor
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.
This is an improvement on #15145 .
If the cursor is automatically hidden, users may not know whether
they are clicking on the inside or outside of selectable items,
the result after clicking is unclear to them.
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.
The conversion is done to DXGI_FORMAT_B8G8R8X8_UNORM, this was tagged
as IMGFMT_RGB0 because vo_gpu didn't understand that B8G8R8X8 needs to be
sampled differently. This is fixed now, so we can tag the image with the
correct format.
Fixes output with dxva2 for gpu-next
(after https://github.com/haasn/libplacebo/commit/bbe63109cba2ef5c7e6aea1c47d5f6994b6dc71c)
and gpu (after previous commit).
Will fail with older libplacebo, but there is no reason to use dxva2
anyway. d3d11va is available on all supported platforms and is bit-exact
unlike dxva2 which always does conversion to 8-bit BGR.
Also note that libplacebo was broken with all BGR inputs up until
recently, and only because it was working the same as vo=gpu, the issue
was canceling out.
Pressing ctrl+c in select mode crashes if console wasn't opened in
free-form text mode before.
This also makes the type of the history variable clear.
Fixes a6024b562a.
Those properties are already observed and trigger update, remember the
value to avoid re-fetching them.
This fixes delay caused by properties that synchronize GUI thread like
`focused` which takes 30+ ms in certain cases.
Co-authored-by: Guido Cella <[email protected]>
14-17 Data length in samples (binary, Little Endian)
This has been validated with sample generated with:
ffmpeg -i $(ffmpeg_fate)/lossless-audio/luckynight-partial.tak -c:a tta lucky.mka
The length is correctly calculated to be 418950 for that sample.
Basically this is a port of https://github.com/FFmpeg/FFmpeg/commit/af248fa1174200acb537a6ab1198bb2fed38e884
Fixes: d53d75e080
script-message-to commands type was passing cursor_position as a string,
which caused a crash if you e.g. moved the cursor afterwards. Convert it
to number in console so commands.lua and similar clients don't have to
manually convert it.
Currently --osd-font is the default for select, and a monospace font is
the default for free-form text mode. We can also default to the
proportional --osd-font for mp.input.get clients that don't specify
completions and thus don't need alignment, which is most clients.
In builtin scripts, this is the case for filtering stats key bindings.
With script-message-to commands type, instantly show completions if
available. Useful e.g. with loadfile or apply-profile.
This also shows completions if you just close the console with a filled
line and reopen it.
It was suggested by CogentRedTester in
https://github.com/mpv-player/mpv/pull/10282#issuecomment-1858727729 and
https://github.com/mpv-player/mpv/pull/10282#issuecomment-1858809580 and
by avih that making running commands an mp.input client is a better
architecture.
A practical advantage is that completions are calculated in a different
thread, which prevents hanging when completing slow/network filesystems.
script-binding console/enable becomes script-binding commands/open,
though the console one is kept as an alias. I took the opportunity to
rename this because open makes more sense for a graphical modal, and it
is the word used in mp.input and user-data.
script-message-to console type becomes script-message-to commands type,
though the console one is kept as an alias. It is also changed to
automatically close on submit without having to append '; keypress ESC'
as you don't need to keep the console open after running prefilled
commands.
Also convert to double quotes like other scripts and rename some
inconsistent functions.
Let the complete callback return the character to append to the selected
completion.
I didn't want to document this because it's specifically meant for
properties and unlikely to be needed by other scripts, but silently
interpreting the 3rd return value can screw you over if you do something
like
return candidates, code:find('[%w_]*$')
I was doing this in my lua-repl script, and find() returns the end
position as the 2rd argument, this becomes the 3rd return value and gets
appended to completions. So you have to do
return candidates, code:find('[%w_]*$'), nil
Needed to split running commands out of console.lua.
add_tl() when creating virtual_stream list is referencing sh->codec
which is owned by the demuxer. Don't close it to avoid dangling
pointers. The comment is right, but this happens regardless of
delay_open as we can clearly see in the add_tl() function.
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 has been moved to the mpv core with additional security
considerations, including filtering unsafe protocols from being opened
via the URL handler.
While we are not aware of any active exploitation, naive protocol
handling could allow the use of niche protocols in FFmpeg, which, in
turn, might load native code. How such native code would be dropped on
the local machine is another question.
This remains theoretical, but it's better to be safe than sorry.
Fixes: 494d408583
This is useful to run mpv from URL handler. Can be used to start mpv
from you web browser or anything that would trigger url handler for
given protocol. Only safe protocols are allowed.
Current solutions to run mpv in such context are to spawn IPC proxy and
run mpv when requested, but this is in most cases not necessary.
Currently the protocol is added in mpv.desktop. Windows related
registration will follow in future changes.
This increases the priority from 50 (which is neutral) to ensure that
profiles are applied before other scripts.
In general, applying profiles before other scripts makes sense. This was
already the case for external scripts with default priority because they
would load after auto_profiles.
This commit primarily fixes ytdl_hook.lua to respond to profile changes.
In most cases, profile conditions are triggered by external conditions,
not the output from the ytdl hook, so this is fine.
I acknowledge that this will change the order if a script previously had
a priority lower than 50. However, injecting itself before profiles are
evaluated is a very obscure use case, if there is even a valid one.
This is required for creating a copy texture. Note that alignment is
applied only when making a copy; if mapping the texture directly, the
native texture size is used as-is. The texture itself may be larger
depending on the coded dimensions, but we only copy the "interesting"
part of the image.
Fixes playback of videos with odd dimensions.
Make sure the `early` variable is boolean. The issue was that if url have
`ytdl://`, find() would return position `1`. This makes `early` also `1`.
And now we try to compare `early == load_fail`, which for `1 == true` is
false, while we expect it to be true. Make sure we compare booleans.
Fixes unnecessary hook processing when using ytdl:// protocol.
This assert won't give much more information than the abort() itself. We
just want to abort on OOM there is not much to debug here. talloc macros
also doesn't add an assert.
It is easy to craft a config file that loads a profile recursively. To
prevent this, not only check the depth of the current inclusion but also
ignore already-seen profile names.
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.
The documentation does not mention that using add/cycle to change
the property is subject to --chapter-seek-threshold option,
and the fact that a chapter number of -1 indicates a playback
position before the start of the first chapter.
The relative time chapter is 1-based even though it stores
0-based values internally, but the printing doesn't consider
that and gives 0-based value.
Change it to use the same base as setting the value so that it prints
the same value as being set.
Fixes: 877775f84e
When a stream is not set to passthrough and there is no data to read or
write, a handle to the NUL file is created. However, these handles were
not included in the list of inheritable handles for the child process.
This commit ensures they are properly inherited.
Fixes: 83fec9bafbFixes: #15982
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.
The overlay to calculate the max item width was never removed, so a new
one was added on each select call, adding 5-10 MBs of memory usage on
each menu opened.
Fix this by reusing the same overlay, which is also faster.
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.
537006965e introduced this while
implementing n-buffering. The changes are all good, but the suspect part
is the implementation of wait_fence/new_fence to specifically bypass
what is done generically in context.c for all other opengl backends. The
commit message says that the reason for this is because "the places we
create and wait for the fences needs to be somewhat different for best
performance". It's certainly plausible that it may have been true then,
but I see no evidence it's true now. Driver code is way different these
days under the hood, and the general vo drm code has been rewritten a
lot since then. The generic fencing in context.c works fine and shows no
difference compared to this custom implementation. Delete it and
simplify.
Windows works totally differently than the other backends and is
sensitive to synchronization issues since it runs its control on a
separate thread. The spot where this was originally placed was a perfect
storm of causing resize weirdness because it was before the flip and
right after the redraw. Ideally, this is known to the windowing backend
before the flip actually happens so just move this out to before the
do_redraw call. It makes no practical difference for the one user of
this and sidesteps the implementation differences that exist on Windows.
Fixes fc9d1ca182.
The names of single invocation key bindings for specific pages will be
changed if defines user key bindings, then original invocation fails.
e.g. : when user defines `key_page_4=F4`, then key binding name
`stats/display-page-4-toggle`
becomes
`stats/display-page-F4-toggle`,
and OSC menu `Help` fails.
Partially revert bede44618b. This was removed to allow nested
input.select() calls, but it is better to use the new keep_open flag for
this, because it avoids the flicker of console quickly closing and
reopening.
Unregistering the script message allows garbage collection of variables
defined in the scope that called mp.input, this is useful e.g. if you
were selecting from 10k history entries.
With input.select this allows building nested submenus without the
flicker of console quickly closing and reopening, and also doing
multiple selections, to e.g. cycle through different values of a
property, or increase a property multiple times.
With input.get this is used to change the default behavior to closing by
default on submit. It was argued by avih that this is more useful, and
indeed Github code search shows that everybody is calling
input.terminate() unconditionally on submit, so the impact of the change
should be low, and restoring the old behavior is as easy as passing
keep_open = true, which is just ignored in older mpv versions.
This needs to strike a fine balance between being visible and having
contrast with the text color and not taking attention away from the
selected item. Make it slightly more opaque to differentiate it more
easily.
Fixes#15711.
fzy returns which characters matched the search for every item, so use
this to highlight them.
This defaults to a light blue color that is readable with both black and
white (selected) backgrounds.
The returned positions are just bytes, so we can't put ASS tags or
escape sequences around each byte because that would break displaying
multibyte UTF-8 characters. Only put them around sequences of matched
positions, and only when the sequences start and end at actual character
positions.
The next commit will inject ASS within matching items to highlight
matching positions, which means that the text key of log lines can no
longer be used, and that matching items and log lines diverged enough
that it's simpler to separate them.
As a bonus, we can stop clearing the log and completions when searching
the command history, and restore them after the search.
--prefetch-playlist improves performance by starting to read the next
file in the last second or playback or while viewing an image. This is
obviously noticeable with playlists of direct media URLs, but can also
make a difference on local slow hardware, mainly large (in bytes) images
on HDDs. You can easily see the difference with 10+ MB images.
Since e7a253614c and 24db17d10f fixed niche issues, and it's known not
to cause other issues by users using since 2017 who haven't reported
issues, enable it by default to improve performance.
The only flaw is that it doesn't support ytdl-hook URLs, so in Youtube
playlist, it does a web request with ffmpeg that is doomed to fail since
the last second of playback, though this doesn't cause practical
disadvantages.
There is no known issue with --prefetch-playlist and file-local-options.
It works just fine with them, and people have been using it since 2017
and haven't reported related issues. So ease the warnings to not scare
users away from using a useful option.
Also when --prefetch-playlist was implemented it also prefetched the
stream cache until 559a400ac3 removed it - see #6753. So if such issues
ever existed, they were fixed by not making it prefill the stream cache.
Now it doesn't do much, it only opens a connection to the next file, and
the cache of the next video starts empty.
An alternative is to bind to right click only for images, but since we
will likely bind right click to the context menu once it works on
platforms other than Windows, bind to ctrl+left click to not have to
change it later.
When searching the command history with outline-and-shadow, the counter
should preserve the border, shadow and blur. Only with background-box it
should disable the shadow to not overlap 2 rectangles. While disabling
border and blur is needed with the menu background+outline-and-shadow.
Basically whenever the VO does a redraw, we always have to flip buffers
for vo_drm and drm_egl. The old way of doing this was checking if the
video was paused and if the frame was still. This does work, but what
really needs to be known is simply if the VO is redrawing. Since the
added VOCTRL_REDRAW tells us this, we can shuffle around some logic and
simplify greatly. drm_egl no longer needs its custom override for the
submit_frame step so that can be eliminated along with the vo_gpu_next
hack.
Fixes 0959cdeb03.
This backend is a special case where the state of the frame (i.e. is it
still) needs to be taken into account when flipping the page because it
does its own fencing. vo_gpu_next never calls the submit_frame API in
ra_swapchain which meant the drm backend wasn't aware of the state of
the frames and thus couldn't respond. This is a bit weird though because
in vo_gpu we actually want the ra_gl_ctx_submit_frame call after the
custom external drm_egl_submit_frame. But we don't want this in
vo_gpu_next, we only want the state update. Be lazy and just compare the
vo_drivers, but the way this is currently designed feels wrong. Fixes
delayed OSD rendering when you play a still image like an audio
file with cover art.
The comment is true, but just passing an empty ra_gl_ctx_params does
exactly the same thing. There's no reason to specifically use the
external_swapchain API.
These were separate for some reason which makes no sense and is really
annoying if you want to use something that's in the vk version and not
the gl one or vice versa. As a bonus, these now get to live right above
the ra_swapchain definition which is more convenient.
Not all compositors will send another action after the data_device entry
event. We currently assume this which always causes the previously set
action to be overwritten with the default value (-1). The easiest way to
solve this is to simply save the old dnd_offer action value and then
reapply it after we update it to the pending_offer. Fixes#15939.
This ensures a clear separation between public and private headers. It
also makes it clear in Meson and prevents the accidental use of private
headers.
I don't know why I didn't get it before but Lua's LSP now complains with
Compute `"Edition " .. (edition.id + 1)` first. You may need to add
brackets. [ambiguity-1].
Just move the parenthesis to make it happy.
osd_surface is a sync sub-surface of video_surface meaning that a commit
of osd_surface will not take effect until the next commit of
video_surface.
Some compositors (wlroots) do not implement sync sub-surface correctly,
meaning that the difference cannot be observed there. But it can easily
be seen on Jay and GNOME:
1. Open an mpv window.
2. Pause the video.
3. Enter the surface with the mouse.
Expected behavior:
1. The OSD shows up immediately.
Actual behavior:
1. Nothing happens for a few seconds.
2. The OSD shows up and immediately fades out.
This is because the fade-out commits cause the initial osd_surface
commit to become effective.
This reverts part of PR #15899 (commit dd6e3a0ece).
"Why is this even useful?": It's very useful for multi-disc playlists. Compare:
`mpv bd:///DISC{1..4}`
`mpv -\{ bd:// --bluray-device=DISC1 -\} -\{ bd:// --bluray-device=DISC2 -\} -\{ bd:// --bluray-device=DISC3 -\} -\{ bd:// --bluray-device=DISC4 -\}`
Basically just bits of a9d83eac40 that was
removed and ported to here. Not really smart but it seems like flushing
buffers during seek generally leads to better behavior and avoids some
errors. The additional stream_seek call that was being performed is
definitely bogus (will never work and spams errors). So that is skipped
for bd/dvd. SEEK_FORCE is no longer needed. Instead demux_disc calls
drop_buffers on the slave demuxer (i.e. lavf).
Need to shuffle some stuff around but it's pretty simple. Mute the
audio stream before the frame step and then unmute it when we're done.
It's exactly the same as the default play mode otherwise.
You probably wouldn't guess what this does from the name alone, but it
actually selects a range of tracks to play. It's slightly different than
using --start because it confines the range to just that track and you
cannot seek before it. The functionality is useful, but you can
accomplish exactly the same thing with --start and --end. Also the
implementation of the cdda option is weird because starting from a track
after 1 makes it impossible to seek before it. There's no reason to have
this when using the core option is simply better and works fine.
This is allowed but it's pretty weird. You'd end up typing something
like dvd:////dev/sr0 or cdda:///dev/sr0 (notice the differing amount of
/). Why is this even useful? Just use the matching --cdda-device option.
There's no need to have two ways to do the same thing here.
modal dialogs steal the key/mouse input and possibly eat corresponding
key up events when opening via key binding. this leads to key sequence
ends to not reported and key bindings not being triggered if no key up
event was triggered after closing the modal.
This is only needed for spawning main mpv process, there is no need to
spin CRT just to call main() and support basic memcpy.
Additionally adjust compilation flags to reduce the size of mpv.com.
This is the small binary using only kernel32 as dependecy now.
Stripped mpv.com built with clang 19.1.7 (x86_64-w64-windows-gnu)
Before:
text data bss dec hex filename
6982 7281 0 14263 37b7 mpv.com
After:
text data bss dec hex filename
1094 2894 0 3988 f94 mpv.com
Depending on compiler and options the size may vary. For example with
-flto and -Wl,-gc-sections it is:
text data bss dec hex filename
833 750 0 1583 62f mpv.com
but gc-sections were rejected as an default option before.
As a bonus add some error checking to this code.
No need for pointless prefix, print error directly. Don't use CRT
function. This will write only to console, but it's not meant to be
written to file anyway.
This adds --video-aspect-method=ignore to replace --video-aspect-override=0.
--video-aspect-override=0 and --video-aspect-override=-1 will no longer be
handled specially. For compatibility, 0 is mapped to always use ignore
and -1 is always mapped to always use container.
"no" is now the replacement for --video-aspect-override=-1, which is
internally remapped to -2 to avoid using a deprecated value.
This is poorly implemented and will break existing scripts which set
the value directly with double without a string value, like
mp.set_property_native, or if the value is set with add/multiply commands.
Revert this until a better solution is found.
This reverts commit cb91de2a34.
Maybe the xx version was different (probably not), but looking over this
code again it's pretty clear that there is a lot of unneeded
complication. There's no need to keep track of the image description,
creator params, etc. globally. This can all be passed around on the fly.
Also, reset_color_management was redundant because it would execute on
reconfig and also on the first draw after the reconfig. We don't need
both so delete the reconfig path. Collapse the various color functions
into one simple "set_color_management" and let the wayland listeners do
all the object destroying for us.
343a5fd345 killed all mmal hardware
decoding, but there was still some junk lying around. There's
IMGFMT_MMAL still, but that's harmless to keep around.
I started doing this in f594482451 for
protocol objects that were newer than the lowest version, but I can't
remember why (some waf-related reason?). This wasn't even followed for
other PRs merged recently like ext-data-control and color-management.
Anyways, it's not needed and works fine if you're on wayland-protocols
1.31 so stop doing this void weirdness.
Previously stats_time_start first sampled cpu-time and then real-time,
while stats_time_end sampled them in reverse order.
This resulted in real-time delta values being possibly a bit smaller
than the respective cpu-time deltas, which could become meaningful if
the start/end durations are consistently very short and very frequent.
In one test case (measuging the time spent at the event loop of
a script which spins on zero timeouts), this resulted in accumulated
real-time value of ~230ms per second, with a respective cpu-time
values of ~500ms. This should not be possible with single thread load.
Now start and end sample the values at the same order, so that it
balances on average. Each start/end delta now includes overhead of one
of each sample type, and excludes one of each sample type on average.
With the test case above, it's now 490 +-1 ms for both.
(the other 510ms real-time are at the excluded mpv_wait_event calls
and the unmeasured-overhead-parts of stats_time_start/end).
This fixes a bug where if stats reset happened after stats_time_start
and before stats_time_end, then the next reported cpu-time value of
that measurement was from the thread startup.
The long version:
stats resets the time-accumulated values if more than two seconds
ellapsed since last poll.
The reset keeps the elements, but makes them as if no measurement was
yet taken, so that they don't show up at new reports until a new
measurement is taken.
While the events and (untimed) cpu are reset, the timed-cpu value
was only partially reset - the values are reset but the indication
that the element is empty was not enough for stats_time_end.
So when reset happened between start/end calls, stats_time_end was
entered eventhough it shouldn't have, but with reset cpu-time value
it calculated the time since the thread's startup, hence this bug.
Further polls were ok, because they are of the delta since the
previous poll. But at the next reset it happened again.
Now the cpu-value is reset correctly, which fixes this bug.
stats_time_start and stats_time_end accumulate real-time and cpu-time
between these calls, but the total was only updated on stats_time_end.
This resulted in two issues:
- Inaccurate measured value if a report (read the perf-info property)
happened between start/end. No biggie because it's OK on average and
typically each start/end duration is quite smaller than the interval.
- If the start/end duration is bigger than the interval, then one or
more intervals had a report value (delta) of 0, and then one report
with a value bigger than the interval - which shouldn't be possible.
This commit effectively does end+start at the report time for ongoing
timed measurements, so that the report accounts for them too.
Doing end+start at the report required two more changes:
Store the element type (VAL_TIME) at stats_time_start rather than at
the end. Otherwise if the report happens after the first start but
before the first end, then the type is not yet set and the element
is skipped at the report (bypassing the end+start).
Store the thread id at the element. start/end measure the cpu-time at
the current thread so they used pthread_self(), but with the report
usually running on a different thread, it needs the thread id for the
measurement. Measuring cpu-time from a different thread is OK, and
already happens with VAL_THREAD_CPU_TIME elements during the report.
While at it, stats_time_end now uses the thread id which was stored on
start instead of using pthread_self(). This also serves as a general
protection against measuring start/end from different threads, which
would yield generally meaningless results anyway. In mpv all the
start/end calls for the same element are at the same thread.
On Windows and any other platform where cpu-time is unsuported,
previously the cpu-time was reported as 0, and now it's omitted
(at the perf-info property native value).
Code which process this report, like stats.lua, could not distinguish
between 0 which was due to unsupported platform, and "real" 0 which
indicates zero cpu activity in this poll-period.
In stats.lua this resulted in a whole lot of empty cpu graphs,
including one for every loaded script.
Now cpu-time is excluded from the report on unsupported platforms.
Real-time is obviously still being reported where requested.
Implementation wise, this is slightly hacky, by literally only
excluding the cpu-time nodes from the report itself, while keeping
all the other cpu-tinme code intact.
A more correct solution might be to identify support at compile
(configure) time, and no-op the relevant code if needed.
However, stats.c is already hacky in parts, and there's no real cost
to keeping the code active even if the result is excluded at the
report, and it's also way simpler and less bug prone. So be it.
Amusingly, this was not working correctly for at least a decade. For
all OSes, the default drive is the same except for macOS. It had
"/dev/diskN" as the default dvd drive. Back in the mplayer days, there
was actually dynamic compile time generation (only for mac) that
replaced the N with the actual number*. But this didn't actually work
for all stream types. It seems like it never worked for stream_dvdnav
and was only a stream_dvd (libdvdread) feature. And then later that
stream got removed completely. So at least for macOS users, they had a
fallback device of "/dev/diskN" for certain stream types and for a very
long time.
We can't really do better here, but we should at least pick a default
string that has a chance of working. So /dev/disk1 it is then. With
that, all of the devices become the same so we can combine it all and
use the same default optical drive for both CDs and DVDs. BD will be
added in the next commit. Also /dev/dvd is some antiquated thing that
doesn't really exist anymore. Linux systems will likely still have
/dev/cdrom which has a decent chance of being usable. /dev/dvd probably
won't be there.
*: f215e84339
The refactoring in bbac628a1b missed that
the initial update handler didn't immediately run all the triggered
callbacks but would instead delay it until the next playloop. This
subtly breaks things of course like hooks, force window handling, etc.
Ensure that we immediately run all the callbacks like before on startup.
Fixes bbac628a1b
Fixes https://github.com/mpv-player/mpv/pull/15828#issuecomment-2663830477
A very long time annoyance with wayland was compositors indefinitely
blocking our vo thread if the surface gets occluded in some way. We've
worked around this by using mailbox and our own custom vsync function.
Thankfully it looks like people are finally solving this and with these
two protocols it should be possible to guarantee forward progress on
vulkan which means all the workarounds we do shouldn't be needed. So we
can just request fifo in this case as a default since all we want is
standard vsync blocking.
With the upcoming fixes to FIFO in wayland, it should be preferable to
use FIFO instead of our own hacky heuristic. This means
--wayland-disable-vsync should become a tristate option with an "auto"
behavior (not implemented in this commit). The semantics have to
slightly change so introduce --wayland-internal-vsync and deprecate
--wayland-disable-vsync.
Enabling IME by default can cause problems when the player is
expecting keybinds and not text input. Windows IME implementation
mitigates this by switching IME to alphanumeric mode,
but this is impossible on Wayland with the text input protocol.
Disable it by default and add a note to recommend enabling IME only on
demand, like console.lua.
This makes console and mp.input users enable IME when text input is
active and restore IME to the previous state when text input is inactive,
to ensure the best IME mode is selected based on input context.
The default item also has the same background color but with
transparency.
Also stop bolding selections since inverted black and white backgrounds
should be visible even with color blindness. It was annoying with
proportional fonts because it misalignes similar strings.
As mpv's default text colors are white on black border or background,
--osd-selected-color's default of a bright yellow meant to be used with
a black border becomes unreadable with the inverted white background.
We could default to a dark --osd-selected-color and a a light
--osd-selected-outline-color and use --osd-selected-outline-color as the
selected back color. However in show-text commands having only the
selected item with a different white border doesn't look good.
This therefore adds indipendent selected_color and selected_back_color
script-opts. --osd-selected-color is only used for completions and for
the selected item when searching the command history with
outline-and-shadow.
This reverts commit ad0c29e5ac.
This should be unnecessary now that the menu has a visible horizontal
and vertical hitbox, and was not discoverable anyway. Right click can be
useful even while the console is open to pause or open a context menu.
Requested in
https://github.com/mpv-player/mpv/pull/15145#issuecomment-2428032616.
Draw a background behind selectable items even with outline-and-shadow.
This makes sense for a menu because you want it to be readable, select
something and move on. It doesn't stay open while watching like OSD
messages and subtitles, so it can cover more of the video. In fact this
was probably the only menu without a background by default. Also the
scrollbar without a background looked weird, and the background shows
the new horizontal hit box.
--osd-outline-color determines the background color with
outline-and-shadow, while --osd-back-color determines the background
color with background-box. Some transparency is added because using pure
black is not recommended because it causes eye strain; alternatively
--osd-outline-color could default to #222222.
Drawing the background ourselves also allows making the corners rounded.
Free-form text mode keeps using only background-box backgrounds if
configured as covering the whole screen while searching stats key
bindings would be bad. Searching history also doesn't add a background
to not change the layout abruptly. When searching history with
background-box, it preserves the alpha component of --osd-back-color.
Add a scrollbar to give a visual representation of the size and position
in the items. It is not clickable.
The counter is moved above the scrollbar to free up a line for an
another item, simplify calculations, and prevent the selected item from
jumping from the second to the first line as you type.
In terminal output there is no easy way to draw a scrollbar to the right
due to Unicode widths. This just moves the counter into the prompt.
The newly added max width calculation allows positioning the select menu
in the center of the window.
The input line is moved above the items so that the selected item stays
near the input line as you type instead of jumping from top to bottom as
the matches decrease.
Keep aligning to the bottom left to search the command history to not
change the layout abruptly, the same reason the monospace font is kept.
Follow up to c438732b23 which improved the calculation with the default
outline-and-shadow. We can make the calculation accurate for
background-box too without making semitransparent rectangle backgrounds
overlap by disabling the shadow of selectable items, and drawing a
single rectangle below the items.
We could also calculate the height of each item to make them perfectly
adjacent by rendering each one with compute_bounds, but that takes 15ms
per render even on a new CPU, so 20 lines would take 300ms, which is too
slow.
The rectangle is as wide as the longest item. Even using compute_bounds
once on the longest item on each render() slows it to the point of
making updating the highlight while moving the mouse slower than with
outline-and-shadow, especially on old hardware. So cache the width of
the longest item when opening the console and update it when
osd-dimensions change.
Also increase the items' height to opts.font_size * 1.1 because it looks
better with some margin between the items. It is possible to do it now
because selectable items are drawn in separate ASS events in all border
styles.
The big option callback in player/command will trigger on every single
update. This is not so great when several heavy option changes are
called in rapid succession and operations are pointlessly repeated. Try
to copy the approach that input commands do and run the actual callbacks
during the playloop. This is not really a smart or sophisticated
mechanism. It also only works for the main option cache. In theory,
other option caches like vo_opts could get spammed too and this makes no
attempt on those. But regardless, this is probably good enough for us.
mp_option_change_callback now tries to group together any new callbacks
with existing unprocessed ones and drop redundant ones whenever
something new arrives.
For some reason, mp_option_change_callback had weird special logic on
init to start the ipc client. This makes no sense. It should just be
started in mp_initialize like all the other clients.
Users basically never need --hwdec=auto in reality and sometimes it
bites them unexpectedly (e.g. #15814). Unfortunately the name is kind of
nice sounding and if you don't read the manual closely, you might
inadvertently end up using it. So just make auto the same as auto-safe.
auto-unsafe is introduced to have the old behavior of auto instead. A
similar thing is done with the -copy variants. Try to update the
documentation of this section a little bit and discourage people from
using auto-unsafe because it's kind of dumb.
Partial revert of the drm stuff added in commits
4d09cde8f9 and
0d7b4d64a5. This was due to my
misunderstanding and simply that my card has some sort of mesa bug. It
appears that YUV sampling is somehow skipped for the implicit modifier
path on radeonsi if the client doesn't use EGL directly (e.g. like
vo_dmabuf_wayland which creates a wl_buffer from dmabfus directly).
Anyways, all of this is just wrong so remove it. All mpv should do is
match format + modifier pairs in the tranches and nothing more.
Currently using mp.input while the console is open doesn't do anything.
We can allow using mp.input multiple times in a row by keeping the
console open, and sending a closed event only when the previous calling
script is different from the current one. If it is the same, sending a
closed event would unregister the new input-event listener, so it is
just never sent in this case as there is no sane way to do it. This is
useful e.g. to try out select script bindings in the console, or to
switch to a different mp.input script binding with a key binding without
having to close the current one.
Calling input.select() again within input.select()'s submit handler
needs to be fixed separately because with select the console is
immediately closed on submit (367a6b561a), so input.lua receives submit,
requests a new selection, and receives closed wich unregisters the
handler of the new selection. Just not calling
mp.unregister_script_message("input-event") fixes it; its only purpose
was to allow garbage collection of variables defined in the scope using
mp.input.
Fixes#15795.
Having path -> path in the log is kind of useless. If someone happens to
call this on memory://, it will also flood the log with garbage. Only
log it if the path actually gets expanded.
We already have more than enough options. This doesn't need to exist.
Just use the environment variable if you really want to use this for
some reason.
Sometimes there was an immediate return on error and other times it
destroyed things before returning the error. Make this consistent
whenever something fails while we open. Also remove the destruct
function since it is completely redundant with bluray_stream_close.
Sometimes a CD can have non-audio data at the start that is not
playable. libcdio/paranoia is smart enough to already skip this, but our
calculations for when the tracks/chapters start completely fall apart.
The beginning bytes are not valid CD audio so it should just be
subtracted and ignored. This probably doesn't work if a CD somehow has
its audio tracks in a non-continuous manner with non-audio data
in between tracks at random points. There's likely not much we could do
in such a case, and probably nobody has an audio CD like that anyways.
Ref: #8322
We hit a -Wstrict-prototypes error which was fixed in the latest release
of libcdio-paranoia but openbsd is too old. We already have coverage of
this in other CIs so remove it.
The same as 04a2450aab, but now cdda is
auto detected, so disable it explicitly.
This test requires that the OS language settings be English so the
--subs-match-os-language option is actually testable. In Linux, this can
be done by just setting LANG and it always will work. For macOS and
Windows, we use the OS APIs to get the languages and let the test
proceed if we find English. Gracefully fail and skip otherwise.
Internally, mpv uses '-' as a separator for language codes like
specifying the region/variant for the language. However, the posix
environment variables for this separate using a _. Since
5009e13431, support for the _ separator
was dropped which meant that --subs-match-os-language actually didn't
work on linux/bsd at all (mac has its own separate implementation).
Instead of adding _ back to the function, it makes more sense to just
replace _ with - while we parse through the languages since this
implementation of mp_get_user_langs is the only one that separates with
_.
Notably they are exchanged between demux and decode thread. It's fine
because we know those pointers will be alive as long as avctx is alive.
And only the value may change during decoding in rare situations. Make
those pointers atomic for the sake of it.
It shouldn't change anything, except some codegen.
From https://www.gnu.org/software/libc/manual/html_node/Atomic-Types.html#Atomic-Types:
In practice, you can assume that int is atomic. You can also assume that
pointer types are atomic; that is very convenient. Both of these
assumptions are true on all of the machines that the GNU C Library
supports and on all POSIX systems we know of.
We use the ext protocol, not the wlr specific protocol. Moreover,
"zwlr_data_control_manager_v1" is an interface within the protocol, not
the protocol name itself.
Loading the file and then waiting it for it to be loaded again doesn't
need to be two separate functions. Combine it into a simple
"reload_file" so it's more readable.
This got refactored so it only loads one file at a time and not
everything in a loop. The option resetting at the end of conditional
branches is pointless.
The amount of options we have that are related track selection is insane
and touching any of this stuff is scary. Add some track selection
testing to the CI to hopefully make it slightly less scary to touch any
of that. Since trying to work in media files from some outside source
would be a pain and need to live in some repo somewhere, it's nicer to
just generate dummy files on the fly with ffmpeg during the ci runs and
use that. Obviously, the actual tests themselves could be even more
thorough (external tracks were not even considered), but this is more
than a good enough start for now.
The big libmpv test file is really actually three different tests shoved
together into one. They do all use fairly similar underlying structures,
so put the shared stuff into an inline header. There's a little bit of
duplication with regards to the main function, but it's cleaner to
separate out the tests.
mpv internally treats all string options/properties with NULL or an empty string the same way. client.h explicitly forbids MPV_FORMAT_STRING from being NULL, but in the C API, it has been working accidentally due to how strings are copied. Nevertheless, none of the APIs allow this; JavaScript, Lua, IPC, and CLI all require strings to be at least empty. We cannot pass NULL.
Furthermore, currently passing NULL causes an assertion failure in the JSON formatter, so it is clearly not intended to be used that way.
Internally, all string options default to NULL, but in this case, they should behave exactly the same as an empty string. Hence, this change is applied to the `demuxer-lavf-format` option.
Note that get_property will never return a NULL value, regardless of the internal value.
Fixes: #15840
HDR or any color-space pass-through should be opt-in, as we cannot
control the user's compositor or display. Allowing HDR signals to be
pushed by default may lead to surprising results for some users.
Additionally, for an optimal experience, this option should be paired
with the target-peak of the display.
Make the pass-through opt-in and let the user decide if they want or
need it. By default, mpv should render a safe and consistent sRGB
output. mpv's tone mapping is generally of higher quality than any
external solution.
This reverts commit 23843b4aa5.
This is not only cosmetic, but also avoids dummy get key action with
empty key. While this was allowed previously, I'm bit concerned about
Hyrum's law. But let's be strict about it.
This commit fixes current-tracks property.
Fixes: 95019fc256
Updating input-commands string list causes all commands to be rerun.
This happens during load-config-file command, so even with few commands
it is easy to amplify single command to run hundreds of times instead of
one. This causes timeouts and OOMs when specific command for example
reopens current playlist appending an item.
Also avoid even single input-commands, we want to test load-config-file
parsing and input-commands can do loadfile and trigger heavy code
paths. We don't want to mix this. Unfortunately parsing of
input-commands will not be tested.
It's unfortunate that it is implemented this way since changing it will
take time. This option should *really* be like OPT_CHOICE but with
doubles and not integers. We don't have that though and implementing it
is something for the future. Even if that was done today, this still
couldn't be switched to since setting -1 has been the effective way for
years to undo video-aspect stuff. So the approach is to just add another
special keyword for this and tell people to use that instead. Note that
setting 0 isn't deprecated since M_RANGE(0, 10) is totally fine and
would work in the future if this option type ever gets redone.
Setting this to M_RANGE(-1, 10) meant that you could pass fractional
negative values without it being an error. This is, of course, nonsense.
-1 is the only special negative value with a meaning. Error out if we
get anything else by doing some additional parsing before we send it off
to parse_double which will then restrict the range to 0, 10 with these
changes. Note that this approach requires defval to be there which is
not the most extensible thing in the world. But there's literally only
two OPT_ASPECT type options out of the hundreds we have so not a big
deal. Ideally, this type should be OPT_CHOICE but with underlying
doubles but that's too much effort to implement cleanly.
These were still set to float. For some common aspect ratios (e.g. like
4:3), the loss of precision is significant. The underlying calculations
are already done with doubles so all that needs to be done is to change
the type of the sub-property.
The error message is completely incomprehensible and also inconsistent
about whether it wants two newlines or just one after an import.
Consider this python script:
import sys
sys.stdout.write("garbage")
That passes the ruff isort check just fine. But this does not:
import sys
def fake_function():
sys.stdout.write("garbage")
fake_function()
This will fail. Why? Because there should be two newlines after imports
but only for functions. This is because of PEP8 rules about blank lines,
but this is not explained or referenced anywhere in output from the
lint. You only get a cryptic "Import block is un-sorted or un-formatted"
with some visual that isn't clear in what it's trying to communicate.
Additionally, it seems to go a bit beyond PEP8 and also will fail if you
have too many blank lines (i.e. more than 1) in certain cases if the
succeeding line isn't a function or class definition.
Furthermore consider this example:
import os
import sys
from subprocess import check_output, DEVNULL
This also fails the lint. Why? Because DEVNULL should come before
check_output. Again, the lint doesn't explain this and you're left
guessing what horrible formatting sin you committed.
Considering the amount of time I wasted trying to even understand this
and I still don't, just delete it. How are contributors supposed to
understand what this lint wants when the project's own developers were
confused by it. Please just alphabetically sort your python imports and
don't do "from foo import *".
If the cloned repo is shallow (e.g. like the default github actions
settings), the git describe command won't actually be able to fetch any
tags and will instead just get a hash. The resulting binary version
string will end up being that git hash. While it does tell you the exact
commit, it's not exactly helpful when wanting to know the general
version at a glance. For the case where we do have a git directory but
no available tags, build a version string using the mpv version + the
commit hash.
Fixes#15789.
While parsing through the separators, the OP_APPEND also needs to use 0
for the separator since it is supposed to be unescaped. This was missed
in the code reorganization of d2c409c56b.
Keyvalue lists were unaffected because only OP_DELETE and OP_REMOVE use
this code.
This update introduces a demux_packet_pool, allowing for the reuse of
previously allocated packets when needed.
sizeof(AVPacket) is not a part of the lavc public ABI, which prevents us
to allocate memory in larger blocks. However, we can substantially
decrease the amount of alloc/free operations during playback by reusing
both mpv's demux_packet and AVPacket.
This adjustment addresses the root cause of issue #12076, which,
although resolved upstream, did not fully tackle the persistent problem
of allocating small blocks of aligned memory. This issue largely stems
from the FFmpeg design of the AVPacket API. After this change memory
will no longer be allocated once cache limits is reached.
The demux_packet_pool is shared as a global pool of packets for a given
MPContext.
This change significantly speeds up the demuxer deinitialization,
benefiting file switching scenarios, especially when a large demuxer
cache is used.
See: #12294
See: #12563
Signed-off-by: Kacper Michajłow <[email protected]>
And move show-text ${path} to middle click. This is more useful than the
replaced show-text ${filename} binding since the left click stats
binding already shows the filename, and it matches how right clicking
other buttons shows menus. Alternatively middle click could also be
bound to select-watch-later.
Property names contain '-' characters, which are translated into
underscores because POSIX shell variables cannot contain hyphens.
We should do the same thing for forward slash characters (i.e. '/')
because these also cannot be present in the names of shell variables.
Fixes: #15782
When playing a video, 55% of CPU used in strlen, callgraph flip_page: ta_talloc_strdup_append ,
ta_talloc_asprintf_append and ta_talloc_strndup_append .
Before the fix: 2 fps when playing 1080p 24 fps video (--vo-kitty-use-shm=no),
24 fps after the fix.
video/out/kitty: move bstr cmd to priv
Now that mp_normalize_path can accept NULL and we have a shorthand for
expand + normalize, now is a good chance to simplify this to make it
less awkward.
Expanding a path and then normalizing it is probably a common shorthand.
The reason to not incorporate this directly into mp_normalize_path is
because it requires the global struct which is out of scope for
path_utils so use this wrapper instead.
If a talloc_ctx was being made solely for a onetime usage of getting a
normalized string, we can now just pass NULL instead and free the string
directly to make things easier.
It is not needed to expand ~ in file completion as you type after
62c3aeb9c made commands themselves interpret it. We only need to call
expand-path on the directory before passing it to utils.readdir in order
to find files in it when it contains ~ placeholders. As a bonus this
will now also complete files in directories like ~~/ and ~state/.
This simplifies command completion, and was also the blocker for
splitting running commands out of console.lua, since I didn't know how
to replicate it through mp.input.
This reverts commit 86383aef95.
shutdown isn't actually sent on exit() but only with internal options,
e.g. set osc no, which isn't relevant for users.
shutdown is not sent only when the player quits, but also when
individual script are unloaded, either by calling exit() or by toggling
options like --osc.
This was already mentioned in javascript.rst so remove it from there.
This reverts commit 850e03d29f.
The previous commit solved this in a more general way. You can do:
[open-console]
profile-cond=p['user-data/mpv/console/open'] and p['current-tracks/video/albumart'] == false
profile-restore=copy
pause
Thankfully pause_on_open was just added and has not been in a release so
we can remove it.
b56e63e2a9 removed this because it was
deprecated and not clearly useful. This commit adds this operation back
to string lists and keyvalue lists, but with one important change. It
operates via the actual values and not indexes. So you can use
--foo-del=bar,bar2 to remove bar and bar2 from foo. The difference from
using -remove is that this is subject to escaping rules and has the same
caveats as -add. Note that -del wasn't added back to the object settings
list because you can already remove multiple items with -remove from it.
Done with 4a084c0df8. The reasoning was
that it was "confusing", but without using -add it is impossible to
append multiple items to a list in a single command and just overall
makes this less powerful. The code works fine. You might find yourself
in escaping hell, but that's on the user to deal with.
Also it's worth noting that -remove with object settings lists can
actually remove multiple items and unlike the other list option types.
As described in 544240c829, the callbacks
are all run on init so UPDATE_AD and UPDATE_VD both executed. While this
is probably not harmful, it is completely pointless work and results in
extra event notifications being sent. Just skip these if there is no
matching chain.
The options in vd_lavc are all related, but they don't all require the
same thing for runtime changes. To avoid having to manually add UPDATE_*
to every single option flag, the options can be split into two separate
structs. The vd_lavc_conf becomes a catch all for all the --vd-lavc
options that require the full UPDATE_VD flag. The rest of the options
are split off into the new hwdec_conf instead. Additionally,
--vd-lavc-software-fallback is renamed to --hwdec-software-fallback and
moved to the hwdec_conf as well. The new name better reflects what it
does and it logically fits with those more. UPDATE_* flags are added on
everything now so these should all now be changeable on runtime.
There's several path-related options that do not handle common shortcuts
(like ~/). Fix this by using mp_get_user_path where appropriate which
expands the path so users get more intuitive behavior. Fixes#15598.
The frame-step command also signals on up events. This is only useful
when using the default "play" mode. For seek mode, it triggers another
frame step which is not what you want. Rearrange the logic so the up
event is ignored for the seek flag. The frames check is also not needed
since add_step_frame already handles it.
Fixes 9661a3839b
1a558bf5c2 effectively aliased the custom
OSC printing to actual mpv properties instead. These only exist for
backwards compatibility which hopefully will get removed one day so
instead deprecate them and warn users of what they should be using.
This ensures that we don't open some other fd, for example when loading
playlist. Also filters out loading any local files.
This also allows to remove custom filtering from fuzzer itself.
Previously, the default behavior of frame-step and frame-back-step is to
play forward 1 frame or seek back 1 frame. We keep this behavior but
introduce additional flags to control the exact behavior of the frame
stepping. The first argument simply specifies how many frames to go
through. The second argument specifies whether to play video to step
through frames or to seek to step through frames. Playing through the
video to step through frames only works going forwards (otherwise it
will always seek). In theory we could use backwards playback for this,
but that can be decided later.
As a minor note, MPSEEK_BACKSTEP is renamed to MPSEEK_FRAMESTEP since
forward seeks can use this as well. Fixes#10128.
Add the generic menu to bar layouts to provide discoverability for the
select menus to users who don't realize you can right click OSC buttons.
There's no space to add it in box layout.
Taken from the last freely licensed version of Symbola and manually
adjusted the number in the glyph file to match the adjacent arrows.
Saving sfdir with fontforge also automatically removed the O flag from 2
existing glyphs. According to
https://fontforge.org/docs/techref/sfdformat.html "O" just meant "the
character was open when last saved", so it doesn't change anything
visible.
When using --prefetch-playlist, if demuxer options are changed in the
time window between the start of prefetching and the playback of the
next file, the old values are used. This includes setting demuxer
options in legacy extension auto profiles.
Fix this by setting a flag when demuxer options change and not using the
prefetched data when that flag is true.
UPDATE_DEMUXER is not added to demux.c's options because those already
support updates while playing.
It should be more than enough for this and avoids some huge allocations
on broken files. 128 MiB is already huge for audio buffer, but better
than 4 GiB...
The history could be formatted as CSV, but this requires escaping the
separator in the fields and doesn't work with paths and titles with
newlines. Or as JSON, but it is inefficient to reread and rewrite the
whole history on each new file, and doing so overwrites the history with
an empty file when writing without disk space left. So this uses a
hybrid of one JSON object per line to get the best of both worlds. This
is called NDJSON or JSONL.
Co-authored-by: Kacper Michajłow <[email protected]>
This adds a "native" Wayland clipboard backend based on the
ext-data-control-v1 protocol.
This backend overcomes the limitation of the VO (Wayland core protocol)
backend, and does not require the presence of the VO window to receive clipboard
updates.
This backend also supports primary selection if supported by the compositor.
The backend runs in a separate thread, so clipboard reading
does not stall the player like the VO backend.
Fixes reading EMBL sizes in some files and makes this function readable
while at it.
Would be good to inline mp_log2(), but should be good enough.
Fixes: #15691
basically a copy of tsl0922/mpv-menu-plugin#77
if you have 200+ menu items and update `menu-data` about 400 times,
clicking menu item will not execute any command, the reason is that the
menu identifier greater than the max value of 16-bit unsigned integer.
1. make menu id always less than 0xF000 as mpv-player/mpv@861908c7 said
2. old menu items are never reused, should delete by DeleteMenu()
instead of RemoveMenu(), destroys the handle and frees the memory
The leak detector has been disabled due to a libass leak that was
causing the test to fail. I initially expected this change to be
temporary until a patch release of libass became available and we could
update it. However, it has been a few months without a release. Instead
of waiting, re-enable the leak detector and add a suppression file for
this specific leak.
Fixes: d6eb85bb1a
Note that all mpv code expects 64-bit offsets already. And we set
_FILE_OFFSET_BITS=64 unconditionally. Also this mirrors lseek() that we
already have wrapped in similar way.
Trivial wrapper around _chsize_s() to return -1 on errors always.
_chsize_s() returns errno value. At the same time errno is set to the
same value.
FILE_WRITE_DATA has to be added in append mode, because _chsize_s()
requires write permissions, not only append. We lose atomic append, but
we follow POSIX here, so that's fine, I guess.
If you have two seats connected, both with the pointer capability, and
use two hands to start a drag and drop operation with each pointer, then
move one pointer to the mpv window, then the other, mpv fails the
!wl->dnd_offer->offer assert in device.enter, because it expects that
the compositor wouldn't just call device.enter again before device.leave
or offer.finish.
The data device is per-seat, so this commit makes mpv track the data
device's offers per-seat rather than in vo_wayland_state, which makes
more sense and is easier to reason about when multi-seat is involved.
I have no idea why, but console's blur is smaller than in OSD messages
and stats (regardless of persistent_overlay). It's smaller regardless of
scale_with_window, or if using 0 PlayRes like stats with
persistent_overlay=yes.
With scale_with_window=yes, multiplying the blur by 2.5 seems to make it
the same. This is probably because 2.5 is 720 / 288, which are the base
height sizes scale from and the OSD's PlayResY. With
scale_with_window=no, we need to multiply by osd_h, which is always 720
with scale_with_window=yes.
This is useful for text input in, for example, console.lua. Each
character in the commit string gets turned into an mpv key press.
Pre-edit strings are not handled, since there's currently no good way to
handle that or make it useful to text input scripts. Like win32, which I
tested in wine, another limitation is that the composition window is
always positioned at the top left of the window, since we cannot get
useful positioning hints from mpv scripts. It allows the composition
window to be within the window and avoids obstructing the console
prompt.
This can be enabled/disabled with --input-ime=<yes|no> (default: yes).
To make mypy happy. PyQtGraph doesn't define types, so ignore those.
PyQt6 has types, but we use only one function from it, so to avoid
installing it, ignore it too.
FLT_MIN is a small positive number (1.175494e-38), so the check v <
FLT_MIN introduced in 0e7f9c39dc made all 0 and negative float option
values error, e.g. panscan=0 or video-align-y=-1.
Fixes 0e7f9c39dc, fixes#15728.
table.sort() is unstable, meaning that it randomly reorders items with
the same score, so currently fuzzy_find() checks if the line is empty to
not change the original order of the unsorted items. But actually filled
lines have the same problem: e.g. searching foo with filenames like
foo_{1..99}, they are returned in random order.
To fix this sort by score only when 2 items have different score, else
sort by the original position.
It is not clear what update() updates, in fact this rename allows
removing the comment explaining it. render() is clearer and is the same
term used by the OSC.
OPT_FLOAT values currently reuses OPT_DOUBLE handling, but if a
finite double value is produced which is out of the float range,
it results in UB.
If the floating point implementation is IEEE-754, then the value is
converted to infinity and stored in the float. However, this still
does not work as intended, as infinity is rejected for OPT_DOUBLE
unless infinity is explicitly specified as the min/max range.
Fix this by adding another clamping stage after operating the values
as double. Finite double values are clamped between FLT_MIN and
FLT_MAX, and out of range error is signaled when suitable.
With this combination of options, the playlist is shuffled every time
the last playlist is reached, instead of when restarting from the first
playlist entry. Abort prefetching in this case, as we can't predict
which file to prefetch until the playlist is shuffled when actually
going to the first file again.
With --prefetch-playlist and --loop-playlist, mp_next_file() is called
continously since the last second of playback or when viewing an image,
which decreases --loop-playlist=N to 1.
Fix this by adding a flag to mp_next_file() to specify whether to
decrement --loop-playlist=N. The first playlist entry is still
prefetched when it's the next one, but without decrementing
--loop-playlist=N.
Give console's overlay a high z only in select mode, since in this case
you want to click it so it should be above other overlays. In particular
console should be above the OSC's box layout with visibility=always when
you show it by clicking its buttons.
Keep using z=0 otherwise when it doesn't handle clicks, to avoid
unintuitive behavior of overlays handling clicks like the OSC being
drawn below console.
Since the legacy mp.set_osd_ass() doesn't accept z, we need to repeat
its caching logic, like 490b3ba007 and 86d24b069b did for the OSC.
This reverts commit 2dd5bd4cd1.
Instead of drawing the box layout below any other overlay with z >= 0
which may not be wanted, the next commit will increase console's z only
in select mode instead.
Currently determine_hovered_item() assumes that each item is
opts.font_size pixels tall, which usually works well. This breaks with
fonts that get drawn taller than that, such as Japanese text, which
makes the calculation inaccurate for the top items and clips the
counter. A couple of users reported that it is inaccurate for them for
the top items even with ASCII characters in track selectors, presumably
because the circles are taken from a different font and make all lines
taller.
To fix this place each selectable item in its own ASS event positioned
like determine_hovered_item() expects.
Unfortunately this breaks --profile=box, so keep placing every item in
one ASS event with it.
This deduplicates the calculation of the y position by assigning it to a
y variable, which will also be used in the next commit. margin_x is also
renamed to x for consistency.
Rename lines_max to max_lines which is the name used in other functions,
and inline the log_messages variable because its name was confusing.
The math.max(0, lines_max) call was not necessary because console
doesn't crash with 0 or negative max lines.
Some Wayland clients not offering text/plain will send their non-text
data regardless of the MIME type requested in wl_data_offer.receive. We
should just not call receive if they haven't offered a MIME type we
want.
Define the icon font and icons in variables instead of scattering them
throughout the code to make it easy to change them in the future, or for
forks to change them. Also put the hex values in comments to easily
compare which icons in the font are unused, and explain how to get the
decimal values of the bytes.
Copied from ModernX.
This adds a format parameter to screenshot-raw command which controls
the format of the returned image data. In addition to the bgr0 format,
this adds support for 3 other formats: bgra, rgba, rgba64.
bgra is used by overlay-add command and several window systems.
rgba and rgba64 are used by several GPU APIs and are the formats
returned by the gpu and gpu-next screenshot code, which avoid the need
for further format conversion (see convert_image function).
rgba64 also adds the ability to acquire high bit depth screenshots
for screenshot-raw command.
When the monitor goes to sleep, the OpenAL context was not properly
handled, resulting in a null pointer dereference and a crash. This
fix ensures that the OpenAL context is created and set correctly,
avoiding crashes under these conditions.
Fixes: #15648
The server's protocol version is not available until a connection is
properly established. Currently the value of `PA_INVALID_INDEX` is printed
due to calling `pa_context_get_server_protocol_version()` before connecting.
Fix this by doing the call after the connection has been set up.
Fixes: f744aadb77 ("ao_pulse: dump library version etc.")
Add a script-opt to pause when console opens and unpause when it closes,
disabled by default.
This is particularly useful for selectors that take several seconds to
open so you don't have to guess when to pause, like the subtitle line
selector with embedded subtitles, or my script which lets you select
which lyrics to download after requesting them with curl.
Make this behave like the comment says it should, because currently when
you show oneshot stats and change file, stats are printed again and hide
--osd-playing-msg. This happens even if you hide the stats by
show-texting something else and change file before the timer expires.
Implement VOCTRL_GET_DISPLAY_FPS and VOCTRL_GET_DISPLAY_RES by returning
values obtained from Vulkan.
Currently, display fps and resolution info is not available in the
displayvk context. Display fps is needed for display sync to work
properly. The information is also used as the value of a few properties.
This slightly improves parity with the drm context.
Unlike font and border sizes, the default stats shadow offset is 0 like
--osd-shadow-offset, so it can be inherited from it by default to not
make users configure it in 2 places.
Since 0 and negative numbers are valid offsets, use infinity as the
placeholder for unconfigured values.
they were meant to be immutable. imported in swift as mutable pointer,
which leads to errors with the strict concurrency in swift 6.
make the pointers const.
they were never meant to be mutable and are imported as mutable vars
in swift. that causes errors with the strict concurrency in swift 6.
make them const/lets and immutable.
It is now handled internally by the libmpv profile.
Since `player` was the default option, the impact should be minimal, as it
is uncommon to override the default option with the same value.
yes/no args will function the same way as before this commit.
3dcc661de7 made the cursor reset to Default style to not apply the blur,
but \blur0 achieves that without resetting every user style. The cursor
can thus respect the user's --osd-back/shadow-color.
Following up 19537a4996, also respect the user-specified color in the
cursor. But the cursor is drawn as a border, so we actually need to use
--osd-color as the border color.
It was requested in
https://github.com/Samillion/ModernZ/issues/259#issuecomment-2556608926
to make console's shadow offset consistent with --osd-shadow-offset. Not
specifying shadow offsets achieves that. This disables console's shadow
by default but there is no reason console should default to having
shadows but the rest of the OSD shouldn't. Users who want shadows can
enable them in the whole OSD with --osd-shadow-offset. console-specific
shadow_{x,y}_offset script-opts can be added if someone requests them
later.
The previous commit changed --osd-back/shadow-color to nearly the same
one console was using. This allows unhardcoding it from there and using
--osd-back-color even with --osd-border-style=outline-and-shadow for
consistency with the rest of the OSD.
By default OSD and subs have no shadow, but if you do set a
--osd/sub-shadow-offset, the current default white shadow color looks
bad around white text with black border. Default to semitransparent
black instead. Use the same color box profiles were using to allow
removing it from there.
The lines in populate_log_with_matches()
if selected_match < first_match_to_print then
first_match_to_print = selected_match
will set first_match_to_print to 1 even if it is not set here since
handle_edit() sets selected_match = 1.
When console is opened with selectable items and a default item, the
default item is placed at the center. But if you type something and then
clear the line, the first item becomes the selected one. Make it select
the default item and place it in the center in this case too.
fixes problems with upcoming features DisableOutwardActorInference,
GlobalConcurrency and InferSendableFromCaptures for swift 6 strict
concurrency. enabled with -enable-upcoming-feature flag.
since we load covers/images directly in a our own thread and the quick
look thumbnailing also works asynchronously on its own thread, we need
sync/coordinate both threads. otherwise it would be possible that a
cover from a different file could overwrite the cover of the current
file.
to prevent this every cover generation has a unique timestamp and only
covers for the last cover timestamp will ever be shown.
we are also not interested in icon type thumbnails, since those are just
generic file type icons.
quick look thumbnails can only be generated if quick look can read those
files. files unknown to macOS don't work out of the box and you need to
install a quick look extension for this, "QuickLook Video" for mkv.
I added RW to edition-list/N/id in 34f2143e8f because in #8077 it was
assumed that it is writable from the wording of the docs. But what the
docs actually meant is that you can retrieve edition-list/N/id and then
use the retrieved value to set the edition property.
Remove RW and the ambiguous sentence.
In files other than MKVs edition-list is an empty table, not nil. It is
current-edition that is nil.
However nil still needs to be checked to not crash with mpv --idle.
When this was originally implemented, I lazily skipped the optimization
when using display sync because mpv would rip through all the frames
without waiting since there was no blocking. With the previous commits,
we now fall back on the audio sync logic when the window is not visible,
so the extra condition can be removed.
The previous commit put all the pieces in place so now this can be
implemented. Scheduling frames is already written with the assumption
that display sync maybe turn on/off at any time. So all that needs to be
done is check if the VO reports that it is not visible. If so, simply
flip mpctx->display_sync_active to false for that frame and skip the
display sync frame handling. It will become true again when the mpv
window comes back into view.
x11 and wayland VOs + backends all have logic that skips drawing frames
when the mpv isn't visible for efficiency reasons. This is implemented
in each individual VO, but it is useful for the core to be aware of this
as well. Currently, the display-sync modes on x11 do not try to be
efficient and always render anyways because there is no blocking on the
graphics API level if you skip rendering a frame (wayland works here by
accident). This means mpv would otherwise blaze through frames which is
not what anyone wants. We can instead improve this by implementing the
blocking mechanism in the core and using that when appropriate. This
commit does not implement that yet, but simply switches the draw_frame
to a boolean. Receiving false means that the VO is not drawing frames
and it should be treated as if the surface was hidden.
The first completion is highlighted because it is automatically inserted
when pressing Enter, but this isn't the case when the console is used
with mp.input.get, and autoselecting it can be undesirable if you're
entering arbitrary text, unlike with mpv commands where you're usually
choosing from predefined lists. So just don't highlight the first
completion for mp.input clients.
We build and ship this code, so it makes sense to make sure it is ok.
Tests for FFmpeg, libass and libplacebo are explicitly enabled. The rest
is in default state, so if tests are enabled by default, they will run.
similar to how our config.h is created the feature flags added to the
swift build should be generated from our features array, instead of
manually adding those when needed.
this prevents errors when forgetting to add any needed flags or remove
obsolete ones.
the equivalent options have been deprecated since mpv 0.35 in ac39661
and 2207236.
also bumping the MPV_CLIENT_API_VERSION to 2.5, since 2.4 was forgotten
in 6f619d5.
There were a few pitfalls with the way this was previously implemented
because --geometry implicitly depended on --auto-window-resize being
enabled to operate in a few cases. Instead, let's change the logic a bit
so that instead we choose whether or not to reuse the old rc (i.e. don't
resize) and use the wh_valid and xy_valid fields within the m_geometry
struct instead of using x11->geometry_change. This fixes several edge
cases involving setting the position with --geometry when using
--auto-window-resize=no.
Document the syntax and mention how it can be used as Unicode
codepoints. ASCII range has worked since the feature was inplemented
in 86a87de590 and Unicode range has
worked since a63e880400.
It also works with known special keys if you know the internal values
of keys because there is no filtering in place, but this should not be
encouraged.
When shift modifier is used with text key names, it is usually
silently ignored, except for ASCII key names, which can be
confusing. Document it clearly.
This doesn't work for changing page key script-opts at runtime because
they are used as the indexes of the pages variable, but nothing actually
breaks if you do, it just uses the initial values. This is still useful
for conditionally changing sizes at runtime or for trying out the
osd-box profile by applying it from the console.
Stop overriding the OSD font and outline color in the console input line
and log, except for the lines already in a different color. This allows
configuring the console color and makes it consistent with the rest of
the OSD, like 51bd00c33a did for stats.
Modified the man page.
There were two pairs of key bindings that appeared in one order but
the description of what they do appeared in the reverse order. Modified
the description to match the order in which the keys appear.
Note: I have not tested this change.
Currently if you change --osd-selected-color the preselected item stays
yellow and can't be changed. Since the default item style was just
chosen from the selected color without the bold, also make the default
item follow --osd-selected-color.
Requested in
https://github.com/Samillion/ModernZ/issues/259#issuecomment-2556608926.
an empty value to a commandline option usually means that parameter does
not expect anything, but in case of `--proxy`, yt-dlp use an empty value to
disable proxy setting, the empty value need to be passed to `--proxy`
Like 565e7d906c did for avif, consider 1-frame HEVC as images, as HEVC
videos have nb_frames 0 or > 1.
Specifically, in the FATE suite:
nb_frames = 0 and are images:
cbf_cr_cb_TUDepth_4_circle.h265 food.hevc hdr10_plus_h265_sample.hevc
hdr_vivid_h265_sample.hevc hevc-monochrome.hevc
nb_frames = 0 and are videos:
mv_nuh_layer_id.bit paired_fields.hevc
paramchange_yuv420p_yuv420p10.hevc pir.hevc
nb_frames > 0:
dv84.mov extradata-reload-multi-stsd.mov multiview.mov
two_first_slice.mp4
As with other video codecs, the hevc images with nb_frames = 0 which are
really frames cut from a video are not detected as images, but you will
only find these files in FATE.
Right clicking playlist arrows already opens the playlist selector so
bind something else to right clicking the title. Make it show the full
path which is useful but not bound anywhere on either the keyboard or
the OSC.
- It makes more sense to select a playlist entry from the buttons that
navigate the playlist than from the title
- Provides different bindings for right and middle click
- Mirrors chapter button bindings
The problem here is likely ao_alsa specific and has the same symptons as
what the previous commit fixed (audio not playing when the file changes
but the details are a bit different here and the sample rate does not
matter. When using gapless audio (the default), the core player
immediately marks the audio status as EOF after it starts draining and
allows the remaining audio buffers to play while it marches on. This
works fine. When not using gapless audio, it doesn't immediately set EOF
and instead waits for the audio to finish playing before it does
anything else. The problem is that ao_is_playing is always true so the
core waits forever thinking audio is still playing when it actually
isn't.
ao_play_data is what is in charge of setting the mp_pcm_state with it
calling out to the backend for additional help. Unfortunately, this
doesn't work for alsa because it's too dumb to signal the desired states
in this edge case so we have to help it a bit. The main thing to notice
here is that even though we can get EOF from a frame, there can still be
additional valid samples that compe after it. So we can't just
immediately quit after EOF is seen. The approach here is to simply save
if we got eof sometime in the past, wait until we get no more samples,
mark state.playing as false and then jump over to the eof code. This
will set p->playing to false as desired which allows the core code to
set EOF and finally we can go through the reset logic and actually play
audio for the next file.
There is a condition here that is supposed to wait until the ao is
finished playing before it goes through the rest of this function and
actually starts the reinit of the audio chain. This is not needed
however and actually causes a bug. uninit_audio_out already takes the
gapless audio case into account and drains the audio before preceding.
There is no reason to bail here. Additionally, returning early here
actually breaks ao_alsa. ao_alsa is pretty dumb and not able to cope
with changing samplerates. It explictly needs to stop the PCM and then
start it again for it to work. The old code here ensured the ao would
never reinit itself and then would wait forever trying to play samples
with no actual data. Other AOs (pipewire and pulse) seem to be able to
cope with this and reinit themselves in other ways (didn't look in
detail). This change makes no difference for them. Note that in many
cases, this appeared to work on ALSA because there is a high likelihood
that your default audio device will choose a 48 kHz sampling rate and
thus your entire playlist is resampled to 48 kHz which avoids the
bug.
Fixes#15477.
Previous fixes in bcc3d72 make subtitles on videos with non-square pixel
aspect ratios appear incorrect. This can happen on subtitles for SD
Blu-rays where the video resolution is 720x480 but the aspect ratio is
4:3. The scaling still applies when the video frame is cropped with
filters so the previous fix will still work.
Fixes#15415.
console is drawn below the OSC. This looks bad only with layout=box
because there is no user-data/osc/margins so it overlaps with it. Fix it
by using z -1 with box layout.
Follow up to 86d24b0 and 9c22d6b.
This is still used for caclulating a/v sync and delay remaining even
for initial samples, so we should always update it to the actual vsync
for those initial samples so we have something to work with at least.
And if we receive bogus values, also reset it to 0 along with
prev_vsync.
Not having base_vsync set to _some_ value completely breaks
vsync_skip_detection, and mpv stays stuck in a permanent mistimed state
where every frame is marked as delayed and never recovers from it.
Introduced a new `fadein` option to control the fade-in effect for the OSC.
The default value is `no`, which disables fade-in. This option allows users
to enable a fade-in effect when the OSC appears. Updated documentation
accordingly.
These are easier to read with _ between words. Also screenx/y could be
assumed to be display coordinates, so rename them to osd_w/h. They are
not named osd_width/osd_height to avoid Redefined local LSP warnings
with the ones in the upper scope.
Update flags are often updated, so make space for expand them. Reorder
all values to make it easier to add new ones, until there is no more
space.
Co-authored-by: Guido Cella <[email protected]>
With --ignore-path-in-watch-later-config the basename of files is used
for watch later files, but since 1d640c9887 this was checking the wrong
variable to determine if the file is a URL and thus also taking the
basename of URLs, when URLs should use the full path regardless of this
option.
This is already done in WndProc, but the flag was not set if we exited
event loop and were processing mpv dispatch messages in fallback loop.
This fixes the case when Window is destroyed externally or otherwise
event loop fails for whatever reason. Calling vo_w32_uninit does call
DestroyWindow() through dispatch, which in turn calls WndProc, so we
need to guard recursive call.
If a hook fails to invoke or a client has been removed during hook
processing, attempt to continue with the next hook if possible.
Before this commit, any failure during hook processing would cause the
hook processing to stop.
This issue can be reproduced when auto_profiles.lua registers an on_load
hook and exits afterward because no profiles are registered. In such a
state, the next hook would fail and not invoke.
There are many scenarios where a hook client may be broken,
unresponsive, or disabled, so it makes sense to continue processing
subsequent hooks.
The regression we observed was caused by e2284fba1 and 5dc404741, which
made auto_profiles.lua register hooks and then exit, leaving stale hooks
registered. However, the root cause is not limited to the
auto_profiles.lua case.
Fixes: #15465
* Early exit if there is no useful data in the AVReplayGain
structure (FFmpeg does check that gain of at least one thing is
not INT32_MIN, but leaves the peak unchecked so it can be zero).
* Less depth in the if structure.
This simplifies the code, not requiring a loop.
Moves the getter definition somewhat upwards to allow
for its usage in a function that was defined before it.
This allows to select DVD/Blu-Ray title easily. Titles are listed as
editions with their duration and number.
I wanted to include Angles also in this selection, but currently Angles
are not that well supported, so let's stick with titles and leave the
rest for the future changes.
We might migrate to lavf demuxer for DVD/Blu-Ray in the future, the mpv
implementation is rotted anyway.
Fixes#14586
This ignores --video-align-{x,y} when the video is smaller than the
window in the respective direction.
After zooming in, panning and zooming out, this is useful to recenter
the video in the window.
Unlike doing this by observing osd-dimensions in a script, this is done
before rerendering, so you don't see the image being rendered uncentered
for an instant after zooming out, before being rerendered centered.
Also update --video-align docs while at it.
This doesn't work well with --video-pan-{x,y} because you can move the
output rectangle far away from the image, and when zooming out pan is
abruptly reset to the center. It doesn't feel like natural like zooming
out after changing --video-align-{x,y}. So this commit doesn't set pan
to 0. Also this leaves a way to move scaled images within the window
even with --video-recenter.
The first AVPacket method has been deprecated in FFmpeg, and only
the HEVC decoder would read this information from there. The native
AV1 decoder as well as the libdav1d wrapper only support the newer
propagation method via codec context's side data. {ad,sd,vd}_lavc
call mp_set_avctx_codec_headers which copies the side data from
codecpar to codec context, so no changes are required on the
receiving end.
This process has been deprecated since avformat 60.15.100 and
since avcodec 60.30.101 AV_PKT_DATA_DOVI_CONF has been read from
AVCodecContext's coded_side_data. Additionally, the HEVC decoder
is the only one which currently reads this side data from packets,
the native AV1 decoder as well as the libdav1d wrapper instead only
support the newer propagation method via codec context's side data.
How this currently is supposed to propagate is:
* demux_lavf copies the codec parameters into sh_stream's lav_codecpar.
* {ad,sd,vd}_lavc call mp_set_avctx_codec_headers that calls
avcodec_parameters_to_context, which then sets global side data
to the codec context.
As this logic is already in place, so no additional changes are required
for things to work and the deprecated function call can just be
cleaned up.
Ref: FFmpeg/FFmpeg@5432d2aaca
Ref: FFmpeg/FFmpeg@804be7f9e3
Ref: FFmpeg/FFmpeg@12e5116872
This avoids inserting the characters in front of the cursor again when
completing to text already in front of the cursor.
This is important after 2f271a92de made Enter automatically insert the
first completion.
the mpv_global struct is a public struct defined in common/global.h. in
the case that this header is included directly or indirectly into our
swift bridging header, code that uses that struct as an OpaquePointer
will fail to build, because swift would now be aware of its actual type.
preemptively include the header and properly define the type to prevent
such errors in the future.
i also checked all other usages of OpaquePointers and this is the only
case where this is relevant.
See e1d30c4 and 4ff9f50 as reference
If p->colormatrix is 0 if not set by user, so it would always override
_orig parameters with Dolby Vision ones and restore that erroneously.
Fixes: e2365bfece
This documents the scalable keys (currently WHEEL_*) and notes
how the keys work with scalable commands. Mention touch pad
as a common source of scalable input source.
For complex key bindings, the table now contains a new member
of the current key scale. mp.add_key_binding() now accepts the
scalable flag to make the binding scalable.
script-binding command is currently not scalable, so script
registered key bindings also cannot be scalable, unlink input.conf
bindings.
This makes script-binding command scalable so that it's possible to
define scalable key bindings in scripts. It now calls script-message
command with an extra argument with the scale of the key.
Since native clipboard is implemented on win32 and wayland,
use the clipboard property instead.
This fixes the problems with commandline implementations of clipboard:
- On win32, the powershell implementation is complex, and it can take
several seconds to run for the first time.
- On wayland, it requires wl-paste to be installed, which isn't always
available. It also works poorly on GNOME.
Since VOCTRL is not suitable for frequent data query
(see 477a0f8318 for details),
it's not suitable to be used by the VO clipboard backend.
Instead, since the VO does the clipboard monitoring by itself,
it can notify the player when the clipboard is updated.
This adds an internal notify-property command so that VOs
can notify player when the clipboard is updated, so that clipboard
monitoring works.
This uses GetClipboardSequenceNumber() to detect clipboard
content changes. Clipboard Format Listener is a better way to
do this according to MS docs, but sequence number works and
the listener requires creating a dedicated thread and HWND
for monitoring, so I will save it for a later time.
This adds a clipboard monitoring API for backends which use polling
to monitor clipboard updates. --clipboard-monitor option can turn
clipboard monitoring on and off at runtime.
Clipboard contents are available as selection data offers under
Wayland. The offer can become invalid at any time, so request the
text format content immediately when an offer is received,
and cache the content for later use.
This adds clipboard property which uses the clipboard
API to get and set clipboard contents. Currently only
clipboard text is implemented, but this can be extended in
the future to cover primary selection and other formats.
This adds a clipboard API with multiple backend and format support.
--clipboard-enable option can be toggled at runtime to turn native
clipboard on and off.
This has been happening for a while now apparently, so change it to
accurately reflect reality. I chose the next release as the point to
formally make this change, because I was under the impression that we
didn't have to list new options so I never did it and there may be
others like that too.
Instead of printing circles in show-text ${playlist}, ${chapter-list}
and ${edition-list}, introduce --osd-selected-color and
--osd-selected-outline-color to reduce clutter, make the selected item
easier to differentiate, and have visual consistency with select.lua.
The defaults are taken from the style of the selected item in the
console. These new options are also used there, replacing the hardcoded
styles. Due to being user-configurable, selected item styles are changed
to take priority over default item styles.
The default selected style is yellow and bold. The bold (hardcoded)
allows differentiating the selected item with color blindness. There is
also a separate --osd-selected-outline-color option defaulting to black,
since without it if the user changes --osd-outline-color yellow text
becomes unreadable without a black border. --osd-selected-back-color is
omitted for now.
Text and background colors are inverted for the selected item in the
terminal. This is hardcoded, adding an option is overkill.
A disadvantage of this commit is that if you run print-text ${playlist}
with a VO, the selected style ASS is printed to the terminal (but ASS
printed in the console is interpreted). This commit avoids printing the
reset ASS sequence for non-selected items to reduce clutter in this
case.
Dependent tracks are supposed to be processed further and not directly
used.
For example, an HEIF tiled image tracks are meant to be stitched into a
full image before being displayed and requires special handling.
Another example would be MPEG-TS audio track tagged with mix_type=0.
Which means that the audio stream is a dependent stream and is intended
to be mixed or combined with a separate complete and independent audio
stream by the receiver.
In either case we should not directly select such tracks.
After pressing Tab a space is usually appended after the suggestion, and
with the new autocompletion you have to enter a space again before
seeing the completions for the next token even when there is only 1
matching completion. Just don't append spaces and let the user manually
type 1 space after completion, which is more intuitive.
...and after navigating the history.
I thought of making the new function accept the new cursor position and
set it, but it would not be clear that you're only supposed to call it
when handle_edit() is not already called.
2f271a92de made it so that the first completion suggestion is
automatically selected when pressing Enter, if none was manually
selected. So automatically highlight the first completion in yellow to
show this.
2f271a92de made it so that the first completion suggestion is
automatically selected when pressing enter, but that was done after
saving the command in the history. Save it to the history after
expanding it, so re-running the previous command actually works, e.g.
save "set vo gpu-next" instead of "set vo gn".
It turns out mpv doesn't tag at all when doing conversions, so we just
re-tag here and hope for the best. This should be improved, but there
are many different code paths when conversion can happen, so for now
revert to previous behavior.
Fixes: 4e5cc9cf1d
If we lose the current output for any reason (unplug, turns off, etc.)
and then later it comes back, mpv should always recalculate all the
scaling stuff. The optimization to avoid needless scaling calculations
didn't consider this case and would always exit since the scaling is the
same. So just check wl->current_output's existence as well.
Fixes#15361.
The previous documentation was pretty scary and misleading, and was
also outdated in several sections.
It was also difficult to understand some of the paragraphs.
The path documentation has now been overhauled to be much easier
to understand and to document the latest mpv behavior.
Typing a command prefix crashes console because first_useful_token is
nil. This already happened before implementing autocompletion if you did
no-osd<Tab>, but autocompletion made it evident.
Show available completion suggestions as you type without having to
press Tab.
This is fast even on a 2011 CPU, so we can get away with doing this in
the same thread that draws the console. The one case where it could make
the console hang is file completion of network drives, but in general it
is convenient for loadfile.
mp.input.get clients also get a request to complete on each character
typed, but those run in a different thread so performance is always
fine, and completions were already rejected if the input line or cursor
changed after the request. If I ever make running mpv commands an
mp.input client in the future, command completion will also benefit from
running in a different thread.
This fixes `ytdl_hook`, which would start playback with the thumbnail
track selected. This issue occurs because the thumbnail track is added
first. If the main track is not marked as default afterward, which it
isn't for single streams, the first track (the image track) would be
selected.
In general, if a non-image track is available, it should be preferred.
Ubuntu 24.04's pkg-config is already an almost empty transitional
package that depends on pkgconf, and pkgconf contains the
`/usr/bin/pkg-config` binary.
Thus while we are moving macOS to it, we shall do the same with
this mingw-w64 build.
This works around an issue with recent Github CI runners where
Homebrew is in an intermediate state. This is where old pkg-config
is installed, yet pkg-config as a package has become an alias
for pkgconf, thus causing failures to automatically switch symlinks
from one to the other.
Ref: actions/runner-images#10984
Giving very long lines to libass freezes mpv and makes the CPU spin
(though it's fine with terminal output). This is often the case
user-data/mpv/ytdl/json-subprocess-result in the property list. So limit
the length of selectable items to 300 characters (not Unicode aware).
This is enough to fill a 1920x1080 window with font_size=16 and Japanese
text.
If an item contains newlines, it hides the top items. This is often the
case for sub-ass-extradata and metadata/ytdl_description in the property
list. So keep only the first line.
Whenever mpv window gains focus, a new data offer is sent for the
selection. However, mpv currently treats it the same as dnd data
offers, which results in wrong handling. One bug which results from
this is when focus follow mouse is enabled, dropping the dnd file
results in the window being focused and selection offer being sent,
freeing the existing dnd offer. This results in dnd being broken
on at least GTK3.
Fix this by separating selection and dnd offer handling. Since there
is no way to know whether an offer introduced by
data_device_handle_data_offer is a selection or dnd offer, make it
pending, and move them once the identity is confirmed.
While most Wayland compositors provide a socket path indicated by
environment variable WAYLAND_DISPLAY, others may sometimes bequeath a
socket file descriptor specified by WAYLAND_SOCKET.
mpv has too many commands and they are unorganized in the
documentation, making it difficult to navigate.
This commit completely reorganizes the commands into several
categories to make the documentation easier to navigate.
The following categories are defined:
- Playback Control: Seeking and stepping.
- Property Manipulation: Changing property values.
- Playlist Manipulation: Playlist navigation and editing.
- Track Manipulation: Track navigation and editing.
- Text Manipulation: Text printing, expansion, escaping.
- Configuration: General configuration and related files.
- OSD: Displaying contents as OSD.
- Input and Keybind: Input configuration and key bindings.
- Execution: Execution of mpv and subprocesses.
- Scripting: Script loading and communication.
- Screenshot: Taking screenshots.
- Filter: Changing filters.
- Miscellaneous: Other commands.
If the playlist is loaded directly from a protocol like memory://, the
playlist_path represents the entire playlist. In cases where we have a
large playlist, this results in the entire playlist being duplicated for
each item. For example, if the input size is 300 kB with 10k items, we
end up using 3 GB of memory just to store the playlist_path strings.
With --osd-border-style=opaque-box and background-box, respect
--osd-shadow-offset.
I am not sure if --osd-shadow-offset should be inherited with
--osd-border-style=outline-and-shadow, especially since it doesn't let
you specify different x and y offsets.
The current OSD font size is excessively large, causing most
messages—except for very short ones to overflow horizontally.
I conducted testing across multiple devices of varying screen sizes and
under different scenarios. The adjusted font size strikes a good balance
for readability on non-high-DPI displays, while high-DPI displays should
utilize DPI scaling as needed.
Additionally, I compared the font sizes of subtitles and UI elements
across various VOD platforms, which generally use smaller font in most
cases.
The current sub font size was significantly larger than even PGS
subtitles, which are quite large on their own. Now, they are comparable.
The subtitle font size was chosen based on recommendations from the BBC
Subtitle Guidelines. It is set to 8% of the video height with a
recommended scaling factor of 0.67. Therefore, at 720p (the reference
size for mpv font scaling), the calculation is 8% * 0.67 * 720 = 38.592,
rounded down to 38. This value falls within the recommended scaling
range of x0.5–x1 for desktop PCs/Laptops and TVs (32"–42"). For more
information, see
https://www.bbc.co.uk/accessibility/forproducts/guides/subtitles/#Presentation-font-size.
OSD font size is smaller than font as those elements shouldn't be
distractful and only noticable when the user wants to look at them.
Outline size is set to 5.5% of font size.
--input-cmdlist crops playlist-next-playlist, playlist-prev-playlist,
write-watch-later-config and delete-watch-later-config, so increase the
string length to that of the longest command.
Also stop specifying both the minimum and maximum length since they are
the same.
It already prints %, so there's no need for '/100'. Also, use the print
helper while at it.
6ea08be59a added a percent sign but didn't
remove '/100', so we ended up with both, which is redundant.
Allowing arbitrary command execution for the fuzzer is not ideal. While
some testing of this code is valid, unsupervised fuzzing of the input is
not. It may be better to add a dedicated test or fuzz-test for this
case.
82231fd74d mentioned that for the "rot"
transform flip=true must be set, which "makes no sense at all".
The reason this is happening is that the rotation matrix calculation
is only valid for the 2D coordinate system where y axis is 90 degrees
counterclockwise from x axis, but the coordinate system of chroma
offset has its origin at top-left so it is the opposite, which results
in the rotation going to the opposite way. Setting flip=true fixes the
rotation direction, but results in a flipped y coordinate.
Fix this by reversing the rotation angle for chroma offset rotation
matrix calculation. This also allows removing some duplicated code.
High --osd-blur values break the osd-bar by not drawing the filled
portion, and even low values just make it look worse, so don't apply
--osd-blur to the osd-bar.
Most of the commands list here are several years old and we will
probably never change them. And it is already stated in the description
of individual commands if they are deprecated or subject to change.
Furthermore, it is easy to add new commands at the end of this section
by accident. I added load-config-file and load-input-conf here without
realizing it's a separate section, and I assume this was also the case
for begin-vo-dragging.
The detailed issue is here:
#15212
problem: Since The AudioTrack is not an mpv instance level but a global object, it cannot support multiple mpv instances at the same time. For example, if you create two instances and then destroy one of them, the other instance may crash.
Add jni usage count to fix this.
Currently it asks which version introduced the problem, but
users are unlikely to know if they don't update and test every
single version released, and this field is rarely filled in
practice by non-developers.
On the other hand, it's much easier to recall the last working
version that they have used before.
So ask for the last known working version, which is useful
information for developers to narrow down bisecting range.
Also ask when did the issue start in general since the issue
can be caused by system or driver updates.
Observing playlist property with "native" type is too expensive for
larger playlists, and we only observe this property to
activate/deactivate next/prev buttons on the osc. We actually only need
to know if the playlist-count has changed, nothing else.
Fixes: https://github.com/mpv-player/mpv/issues/15264
The libplacebo colorspace hint api makes sense for things like vulkan,
but for other APIs like drm that are capable of directly handling
colorspaces and hdr metadata it's a nuisance. Add a pass_colorspace fns
that signals to vo_gpu_next that the backend doesn't need the color
information to be manipulated and can handle the metadata itself.
libdrm unfortunately doesn't give us what is actually supported by the
connector in question. To do that, we would have to parse the edid blob.
Use libdisplay-info to do this and make it required for drm support.
Using what we get back from the library, we can do a bit of sanity
checking for hdr metadata to make sure that the display in question can
handle it before we try setting the metadata. Strictly speaking,
libdisplay-info has stuff for dynamic metadata that we could potentially
use, but as a first pass and for simplicity, only static is considered
for now.
If a hook event can't be sent to a client because it no longer exists,
stop logging it as a warning, as there is no way for a client to remove
hooks, so it is expected that the hook can't be sent. This is documented
in libmpv/client.h.
If the hook event can't be sent for other reasons, like the event queue
being full (currently the only other possible reason), keep logging as
warning.
Also add the client and hook type to the message. They are also logged
just above, but only in verbose mode, so when only the warning is logged
you didn't see the client before.
auto_profiles.lua logs these warning since 5dc4047415, and this commit
fixes that.
Fixes#15244.
c2ed2e7 introduced the terminal_set_mouse_input function to various terminal
backends, but overlooked the dummy backend.
This causes linking errors when trying to build on platforms with no terminal,
as vo_kitty and vo_tct are unconditionally enabled and make use of that
function.
Unsetting _G.mp_event_loop at the top level quits the script, but not
within callbacks. Use the new exit() function instead. Fixes e2284fba18.
This actually has an edge case since e2284fba18 where you can add auto
profiles only later with load-config-file and the script stays unloaded,
but it's still reasonable to quit if mpv.conf has no conditional
profiles. You could always explicitly set --load-auto-profiles=yes in
this case.
Scripts can terminate execution by setting mp.keep_running = false. Add
an exit() function to wrap setting mp.keep_running and properly expose
this feature. It can be used e.g. by a thumbnail script to spawn workers
with load-script and then let them quit.
It is not added to the mp namespace as mp.exit because that would make
it look like it terminates mpv.
This mirrors the exit() function which already exists in js.
The note in javascript.rst about having to remove key bindings before
exit is not kept because they are actually removed automatically since
bf385e1140 (though it was accurate when the JS backend was developed
before upstreaming it).
The geometry output of vo_calc_window_geometry does not have
any information about the current window position. This causes
the window to move when setting geometry even without setting
x/y.
Change it so that the window position is unchanged if x/y are not
set and after startup.
Elements are not parented to the add list, as they are directly copied
to the target list. Therefore, we need to clean them up manually.
Fixes: 1f5a67d8fa
Some properties, like `${decoder-list}`, are resource-intensive to
expand. Prevent fuzzing from generating strings with excessive
expansions to encourage shorter test cases.
Expanding properties on each playback frame for `osd-msg1` can be
demanding. However, in regular use cases, this typically isn’t an issue,
so implementing a caching solution wouldn’t be practical in real
scenarios.
Fixes timeouts on OSS-Fuzz.
It comes up often in IRC and issues that users don't understand why the
path property is initially unavailable, so link the section that
mentions it from the Properties section, and expand on how to get these
properties.
Because it is a bit shorter than calling
utils.join_path(working_directory, path), it gives you a canonical path,
and it doesn't concate working-directory before URLs.
The command is documented to use the same syntax as input.conf, but
it doesn't work with sequence keys because it uses
mp_input_get_key_from_name for checking key names, when it should
use mp_input_get_keys_from_string instead.
Fix this by using the correct function.
Also move the loading of profiles and input section activation in one
place. Leaving this in mp_initialize has the drawback that encoding
section profile will overwrite options set by the user in the command
line, since it's set after the CLI options are parsed and processed.
mp_parse_cfgfiles happens before parsing the CLI, so loading the profile
there is better.
Calculate the hovered item from the bottom of the screen where the
console is anchored. This is simpler and accurate because it accounts
for the fact that the empty line between the log and the input line
isn't as tall as a full line, for the exact height of an always visible
OSC bottombar, and for the empty top pixels present because the height
isn't an integer multiple of the font size.
Replace the rounding to calculate the hovered line with ceil which is
what you would expect to work. Rounding worked better before because it
compensated for the errors fixed by the previous 2 commits.
This reverts commit 5e65999eb2.
This was wrong because an empty line doesn't occupy as much height as a
filled line. But update the comment so it is not unclear like before why
1.5 is subtracted.
The OSC changed to use select.lua for various tasks, resulting in a
significant change in user interaction. This adds a config file
which records OSC behavior changes so that the old behavior can be
restored.
Currently --script-opt=stats-font_size=n is much bigger than
--osd-font-size=n, which can confuse users, so calculate sizes the same
way.
The \fs value to replicate --osd-font-size is
${osd-font-size} * 288 / 720 with --osd-scale-by-window, and
\fs${osd-font-size} * 288 / ${osd-height}
with --osd-scale-by-window=no. This is because
sub/osd_libass.c:update_playres() sets
track->PlayResY = ass->res_y ? ass->res_y : MP_ASS_FONT_PLAYRESY,
where MP_ASS_FONT_PLAYRESY is 288.
This also works with persistent_overlay=yes.
{\fscx100}{\fscy100} would also replicate --osd-font-size with show-text
and with osd-verlay + --osd-scale-by-window, but not with osd-overlay +
--osd-scale-by-window=no.
The default sizes are multiplied by 720/288 = 2.5 to keep them the same
as before.
In the select menu there are no completions to align in a grid, so the
better looking proportional font of --osd-font can be used by default.
It is also easier to read for the visually impaired.
The text width calculation is no longer performed if the console is only
opened through select, it is only performed the first time something is
completed. This avoids having to pass an argument to get_font() to make
it use the monospace font regardless of selectable_items.
Fixes#15176.
1a558bf5c2 made osc-*list script messages aliases to show-texting the
relative properties, so use show-text directly in the menu. Also
increase the duration to be the same as the OSC buttons because the
default of 1 second is too short.
This adds --osd-bar-marker-style option which can be used to
customize OSD bar marker style. In addition to the existing triangle
style, a new style option is added to draw markers as lines.
Add support for tracking playlist_title and playlist_id metadata
corresponding to a given playlist url and the entries associated
with it.
This allows the inclusion of ytdl_playlist_title and ytdl_playlist_id
in the metadata property for single videos which have a corresponding
playlist-path property.
This commit also resolvesyt-dlp/yt-dlp#11234
Even with -Dgpl=false, some files including the documentation,
mpv.desktop, and some key binding files are still being built.
This means that mpv as a whole might not be LGPL even when the
program itself is LGPL.
Also the description that mpv is licensed under LGPLv2.1+
"if built with the -Dgpl=false configure switch" is incorrect
as it appears to give a license grant as long as the switch is
used, regardless if there is a bug in the build system that
results in a GPL file being compiled in.
Change the description to clarify this.
Remove some of the features that no longer exist or aren't directly
supported in the mpv code: Linux analog TV (DVB still supported),
SMB, bootstrap.py.
Also fix the path for mpv.desktop.
When the file is in the current working directory, stream->path points
the path user passed as arg, so it may or may not include './'.
Strip it from both to make the comparison work
Fixes: c201c4874d
For most actual desktop users, vulkan should be the a superior
experience over opengl as this point and our autoprobe should pick that.
For linux users, vulkan on wayland is rapidly seeing improvements and is
far ahead of egl. There is no sign of that changing anytime soon and
working fifo is on the horizon, so really wayland users should just all
be using vulkan from now on. For x11, there is not a big difference
between using egl vs vulkan as far as I know and both work well. macOS
already prefers the vulkan backend over the libmpv one anyways, and
finally windows still defaults to d3d11. Probably virtually no one uses
opengl on windows, but vulkan is reasonably common among windows users
and it doesn't make any sense to prefer opengl over it.
The two outliers here are Android and VK_KHR_display. On Android, vulkan
drivers are probably just a total disaster and let's not put ourselves
in that mess if there's no reason to. For VK_KHR_display, it actually
works fine except for one really big problem: VT switching doesn't work.
If you try it, enjoy losing all input and being forced to do a hard
reboot. It might be fixable if you use logind or something, but the
method of using signals like the drm context does won't work because
VK_KHR_display uses render nodes not primary nodes. Also, the opengl drm
context could support hdr in theory (some attempts were made but none
succesful) so it is probably "better". Maybe. Anyways, for these two
platforms, we still prefer opengl.
this effectively disables the workaround that picks the color/dither
depth based on the source and instead picks it based on the output
surface/pixel format.
macOS apparently always operates at 10bit internally regardless of the
display's bit depth. this changed at some point in the more recent macOS
versions, where previously macOS operated at a frame buffer depth
corresponding to the display. either 30-Bit Color (ARGB2101010) for
10bit or 24-Bit Color (ARGB8888) for 8bit.
Fixes#13767
It is redundant if you're already using the OSC, so only show the
chapter text. Also fix the documented default commands of these buttons
which were outdated.
This adds several script-opts to configure what OSC buttons do when
clicked. It lets you restore the bindings present before they were
changed to call select.lua.
The script-opts are listed one per line in the manual to not make that
section huge.
skip_backward and skip_forward script-opts are omitted to lower the
script-opts number because they are only in box layout and undocumented.
I'm not sure if it's worth adding script-opts for the wheel on the
seekbar.
script-opts for the current and remaining time and fullscreen are not
added to not add more script messages.
Closes#6291 and #11878.
There is a consensus that showing these list when navigating is
distracting. Also if you set --osd-playing-msg, the playlist is briefly
displayed and then overwritten by the msg. The chapter list can even
contain spoilers:
https://github.com/mpv-player/mpv/issues/4675#issuecomment-978840475
The next commit will remove these completely in favoring of making the
commands customizable.
Give buttons nicer names before exposing script-opts for their bindings.
In particular, rename cy_audio and cy_sub to audio_track and sub_track
because their left click binding no longer cycles.
This makes it consistent with most other bindings and lets you cancel
the operation by moving the cursor away (the seekbar bind mouse down so
you can keep seeking to different timestamps).
8bf5548 added mouse support to the console's select menu, so open it
from OSC buttons.
Left click on the title opens the playlist selector and showing the
stats is moved to right click.
Right click on chapter buttons opens the chapter selector.
Left click on track buttons opens the track selectors because seeing
which track you're selecting beforehand is useful.
Fixes#10621.
Now that the playlist counter is shown by default there is no use in
showing it again, so repurpose the binding to show the stats page with
file and track info.
First of all, `lutdata` was passed to `pl_lut_parse_cube()` even if
it was empty. This caused a bogus error message to be printed by
the LUT parsing code in libplacebo.
"[vo/gpu-next/libplacebo] Missing LUT size specification?"
One of the reasons why `lutdata` can be empty is if the LUT file size
exceeds the `max_size` limit passed to `stream_read_file()`.
So in this commit, `lutdata` is checked first before getting passed to
libplacebo, and a non-bogus error message is printed if it's empty.
And secondly, the max size allowed is raised from the quite limiting
value of 100MB to 1.5GiB. The new max matches the limit in LUT cache
which is used to support up to 512x512x512 LUTs.
Signed-off-by: Mohammad AlSaleh <[email protected]>
ca7006a6a2 replaced file reading with
stream_read_file which results in error when af_push_file is used
to test existence with 1-byte limit. Fix this by using
STREAM_ALLOW_PARTIAL_READ flag to restore the old loading behavior.
If the pull request is not found or is not open, it should not be
treated as a critical error. This situation can occur after a merge.
There is no reliable way to query a pull request from a workflow_run
event, so this has been made a non-error log.
It is excessive control to manually configure the terminal height limit
just for stats, if anything this should be added as an option used all
throughout mpv.
Use the property introduced in bf025cd289 to clip the lines of stats.lua
with accurate unicode width detection and considering --msg-module and
--msg-time. This allows removing the term ellipsis functions.
Also use script-opts-append instead of script-opts in the docs so
script-opts in mpv.conf, which could change keybindings, are not
overriden.
In idle mode, there is not status line and we sometimes want to have
output without last new line, which were always added after truncation.
Also, make sure we don't overwrite important chars with ellipsis, this
could happen when cut point is near the end.
Fixes: bf025cd289
When the present extension was originally implemented, nvidia was
specifically blacklisted. The reason was because at the time it would
give bogus values that appeared to be real but actively made playback
worse. So out of an abundance of caution, any nvidia detection at all
(e.g. on a multi-gpu system) would disable the use of the extension.
Well times have changed and actually presentation-time on wayland for
nvidia works now amazingly enough. For xorg, the extension still doesn't
work, but from user testing it does not seem to be harmful anymore. It
just does nothing. So we can remove the blacklist part and just only use
a whitelist. Like before, we only enable the extension for mesa drivers
by default so no practical change for anyone except multi-gpu systems
whom may have this enabled now but should not see any negative behavior
change.
This paragraph is clearly wrong. load-input-conf was recently added, but
even before that the enable-section and disable-section commands could
change key bindings at runtime without scripts.
This reverts commit 3840c98b36.
There are multiple reasons:
- the correct way to prevent tabs being mistakenly added is a CI linting step
- it can affect the editing experience of foreign source files
under mpv's tree (e.g. subprojects)
- at least one editor (BBEdit) misinterprets the values and also turns
soft tabs into 7 spaces
- it does not consistently apply to GH code view either
App Bundles operate in their own shell environment that is different
from the one in the terminal. the default PATH variable for all Bundles
is /usr/bin:/bin:/usr/sbin:/sbin. because of that mpv can not find
binaries installed by package manager that might be used in scripts for
example.
add an option to prepend paths to the Bundle PATH. we prepend to make
the order fully configurable, opposed to appending where the default
Bundle binaries would always take precedence.
Basically we only want to create the color surface if the compositor
supports parametric image descriptions and if the vo is dmabuf-wayland.
Instead of doing the weird dance of creating it in one spot and
destroying it later, just only make the wayland object when we actually
want it. It makes the logging less confusing as well.
Look it up if you really care but basically z as a format specifier
often doesn't work in mingw because reasons. Our CI was working by
accident because of meson previously ignoring the CFLAGS variable. Use
our wrapper instead for these places.
We hit a -Wstrict-prototypes error which was fixed in the latest release
of libcdio-paranoia but openbsd is too old. We already have coverage of
this in other CIs so remove it.
Mostly. It is annoying if we want to add some flag/option to all the cis
and then have to do it manually. Things easily get missed that way.
Skipped powershell because of course I'm not going to deal with that.
Scripts and especially internal scripts shouln't bypass msg.c logging
code for various resons, ranging from processing the input, filtering
the log levels, truncating the output and so on. io.write() is lazy way
of outputing to stdout without respecting mpv's logging module.
Uses osd message, because this has no prefixes. Added internal
flush-status-line command to flush current output without clearing
before exiting.
This commit will allow us to remove duplicated terminal handling code
from stats.lua, mpv core already handles all that and does it in better
way, without taking shortcuts.
Note that this still is not perfect, because if osd message is changed,
console cannot know about it and would still clear it, but this change
make it at least not do it to every message even if console is not used.
If not opened in oneshot mode, close the stats with ESC. Especially now
that ? toggles showing key bindings by default, this provides an
intuitive way to close the stats.
Also do some minor reformatting of key binding documentation.
All of the code to format playlist/track-list/chapter-list is
unnecessary when mpv's core can already show-text these properties.
Also an issue with this custom formatting is that showing fewer entries
than can fit on the OSD can make it seem like the playlist ends there
and there are no entries afterwards.
Also remove lots of pointless code around the track-list (mpv's track id
and the osc_id are exactly the same).
This simplification will make it easier to bind customizable commands,
otherwise yet another script message to call set_track would have to be
added, when cycle sub/audio already output information about the new
track on their own.
Call cut_osd_list() like with ${playlist} to print position/count above
the chapters. This is useful for movies with many chapters.
Stop printing the chapter numbers because they are not useful here, they
are only useful when navigating to a chapter.
Remove one of the spaces before the circles because they are too many.
This replicates osc-chapterlist before replacing it with show-text
${chapter-list}.
cut_osd_list() calls osd_get_text_size() even when outputting to the
terminal, which results in max_lines = 19. Use the actual terminal
height instead.
...instead of "n hidden items". This brings it in line with osc-playlist
before replacing it with show-text ${playlist}. Also make count_lines()
return the correct count.
If show-text ${playlist} is used with --osd-scale-by-window=no while
printing to the terminal or while mpv is starting, the out_screen_h
assignment in osd_get_text_size() causes runtime error: signed integer
overflow: 288 - -2147483648 cannot be represented in type 'int'. Fix
this by not making prepare_osd_ass() use an infinite playresy.
This prevents printing show-text ${playlist} without a line limit to the
terminal with --osd-scale-by-window=no, which makes only the last
playlist entries be printed, and the selected one is not printed if it
isn't among them. A later commit will make the line calculation
accurate.
- Don't do anything if clicking on the top counter, the input line or
the new line between the items and the input line
- Don't scroll upwards when hovering the counter
- Don't redraw before clicking to avoid quickly updating the overlay
before closing it with touch input, where the item you touch can be
different from the one that was highlighted
This makes scrolling with the wheel more usable because it doesn't
matter if the focused item is reset by moving the mouse slightly, and
scrolling always begins immediately.
This makes the MBTN_MID binding to handle_enter() unnecessary so it is
removed.
This makes it consistent with the new changes to show-text ${playlist}
and greatly simplifies the logic, making it sane to implement scrolling
the view with the wheel in the commit.
A packet with an unknown duration flagged the entire context and then
this was saved forever throughout the entire lifetime of the object.
This inherently doesn't work with the redecoding sub logic which will go
through all the packets again. So the second time around, packets with
known durations get treated as if they were unknown and things go awry.
Rework this so it is per packet like it should be and not a global
state. Note that f9cefbfec4 originally
added this for specifically eia-608 subtitles but their packets are all
detected as unknown anyway due to the durations so this is not needed
anymore and interferes with other things.
Otherwise, the index can technically grow forever because
sub_read_packets will trigger again, read the same packets, then add
them to the list. We should just clear the cache here in this case to
reset it back to 0. Also flag redraw_subs here as well.
Putting this in handle_osd_redraw was strange and my own comments didn't
help me remember what this was even for. The actual purpose here is that
the osd needs to be redrawn in the still image edge case as you go
through a playlist. This is because all the logic with checking
timestamps isn't applicable and we need to essentially clear the screen
with another redraw. Clearly, it makes more sense for this to be done
when a new file is successfully loaded and not in the osd_redraw where
that happens to work but was called repeatedly pointlessly.
This was added in 8f043de961 but the
redecode is a special case that is only ever needed for subtitles on a
still image. Normal video never needs this so just modify the
conditional to avoid doing more work.
Although this protocol isn't official yet, several compositors are known
to support it to some extent and this lets users actually view HDR with
less hacks/workarounds. The actual protocol here is simply copy and
pasted from the upstream fork* where these are developed. There is also
icc profile support in the protocol, but this is omitted for now in
favor of setting colorspaces and signalling hdr metadata. However for
mpv, this only actually has any practical use with vo_dmabuf_wayland so
this is the only VO that will make use of the protocol. When using
vulkan, this is already handled via vulkan extensions by compositors and
vo_gpu_next. So actually we don't want to use the wayland protocol in
that case since it will just get in the way. The only known limitation
on that front is driver support for hdr vulkan surfaces but as soon as
that is available it should just work with no code changes. For opengl,
hdr support there is a whole other mess with a lot of unknowns but
simply using this protocol isn't good enough and would require changes
elsewhere. vo_wlshm is currently too stupid to pick any format besides
bgr0 or 0rgb, so any color management there is meaningless at this
stage.
So this means that only vo_dmabuf_wayland can actually use this
protocol. But that's perfectly fine. Without this, vo_dmabuf_wayland has
a very bad limitation in that it cannot communicate colorspaces at all
and compositors have to guess. Using xx-color-management-v4 fixes this.
For the other VOs, merely having the common protocol setup stuff in the
common code does no harm and later if they get smarter, it's easy for
them to use the stuff since it is written generically anyway.
*: https://gitlab.freedesktop.org/swick/wayland-protocols/-/tree/color-xx/staging/color-management
we keep track of the current vo struct to flag for events that are
initiated async by various thread from different system notifications.
the problem here is the usage of that vo struct after uninit.
make accessing of that vo struct atomic and clear it on uninit, so it
can't be used afterwards by concurrent threads from system
notifications or events.
Fixes#15088
since the bundle operates in a different shell environment than the one
from the terminal, it only has a few default paths set.
add the homebrew ARM default install paths to the PATH environment
variable, so the bundle can also find the needed binaries like yt-dl.
since commit 15c48f3 we were force to start drawing on the main queue
again. this has several unintended side effects due to the nature of the
main queue. in this case fullscreen event and shutdown event are
executed out of order and fullscreening is done after shutdown, leading
to accessing options that are already de-initialised.
just nil the window on shutdown and make it impossible to fullscreen
after shutdown.
Fixes#14810
This should help new users to view mpv's key bindings as it's easier to
discover than shift+i and 4, because many other websites and terminal
applications show key bindings upon pressing ?.
The implementation is minimal since it already uses XIM for UTF-8 text
input. The only changes needed are small fixes: setting the IC focus and
correct the usage of window param for XFilterEvent, and IME will
"just work"...
...after setting 2 process-wide global values before VO creation:
LC_CTYPE and X locale modifiers. So this usage is currently limited to
libmpv clients which don't want to do their own IME processing.
locale strikes once again:
XIM input methods require them to be set before creating the XIM context to
work, even though they don't matter after the context is created. Both of
these values being process-wide global means that the only time to safely
set these values is before the process creates any thread.
In theory, mpv could set LC_CTYPE in the main when running standalone,
but locale being locale means something is always messed up. In this case,
setting LC_CTYPE changes "Character classification and case conversion"
behavior. While mpv uses its own ASCII-only is*() and to*() functions to
avoid some of the issues, it also uses strcasecmp() and POSIX regex which
behaviors are affected by LC_CTYPE.
In summary, to avoid unavoidable race conditions mpv won't do this in
standalone mode right now.
It's now libmpv users' responsibility to:
- set LC_CTYPE to a locale usable for XIM, such as a UTF-8 locale
- set X locale modifiers with XSetLocaleModifiers
- hope that all stars align if trying to switch locale back afterwards
On most setups, both of these can be empty strings, In this case, the usual
XMODIFIERS environment variable must be set to enable IME support.
(e.g. XMODIFIERS=@im=fcitx)
Running cross-compiled binaries may be possible, but the runtime
environment must be configured correctly. In some configurations, an
exe_wrapper needs to be used, and in all cases, the library path must be
set correctly for the given binary. Fortunately, Meson handles all of
this if cross-compilation is configured correctly.
Fix this by having Meson run the mpv binary directly, instead of as a
subprocess of a Python script. This ensures that the environment is
properly set for running host binaries, if possible.
Fixes: #15075
Fixes: 056b03f9ed
Some keys like WHEEL_UP are "scaled" if the input source is high
resolution, like touchpad. However, sometimes it's desirable to
disable this scaling and only active the key binding in discrete
steps, such as relative keyframe seeking which interacts poorly
if the command is scaled.
This adds the nonscalable prefix to disable this scaling.
Uploading all available formats has proven to be problematic because
more unusual ones can crash the driver, even when no upload is
necessary. Check the upload only if needed to avoid issues with broken
drivers.
This also might speedup the init process.
Fixes: #14956Fixes: #15030
Instead of considering every non-ASCII character 2-cell wide, use this
newly introduced property to let msg.c clip the select menu using all
available with.
Add 4 stage trie to lookup unicode codepoint width and grapheme join
rules.
Generated by GraphemeTableGen from Microsoft Terminal (MIT Licence):
https://github.com/microsoft/terminal/blob/a7e47b711a2adc7b9e80eddea8168089f7d3b11e/src/tools/GraphemeTableGen/Program.cs
With minor adjustment to use it in C codebase.
- Replaced constexpr with static
- Replaced auto with explicit types
Generated from Unicode 16.0.0:
ucd.nounihan.grouped.xml: sha256(b11c2d23673bae660fff8ddcd3c1de4d54bdf6c60188a07696b010282f515fcf)
VO_WIN_FORCE_POS is set even if the position is not provided by the
user, so we have no choice but to always fit. We should do this
regardless, and if any issues occur in multi-monitor configurations,
they should be addressed separately.
Fixes: #15049
Fixes: e5159de811
VK_EXT_shader_object was added in 1.3.246, mpv currently requires
1.3.238. Debian stable is at 1.3.239.
Fixes build on Debian stable (Bookworm).
Fixes: #15041
Fixes: 2ac1d6db32
Currently by default mpv sets --all-subs when calling yt-dlp for JSON
info. --all-subs is an option that simply expands to --sub-langs all
--write-subs. --write-subs is special that without it yt-dlp will no
longer extract any subtitle info.
mpv's yt-dlp hook has a logic that if user specify any sub-langs in
--ytdl-raw-options, it no longer uses --all-subs. Unfortunately, this
means unaware users will not get any subtitle any more until they study
the mpv internal code and add their own --write-subs.
This PR always specifies --write-srt, an alias of --write-subs, in the
hook, so users don't have to. The alias is used to maintain
compatibility with youtube-dl.
Fixes issue #14818
The video_pts condition here would bail out on still images with no
audio since their pts is always MP_NOPTS_VALUE. This is not exactly
great because the subtitles may need to be updated so just let these
files also go through the subtitle redraw logic below.
The CI breaking because some new format was added in the master branch
is pretty annoying so only run these on release versions that are known
to work to reduce some maintenance burden. Although why we even bother
with this is still a valid question.
Bit of an edge case since image-lut requires the frames to be remapped
again so the normal redraw when paused doesn't work. Also we use
update_options in the VOCTRL here.
By the default mpv tries opening URLs with ffmpeg first, and users who
don't configure try_ytdl_first get a slower startup for youtube URLs, on
top of yt-dlp already being slow.
Fix this by adding a script-opt of URL pattern to try with ytdl first.
Youtube and twitch are included by default.
Compared to the alternative of trying ytdl first by default and
excluding URLs with a media extension, this only works for the sites
explicitly included in the new option's value, but doesn't have false
positives on media URLs without an extension.
`av_timecode_make_string()` divides by fps unconditionally. And
relying on container_fps always carrying a meaningful value was
misguided. So we now check that fps is non-zero before calling that
function.
Issue encountered with a couple of old FLV files triggering a segfault.
Signed-off-by: Mohammad AlSaleh <[email protected]>
This adds click support for the select menu. Scrolling with the wheel
already worked.
If a custom OSC binds a button to a select.lua script-binding, this lets
users keep using the mouse to select an item.
While the OSC and the select menu are open at the same time, you can no
longer click the OSC's buttons. By using mp.add_key_binding instead of
add_forced_key_binding you could click both, but the console's binding
would be shadowed by MBTN_LEFT bindings in input.conf.
Homebrew does support 3 latest macOS versions, so while macOS 12 still
works it takes 1h 40m 7s to build. It is bit too much...
While we drop macOS 12, add macOS 15 as it is available now.
This remembers and sets window-scale when exiting maximized state. Also
fixes not staying in maximized state when exiting fullscreen mode.
Fixes: #14126
This change required some minor rework to make the code conform to the
following:
- Restrict line length to 88 character
- Use spaces rather than tabs (only affect ci/lint-commit-msg.py)
- Use f-strings rather than % formatting or `str.format()`
Enabled the ruff python linter in CI, and resolved the issues that were
detected by it. Ruff was used due to it's faster checking compared with
other linters like pylint. This was added to resolve the python linting
request in #13608.
this is already done in the updateSize method of the window.
also fixes an issue where the size wasn't properly changed, even though
the new and old size were different. the unfsContentFrame should have
been checked instead of the pixel representation of the same frame.
without swift mpv as a standalone app is unusable on macOS, since the
cocoa main main loop doesn't exists. furthermore most of the other
needed functionalities like video outputs, contexts, platform features,
etc are also missing.
without swift mpv is really only usable as libmpv.
With the pieces set in place with the previous changes, we can implement
the desired behavior. The trick here is that we do want to force
centering the window when mpv first initially starts and the window size
is not known yet. This can be done by simply checking
x11->pseudo_mapped. The other change is to just look if we have the
VO_WIN_FORCE_POS flag and feed that to highlevel resize.
c4e8c36071 made any usage of --geometry
implicitly center the window on the screen after a resize even if the
user did not pass any x/y arguments to the option. At the time, this was
probably wanted since --geometry was primarily a startup option and
likely the window wouldn't be centered on x11 without moving
coordinates. Times have changed since then and we support full runtime
--geometry changes on all the relevant platforms but it comes with this
automatic window centering behavior (except on wayland of course hah).
It's better to make such window centering optional and user controllable
since it is entirely reasonable that someone wants --geometry=50% to
just resize and not move anything. It's already trivial for a person
that does want to move the window to just add their coordinates to the
--geometry command so there's no reason to continue to force this
behavior since it is less flexible.
Instead, move the window centering stuff out of m_geometry_apply into
vo_calc_window_geometry. We give the power to the caller to whether or
not to force centering the window here and all usage of the function is
updated to simply call it with false for now. Additionally,
--force-window-position being set will also center the window like
before. All that is left is for the windowing code to take advantage of
this. See subsequent commits.
There's really no reason to have all these extra variants. It's not like
this is public API. Collapse it all into one vo_calc_window_geometry
function and callers can simply just pass the appropriate parameters to
get the same behavior as before. I'm about to edit this function again
in a future commit and I really don't want to make a
vo_calc_window_geometry4 for this so let's clean it up.
console.lua binds up and down to navigate its history. Add a private
flag to mp.input.get to instruct console.lua not to bind up and down, so
you can use them to scroll the keybindings page while filtering
keybindings.
If it is requested, this can be replaced with an argument to input.get
to not bind arbitrary keys.
Fixes#14966.
Pass everything in the tables passed by mp.input callers to console.lua
so new flags can be added without modifying these clients.
In Lua, callbacks have to be excluded from the argument tables to not
make utils.format_json() error, while with JSON.stringify they are
automatically omitted.
There was mixup between upload formats and device formats. Instead of
filtering the device formats with VO constraints, upload formats were
affected. It was working, because most of the time the upload is using
the same formats. But if there is conversion on the fly needed we were
filtering wrong list of formats. Upload formats are those that can be
used to upload to the given hardware frame, conversion during upload are
allowed if possible. The main fix is in select_format() which were using
device formats as input, instead of ouptut formats and upload formats as
output, instead of input.
The multi device part is mostly theoretical, but it turns out that
plasma does send multiple tranches to the same device so we have to take
that into account. And that means taking into account multiple devices
as well. In theory, a compositor should give us tranches for any device
that will work so as long as we find a match it should be OK. This is
still technically incomplete since mpv's core wouldn't react to a device
being hotplugged.
Both of these VOs draw buffers in software via wl_shm to an mp_image, so
they are affected by the internals of whatever mpv does for alignment.
When wlshm was originally written, mp_sws was aligning to 16 bytes and
thus it chose this value but it was hardcoded. vo_dmabuf_wayland later
blindly copied this value. e1157cb6e8
actually changed the internal value to 64 bytes. In theory, this doesn't
probably doesn't really matter since 16 should also work in most cases,
but we might as well stop using a magic number and be consistent.
Additionally, wl_shm did some funny alignments that no other software
output did. The reasoning was apparently due to warning messages from
ffmpeg while cropping*. This was left in at the time, but I'm not able
to reproduce any such warning messages on my end when I make this match
other software VOs. Go ahead and remove the MP_MAX business and align to
the fmt x/y like the other VOs do.
*: https://github.com/mpv-player/mpv/pull/6240#discussion_r227930233
The list options --screenshot-avif-opts and --vo-image-opts are
completed with an extra 8), e.g. --screenshot-avif-opts-add=8), because
*= in
screenshot-avif-opts=-:Key/value list (default\: usage=allintra,crf=0,cpu-used=8):
matches up to cpu-used= instead of instead of up to
screenshot-avif-opts=.
Fix this by enabling non-greedy matching.
4d09cde8f9 added this behavior and made
the format filtering more aggressive, but it's over correcting. The
misunderstanding on my part is that the problem was with modifiers not
with formats. There is hardware that do not have any valid modifiers
which means certain formats cannot possibly work correctly with
vo_dmabuf_wayland (broken colors etc.). Formats on the primary plane do
not require modifiers so if it happens to be a planar format, we can
accept it and possibly use mpv's autoconverter. If we do get a valid
format + modifier pair from the compositor, then we should always accept
it regardless if it is planar or not.
The old name is misleading. We do want these formats, but it is not
accurate to call them "gpu formats". Call it "planar" instead so it's
more obvious these come from drm primary planes.
When starting multiple processes of `mpv --shuffle` in parallel,
sometimes the random seed happens to be identical, so files are
played in the same random order.
mp_rand_seed(0) now uses a random seed provided by libavutil,
and only falls back to time in case of failure.
Since f411f3145b, these properties
no longer change with each loop. This however caused a regression
on the behavior of resetting loop count by resetting these
properties.
Previously, after the loop count is decreased, it is possible to
reset these properties back their original values and thus reset
the remaining loop count. Currently, because setting properties
has no effect if the new value is the same as the existing value
(which no longer changes), resetting these properties does nothing,
and remaining-*-loops (which are read-only) remain unchanged.
There is no way to reset them other than temporarily setting them
to a different value, which is awkward.
Fortunately, this can be fixed by marking these properties as
force_update, which always notifies changes when being set.
It turns out that probing too many blocks is bad. I did not attempt to
go through all the logic but reading that many blocks causes the
demux_reader_state have some pretty funny values which then makes the
playloop think it needs to buffer for cache. It's probably fixable...
but seems hard admittedly so I'll be lazy. Just take out a magnitude off
the probing down to 10000. These seems to be more than sufficient. The
sample in #13975 where we had the opposite issue only needs somewhere
between 1700 and 1750 blocks to be properly detected. Crudely looking
at the demuxer values, 10000 here doesn't appear to alter anything
meaningfully so it does not have the "too many blocks problem".
Hopefully this is a perfect medium? Further improvements to the probe
can always be added later. Or maybe we decide this is all a giant
mistake and delete it. Fixes#14924.
Newer meson versions added support for features that mpv has been using
for a long time. Annoying fallbacks were left in place to not break old
versions but ideally everyone should be using the newer build features.
Both the latest ubuntu LTS and debian stable (in backports) have 1.5.0
in their repos, so go ahead and bump the version so we can drop some old
code and let developers use newer meson features if applicable.
Key names are already required be UTF-8 like everything else
in mpv other than media file formats which support other encodings.
stream_skip_bom is the wrong function for this, since it also skips
UTF-16 BOM.
mpv only supports UTF-8 for configuration files. Other ASCII-compatible
encodings may "work" to some limited extent, but strings likely won't
as many places assume that all internal strings are UTF-8.
It makes sense to only descend into the subdirectory meson build file on
windows, but we should always make sure HAVE_WIN32_SMTC is 0 for other
platforms. Otherwise, it gets unneccesarily awkward to work with.
It's useful for user scripts to be able to use the same ytdl binary that
ytdl_hook uses without having to replicate ytdl_hook's process of
searching for the ytdl binary.
Some user scripts might also find it useful to be able to access ytdl's
json output that the ytdl_hook already receives, sparing user scripts
from having to make a duplicate ytdl binary invocation to get the json
output.
Providing just the json output is not enough though, as ytdl doesn't communicate
errors though it -- if an error occurs, ytdl provides no json output and instead
prints to stderr. So without stderr, there is no way for user scripts to figure
out why ytdl has failed: no such username / video id, the channel is not live
yet, etc. Because of that, the entire result of the subprocess call is provided
to the user scripts, containing stdout (json), stderr, ytdl's exit code, etc.
There's no advantage in using the forced version here. It is a leftover
from when this was an external script and forced was necessary to bind
key sequences reliably until 3f83671f20.
This results in all image params not being restored even if only one is
unknown. In particular params->color.hdr isn't cleared, causing
overblown color for some samples.
It should be safe to restore even unknown values.
mp_image_params_guess_csp will handle that.
This reverts commit 3acd253e89.
With the previous change, it is possible that the mp_hwdec_ctx contains
a list of known supported hwuploads. Take this into account when adding
to the p->fmts list. We want to be sure to select only something that is
actually possible to use. If the hwdec does not implement
supported_hwupload_formats, then all are assumed to work.
This is probably fringe, but I encountered it on my machine. The
hwupload filter happily does conversions all on the GPU side if
possible. Makes sense. However, it turns out that there is a difference
between e.g.yuv420p -> vaapi[bgr0] and a vaapi[yuv420p] -> vaapi[bgr0].
The latter worked without any issues on my hardware, but the first
example fails. To remedy this, we need to also do hardware uploads
during probing against formats and track what actually works (i.e.
vaSurfaceExportHandle). This commit only implements it in vaapi since it
is the only known place where this edge case is relevant. But other
hardware decoding drivers could easily add support later if needed.
It's a bit roundabout, but we were doing this incorrectly before. The
format table alone isn't good enough because it is possible the the
compositor may advertise different formats for a specific device which
is a subset of the format table. What we need to do is add formats based
on the array in tranche_formats. Note that it is possible for the
compositor to send multiple tranches (was not able to simulate this but
it's allowed by the protocol). For mpv, we only care about the very
first one which is supposed to be the most preferred one. The compositor
can also send the entire chain of events (main device, format_table,
tranches, etc.) all over again. We handle this in the wayland code, but
handling this in mpv's core code isn't done. e.g. say a format in use
was suddenly no longer supported. We ideally should do a full reconfig
in this case, but that gets complicated and is pretty niche so save that
for another day. Multiple GPUs isn't taken into account either. We just
pick the first one. Not strictly correct, but close enough for us.
Fixes#14544.
The linux-dmabuf protocol gives us the main device being used. Using
that along with some drm code, we can get what drm formats are supported
by the GPU. This is pretty crude as we just check against the first
primary plane we find and hope for the best. Also the protocol can
technically update formats at any time (e.g. if the device changes). We
do update what gets stored in wl->gpu_formats but the next commit won't
make any attempt to address this hypothetical scenario. It's complicated
and this is better than nothing. In practice, this will only work
against one constant device during VO runtime. Additionally, we can add
this check to ra_compatible_format to filter out additional unsupported
formats.
ASS_OVERRIDE_BIT_STYLE includes ASS_OVERRIDE_BIT_ATTRIBUTES, which we
don't want.
This prevents --sub-ass-override=force from overriding attributes such
as bold, italics, underline or strikeout to mpv defaults.
Apparently for an user mpv would crash on startup if built with asan and
mpv attemps to load mpv-mpris. Just set --no-config so we don't load
anything external since this is more correct anyway.
With --msg-module the select menu also highlights the "statusline" on
the next line. Fix this by resetting the color before \n instead of
after it.
This requires changing all log code to not preemptively add a newline,
which is actually simpler, though we have to modify the messages
received with log-message which already contain a newline.
When I introduced the behaviour of `auto` trying every hwdec down the list
instead of giving up after the first one fails, I forgot to update this
part of the docs.
Ideally it should be fast, it is on VO thread and steals precious frame
time budget. Looks like this is one of the main reasons why
display-resample on higher refresh rate displays is too slow.
Even Debian stable has them, so no need to keep compatible with ancient
versions.
Note that this does not change runtime version requirement for Vulkan.
Fixes: https://github.com/mpv-player/mpv-build/issues/234
On platforms where it is unstable/experimental, it is disabled behind
environmental variable, so safe to probe it there too.
Fixes usage of hwdec=yes with gpu-api=vulkan, where hwdec would be not
enabled. Position it after older and more stable variants. That means
the -copy variant of the other API will likely be prefered.
Also avoid regular white/black, because it is often the terminal
background and invisible as foreground color.
Change debug messages to blue while at it to differentiate them from
trace ones.
These options accept an empty value within their choices. If the user
didn't add manually input a quote before completing them, add quotes
automatically so that the blank value can actually be used.
This allows Tab completing them in the console and zsh, and using cycle
scale.
jinc is also added to --tscale=help's output, while before it was
missing because validate_scaler_opt() skipped filter windows with the
same name as a filter kernel, but the jinc kernel was skipped with
--tscale because it is polar.
Also rename the field to appropriately reflect what it is supposed to be
used for. The only other use of this was to search for ordered chapter
sources, and that makes no sense for mkv files from stdin.
This also fixes autocreate-playlist loading in the current directory
when the input file is stdin.
The comment was probably only ever true for x11, and it currently isn't
true anymore. X11 WSI used to return VK_SUBOPTIMAL_KHR in
vkQueuePresentKHR and vkAcquireNextImageKHR before, but as of
https://gitlab.freedesktop.org/mesa/mesa/-/commit/2b885b233f7a6300ae88732c179888c02788493d
it only returns VK_SUBOPTIMAL_KHR in vkAcquireNextImageKHR for
performance reasons. This makes it so that we don't have to tolerate
suboptimal swapchain configurations for the sake of smoother resizing.
On top of that, not recreating swapchain when it was suboptimal, it
also prevented mpv from being directly scanned out when fullscreened on
Wayland compositors. On Wayland, the preferred modifier from the wsi
may change depending on whether the window is fullscreened or not for
direct scan out. If mpv is fullscreened but not using modifiers that
can be directly scanned out, mpv will be receive VK_SUBOPTIMAL_KHR from
WSI and should recreate swapchain to use the right modifier with the
format mpv picked. mpv will always get the format it picks, WSI can't
give us a different format. This allows for recreating the swapchain
with modifiers that will allow mpv to be directly scanned out when the
window is fullscreened spanning an output on Wayland.
I checked X11 and Wayland myself to have no regressions when resizing,
and others have checked Windows and Mac to have no regressions.
With this, direct scanout with Vulkan on Wayland should just work.
You might also need https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31122
if your compositor enables explicit syncronization via
linux-drm-syncobj-v1.
ALSA API reports -EPIPE even when the the device is lost, which we
currently always assume to be an XRUN. If we assumed XRUN 10 times and
didn't manage to recover, just consider the device lost and try to
reconnect. Allows ao_alsa to recover from alsa server being killed then
reinitialized. And even in the worst case, this should be better than
the status quo of mpv attempting to prepare a PCM device indefinitely
until the user restarts mpv.
This is admittedly not ideal, and I don't think the -EPIPE hack is
necessary anymore, but I can only test on my setup and removing the
'assume -EPIPE is an XRUN' hack might break some setups for whatever
mysterious reasons.
It is unclear whether there actually is any usecase for this option
which isn't better served by sub-ass-use-video-data and/or LayoutRes
overrides, but prior to the introduction of sub-ass-use-video-data
it was possible to pass along storage resolution while faking an
aspect ratio of 1:1.
sub-ass-video-aspect-override=1 combined with sub-ass-use-video-data=all
now makes this possible again.
The uper limit of a 10:1 aspect matches
the general video-aspect-override option.
The naming for "blur-compat" was misleading since the setting
actually affects more than just blur affects. Additionally
forwarding storage resolution but forcing an aspect ratio
of 1.0 for the video is likely to result in odd rendering
and there’s no known usecase for it.
Both options control which video properties are exposed to libass
so to fix the aforementioned issues merge these settings into one
tri-state sub-ass-use-video-data.
The default V keybind now cycles through all states of
use-video-data instead of toggling vsfilter-aspect-compat.
Resolves: https://github.com/mpv-player/mpv/issues/10680
Resizing in strictly the vertical direction has been broken forever on
wayland. It's because of how the keepaspect calculation always resized
with respect to the width. So if you moved the mouse strictly
vertically with no change left/right, the mpv window would never change
size since it just calculates with respect to the width that doesn't
change.
Fixing this is kind of weird and maybe someone should think of a better
algorithm for preserving aspect ratio (we just multiply by the gcd
basically), but whatever. You might naively try something like "resize
with respect to what direction changes the most" at first, but this
leads to very cludgy resizing since during a typical mouse dragging
motion, it will flip constantly from "resize w/ respect to the width"
and "resize w/ respect to the height". It "works" but it's really ugly
and not worth it.
The trick is to realize that we need to consider the resizing state as
one continuous motion, choose a direction initially, stick to it
throughout the entirety of the resize, and reset the relevant parameters
after we finish the resize. This ensures the direction never
unintuitively flips during a motion, but also allows for the strictly
vertical case to still work.
Might as well note it here in the commit, but mpv's resizing behavior
technically violates xdg-shell. For the resizing event, "[t]he window
geometry specified in the configure event is a maximum; the client
cannot resize beyond it." Well, we do obviously go beyond the maximum in
certain cases. For example consider resizing strictly horizontally. The
width value increases from the compositor but not the height. Since mpv
preserves aspect ratio by default, the height obviously must increase
which will go over the prescribed bounds by the compositor. This happens
before and after this commit, and I think everyone agrees is the desired
behavior. With this commit, now vertical resizing works which violates
xdg-shell in the same way. Before, it incidentally obeyed the protocol
since it did not resize at all, but let's presume users expect the
window to actually get bigger when they do a drag resize.
*: https://wayland.app/protocols/xdg-shell#xdg_toplevel:enum:state:entry:resizing
These keys should be considered "being pressed" instead of an action of
press. This way, the keypress action won't be triggered; it now triggers
only when the key binding is repeatable and after the initial ar delay.
It has been changed in one of the iterations of the patch during review,
but bstr doesn't have to be null terminated. Fix it by adding dedicated
node_map helper.
Fixes: 1a27f3c
Since d9c1e9bc5c dovi metadata is
unconditionally mapped to colorspace in mp_image.
However, Dolby Vision videos can have backwards compatibility present for
players without the ability to interpret dovi metadata, like all current
VOs other than gpu-next. In this case, the original video colorspace should
be used to make sure backwards compatibility work properly.
Save the fallback colorspace for VOs which don't interpret dovi metadata.
Fixes: d9c1e9bc5c
Since a6683ea3c9 it is possible to bind
MBTN_LEFT to something useful without conflicting with VO dragging.
However, currently wayland edge resizing is an exception and trying to
resize still triggers MBTN_LEFT. This is not a problem on win32 which
does not pass these inputs to the input system.
Fix this on wayland to do the same.
It is possible for a format to be supported by hardware but not by
av_hwframe_transfer for uploading. This breaks the best upload format
selection. We first select the hardware input format and then choose the
best software format that can be uploaded. In some cases, this may
result in a format that is not uploadable at all, leading to an error.
To solve this, we should avoid adding non-uploadable formats to the fmts
table.
For example, for format d3d11/yuv420p, av_hwframe_transfer_get_formats()
returns empty list of formats.
If you type something before pressing Ctrl+r, filter the commands
containing the typed line.
fuzzy_find() is modified to not code a separate case when the line is
empty in both handle_edit() or search_history().
There are too many issues created with problematic contents (like "#1"
in uname output) that cause unwanted expansion to markdown formats
and links to issues. The information here should be fairly simple in
format that markdown isn't needed. Use plain text rendering instead.
Change to always use drmModeAddFB2WithModifiers for all formats and fall
back on using drmModeAddFB2 if drmModeAddFB2WithModifiers fail.
With the DRM_MODE_FB_MODIFIERS-flag now only being used for formats with
modifiers all formats without modifiers should also work.
Signed-off-by: Jonas Karlman <[email protected]>
Similar to handles the modifiers must be supplied for each plane of the
format or a framebuffer cannot be created.
Use the format_modifier tied to the object used for the plane to fix use
of formats with modifiers.
Also fix the improper use of the DRM_MODE_FB_MODIFIERS-flag for formats
without modifiers.
This fixes playback of videos decoded by e.g. rpivid into a NV12 format
using SAND128 modifer on RPi using the drmprime-overlay interop.
Signed-off-by: Jonas Karlman <[email protected]>
In general, mpv treats numpad keys as separate inputs. The +-*/ keys
however are exceptions so it's not possible to distinguish them from
non-numpad keys.
This adds keycodes corresponding to these keys so that they can be
handled differently.
Now that we have identified the device types associated with each hwdec, we
can take advantage of this to ensure that get the right hwdec is chosen when
decoding frames and there are multiple choices available with different device
types.
This is also plumbed into the filter initialisation logic, although in practice
the decision on the hwdec has already been made at this point - still it's
easier than retaining the ambiguous look up logic and worrying that it might
lead to an inconsistent result.
As the first step towards handling scenarios where the are multiple hwdecs for
a given image format but backed by different AVHWDeviceTypes, let us annotate
the hwdecs with their corresponding device types.
From this, we can also see how all the existing hwdecs which match the same
image format also match the same device type.
Previously, this was in the rubberband filter but it gives out random
numbers without explaning where they come from. Move it to the --pitch
section instead and reword it a bit. Closes#14652.
This property is used by the built-in OSC and some third-party OSC scripts
to indicate the margin they occupy so that other scripts such as
console.lua can use this value to position UI elements.
Currently user-data/osc is used for interpolation between the osc and
other internal scripts. Reserve this sub-path and also user-data/mpv
to make sure external scripts can only use these values as directed.
New internal uses of user-data should use user-data/mpv instead.
If a playlist entry ends with a slash these scripts only show the
basename which is empty. Fix this by stripping trailing slashes so that
the last directory component becomes the basename.
I don't know if this broke anything but the the condition was inverted
as a result of the recent commit.
Fixes: 1a27f3caf7 ("input: use bstr for section name")
It won't be TA allocated and would fail on header check. Also
documentation doesn't mention that ownership is transfered to mpv, so it
is unexpected.
This will cause existing clients of this API leak this memory, but I
doubt anyone really used it in this broken state.
Fixes: #14633
Resolves mixed use of bstr in internal processing and char* for storage.
Also makes faster comparision when searching for section and resolves
comparision when name contains null chars.
Waiting for audio_started to be set to true takes too long which causes
us to miss it for the first frame, instead invert the condition so it's
set on the first frame.
Fixes#14615
This makes --input-ipc-client work on Windows.
To use this feature, a parent process needs to create a connected named pipe,
wrap the server handle in a CRT fd, and then spawn mpv as a child process
with the fd as the --input-ipc-client parameter.
The process can then communicate through the client handle.
The named pipe must be created duplex with overlapped IO and inheritable
handles.
Vulkan dependency implies only vulkan loader, but some distributions
split vulkan-loader and vulkan-headers, so check if the headers are
actually there.
Attempting to install `git` on the `pacboy` line fails with
`error: target not found: mingw-w64-clang-x86_64-git`
so move that to another spot.
`video_mp_image_pool.c` fails to build due to libavutil right now
because of missing vulkan headers so install those with `pacboy`.
(also improved in https://github.com/mpv-player/mpv/pull/14610 )
Simplify package lists since pacboy doesn't require `:p` anymore.
player/main.c runs all option callbacks with a flag on init, so since
a5937ac7e3 which added UPDATE_VO, if --force-window=yes is passed, the
VO is immediately initialized, as if --force-window=immediate was
passed. Fix this by not running the UPDATE_VO code when there is no
video output.
Follow up to the previous commit. Stop decreasing --ab-loop-count=N on
each iteration so it is preserved across different loops. In particular
it is preserved between different files without adding it to
--reset-on-next-file. Add a property to expose the remaning A-B loop
count instead.
The current behavior of --ab-loop-count=N is even worse than --loop-file
since it also doesn't reset when defining a new A-B loop in the same
file. Defining it has no effect after --ab-loop-count has decreased to
0, and this can't be fixed by adding it to --reset-on-next-file. This
commit also resets remaining-ab-loops every time --ab-loop-a and
--ab-loop-b are set to fix this.
Unlike most other platforming backends, wayland has its own specific
sub_options struct. 027ca4fb85 originally
introduced this and some more options were added later, but in
retrospect it's an unneccesary complication. There are already x11,
and windows-specific options within vo_opts. In fact, there actually is
a wayland one in there already as well (wayland-content-type) so it's
split btween two places. The wayland code already has to handle vo_opts
and it is already handles callbacks if needed. There is no advantage to
having a separate wayland-specific sub_options struct which is stuck
with whatever you set at init time.
So solve everything by deleting the old sub_options struct, moving it to
vo_opts and make some minor option naming changes for clarity (i.e.
adding a 'wl_' in front of the name). This simplifies the wayland common
code and also makes it have more functionality since you get runtime
updates for free.
Set UPDATE_VO to GPU API options that are only set on init.
To change multiple options without multiple reinits, use
set vo null; set opengl-foo 1; set opengl-bar 1; set vo gpu
This will allow reiniting the VO when more options are changed without
hardcoding them in options.c
Also reinit the VO when changing --gpu-debug and --gpu-sw.
ARGB is in fact _not_ like web color. It's easy to skim over the
actual hexadecimal provided in the next sentence and just assume mpv
understands RGBA after reading the words "web colors"
--sub-margin-y is documented to scale with font size, which is scaled
"by" or "with" window depending on the options. However, when using
ass_set_font_scale to change font size, the y margin isn't scaled, so it is
still scaled to video size. This causes the y margin size becoming smaller
when the video becomes smaller, even when the font size isn't changing.
Fix this by also scale the MarginV with the font scale. Also use lrint
instead of round.
The current documentation of sub-scale-by-window and sub-scale-with-window
doesn't sufficiently convey what these options do exactly. Specifically,
the described effects of disabling one option is only true when the other
option is not disabled. The "clarification" of sub-scale-with-window option
only adds more confusion, when the effect of that option is already told
in more detail before (it scaled with window instead of video).
Clarify this by listing the effects of all combinations of these options.
By default, libass scales subtitle with video size.
When --sub-scale-with-window is enabled, mpv attempts to undo this scale
and use window size instead. However, the current bahavior is incorrect
when use_margins is enabled, because in this case libass uses the size
of video as if it's "fit" to the window, instead of the displayed size.
As a result, subtitle scale is broken when video-zoom is used in this case:
when zooming out video, the subtitle is scaled up.
Fix this by using the correct factor when use_margins is enabled.
These have been deprecated for 9 years so it's fine to remove them.
Using the replacement properties like video-bitrate in stats.lua will
convert big enough bitrates to Mbps.
Show the same flags in loadfile.c, select.lua and stats.lua. The only
differences are that only stats.lua prints both image and albumart
because it's supposed to show detailed track information, and select.lua
prints the image flag because pressing g-v doesn't show Video or Image
like in loadfile.c and stats.lua.
This lets touch events activate a separate timeout for osc hiding so that
the osc only hides when both mouse and touch timeout are expired.
This is the general expectation with touchscreen UI, and also fixes
platforms which reset the mouse position when all fingers leave the
touchscreen (e.g. sway).
Timeouts can happen with various conditions, big, slow to decode files
is one of them. Most of the time those timeouts are not really important
to "fix". While they may show some issues like we currently have with
audio EOF #14427 for ao-null-untimed. Most of the reports are completely
not important and we should focus on other topics.
Ignore the timeouts during file playback, note that this will still
report any timeouts that happen in other conditions.
5 seconds of playback should cover most of interesting mpv code, even
for strange samples.
This will likely be reverted at some point in the future, but let first
stabilize the OSS-Fuzz, without dozens of bogus timeouts.
option-info/<name>/default-value would be initialized with zeroed
object, which is not valid for string typed options, as the would be set
to NULL.
Found by OSS-Fuzz.
if no NSApplication has been initialized, applications using Appkit
functionality are not supposed to work properly or just deadlock
indefinitely. properly error out on macvk context creation in that case.
While the code before 571f9b0f23 had a
typo and it was intended to be 100 MB, there are files that exceed this
limit, like 147 MiB. Increase the limit to 512 MiB which should be more
than enough for valid files.
From quick look ffmpeg limits to 1<<8 bytes, so we should be good with
our new limit.
In theory this limit could be removed, but it is better to play the
file, possibly with skipped some corrupted block of data, instead OOM.
Fixes: 571f9b0f23
tag_property() expect metadata to not be NULL on M_PROPERTY_KEY_ACTION.
M_PROPERTY_GET_TYPE can be skipped only if key is not queried.
Fixes: a05b847879
Described in more detail in the upstream MR*. mpv naively rounds which
makes us susceptible to the mentioned error. Fix this by keeping
wl->scaling and wl->pending_scaling in the base 120 units. Use the
simple rounding algorithm when needed for calculating widths/heights.
Create a wl->scaling_factor as convenient shorthand for scale / 120
which is what wl->scaling used to previously be.
*: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/309
This allows playing arguments like
mf://https://foo.jpg,https://bar.jpg
and also URLs within @listfiles (files with 1 image per line).
URLs still don't work with globs and printf-formats.
On X11, aspect ratio constraint is applied on the window manager side,
so whenever keepaspect and keepaspect-window change, mpv should update
the size hint immediately, otherwise the new constraint isn't applied.
This change removes convoluted core thread extraction through dispatch
added in 500ce69a06.
Currently we fully control this thread, create it and join, there is no
reason not to keep the handle of it in the player context.
As a bonus to code simplification this also fixes thread handle leak on
Windows.
Fixes: #14472
This test:
- Checks if libmpv can be loaded dynamically.
- Checks for leaks after mpv context destroy.
- Checks if libmpv can be reloads after dlclose()
Window classes are global per process, but they are associated with the
module that registered them. Documentation is clear that it is the DLL's
responsibility to unregister its own classes:
No window classes registered by a DLL are unregistered when the DLL is
unloaded. A DLL must explicitly unregister its classes when it is
unloaded.
See: https://learn.microsoft.com/windows/win32/api/winuser/nf-winuser-registerclassw
Using a window class after the DLL is unloaded would result in access
violation errors. This is not that important for libmpv, where it is
unlikely someone would use the "mpv" window class externally. The real
issue comes from the fact that reloading libmpv would fail to register
the class (as it still exists) and consequently fail to create a window.
This commit fixes the operability of libmpv after reloading it.
Fixes: #11638
Client side cursors have always had some issues with fractional scaling.
However since we changed to using viewporter for cursor scaling, most
(or all?) of the problems can be fixed. Unfortunately, a scaling factor
was being truncated to int instead of kept as a double. This matched the
old behavior with buffer_scale, but it's better to use double so the
viewport is actually set to the correct size. Of course, none of this is
relevant if the compositor is using cursor shape.
Fixes f0a6578259Fixes#14001
When you type something in select mode and then delete it, table.sort
changes how selectable items are sorted. Restore the order specified by
the mp.input caller in this case.
- Remove the opts comments because they are already in console.rst and
will become outdated if not updated in both places
- Reuse last_pos in truncate_utf8() instead of recalculating the
previous character's position
- Clear the OSD earlier when the console is not active
The previous commit to avoid refresh seeking video streams has an edge
case when enabling tracks when loading files. Since the streams are
initially unselected and then multiple streams are enabled, the detection
only works reliably when video tracks are enabled first.
This makes sure that loading file enables tracks in a predictable order.
940854c86f added this logic, but when the
demuxer contains a selected video stream, it causes a seek for the video
stream. This is unnecessary since the problems that commit fixed are only
relevant for external audio streams. For a demuxer with a video stream
selected, the synchronization is done by the demuxer implementation.
Add a check to prevent this.
This follows up 96e1f1dfa5 which converted --gpu-context, and has the
same advantages as listed there.
Unlike with --gpu-context auto can be used anywhere in the list, e.g.
--gpu-api=d3d11,auto works.
I wanted to use the list of GPU contexts as the description in
get_type_desc(), but there is no talloc context to allocate it to, so I
set a print_help_list to print them. The APIs go before the contexts so
that etc/_mpv.zsh doesn't try to complete the contexts.
This function is used to reject invalid context names early, and without
it the context fails to create and only audio is played, but it doesn't
need to check for known entries again.
We wrap the default Lua allocator to allow used memory tracking. This
works well, except that we never destroy the default allocator or notify
it that we are closing. Since we override it for the current Lua state,
it is reasonable that the Lua engine does not expect it to be used. We
get and pass through a free call, but in the case of LuaJIT, the
internal allocator has additional state and is freed differently. So, in
fact, it is a LuaJIT leak because once we replace the allocator with our
custom one, they should clean its internal state. I guess the assumption
is to override allocator only before any allocation happen. To work
around this issue, restore the default allocator, the one that we use,
before closing the state. This way, everything is cleared as expected.
Note that the current solution of wrapping the default allocator works
only because none of the supported Lua engines actually invalidate the
allocator on the lua_setallocf() call. However, they could, so keep in
mind that we are currently depending on an implementation detail.
Thanks to @Dudemanguy for help with finding the changes that introduced
the leak.
Fixes: a67bda2840Fixes: #14451
Mainly for debugging. It might be handy to disable presentation feedback
on wayland to make sure something isn't going wrong with the
calculations somewhere.
Before a7158ceec0, string comparision was
done with strcmp, which does unsigned comparison. The natural sort
implementation instead compares on char values.
This causes implementation-defined behavior in comparison, depending on
the signedness of char type.
Fix this by using unsigned comparison instead.
Adding base path make sense only if it is a real directory or url
location. In case of protocols like memory adding base path to playlist
entry in facts adds the whole playlist to that entry.
For example `mpv $'memory://#EXTM3U\na/b'` produces infinite loop,
expanding playlist, adding more to it.
open_file adds the dirname to support relative playlist enties, however,
the dirname is invalid when the name doesn't represent a path, such as
with memory://..., so avoid taking the dirname with such protocols.
Found by OSS-Fuzz.
`:` were not escaped correctly. Also while at it clear other external
file lists, as we don't want to load any. Subtitle fuzzer will be added
in the future.
It is surprisingly hard to clear the list with C API. That needs whole
mpv_node_list with 0 elements, to make it clear it.
Similar to the previous commit but the other way around. If you start
mpv as idle, load up a playlist without immediately hitting play and
then try to go to the next item, nothing happens. Naturally, you would
expect this to go to the first item. Fix this detecting if the playlist
has not started yet, the direction, and going to the first item in the
list.
Previously, playlist-prev didn't work if you played a playlist to
completion using --idle and tried to go back. Naturally, one would
expect this to bring up the last item in the playlist, but nothing
happens. This is just because playlist_get_next is stupid and doesn't
take this into account since pl->current is NULL and thus returns NULL.
Fix this by considering the direction, checking if the playlist was
played to completion and grabbing the last entry in the index.
Most of these are pretty obscure things that were replaced a long time
ago. The special messages they were printing are also not really useful
at all so just remove them.
These were all deprecated in mpv 0.37.0 or earlier and are not
considered common enough options to warrant keeping the deprecated
mapping longer. Since demux_cue had only a single option in it, the
entire option substract is removed. This can be readded later if someone
wants to introduce a specific option to it again.
This prevents line wraps in select mode with terminal output which hide
the top items (OSD output no longer uses truncate_utf8 since the
previous commit). This is not ideal as even accented letters are assumed
to be 2 cells wide. The alternative is using \e[?7l and \e[?7h to
disable and enable text wrapping, but it won't work in Windows console
with VT processing disabled.
In select mode and when printing the OSD, use \q2 to let libass clip
lines longer than the OSD. This works around having to leave a large
horizontal space unused due to libass subtracting the left margin from
the max text width even though the ASS event is anchored to the bottom
left. It also fixes truncating wide Unicode characters.
Even if ass:pos() hardcodes the position at 6px from the left, we still
need to subtract the left --osd-margin-x from the available text width.
See how libass/ass_render.c:ass_render_event() subtracts it from
max_text_width without checking if the event is positioned.
The calculation is still not perfect as the width could be made a bit
larger before the text wraps.
Stop making unselected tracks and editions grey because they can be hard
to read over a dark background (\033[2m would be hard to differentiate
from regular text with a light theme instead), and because there is no
way to not print the escape sequences in --log-file.
Just use the same circles as the OSD and OSC. We need to print the empty
circles for alignment on mlterm with East Asian fonts (we could also
make them invisible with \033[8m but it would still get added to log
files).
Add back the space before tracks and editions when printed after
"Playing..." or "Track switched" and similar, so they look like a
sub-section of it, consistently with the metadata which starts with
space which makes it look like a sub-section of the "File tags" line.
Leave 2 spaces between track columns.
Make the lang options only as long as the longest language.
Place hls-bitrate within the same parentheses as the other data.
Replace the incomprehensible (*) (f) and [P] with textual descriptions
within []. Also place external there.
Stop converting Hz to kHz for consistency with other log messages, e.g.
AO: [pipewire] 48000Hz stereo 2ch floatp
Remove the space in "2 ch" so it doesn't look like 2 separate values (We
considered using mp_chmap_to_str(&s->codec->channels) but it prints
values like "unknown2").
Previously, using m_option_type_alias required that the alias have the
full name of the option value. This is limited if you are reusing the
same opts struct in different sub options. Fix this by add an additional
field to m_option to signal whether or not prefixes should be taken into
account for the alias option. Instead of blindly using whatever is
stored in opt->priv as the name, we can construct the desired option
name for either case (using the prefix or not).
It makes sense to allow the first part of the list. There are
warnings about excessive elements already. This also allows overriding
elements with the same label.
It fixes stack-overflow with keys that contains hundreds of splits. 100
is more than enough for any valid use of user-data, normally key
shouldn't contain more than a few splits.
Found by OSS-Fuzz.
Fuzzing expect deterministic behavior. While we don't use this random
generator for anything significant, still good to set the seed, in case
of future usage.
No need to reset mp_pass_perf which is only read when desc.len > 0.
This avoids zeroing >16384 uint64_t's every time it's called.
Profiling shows that this reduces CPU usage for frame rendering by ~4%.
Since d41f0a54b0, enabling a stream will
no longer perform a refresh seek, to fix issues with switching video
tracks. Additionally, 62e9a0c5f6 also
prevents refresh seek on track switching when it happens right after a
seek.
Unfortunately, when external audio files are loaded, preventing refresh
seeks can cause A-V sync issues. Since external tracks have separate demuxer
instances from the internal tracks, the demuxer instances from both
internal and external tracks are explicitly sought to the same pts when
seeking is performed. When enabling an external audio track for the first
time, the existing logic prevents refresh seek because no packets have ever
been read, so the track ends up not being sought. This means that switching
the track in the middle of playback results in a huge A-V desync.
To make it worse, unlike one demuxer instance with multiple tracks,
tracks from multiple demuxer instances are not synced in any meaningful
way beyond the separate explicit seeking. The only thing which keeps these
tracks synced is the generic A-V sync logic, which is unfit for such large
desync above. This means the audio is at the start position after the track
is switched, behind the video, so the audio is not considered ready, and
audio is continuously filtered sequentially until it is synced to the video.
While this is happening, the audio filtering exhausts all CPU resources.
There is also a case with cache enabled: if a seek causes some new data to
be cached, the demuxer is sought to the end of joined cache range.
If track is switched after this, the existing logic prevents a refresh seek,
so the demuxer is at a wrong position after the track is switched.
Fix this by allowing refresh seek for non-video streams, even when no packets
have been read yet or immediately after a seek.
Preselect and seek to the correct subtitle line when there is a
sub-delay.
Also slightly increase the offset without a video track else it
occasionally doesn't seek to the selected line with non-0 sub-delay and
no video. This now uses the same offset as sub/sd.h.
There is no need to compare sub-start now that we don't check for exact
matches with ffmpeg's timestamps. time-pos can always be used.
Comparing time-pos removes the need for the workaround of sub-start of
embedded subtitles being earlier than ffmpeg's timestamps, as time-pos
is always slightly after sub-start.
Removing this workaround also fixes a bug present since 4059d1832b,
which started comparing numerical values of timestamps instead of
strings to determine the preselected subtitle line, where the line after
the current one is preselected when sub-start is greater than ffmpeg's
timestamps because they have been rounded, e.g. sub-start 10.001 is >
than ffmpeg's 10.00.
This will also allow considering --sub-delay in the comparisons, as
comparing sub-start - sub-delay would preselect the wrong lines.
Since 995c47da9a, setting --mute=auto has
been equivalent to --mute=no. It was formally documented later in
79e20ff485. This is an old legacy relic
and the auto choice popping up during auto completion could be confusing
to users who aren't aware of the history. Remove it for good and convert
the option to a proper boolean.
Since 7fc4bac29f182cab1823221ed580423594041fc1, playback-time and
time-pos will now always have exactly the same values. Both properties
are commonly used, so just make playback-time an alias for
time-pos and document it.
withLock is available for macOS versions starting from 10.10 but can
only be used on xcode 14+. xcode 14 introduced swift 5.7, so we guard it
behind a swift version check.
Hashbangs are meant for scripts that are executed, but a bash completion
script is meant to be sourced and therefor shouldn't have a hashbang.
Remarked by Debian's ``lintian`` tool with the
``bash-completion-with-hashbang`` tag.
Limit list entries to 100. obj_settings_list is not designed to hold
more items, and it quickly starts taking ages to add all items. 100 is
more than enough.
Fixes 30s timeout on OSS-Fuzz and generally fixes possible DoS on mpv.
If the output display reports high bitdepth, 12-bit and 10-bit swapchain
is used the value returned from d3d11_color_depth needs to take it into
account.
The options parameter here can be NULL. It's NULL checked a few lines down,
but not for the propagate_opts loop. This results in null derefence with
--demuxer-lavf-format=image2.
Fixes: b6413f82b2
VapourSynth introduced their version 4 API in R55, 3 years ago. mpv is
still using the deprecated version 3. I think it is good to migrate
before VapourSynth completely removes it.
The most impacted area is the video format. Previously we have a fixed
table of supported formats, each represented by an integer. In v4, the
integer is replaced by pointer to the full struct of the format.
Second, the way to create video filter is changed. Previously caller
needs to supply a "initialization" callback to `createFilter()`, which
sets up video info etc. In v4, video info is prepared first, passed to
the `createVideoFilter2()` and we get back the node.
Also, previously mpv was using the `fmSerial` filter mode, which means
VapourSynth 1) can only request one frame from mpv at a time, and 2) the
order of frames requested must be sequential. I propose to change it to
the parallel request mode, which requests multiple frames at a time in
semi random order. The reasons are, for 1), the get frame function,
`infiltGetFrame()`, unlocks the mutex during output image generation,
thus can benefit from parallel requests. For 2) thanks to the frame
buffer, unordered frame requests are acceptable. Just make sure the
buffer is large enough.
Third, the way VapourSynth scripting environment works change. In v4,
the scripting API is operated through struct pointer, much like the
exist `vsapi` pointer. The "finalize" function is also no longer needed.
There are jpg files out there that have extra embedded metadata
(pictures from smartphones commonly have an embedded gain map). ffmpeg
doesn't currently support this, so mpv currently sees the extra metadata
as essentially another frame. This results in weird video-like behavior.
Until ffmpeg support this more properly, we can work around this by
simply discarding extra packets and not sending the new frame to the
internal playloop. If demux_lavf detects that the stream is a
single-frame jpg, then we only accepts the packet at pos 0. Anything
else is discarded. Ref #13192.
Passing jpg filenames to ffmpeg is actually quite bad. This causes all
jpg images (at least in my testing) to be probed as image2 which is
blacklisted in demux_lavf since it's completely broken (see commit
74e62ed2d1 for some details). What happens
in practice is that the lavf demxuer fails and the it opens in the mf
demuxer instead. This is OK for simple viewing, but because that demuxer
is limited, many specific file properities and other things are
completely unavailable which breaks any script that may depend on them
(e.g. width, height, etc.) For the small subset of files that this
commit appeared to "fix" (in reality, it just fell back to the mf
demuxer) is not worth breaking property usage in the vast majority of
normal proper files. Ideally ffmpeg should fix this but some other
workaround on our end can be used instead.
This reverts commit d0aeca5918.
https://github.com/rossy/mpv-repl enabled and disabled its keybindings
with input sections (define-section, mp.enable_key_bindings and
mp.disable_key_bindings), but when wm4 merged it in mpv, he changed it
to use mp.add_forced_key_binding and mp.remove_key_binding because he
deprecated input sections, but he forgot to remove the
mp.enable_key_bindings line. Remove it now.
This adds file tags to display along with the title, including
album/artist etc. for music, and series etc. for some videos.
The list of tags to display is identical to the tags printed to
the terminal and is controlled by the --display-tags option.
To filter out overlength tags (such as long comments and lyrics) and
files with too many tags, add file_tag_max_length and file_tag_max_count
options so that tags longer than this length are not displayed, and only
the first few tags are displayed.
Also makes tags show on page 5 only.
Normally, key bindings are resolved in the input section stack order.
However, mouse key bindings have a special "active mouse section" feature
(which is a section with MOUSE_MOVE bound and mouse button is down in the
section) which lets the section to be selected instead, with a fallback
to the "default" section. The intention of the feature is for mouse
dragging which should "stick" to the section where the mouse is down.
This causes a problem with scripts which bind mouse double clicks:
since double clicks are triggered on mouse down, it's resolved with the
"active mouse section" feature instead of the section stack order.
If the section which has the double click bound doesn't also have
MOUSE_MOVE bound, the "default" section will be used instead.
If it's already bound there, it will be triggered.
Fix this by not resolving double clicks on the active mouse section, which
is not the intention of the feature.
With the previous commit, they're in effect sorted by the types of the
interface changes.
As a lazy measure to sort changes by the breakages they cause, sort the
content reverse alphabetically, which works OK by accident.
22a8b99 introduced print_perfdata_passes as a stopgap until a dedicated
performance stats page would be implemented. Since it has been
implemented for many years, remove this option, which isn't even
documented, and is likely to make the stats overflow beyond the screen.
To avoid a large append parameter refactoring is to make the append
function add the table index only if the newline character is not empty.
Otherwise, new strings are appended to the existing string.
OSC rendering used to be smooth (up to OSD rendering fps) before
48f906249e, but after that commit the
frame duration is hardcoded to 30 ms. This is too high and results in
choppy OSC rendering, which is very noticeable with the progress bar
while moving mouse over it or playing a short 60 fps video.
This makes the duration an option so that it can be decreased to make
OSC rendering smoother.
Currently the vapoursynth video filter does not accept any argument for
passing arbitrary user data. This limits what the VS script can do.
Ideally, the vapoursynth filter has an user-data parameter that contain
string value. mpv passes that value to the VS script just like
container_fps and others. Once the VS script gets the data, it can do
all sorts of data extraction and transformation.
Another benefit is that instead of mpv always have to catch up to user
needs for this filter, with this users can just pass whatever needed
themselves, thus becomes more future-proof.
Fixes#14214
Allow configuring whether to print the media-title, the filename or both
(as `<title> (<filename>)`) in show-text ${playlist}, the OSC playlist
and in the playlist selector.
Showing only titles hides information when files are badly tagged, or
when it hides the track numbers of album songs. But showing filenames is
not as useful as titles e.g. when playing URLs with media titles. This
option lets the user choose which one to show, or show both if switching
is inconvenient.
The OSC's playlist_media_title script-opt is removed because this option
is better since it works everywhere after configuring it once.
Closes#11653.
Also show the full URLs of playlist entries instead of their basenames
in osc.lua and select.lua, consistently with mp_property_playlist().
For simplicity, this just checks if entries contain :// instead of
replicating all of mp_is_url().
Co-authored-by: Kacper Michajłow <[email protected]>
Currently the documentation for building on Windows, specifically the
"Native Compilation with Clang (Windows SDK Build)" route, could use a
few minor improvement to make the development onboarding experience more
smoothly.
Fixes#14214
ffmpeg outputs timestamps like '100:00.00' in LRCs instead of adding
hours, and timestamps like '100:00' are < '10:00', so since these
strings are being compared, if there is no current subtitle line, there
are subtitle lines at >= 100 minutes, and time-pos is between 10 minutes
and 100 minutes, one of the last subtitle lines gets preselected.
Fix this by converting the timestamps to numbers before comparing them.
Also simplify the logic by merging the 2 loops to determine the default
line, and reformat the timestamps by adding hours to not print minutes >
60 in the selector, and by removing the hundredths of seconds. This
requires storing the accurate timestamps in a table to seek to them on
submit.
Print vlang if present.
Make unselected tracks and editions grey instead of adding (+) before
selected tracks. Mark them with the same circles as show-text
${track-list} and script-message osc-tracklist when not outputting to a
TTY.
Don't print a different symbol with --sub-forced-events-only because
nobody uses this option, and subtitles are very unlikely to mix forced
and non-forced events.
Align 2-digit track IDs.
Align languages of up to 7 characters (the length of zh-Hans).
Leave spaces when a track has no language but at least another track
does to align the following track data with the other tracks.
Add a space between values and their units.
Convert Hz to kHz.
Pretty print FPS and kHz with mp_format_double().
Don't print images' FPS because it's just a bogus value taken from
--mf-fps.
Co-authored-by: Kacper Michajłow <[email protected]>
This effectively bumps minimal MinGW-w64 requirement to v11.0.1. As it
is available in the latest Ubuntu LTS.
While at it clean installed packages list.
The 32-bit builds were disabled, because some packages started
disappearing. MSYS2 is slowly phasing out 32-bit support, but since we
still support it we have to test it somehow. Recent brakage with calling
convention mismatch would be spotted a lot quicker. So enable it, but
with some, not available, packages disabled.
This reverts a56d5c7fa1
Ubuntu 24.04 linux-azure kernel, used on GHA, is compiled with
CONFIG_COMPAT_32BIT_TIME=n. This prevents running any 32-bit binaries
through wine, so disable tests when doing i686 build. 32-bit builds are
still tested on Windows.
See: https://github.com/actions/runner-images/issues/9977
Wayland protocol only guarantees the delivery of modifier information after
the enter event. To handle it properly for keys pressed in the enter
event, save those keys for later processing in the modifier event.
There is a subtle behavior difference for built-in/input.conf key bindings
and key bindings registered by scripts: when a key binding is canceled
(e.g. a mouse button is bound to a command, is pressed down, and then
another key is pressed which is bound to another command), the command is
not invoked if the binding is built-in/input.conf, but is invoked if it's
registered by scripts, because it's handled with a different mechanism,
which gives no way for scripts to detect this.
Fix this by using the newly available canceled flag to detect this.
If a key binding is canceled, the callback is now not invoked unless
the key binding is registered with the complex option. In this situation,
the callback is invoked with the canceled state available so that scripts
can detect and handle this situation.
In certain situations (including but not limited to begin window dragging),
it is desired to cancel the current command completely. However, commands
which have on_updown flag set require the command to be invoked in this
situation. There is currently no way to know if the command is triggered
normally or triggered because it is dropped.
This adds a canceled state to mp_cmd which indicates this.
Fixes crash when FLS data is attempted to be cleared.
This affects only 32-bit build where the calling convention were not
matching the expected one. It has to be __stdcall in this case.
Fixes: 3372e17d
General update. Removed MXE as it is not supported, doesn't support
libplacebo and in general it doesn't do anything useful which native
Meson cannot do already.
Using strchr should be faster as it is optimized for the job. Also
ensure that tags are not escaped and are within {} correctly. This also
is important for performance as it allows to scan only needed areas of
the string.
Co-authored-by: Avi Halachmi (:avih) <[email protected]>
Co-authored-by: rcombs <[email protected]>
Some were duplicated between GCC and Clange. Others were missing in
Clang case. Instead test all the flags and don't make assumptions that
will get invalid over time. Testing flags is almost free.
This allows loading other types of media from the current directory,
with same_type=no, regardless of whether the current type is enabled for
autoload.
Fixes: #14287
4e5d996c3a added this as part of a series
of patches written to avoid wasteful sub redraws when playing a still
image with subs. The is_animated special case was specifically for ASS
subtitles that have animations/effects and would need repeated redraws
in the still image case. This check was done unconditionally for all ASS
subtitles, but for very big ASS subtitles, this text parsing can get a
bit expensive.
Because this function call is only ever needed for the weird edge case
of ASS subtitles over a still image, some additional logic can be added
to avoid calling is_animated in the vast majority of cases. The animated
field in demux_packet can be changed to a tristate instead where -1
indicates "unknown" (the default state). In update_subtitle, we can look
at the current state of the video tracks and decide whether or not it is
neccesary to perform is_animated and pass that knowledge to sd_ass
before any subtitle packets are decoded and thus save us from doing this
potentially expensive call.
This adds the --input-builtin-dragging option, which allows the built-in
dragging behavior to be disabled. This allows scripts to implement custom
dragging behavior with left button down events and begin-vo-dragging
command, which could only be done for other mouse buttons before.
Currently, the built-in VO dragging conflicts with the MBTN_LEFT binding,
so the binding is activated even though the VO dragging begins. Fix this
by releasing the currently down command so that MBTN_LEFT can be bound to
a useful action (such as play/pause).
The stored mouse position mouse_vo_x/y are scaled (currently only for
vo_xv), but the position equality check compares between raw position
and scaled position.
Fix this by storing and checking the raw position instead. The raw
position is useful for the next commit.
Helps with testing during cross-compilation and avoids external
dependency.
Output maybe is not that nice, but this output in our tests is not
useful anyway. We know if it changes it is beacuse one of the dependency
version changed.
Also, if the position is valid, set it to 1 / INF. Windows interprets 0
as non-progress.
Progress is quantized into uint8 range, it is good enough for this
use-case. This avoids unnecessary vo_control and
ITaskbarList3::SetProgressValue calls and should be visually
indistinguishable in practice.
Fixes#14282
The values provided since last disjoint event may include significant
error in case there are periods of slower presentation. We should look
at more localized/current values of presentation.
For more accurate approximation of vsync rate I plan to add better
algorithm to calculate it.
Revert this commit alone as it is not neccessary and gives as separation
from other changes for better regression testing.
This reverts commit f27767f59e.
The problem with using get_current_time is that it can return negative
values. Interally in mpv, we need this but for some spots negative
values are not great. Since the previous commit enforced nonnegative
returns for get_playback_time, we can use that instead. The two areas
changed here are watch later configfile writing (clearly should always
be a positive number) and the time-pos property (negative numbers are
nonsense for users). This fully fixes#10346.
Except for MP_NOPTS_VALUE. We keep that as is. When this was originally
added in a73415584c, it appears like
having the time always start at 0 was the intent. In cases where
get_current_time returns a negative that isn't MP_NOPTS_VALUE, force
this to 0.
Effectively reverts 7051e94e4b. There's
been some confusion with how audio pts gets used internally in mpv which
leads to weird results. The crux of the problem is essentially that
playing_audio_pts can return negative numbers and in many places this is
not expected. This is the first step in trying to hopefully iron out all
the weird corner cases.
The logic in question was added in 201bef7ee1
for the VDPAU vsync frame timing algorithm, but after the code was moved
around for several times, it is now used for all VOs with non-display-sync
mode (where the video is synced to audio or system time). It nonetheless
likely never did whatever it was intended for.
This "correction" reduced the VO frame duration by the amount that the
frame is fallen behind the ideal time. Since a frame is presented between
pts (the ideal time for which the frame is scheduled) and pts + duration
(the end time for which frame drop is determined), and pts is already
computed from the current time and the deviation from the ideal time, this
"correction" causes the end time to have the deviation added twice, which
is nonsense: if the deviation is -0.5x the frame duration, the frame is
dropped, even though it should be displayed from now to 0.5x the frame
duration from now.
It was not noticed at that time probably because the VDPAU secret rabbit
code undid some of its damage, and the subsequent development focus on
display-sync modes resulted in negligence and simplification of audio mode
(e.g. b8bcf0f466), but the generic VO frame
drop algorithm has been observed to cause inconsistent frame drops with
this "correction": playing a 59.94 Hz video at 2x speed on a 60 Hz display
results in spending over half of the time dropping adjacent frames instead
of every other frames, visually causing stuttering, while it should only
happen briefly when the pts is very close to vsync time.
Fix this by deleting this logic, making the VO frame always having the
duration of the video frame.
Fixes: 201bef7ee1
If mpv is launched with --fs, the x11 code tries to reset the size and
position of the window when the fullscreen exits. This has bad behavior
with multiple monitors because the saved nofsrc is not reliable in many
situations. Particularly if the window manager moves the fullscreen
window somewhere else while mpv is fullscreen. The result will be that
exiting fullscreen always goes back to screen 0.
Fix this by translating the rc coordinates of the nofsrc rc to the new
monitor when we're leaving fullscreen from an initial --fs case. By
giving get_current_display a specific rc, we can return what xrandr
display the coordinates are associated with and decide if the nofsrc
should be translated to its new location. After that bit of math, the
usual move/resize logic takes care of the rest but this time it actually
works off of the correct position. Fixes#14226.
If complete is case-sensitive and no completions exist the script crashes
with the following:
Lua error: @console.lua:1417: attempt to concatenate local 'prefix'
(a nil value)
Fix the bug that seeking to the end of cover art while paused goes back
to the beginning of the file because of this condition meant for videos.
This doesn't check mpctx->vo_chain->is_sparse because prevent_eof should
be true with actual sparse videos.
Includes cleanup of CFBundleDocumentTypes, UTImportedTypeDeclarations,
LSItemContentTypes. Reordered general structure of the Property List as
in nodes/collections/arrays. Declared MIME types.
c522d0dfbd added parser to avoid opening
decoder and left decoder only for DTS. Since then more audio codec needs
decoder, so open decoder always when it might be needed. Exclude only
AC3, other codec have profile to be extracted.
Fixes: c522d0dfbd
The naming of these conflict with existing mpv protocols, so skip if we
get them. Users can still use them via lavf://bluray: or lavf://dvd: if
they wish.
If we can run the built mpv binary, then it is possible to use a custom
target that reads the protocols we have available in mpv and write the
mpv.desktop file based on the output. For cases where this is not
possible (e.g. cross compiling), then just install the unmodified
mpv.desktop file like before. Fixes#8731 and fixes#14124.
Previously, all stream protocols were a static list in mpv. This is okay
for own builtin stuff, but for protocols that depend on ffmpeg it's not
so great. Support for certain protocols may or may not be enabled in a
user's ffmpeg and the protocol list that mpv generates should ideally
match this. Fix this by implementing a get_protocols method for
stream_lavf that will have different results depending on the ffmpeg mpv
is built against. We keep the safe and unsafe protocols separation. The
former is essentially a whitelist. Any protocol that is found in ffmpeg
but is not in the safe whitelist is considered unsafe. In the stream
list, ffmpeg is moved to the bottom so any possible protocols that are
added in the future don't automatically take precedence over any builtin
mpv ones.
The idle inhibit protocol specifies that the compositor may ignore the
idle inhibitor if the surface is occluded. In the case of
vo_dmabuf_wayland, wl->surface corresponds to typical black bars when
the video aspect ratio is different than the display's. So in many
cases, wl->surface is actually occluded by wl->video_surface which sits
above it. Change this so that the idle inhibitor is created on
wl->callback_surface instead which is either wl->surface for the gpu VOs
or wl->video_surface for vo_dmabuf_wayland. Fixes#14206.
They were previously left over, and now that it looks like runners are
stuck, the big question is: is /tmp persistent?
This commit will be reverted after the next rebuild.
This recommends querying the value of this option when drawing UI elements.
This allows a greater level of consistency by using a single flag which
already controls the scaling behavior of the OSD to control the behavior
of all scripts.
Also fix a capitalization nearby.
Statically linking, especially with LTO can use a lot of memory. Limit
to 16 jobs by default, which is more than enough. Only fuzzers are
affected as we don't produce that much binaries otherwise.
This commit adds a state `hw_paused` for pull-based AO.
`driver->set_paused(false)` is only called if `hw_paused` is true.
`hw_paused` is cleared after `ao_reset`, so `set_paused` will
not be called after a reset; instead, `driver->start()` will
be called, which properly starts the AO.
The default values for --ao, --vo, --gpu-api, --gpu-context change from
time to time, but some libmpv clients rely on the existing autoprobe order
and breaks as a result when the value changes. This specifies that the
default autoprobe order should not be relied upon.
Currently there is no policy on what should be done when an immediate,
severe breakage happens for "important/often used parts", which can cause
serious concerns especially if such changes remain obscured.
This adds a provision for this kind of incompatible changes under
"extraordinary circumstances", which allows for the breaking change to happen
if there is a critical reason to do so. Such changes must be extensively
documented, and should be avoided as much as possible.
Currently incompatible changes are not clearly outlined in the related
documentations, such as interface-changes.rst. The impacts and suggested
actions to address the compatibility concerns also rarely exist.
This adds a requirement to include these information for incompatible
changes, so that such changes are clearly conveyed to the users, with
suggested actions to minimize the impacts of such changes.
handle_osd_redraw is called while we're in the middle of the cleanup portion
of play_current_file (via kill_demuxers_reentrant and mp_idle). This happens
after we've torn down the subtitle track, so we end up requesting a redraw
from the vo, which results in a 1-frame flash of the video without subs
before we either quit or switch to the next file (or the force-window state).
This detects that condition and skips the redraw, without interfering with
drawing the osd during idle (eg for pseudo-gui mode).
It is not actively maintained, third-party, javascript wrapper for GitHub
API. The v7 version has issues and most importantly, we don't need a
JavaScript interface to create a comment. Use the first-party CLI tool
and jq.
Sort artifacts by name while at it.
The value of list options is a table not just for vf and af but for all
object settings lists. Extract just the names from the tables returned
when retrieving these options.
This fixes 2 different bugs:
- mp.add_key_binding('c', ...) taking priority over the builtin g-c
binding.
This follows up 994a08f5a7 which fixed this within the same input
section. This fixes it across different input sections.
- mp.add_key_binding('g-c', ...) not taking priority over a c binding
defined in input.conf.
This happened because is_builtin of bindings added with
mp.add_key_binding is true though they're not actually builtin.
If using --script-opts=stats-vidscale=no, until osd-height changes from
0 to the correct value, stats.lua's text sizes are multiplied by a scale
of 720, which with the default font size results in a font size of 5760.
Depending on the order of operations, if the stats are drawn at this
size before osd-height is updated, mpv freezes. I get this with
--input-commands=script-message-to stats display-stats-toggle in
conditional profiles, e.g.:
mpv --script-opts=stats-vidscale=no --include=<(echo $'[test]\nprofile-cond=true\ninput-commands=script-message-to stats display-stats-toggle') av://lavfi:testsrc
Fix this by setting a scale to 1 until osd-height is updated to the
correct value.
Refine populate_log_with_matches()'s logic to not reserve 2 lines for "n
hidden items" when it is not necessary. This avoids printing "1 hidden
items", and doesn't leave an empty line when there are hidden items only
in one direction.
GitHub cache action doesn't allow updating cache with the same key. We
workaround this by saving the cache with a unique key each time (added
timestamp). This works fine, but since there is a limit on cumulative
storage size for all caches, it can force the master branch cache to be
evicted if a lot of PRs are updated. Cache is evicted with LRU policy,
so as long as master branch cache is used it should stay alive, but it
can happen that only PR specifc caches were only used. As a reminder,
PRs can access the master cache, but they are isolated from each other.
Because of this, it is important to keep the master cache, which is
available to all, alive longer.
The solution is to remove all old caches per branch. This is done in a
separate workflow that validates all cache items and removes ones that
would never be used anyway. If PR is closed all caches per branch are
removed. In other cases most recently used one is preserved.
It is done in a separate workflow to limit cache manipulation access.
GitHub workflows triggered by pull_request event are run in the context
of the fork and does not have access to our token, which is good thing.
Also it is quite awkward to get PR number which triggered build
workflow, so just do a full cleanup pass.
In various edge cases, this causes an assertion that was added later in
8816e1117e to be hit. The actual purpose
of the special case is not really clear. mp_seek already will change the
mpctx->stop_play value, so there shouldn't be any need to do it in
queue_seek. And it is known to cause problems so revert it. Also, remove
the special play direction logic that works around this behavior.
Fixes#13778.
This reverts commit dbdc46c97a.
Reading an entire file is a common operation, meanwhile
stream_file will happily open a directory. This doesn't match well.
Analogously for open_output_stream().
This adds script messages to select playlist entries, tracks, chapters,
subtitle lines, bindings and properties using the newly introduced
mp.input.select().
This fully closes#13964.
When you select an item, due to the submit handler being called
asynchronously, the default item list is redrawn before the console
closes, which is jarring. Fix this by always closing the console as soon
as enter is pressed, as keeping it open is unlikely to be useful with a
fuzzy selector (unlike with input.get() where it can be used e.g. to
implement a Lua REPL). If desired we can later add a close_on_submit
flag defaulting to true.
Also fix a crash when pressing enter without any match.
With mp.input.select() these keybindings were both scrolling and moving
the cursor because of how the condition was written and
handle_pgup()/handle_pgdown() not returning a truthy value.
selected_match can become 0 when pressing certain scrolling
keybindings without any match, and
for i = first_match_to_print, last_match_to_print do
in populate_log_with_matches() runs from 0 to 0 and accessing
matches[0].text crashes console.lua. Return early when it is 0.
Avoid messing up the max_log_lines calculation when mp.input.select() is
called with very long items.
This doesn't work with Japanese characters because they are bigger.
I misunderstood CogentRedTester's review in
https://github.com/mpv-player/mpv/pull/10282#discussion_r1428972352 as
referring to the cursor_position in mp.input's arguments instead of the
one received by the closed callback.
The cursor_position passed to input.get doesn't need to be converted to
a number because it was already JSON, while the cursor_position received
by the closed callback is currently a string, and we need to pass JSON
in input-event script messages to keep it as an integer to work around
mpv converting integer script message arguments to string.
This is more noticeable after implementing mp.input.select(): its submit
argument currently receives the selected index as a string, and this
makes Lua error if you use it as an index of a numerical table, e.g.:
submit = function (id)
mp.set_property(property, tracks[tonumber(id)].selected and "no"
or tracks[tonumber(id)].id)
...
end,
This commit avoids having to call tonumber(id).
If g-p is a builtin binding and p is bound in input.conf, pressing g-p
triggers the p binding. Fix this by searching for builtin bindings that
match a longer key sequence even after a user-defined binding has been
found.
Even after changing the condition from >= to > bindings of the same key
defined later in input.conf are still preferred over earlier ones,
because bind_keys() overwrites duplicate bindings. Bindings defined by
later mp.add_key_binding calls are also still preferred.
This allows more completions than patterns:
Both single and double quotes are recognized.
Quotes around the first token are recognized.
Command prefixes are recognized.
Choice options are completed after change-list/vf/af add/append/pre/set.
File paths are completed after set/cycle-values/change-list with options
that expect files, including cycling between paths with spaces, e.g.
cycle-values glsl-shaders 'foo bar' 'baz qux'.
File paths are completed in the fourth argument of dump-cache.
Items that have been set are completed after change-list remove.
This is unused since 4e013afd37 because the mpv logo and the "Drop files
or URLs to play here." message are shown instead of the OSC controls. It
has the adverse affect of making the OSC twice as big when playing
videos with --lavfi-complex, because that makes the video property which
osc.lua checks unavailable.
Fixes:
autoload.lua:201:1: setting undefined field filter of global table
autoload.lua:209:1: setting undefined field append of global table
autoload.lua:322:11: value assigned to variable extensions is unused
The stream layer is just not the right place to make this change
since it's also used for completely unrelated purposes such as reading
configs.
This reverts commit bb7a485c09.
This might not always be correct depending on filtering done in VS. But
unless VS send us all the metadata we have to get it from somewhere.
Fixes dynamic frame metadata, which was copied from fmt_in, initialized
only upon reinitialization.
Fixes crashes caused by the use of stale pointers.
Fixes: #13956
Same as ffmpeg uses. Such big values does not make sense probably, but
let's not overflow values and maybe one day it will be useful.
Fixes signed integer overflow.
This loads subtitle files like foo.en-US.srt with --sub-auto=exact.
To preserve the case of these locales and not convert them to e.g.
en-us, stop lower casing filenames, and instead use case insensitive
functions to check if the media filename is contained in the external
filenames. Extensions, whitelisted cover art filenames and idx files
were already being compared case insensitively.
Fixes#12372, fixes#13251.
Loading external files makes little sense. Might disable this completely
later, but let see how it works, The idea is the same as for direct
load. Exclude paths starting with `file://.` and `file:///`. But still
fuzz any processing that other input might have. It shouldn't be a huge
problem if we do `file://mpv` for example. Not great, but also not
terrible.
This problem does not exist with --demuxer=lavf. --demuxer=mkv just never
signals EOF for the problematic sample, so it needs to be fixed there, not
in AO.
This reverts commit 0cfd52074b.
scaletempo2 has this optimization where it first uses a step size of 5
together with a quadratic interpolation to quickly get the approximate
position of the best overlap and then does a more thorough search aroun
that area.
Doing the same thing in scaletempo brought a 4.8x performance
improvement, however in my measurements a step size of 3 more
consistently finds good overlaps and it's still a 2.9x improvement for
this function.
I should note that while a step size of 3 produced better numbers,
I was not actually able to hear any difference in my test.
A step size of 3 was chosen just in case it actually makes an audible
difference in some cases and the cpu usage isn't really a problem
anymore, but that can be revisited in the future.
scaletempo2 is still faster then scaletempo with a step size of 5,
which I suspect is mostly because it uses some vectorized functions and
scaletempo does not.
This might seem counter intuitive at first, but we want to change the
sound in total as little as possible, not only the middle part of the
overlap.
This also removes the loop unrolling from the integer path to keep it as
close to the float path as possible. The difference in performance is
fairly small and if such an optimization is deemed desirable in the
future it should be implemented for both float and integer
This allows scripts to make the user choose from a list of entries by
typing part of their text and/or by navigating them with keybindings,
like dmenu or fzf.
Closes#13964.
Conditional jump or move depends on uninitialised value(s)
at 0x10FE22: drm_prime_remove_handle_ref (drm_prime.c:144)
by 0x10FCCD: drm_prime_destroy_framebuffer (drm_prime.c:107)
by 0x10FEB1: set_current_frame (hwdec_drmprime_drm.c:73)
by 0x11054F: overlay_frame (hwdec_drmprime_drm.c:223)
by 0xF1311: gl_video_render_frame (video.c:3315)
by 0xFA015: draw_frame (vo_gpu.c:85)
by 0xF8FDB: render_frame (vo.c:961)
by 0xF943F: vo_thread (vo.c:1099)
by 0x5EBE89B: start_thread (in /lib/libpthread-2.31.so)
Uninitialised value was created by a heap allocation
at 0x484713C: realloc (vg_replace_malloc.c:1437)
by 0x10258B: ta_realloc_size (ta.c:195)
by 0x10325D: ta_xrealloc_size (ta_utils.c:298)
by 0x10FDBF: drm_prime_add_handle_ref (drm_prime.c:133)
by 0x10FC57: drm_prime_create_framebuffer (drm_prime.c:87)
by 0x1102FF: overlay_frame (hwdec_drmprime_drm.c:188)
by 0xF1311: gl_video_render_frame (video.c:3315)
by 0xFA015: draw_frame (vo_gpu.c:85)
by 0xF8FDB: render_frame (vo.c:961)
by 0xF943F: vo_thread (vo.c:1099)
by 0x5EBE89B: start_thread (in /lib/libpthread-2.31.so)
Conditional jump or move depends on uninitialised value(s)
at 0x10FCE4: drm_prime_destroy_framebuffer (drm_prime.c:109)
by 0x10FEB1: set_current_frame (hwdec_drmprime_drm.c:73)
by 0x11054F: overlay_frame (hwdec_drmprime_drm.c:223)
by 0xF1311: gl_video_render_frame (video.c:3315)
by 0xFA015: draw_frame (vo_gpu.c:85)
by 0xF8FDB: render_frame (vo.c:961)
by 0xF943F: vo_thread (vo.c:1099)
by 0x5EBE89B: start_thread (in /lib/libpthread-2.31.so)
Uninitialised value was created by a heap allocation
at 0x484713C: realloc (vg_replace_malloc.c:1437)
by 0x10258B: ta_realloc_size (ta.c:195)
by 0x10325D: ta_xrealloc_size (ta_utils.c:298)
by 0x10FDBF: drm_prime_add_handle_ref (drm_prime.c:133)
by 0x10FC57: drm_prime_create_framebuffer (drm_prime.c:87)
by 0x1102FF: overlay_frame (hwdec_drmprime_drm.c:188)
by 0xF1311: gl_video_render_frame (video.c:3315)
by 0xFA015: draw_frame (vo_gpu.c:85)
by 0xF8FDB: render_frame (vo.c:961)
by 0xF943F: vo_thread (vo.c:1099)
by 0x5EBE89B: start_thread (in /lib/libpthread-2.31.so)
```
dd if=/dev/zero of=/tmp/10g.empty bs=1 seek=10G count=0
dd if=/dev/zero of=/tmp/10m.empty bs=1 seek=10M count=0
time mpv /tmp/10{g,m}.empty
```
I keep files with the name format `${name}-${hash}.${ext}.empty`
around, where the original is removed, and a sparse file with
the size of the original is created instead.
A lot of time is wasted on such files when going through
playlists/directories that include some of them.
This admittedly may not be that common of a use-case.
Signed-off-by: Mohammad AlSaleh <[email protected]>
`cuInit` wakes up the nvidia dgpu on nvidia laptops. This is bad news because the wake up process
is blocking and takes a few seconds. It also needlessly increases power consumption.
Sometimes, a VO loads several hwdecs (like `dmabuf_wayland`). When `cuda` is loaded, it calls
`cuInit` before running all interop inits. However, the first checks in the interops do not
require cuda initialization, so we only need to call `cuInit` after those checks.
This commit splits the interop `init` function into `check` and `init`. `check` can be called without
initializing the Cuda backend, so cuInit is only called *after* the first interop check.
With these changes, there's no cuda initialization if no OpenGL/Vulkan backend is available. This prevents
`dmabuf_wayland` and other VOs which automatically load cuda from waking up the nvidia dgpu unnecessarily,
making them start faster and decreasing power consumption on laptops.
Fixes: https://github.com/mpv-player/mpv/issues/13668
This avoids printing any stray messages in encode output stream.
--o is already pre-parse cli option which is designed to be parsed
before anything else is printed to output. So we can use that to force
stderr output if needed for encode mode.
Paths like foo.mkv, ./foo.mkv .//foo.mkv, ../"$(basename
"$PWD")"/foo.mkv, and C:\foo.mkv and C:/foo.mkv on Windows, use
different config files for resuming playback, so if you quit-watch-later
and later play the same file with a different path, mpv does not resume
playback. This commit normalizes the paths on Unix to fix this.
by default utilises the color space of the screen on which the window is
located. if a specific value is defined, it will instead be utilised.
depending on the chosen color space the macOS EDR (HDR) support is
activated and that OS's transformation (tone mapping) is used.
Fixes#7341
This adds non-mpv filters to option-info/af/choices and
option-info/vf/choices, which allows completing them with set af/vf
<Tab> in console.lua.
Partial fix of #13017. Getting the filter options would required adding
af-list and vf-list properties.
If blocks were already demuxed we would skip them and ask for new ones.
For files with few blocks it would return EOF without actually checking
the content.
Also make demux limit higher. In practice it doesn't matter, because if
it is image, video track will have only 1 block. And if it is not image
it will break on 2nd video block.
Fixes: #13975
WS_POPUP windows cannot be maximized, so instead of forcing it with
unavoidable side-effects, change the window style before maximizing to
make it work correctly.
Users shouldn't have to care if subtitles' duration is unknown because
the only difference is that decode() sets a duration to packets without
one, if any.
The main difference was code intentionally breaking sub-seek, sub-step,
sub-start and sub-end for unknown duration subtitles for some reason,
but I removed it in 0f2370476b and 185fa9ffc6.
LRC subtitles always have unknown duration so if you use them having
this logged on every song is annoying, so only log it in verbose mode.
The pad count serves as a minimum even if the filter has
dynamic inputs/outputs, so we should reject them here.
At least on FFmpeg 6.1 this results in no practical change
in the list accepted filters.
fixes: 8bf3fe7e2a
This makes the context menu items accessible from the window menu,
which can be opened by either right-clicking on the title bar or
left-clicking on the mpv icon on the title bar.
Currently if VO init fails, the context menu is leaked. Additionally,
init/uninit are in the VO thread, while other accesses are in the GUI
thread.
Fix this by moving them to the GUI thread, similar to other resources.
This also lets init function take the mpv HWND in the next commit.
If we get either preferred_scale or preferred_buffer_scale this early
during initialization the wl->scaling value should be immediately
updated instead of being deferred until later for correct geometry.
Fixes#14019.
With multiple rects touching each other without any gaps, the current
scale method can cause gaps or overlaps between rects. To make sure that
this does not happen, scale on the edges of the rects instead, and then
calculate the width and height from the results.
NB: while this is better than the status quo, it does not fix all
scaling artifacts because of the following:
- When two rects share a vertical edge but have different heights,
misalignment will occur: after rounding rect heights to pixels,
the height scale factor for the two rects will be slightly different.
As a result, there will be misalignment between the scaled images.
- With a GPU renderer, different bitmap subtitle parts are rendered as
different textures. This means that the pixel contents of the parts have
different boundary conditions from the whole combined image. As a result,
there will still be small gaps when the subtitle is scaled up.
The only way to properly address these points is to make sure that the
parts are combined to a single image at the native resolution before
being scaled. This can be partly achieved with --blend-subtitles=video.
For platforms which send emulated mouse inputs for touch-unaware clients,
such as Win32 and X11, this option enables the native multitouch handling
and disables emulated mouse inputs. This enables interested scripts to
handle multitouch events while keeping compatibility with touch-unaware
scripts.
This adds --input-touch-emulate-mouse option, which controls whether to
enable legacy touch handling where touch inputs are emulated as mouse
inputs. This establishes a primary touch point (the one with the lowest
index) as the emulated mouse position, and MBTN_LEFT up/down with the
appearance of the first touch point and the disappearance of the last
touch point.
This fixes some problems with touch handling on Wayland, for example
attempting to pinch results in a double click.
This adds touch-pos property, which contains the information of all
current touch points. The property has sub properties:
touch-pos/count: the number of current touch points
touch-pos/N/x,y: the position of touch point N
touch-pos/N/id: unique identifier of the touch point
The goal of multitouch support is to interpret as little as possible:
mpv just stores the touch point information and makes the position
available for query. Does not participate in the deprecated input section
system.
The API is modeled after the common part of the touch input APIs of
Win32, X11, and Wayland, to make sure the platform-specific implementations
are as simple as possible.
Autoload script can now exclude certain files
Why? Sometimes you want to ignore thumbnails,
auto-generated backups or just unwanted files
A non-exhaustive list of real-world examples:
- user backup files: '%.bak%.mp4$' or '^bak-'
- telegram-desktop thumbnails: '_thumb%.jpg$'
- a krita graphics editor backup suffix: '^~'
See documentation here: lua.org/pil/20.2.html
After explorer is restarted while show-in-taskbar is false, toggling
show-in-taskbar no longer puts mpv back to the taskbar until it's
unfocused and refocused.
My guess of how this works is that the HWND of the taskbar is cached,
and setting the WS_EX_TOOLWINDOW style internally uses this value to
show/hide the taskbar button. But after explorer is restarted it no
longer works until its taskbar state needs to change (such as focusing).
Only then it realizes the HWND is no longer valid and refreshes it.
Fix this by following MS documentation on this: the window needs to be
hidden before changing the style, and be shown after that. This
unfortunately can sometimes introduce a brief window flash, but it
fixes the problem.
This is made by possible by 96e1f1dfa5 standardizing --gpu-context's
help output. This changes the check to complete any Object settings list
so it will automatically work with future options of this kind.
fuzzer_set_property.c:
fuzz mpv_set_property in both initialized and non-initialized state.
Useful for user provided values sanitization test. I've already seen
some memory leaks in parsing code, good to drill it.
fuzzer_loadfile.c:
mpv_command "loadfile" test. Good for testing demuxers, decoding and
playback loop. Sadly in headless mode we can't really test AO and VO,
but at least all the code around can be fuzzed. Especially our custom
demuxers like demux_mkv.
fuzzer_loadfile_direct.c:
Similar to loadfile above, but instead of saving the data to file, it
passes the fuzz input in the command. Generated protocol specific
versions (mf:// and memory:// for now) and generic one.
Nothing really complex, but good start and even those few targets should
give good coverage of the most common code paths in libmpv.
This change displays the scaled position and size of the image before
cropping to the target rectangle. In simple terms, it shows how much
margin has been added to the image or how much of the image has been
cropped.
Note that target resolution is displayed after crop as in fact all other
pixels are discarded anyway.
This fixes converted subtitles that are styled.
This reverts commit 5e2c211a4e.
Most of the subtitle decoders in libavcodec sets meaningful style
values. For the rest we can conditionally strip style.
Abstract out EGL, and allow choosing between EGL and vulkan at runtime.
vf_gpu_egl.c contains GL specific context and creation/destroy code,
vf_gpu_vulkan.c contains Vulkan specific. This allows vf_gpu being
built in systems where EGL is not available and where Vulkan is
available.
Fixes corrupted audio after resize_input_buffer; realloc_2d did not move
data to new location. Rather than reimplementing more allocator logic,
migrate internals to use talloc and grow buffer with realloc.
6863eefc3d handled this situation by using
an atomic variable to express the state for which the wakeup is caused
by AO control, and the dispatch queue is only processed at this state.
However, this can cause permanent lockup of the player core when the
following happens:
- AO control sets the thread state to WASAPI_THREAD_DISPATCH, and
sets the wakeup handle.
- WASAPI thread reads the WASAPI_THREAD_DISPATCH state and processes
the dispatch queue.
- Another AO control happens. A dispatch item is enqueued, and the
state stays at WASAPI_THREAD_DISPATCH.
- WASAPI thread resets the thread state to WASAPI_THREAD_FEED since
the state has not changed.
- WaitForSingleObject() returns in the WASAPI thread, sees this state,
and does not process the dispatch queue.
- The player core locks permanently because it is waiting for the dispatch
to be processed.
This has been experimentally verified on a system under high contention:
The easiest way to trigger this lockup is to continuously hold down "i",
which rapidly issues AO get volume/mute controls.
To properly handle this, use separate handles for system and user wakeup
requests. Only feed audio when woke up by system and only process the
dispatch queue when woke up by user.
Fixes: 6863eefc3d
bc28f7693d originally added this, but the
implementation isn't correct and causes excessive notifications when
writing to other options which may have bad behavior in some some
circumstances. Fix this by reworking the implementation for force
options so that the timestamps of the option update compared instead.
Whenever an option gets changed, the internal timestamp in the cache is
always incremented. For a special force option, we can save this
timestamp internally as well.
Because cache_check_update is always checked before potentially sending
an option notification, we know that if the internal timestamp is equal
to the timestamp saved by a force update option, it must have been
previously written. Thus, the notification can be sent. This lets
options like geometry work repeatedly but without constantly sending
notifications. Fixes#13954.
dead keys like tilde and accents were not reported because they returned
an empty string from the NSEvent.
try to retrieve dead key with alternative Carbon API when an empty key
is reported.
the Screen property localizedName returns a none unique dynamic name
that doesn't allow a specific selection of a Screen on every OS boot.
the name consists of the vendor name and model name (eg DELL U2723QE).
if the same model display is connected to the system several times,
macOS starts to add numbers to the localizedName (eg DELL U2723QE (1)),
that may not be associated to the same Screen on every OS boot or
connecting the display. it also changes the name of the first connected
display by adding that numeration. this makes it impossible specify the
proper screen with the screen-name option every time.
to circumvent this we remove the enumeration from the name and instead
add the serial number to the display-names property. this makes the
actual Screen unique and none dynamic. furthermore the selection of a
screen by name will check for equality for the old localizedName, simple
name without enumeration, serial number and the combined name with
serial number. this makes it possible to select the screen by either of
those names and identifiers, and keeps backwards compatibility with the
old behaviour.
Examples:
localized name (System Settings name): DELL U2723QE, DELL U2723QE (1)
simple name: DELL U2723QE
serial number: 123456789
combined name: DELL U2723QE (123456789)
When this was originally implemented, the fixed conversion factor was
accidentally reverse engineered. It was left as is though. Instead, use
the wl_fixed_from_int helper, so it's more obvious what is going on
here.
Currently they refer to the OSC documentation. However,
the "mp.options functions" already documents that, is more detailed,
and does not contain false statements like "there may be no spaces around
the ``=`` or anywhere else" (the primitive parser does not care about
them, so starting a string option value with spaces is perfectly fine).
Change them to refer to "mp.options functions" and remove the redundant
section in the OSC documentation.
mp_input_sdl_gamepad_add() calls mp_input_add_thread_src() which
already locks, so it cannot be called inside a lock.
Missed in e8b9476bf7 refactoring.
DXGI debug interface encapsulate multiple message queues, which allows
to get validation not only for D3D11 calls, but also DXGI ones.
Also this makes leak detector not report self debug interface as alive
like it was before. And same as with validation, it has ability to
detect more alive objects, not being limited to D3D11.
This allows users to set buffer duration in exclusive mode. We have
been using the default device period as the buffer size and it is
robust enough in most cases. However, on some devices there are
horrible glitches after a stream reset. Unfortunately, the issue is not
consistently reproducible, but using a smaller buffer size (e.g., the
minimum device period) seems to resolve the problem.
Fixes#13715.
Not all cards support gbm which means the creation of the gbm device
will fail. However during the uninit process, the destruction of the
device was unconditionally done which leads to a segfault. Guard it
instead. Fixes#13929.
Previously, the code required a check against the old saved geometry to
make sure the size and/or position was different before updating. The
doesn't work with the previous changes that allow a geometry value to be
set again with the same value as before. It would probably be nicer to
check against something that always keeps track of the actual window
size in real time, but it seems geometry in x11 doesn't quite work that
way so we'll do it the easier way instead.
mpv's core does not propagate option notifications unless they actually
change to the rest of the player. Most of the time, this makes perfect
sense. If the user sets fullscreen multiple times, there's no reason to
care about anything other than the change in state. However, there are
certain options where it makes sense to always broadcast a notification
even if the value doesn't change. For example, consider the window-scale
case. A user may set window-scale to some value, resize the window
further through some other means (such as mouse resizing) and then want
to set the window-scale again to the same value as earlier. The
window-scale value did not change from before so no notification is sent
and nothing happens even though it is desirable and expected that it
operates again.
This was solved by making the current-window-scale property writable a
few years ago, but actually the easier solution is to just always force
the option to update on any write. For the big callback, the needed
changes are trivial. Unfortunately, it requires a hot mess in order to
have this work with the m_config_cache_update APIs. Spooky stuff in
there, but it does send the notification now.
This option type is not used only by filter options: they're already
used by --ao, --vo, and --gpu-context. Replace the mentions of
"filter" to "item" instead, and changes some languages to improve clarity.
Also change the documentation on "Filter options" to describe what it
really is, and fix a typo.
Now that obj_settings_list is used for GPU contexts, detailed
descriptions can be added so that --gpu-context=help can print
the descriptions of the GPU contexts using standard
obj_settings_list help printing.
This adds a dummy context at the start of the context lists, which
serves three purposes:
- The "auto" option is listed for --gpu-context=help.
- Some special handlings of "auto" string are removed.
- Make sure that lists have at least one element, so MP_ARRAY_SIZE()
works as intended.
Since the list of available GPU contexts is a compile time constant,
use obj_settings_list instead of opt_string_validate for GPU contexts.
This has several advantages:
- Aligns with the existing usage of vo, ao, and filter lists.
- Allows custom probing order.
- Allows list option suffixes. (--gpu-context-append, etc.)
- Allows autocomplete in console.lua.
- Uses the standard obj_settings_list help printing, so the custom
help printing function is no longer needed.
This also deduplicates some context creation code for ra_ctx_create
and ra_ctx_create_by_name.
This gives these properties the "time" type, which allows them to be pretty-printed as HH:MM:SS easily (but also still allows raw formatting using e.g. ${=sub-start}).
This lets you press / in page 4 of the stats and type a keybinding or
part of its command to filter it by using mp.input.
This works badly without a VO because both stats.lua and console.lua use
show-text and only one can be displayed at a time, but it's still better
than not having the search available at all.
21d434d2db attempted to ignore unknown
CSI sequences with a specific termination rule. This however does not
apply to mouse CSI sequences which can have characters out of that
range. Fix this by throwing away the whole sequence when an unhandled
mouse sequence is detected.
These 6-byte codes have the format of \e [ M <button> <xpos> <ypos>.
Support the first 3 mouse bottons + scroll up/down for now as
button numbers > 5 are pretty non-portable across terminals.
Pixel-based mouse position values are calculated and sent to the
input system.
Enable ASS_FEATURE_{WHOLE_TEXT_LAYOUT, BIDI_BRACKETS} and auto base
detection by default, and add an option to disable this if needed.
This is strictly an improvement for webvtt files as they always use
auto base detection. This _fixes_ right-to-left text rendering for
webvtt files which correctly mark rtl/ltr. Webvtt files obtained from
sources which sideload the RTL information through css also see an
improvement due to the auto detection.
Generally SRT files also want this, but some are also written to
workaround VSFilter quirks.
See also: https://github.com/mpv-player/mpv/pull/12985#issuecomment-1839565138
This adds a new option --show-in-taskbar, which controls whether
mpv appears in taskbars. This is useful for picture-in-picture
setups where the video window should not appear in taskbars.
On X11, this can be controled by setting the
_NET_WM_STATE_SKIP_TASKBAR window state.
Avoid having to configure both the OSD and the stats script opts when
you change the OSD options, in particular avoid having to convert colors
to BGR.
Also document the shadow options.
font_size, border_size and shadow offset defaults are kept because the
same values look much bigger in the stats than in the corresponding OSD
options.
osd-back-color is now respected without extra checks until you
explicitly set a shadow_color.
Showing media titles in the playlist is pointless when sources are ill
tagged and media titles contain only garbage. Being able to opt for
file names at least gives us a choice in such cases.
92a9f11a0b added locking for dec_sub.
At that time, because the lock was exposed to the outside world,
a recursive mutex was used. However, this is no longer true after
e9e883e3b2, when the public locking
functions were removed. This means that the lock is now private.
Unlike input.c, dec_sub already enforces said call hierarchy, so
combined with the aforementioned change, the lock is only ever
called once and never recursively. Thus the lock can be converted to
a normal mutex.
Previous commits made sure that the lock will never be called for more
than once for all public functions. Thus deadlock is impossible, so
recursive mutex is unneeded and can be converted to a normal mutex.
The absense of a call hierarchy between public and private functions
results in many unnecessary recursive locks: public functions require
locks, which are also called by other public and private functions in this
file. Fortunately, since the lock is private to this file, this situation
can be avoided by establishing a call hierarchy:
- Public functions must lock, and can only call private functions in
this file
- Private functions must not lock, and can only call private functions
in this file
- No function can call any public function in this file, the only
exception being mp_input_wakeup and mp_input_parse_cmd.
This arrangement ensures that there will be no locks more than necessary:
All public function calls will lock only once, and never recursively.
Depending on the options:
For AV_CODEC_ID_ARIB_CAPTION this allows using bitmap output.
For AV_CODEC_ID_DVB_TELETEXT this allows using text output.
Fixes: #13471
--stop-playback-on-init-failure=no is documented to continue playback in
audio-only mode if video init fails. However, this does not function
properly after a080432992: because video
is initialized first, if video init fails, ao_chain is still null.
As a result, !(mpctx->vo_chain || mpctx->ao_chain) is true, a playback
error is raised, so the playback ends and audio does not play.
Fix this by reverting that change, so it checks the tracks instead.
Fixes: a080432992
Turns out that adding more medatata like HDR10+ and Dolby Vision would
produce a lot of duplication and it is better to centralize it around
the track-list property.
Fixes: e720159f72
If the player is paused, switching subtitle track requires us to read
subs packets for an indefinite amount of time in order to actually
display the subtitles. The problem with this is that it puts a blocking
loop in the play thread which can be slow in cases where it takes a long
time to fetch the subtitle (e.g. over a network).
9e27b1f523 alleviates this when a pause
happens because of buffering, but it's not complete. One could encounter
this if the user pauses the video first manually and then switches the
subtitle track.
To solve this better, make it so the loop has a time out (totally
arbitrary number) so the player isn't blocked forever. If subtitles are
not fetched within that time, we flag the track and try again later in
the playloop.
Section 12 of Matroska Media Container Format Specifications says:
If a BCP 47 Language Element and an ISO 639-2 Language Element are used
within the same Parent Element, then the ISO 639-2 Language Element MUST
be ignored and precedence given to the BCP 47 Language Element.
Fixes: #8144
Adds support for extracting codec profile. Old properties are redirected
to new one and removed from docs. Likely will stay like that forever as
there is no reason to remove them.
As a effect of unification of properties between audio and video,
video-codec will now print codec (format) descriptive name, not decoder
long name as it were before. In practice this change fixes what docs
says. If you really need decoder name, use the `track-list/N/decoder-desc`.
The protocol strongly implies that this only happens when the value
changes, and it's also what you would naturally expect. But maybe it's
worth guarding this in cause for some reason the same value twice in a
row happens.
The mpv window overlapping multiple outputs with different scale values
can result in some weird behavior when dragging it from one monitor to
another one. This is due to the way some compositors implement
preferred_scale or preferred_buffer_scale (integer scale equivalent).
Depending on the scale values, mpv window has to be resized to match the
new scaling value (due to fractional scaling requiring a viewport). This
can cause the window to become smaller and no longer overlap the monitor
you were just trying to drag it to. Repeat this and the window will
become smaller and smaller. Depending on the layout, the reverse can
also happen (the window becomes larger). This can cause additional
events to fire as the preferred_scale value may change again which does
more weird things.
It seems kwin is not affected by this because their implementation of
preferred_scale sends the event only if the window is fully on the new
monitor. Honestly, this is probably more logical anyway but we should at
least deal with the other implementations better. Try to deal with it by
reworking scaling changes so they only occur when the mpv window is
fully on one monitor. If we get a preferred_scale event and there is an
overlap, save it as a pending change to be performed on the next
surface_enter or surface_leave event (whichever results in there being
only one monitor. Some weird rendering glitches can still happen during
overlap but this makes it usable again.
Turns out libplacebo uses unrotated target crop in relation to source.
Use dst rect from VO, instead of extracting it from pl_frame, to avoid
another unrotating operation.
Fixes: a9354b36ca
Previously if mpv's size was constrained by the compositor's configure
bounds event, there was no attempt to preserve the aspect ratio of the
given coordinates if --keepaspect (the default) was used. Be sure to
apply keepaspect to the bounded widths and heights if we are using this
event.
The reconfigure event handles setting fullscreen, maximize, etc. We were
implictly relying on the compositor to just ignore mpv if we set a
redundant state (e.g. setting fullscreen when we're already fullscreen),
but kwin actually doesn't and operates again. This causes some subtle
issues when handling geometry on state changes. Rework the state change
calls so they are only executed if wl->geometry_configured isn't set yet
(i.e. the window just opened up for the first time). It's the only time
this is actually needed.
If mpv is coming out of some locked size state (fullscreen, maximized,
tiled), the window size given by the reconfigure event should be used
assuming the --auto-window-size option is set.
Fixes 8a9749b8a5
the mp_log is freed when the corresponding mpv_handle (ta_parent) is
freed in the EventHelper, though it could still be used from different
threads. instead don't use a ta_parent and manually free on manual
dereferencing. on app shutdown (memory cleanup) this is not called but
instead is freed by the usual cleanup and freeing.
the LogHelper is only able to be manually dereferenced in the AppHub,
so no race conditions are possible in all other cases (vo).in the AppHub
it's impossible to hit a race condition atm, because of how the init
process works and how/where the log is used. only manually forcing
logging in the exit process itself could theoretically trigger a use
after free.
Fixes#13823
Playback with many audio channels could be distorted when using
scaletempo2. This was most noticeable when there were a lot of quiet
channels and few louder channels.
Fix this by increasing the weight of louder channels in relation to
quieter channels. Each channel's target block energy is factored into
the usual similarity measure.
This should have little effect on very correlated channels (such as most
stereo media), where the factors are very similar for all channels.
See-Also: #8705
See-Also: #13737
When converting a list to string for show-text, since
05c398fb6c the OSD_ASS_0 escape hatch
is used. This usage is problematic because the same format string is
used for print-text, which results in these ASS escape sequences
being printed in the terminal.
Also since d6610a5b2f, the print-text
output to console.lua is no longer escaped if OSD_ASS_0 is present.
This results in abnormally formated text in the console output.
Fix this by not using ASS escape sequences for this. Instead, use the
circle symbols used by the OSC, which also results in the same width
for active and inactive items.
this will prevent jumping of the window size in the case the window size
was 'externally' modified and not via the window-scale property, when
using the pinch gesture.
Fixes#11594Fixes#13799
Lots of filters have generic internal function names like "process".
On a stack trace, all of the different filters use this name,
which causes confusion of the actual filter being processed.
This renames these internal function names to carry the filter names.
This matches what had already been done for some filters.
"playthread" is a confusing name which doesn't describe what it really
is. Rename it to ao_thread, and ao_wakeup_playthread to ao_wakeup,
in the same style as VO threads. This makes call stack function names
less confusing.
This commit was originally sparked by a change in sway. When looking at
the wording of the spec, it was believed that the rotation should be
counter-clockwise. But that was interpreted incorrectly. The rotation
direction in the spec is meant for compositors not clients. Clients
should be rotating clockwise and compositors rotate it the opposite
direction. Also see the discussion in upstream wayland*.
*: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/369
This reverts commit 27ef1725e7.
Allows to avoid non-portable strlen usage. Also avoid "initializer
element is not constant" warnings on older GCC that doesn't like
explicit type specification in aggregate initialization.
Co-authored-by: NRK <[email protected]>
Co-authored-by: nanahi <[email protected]>
Removes mp_puts/mp_fputs and adds mp_fwrite.
In fact I wanted fwrite instead of puts, no need to make it more awkward
with the implicit new lines.
Fixes: fc55f355fc
This is multiple times faster than just writing every pixel sequence
separately. Especially on slower terminal emulators. In general no need
to stress I/O, while we can just prepare the frame to print and do it
once.
This change is mostly motivated by missing
VK_KHR_portability_enumeration instance extension when enumerating the
devices. Which causes issues with MoltenVK which does not advertise full
Vulkan conformance.
To avoid duplicating code use pl_vk_inst_create() which correctly query
availability and enables the mentioned extension.
While at it fix the VkInstance leaking in vk_validate_dev().
Probing for hwdec can be very slow: on my setup (Nvidia GPU without
VP9 hwdec capability), this causes 2x hot cache startup time compared
to explicitly disabling VP9 in this list (500 ms -> 1 000 ms).
Also remove --vo=vdpau reference.
In many places, flags options have duplicate descriptions like
--break-player and --no-break-player. This is redundant since the
equivalence of this syntax to --break-player=<yes|no> is already
documented, and the =<yes|no> syntax is more in line with the syntax
of other option types.
This replaces all usage of --no-foobar with --foobar=no, and use
--foobar=<yes|no> when possible.
A figure from pipewire documentation:
```
stream time domain graph time domain
/-----------------------\/-----------------------------\
queue +-+ +-+ +-----------+ +--------+
----> | | | |->| converter | -> graph -> | kernel | -> speaker
<---- +-+ +-+ +-----------+ +--------+
dequeue buffers \-------------------/\--------/
graph internal
latency latency
\--------/\-------------/\-----------------------------/
queued buffered delay
```
We calculate `end_time` in the following steps:
1. get current timestamp in mpv
```
int64_t end_time = mp_time_ns();
```
2. add duration of samples to enqueue
```
end_time += MP_TIME_S_TO_NS(nframes) / ao->samplerate;
```
3. add delay of the pipewire graph
```
end_time += MP_TIME_S_TO_NS(time.delay) * time.rate.num / time.rate.denom;
```
4. add duration of queued and buffered samples.
```
end_time += MP_TIME_S_TO_NS(time.queued) / ao->samplerate;
end_time += MP_TIME_S_TO_NS(time.buffered) / ao->samplerate;
```
New in this commit. `time.queued` is usually zero as `SPA_PARAM_BUFFERS_buffers`
is default to 1; however it is not always.
`time.buffered` is non-zero if there is a resampler involved.
5. add elapsed duration from when `time` is captured
```
end_time -= pw_stream_get_nsec(p->stream) - time.now;
```
New in this commit. `time` is captured at `time.now`.
From then, time has passed so we need to exclude the elapsed time,
by calculating the diff of `pw_stream_get_nsec()` and `time.now`.
instead of using the MP_KEY events (Int32) and using a logical OR to
generate a key event for the mpv core, use the cocoa event type for key
states and pass those to the the function. in the function we properly
map those events to the right MP_KEY events.
when dropping more than one file on the App icon or opening via Finder
the open(urls:) event might not pass all files at once in the array, but
may consecutivly call open(urls:) for each of the files or batched in
several arrays.
to fix this append any file passed to the open(urls:) event within 0.1
seconds of each other to the current playlist. the first event uses the
default behaviour.
the unfsContentFrame wasn't updated when externally resized leading to
a wrong unfs window size afterwards. update it on windowDidResize event
when not in fs, not animating and not live resizing.
No idea how things previously worked without having these set, but
apparently they did...
If this was a normal encoder to muxer case, we would utilize
`avcodec_parameters_to_context`, but alas this is not.
Fixes: #13794
`hotplug_cb` was registered only in `hotplug_init()`.
This commit make it registered in `init()` as well,
so that the ao can listen for latency change
in playback.
When a video-reconfig occurs with an image, the cache is not used
because find_cache_seek_range() checks if the start time was
initialized, but for images it stays at MP_NOPTS_VALUE. This makes
rotating large network images slow because they are re-downloaded on
every rotation.
Fix this by setting the timestamps of image cache ranges by altering a
condition.
This field is used by compare_track when determining if the next track
should be preferred. The only problem is that we were only setting this
in compare_track which isn't used for the very first subtitle track
selection. So if the first subtitle track was a forced track that was
selected, this wasn't marked and the next subtitle track could
mistakenly be detected as preferred. Fix this by setting the field after
we set pick equal to the track in select_default track. Fixes#13804.
when in libmpv mode there is no need to for logging and reading options.
this also prevents possible race conditions with the usage and deinit of
the mpv_handler.
NSApp.terminate() is not a requirement to properly shut down a cocoa
App since it only calls exit() internally. though when not used the
cocoa termination events won't trigger, which we don't need. this
prevented us to exit with a proper exit code.
rework the whole termination logic to end up at one point where we can
return the exit code from the mpv_main function.
Fixes#7456
this event has several advantages, it unifies the mpv:// url handling,
the dropping of files on the App icon and opening via finder into one
event, and it also lets us remove the file open workaround.
we had to keep track of opened files via the command line because the
event was also triggered by passed files on the command line, leading
to redundant load events.
the new event doesn't trigger from files passed via the command line
anymore.
since cocoa is initialising mpv and does several things before the mpv
core does anything and the mpv_handle was passed to the App, this can be
used to log such things before the mpv logging is available. helpful for
debugging especially bundle related things.
the logger mapping looks a bit unintuitive but error is basically yellow
what our warning is and fatal is red what our error is.
At least on some compositors, when the pointer enters a surface,
only a wl_pointer_enter event is generated, but not wl_pointer_motion.
This results in the initial mouse position being lost, which is
especially problematic when input simulation is used.
Fix this by setting the mouse position on pointer enter event.
`buf` contains a `struct spa_data` for each channel.
Therefore the number of channels does not matter to calculate the frame capacity of one `struct spa_data`.
In practice this shouldn't make a difference as `b->requested` would reduce nframes even more.
During AO init, snd_pcm_open() is called, which calls snd_config_update()
to allocate a global config node and stores it in the snd_config global
variable. This is never freed on uninit.
Fix this by freeing the global config node on uninit.
this broke with the recent refactor of the input handling. one of the
edge cases was not considered, where not every mouse down event has a
corresponding mouse up event, eg all double clicks or more only have one
up event after the first down event.
this was handled correctly previously.
Fixes#13777
win32 does not respect --native-keyrepeat option, and native key
repeat has been broken since 0ab3482f73.
This lets mpv respect the --native-keyrepeat option on win32.
The device latency may change during hotplugging.
This commit updates p->hw_latency_ns each time
hotplug_cb is called so that it can reflect
updated device latency.
With certain speed settings, the following can happen at the start of
the playback:
- can_perform_wsola returns false, so no frames are written
- mp_scaletempo2_frames_available returns true when
p->input_buffer_final_frames is 0 and target_block_index < 0
This results in infinite loop and completely stalls audio filter
processing and playback. Fix this by only checking this condition
after the final frame is set.
Fixes: 8080d00d7f
Would be better to search the other way around, because options list is
bigger than property list, but with minimal changes this is good enough.
Both are relatively small tho and the only reason for this micro
optimization is to increase the fuzzing throughput.
add new app_bridge objc file for bridging between mpv core and app
functionality. replace old EventsResponder singleton with AppHub.
another step to clean up all App functionality and have one central
place for it.
As far as I can tell PulseAudio introduced a bug in 16.0
where if a stream is (un)paused too often the reported latency
will momentarily spike by 3000% or more. Apparently in certain cases
just pausing once and waiting can also cause this.
Save the remaining users of PA the trouble of debugging the various
obscure issues that can arise from this (desync is a harmless example)
by enabling the latency hack code again.
ref: <https://github.com/mpv-player/mpv/issues/12057>
<https://github.com/mpv-player/mpv/issues/10333>
Both possible paths had bugs:
For OpenGL it passed EGL_CONTEXT_CLIENT_VERSION, which - in older versions
of the standard - was not permitted.
For GLES it always assumed EGL_CONTEXT_FLAGS_KHR to work, which belongs to the
aforementioned extension.
Ironically this was never a problem (probably saved by implementations
not being overly strict) except in 2024 on an emulated Android 14 device
that trips over this edge case. It is a mystery.
Basically a simple way to perform any command/property action from the
command line. This takes the exact same syntax as input.conf but not
including the key naturally. Potentially useful for weird properties
that don't map well to options (like ao-volume). Fixes#12353.
This enhancement makes it easier to create constant width property
expansions, useful for the `--term-status-msg`. Additionally, it changes
to `%f` printing with manual zero trimming, which is easier to control
than `%g`. With this method, we can directly specify precision, not just
significant numbers. This approach also avoids overly high precision for
values less than 1, which is not necessary for a generic floating-point
print function.
A new print helper function is added, which can be used with adjusted
precision for specific cases where a different default is needed. This
also unifies the code slightly.
Escape all messages in osc.lua, because other than the title they
weren't being escaped at all. If for example you did mpv foo.mp4
'{\fs50}bar.mp4' and script-message osc-playlist, it would just render
the second entry as bar.mp4 in big text.
The title was escaped partially, now the escaping is complete because:
- It escapes \. Backslashes at the end of the title are escaped instead
of being stripped, and \n, \N and \h are now printed verbatim. In
particular, "\\n" is no longer converted to space and is printed
verbatim instead which is more correct.
- Newlines ("\n", not the "\\n" escape sequence) are converted to spaces
instead of rendering them and messing up the text positioning within
the OSC.
- Spaces at the start are preserved.
Fixes#11209, fixes#11275.
This adds a command to escape ASS tags to remove code duplication
between sub/osd_libass.c, console.lua, osc.lua, stats.lua and any user
script that calls mp.create_osd_overlay().
A command is used instead of scripting functions so that all clients can
use this and not just use Lua and JS ones.
osd_mangle_ass() also interprets osd-sym-cc and osd-ass-cc/{0,1}, but
since they use invalid UTF-8 characters there is no risk of escape-ass
users using them by accident, like with any OSD message.
Always replacing \n with \\N in mangle_ass() even when it is not called
by escape-ass doesn't seem to cause any issue, but I made it conditional
anyway to avoid changing how all OSD messages are treated unnecessarily.
585d8c6856 increased max active
section limit from 5 to 50 but this obviously doesn't properly fix
the problem. Input still breaks if more than 25 scripts are loaded,
or if some scripts define lots of input sections.
Remove the limit completely by using a dynamic array for active sections.
Fixes: https://github.com/mpv-player/mpv/issues/13707
The terminal output was static in size with no way of automatically
adjusting it to the current terminal size.
The new term-size property makes truly automatic adjustment possible.
There was no way for scripts to know the current size of the terminal,
which is essintial if they want to provide a good user experience even
without a window.
The scroll hint on page 4 had baked in ass tags, which shouldn't be
there in the terminal. Also the scroll hint on page 0 was missing.
Refactor scroll hint generation into a function and use that for
pages 2, 4 and 0.
The terminal is assumed to be 80x24 in size, the new options
`term_width_limit` and `term_height_limit` can be used to overwrite
that.
Lines longer then the terminal width cause problems with scrolling
pages and need to be shortened.
The algorithm used for shortening can deal with tabs and escape
sequences, has rudimentary support for UTF-8 and runs in O(n).
avih helped in the creation of the term_ellipsis() function and split()
is also from him.
Pages 2 and 0 had their own scroll implementations, which worked fine
for ass, but didn't work well in the terminal.
Now they both use the same scroll function as page 4.
That scroll function requires each output line to be one entry
in the table. Page 0 did not adhere to that new requirement, instead
it generated two table entries for a single output line when a graph
is shown. To fulfill that requirement the generated graph now gets
directly appended to the same table entry that's used for the rest
of the line.
This scrolling implementation will be used for other pages in future
commits.
The comment said it takes up 20 lines of the terminal, but in reality
it was 22 lines.
Make it more straightforward by always calculating top offset first
instead of having two branches, that tries to calc it directly.
This also fixes missing negative check before `\033[%dA` which was in
practice only problem on macOS which was handling negative values, while
in fact it shouldn't.
Fixes: #13484
Manually editing interface-changes.rst is a giant maintenance pain that
causes merge conflicts all the time. Stop doing that nonsense and
instead have changes be written to files in DOCS/interface-changes. Also
remove that one sentence in changes.rst because it's just not true.
timeBeginPeriod() only allows setting minimum timer resolution
to 1 ms. However, modern x86 platforms support a minimum timer
resolution of 0.5 ms. Use NtSetTimerResolution() instead for
the increased resolution, which can be set with MPV_HRT_RES.
Additionally, change the units of mp_start_hires_timers(),
mp_end_hires_timer(), MPV_HRT_RES, and MPV_HRT_MAX to nanoseconds,
in accordance with other functions used in timer.h.
GetConsoleMode() can be quite slow and in mpv the mode never changes, so
we can just check it once.
Fixes performance when writing lots of logs to terminal.
%s is evaluated as wchar_t only in "Windows classic" semantic. It is not
C standard compliant.
%ls is compatible with both and means the same wchar_t format.
This commit fixes error output from mpv.com.
See: https://devblogs.microsoft.com/oldnewthing/?p=102823
This is default behavior to attach to existing console, passing custom
handles is useful if we want to replace them, but in case they are
already attached to console we want to attach to console directly.
In theory, it should work out of the box because "console-like" handles
should be managed by Windows internally, which works for INPUT and
OUTPUT, but in certain cases, not for ERROR. This allows using VT
features in those cases for stderr too.
When 3cb9119984b88b31a5b958b1b83efe8d1cf0b818 introduced AVIF screenshot
support, FILE * in write functions were replaced by filenames. This
resulted in unnecessary duplication of FILE * handling code and the usage
of avio_open API made it hard to use exclusive open with it.
To unify file handling, use avio_open_dyn_buf instead which writes to
memory instead. This way FILE * can be used for the write functions
and file handling code can be deduplicated. Since we now control
the file opening, exclusive open can now be used for AVIF screenshots.
The screenshot command is documented to not overwrite existing files.
However, there is a race window between the filename is generated with
gen_fname and when the file is open to write. Specifically, the
convert_image function in this window can be very time consuming
depending on video and screenshot image format and size. This results
in existing file being overwritten because the file writing functions
don't check for the existance of file.
Fix this be opening the file in exclusive mode. Add overwrite parameter to
write_image for other operations that are documented to overwrite existing
files, like screenshot-to-file. Note that for write_avif, checking
existance is used instead because avio_open does not support exclusive
open mode.
This flag is a GNU extension in C99, but was standardrized in C11,
so mpv should be able to use it. fopen is wrapped on win32 so
non-compliant MSVCRT.dll isn't a concern.
Since the upcoming commit uses this feature it can be brought back.
This reverts commit c36e051470.
This commit allows image_writer to attach HDR metadata to AVFrames via
the corresponding AVFrameSideData attachments, if present. It does this
by calling pl_avframe_set_color, already used by mp_image_to_avframe.
Signed-off-by: Leo Izen <[email protected]>
Debanding is an inherently destructive process. It is not needed for
most high-quality sources and only produces an adverse smoothing effect
when applied to fine-detailed content, removing detail. It should only
be applied when necessary, either manually with the `b` keybind or with
an automatic profile.
Additionally, it is quite computationally heavy with no real benefit for
high-quality content.
By default, and especially in the high-quality profile, mpv should
preserve source detail and quality as much as possible. Additional
processing should be opt-in.
Fixes the issue described in https://github.com/mpv-player/mpv/issues/11862
for SDR files for non-d3d11 gpu-api. We currently don't have a smarter
way to get the real on-the-wire bpc for other APIs, so this is the best
that can be done.
Windows 10 top bar height cannot be adjusted individually when
WS_CAPTION is enabled due to buggy DWM NC drawing behavior. The issue is
fixed in Windows 11.
To keep consistent window look remove the border on each side, but only
on Windows 10.
Windows 11 draws border regardless, so we are 1px off on window size,
blending border with one line of video. Fix that by adding the border to
our internal windows size calculation.
Windows 10 on the other hand has a bug where specifying left and top NC
area will trigger title bar drawn in full height always. Keep old
behaviour in this case. Also while there is similar "visible" border
there, it seems to be transparent on Windows 10.
For high contrast themes, don't adjust title bar height and instead
remove WS_CAPTION to have the same border all around the window, as DWM
doesn't make borders invisible in this case.
With runtime geometry change, currently it only results in a
SetWindowPos call to resize the window. However, SetWindowPos doesn't
change the window maximized state, so Windows still thinks that the
window is maximized even though it no longer covers the whole workspace.
This results in visual glitches, and if the window is dragged afterwards
it's "restored" again.
Fix this by correctly setting the window maximized state in this case.
Currently mpv always uses the previous window size when unmaximizing
or exiting fullscreen. This disregards compositor's preferenced size in
the configure event, resulting in wrong window size if changing window
state and size are delivered in the same configure event.
It's better to always respect the preferenced size instead, unless
the state change is due to runtime geometry change, where we want
to use our preference.
Clarify that --autofit-larger sets the maximum size of the window.
The original wording was not written with runtime change in mind,
so the implication of "not changing size" is ambiguous.
In the xdg_toplevel_configure handler, in some cases the geometry is
not equal to the width and height in the event. This can happen
when runtime geometry change is requested (a new size is set),
or in the case of wl->state_change || width == 0 || height == 0
(the old size is used).
However, prepare_resize always uses the width and height in the event
and not the corrected geometry here. This causes
xdg_surface_set_window_geometry using the wrong value resulting in
wrong size of window decoration. Amusingly, the debug message right
above it uses the correct size.
Fix this by using the updated geometry size instead. Since now all
prepare_resize have parameters of 0, the width and height parameters
are no longer needed.
Fixes: 828dd65ef8
8e793bde78 made that changing geometry
while maximized has no effect until the window is unmaximazed. However,
this behavior is inconsistent with setting window-scale on all of win32,
wayland, and x11, which always unmaximizes the window and sets the
window size.
Since setting geometry is conceptually similar to setting window-scale
(both change the window size), they should have the same behavior.
If not fullscreen, unmaximize window on runtime geometry change to
keep the behavior consistent with window-scale.
Currently, setting geometry on runtime only changes the window size
but not the position. This is because reset_size is only set if
the window size is changed, and vo_x11_highlevel_resize doesn't set
the window position without force_window_position enabled. Fix this
by setting the related flags and perform a window move when
geometry is updated.
Fixes 8e793bde78.
Commit 39f7f83 changed ao_driver.reset to use AudioUnitReset instead of
AudioOutputUnitStop. The problem with calling AudioOutputUnitStop was
that AudioOutputUnitStart takes a significant amount of time after a
stop when a wireless audio device is being used. This resulted in
lagging that was noticeable to users during seeking and short
pause/resume cycles. Switching to AudioUnitReset eliminated this
lagging.
However with the switch to AudioUnitReset the macOS daemon coreaudiod
continued to consume CPU time and did not release a powerd assertion
that it created on behalf of mpv, preventing macOS from sleeping.
This commit will change ao_coreaudio.reset to call AudioOutputUnitStop
after a delay if playback has not resumed. This preserves the faster
restart of playback for seeking and short pause/resume cycles and avoids
preventing sleep and needless CPU consumption.
Fixes#11617
The code changes were authored by @orion1vi and @lhc70000.
Co-authored-by: Collider LI <[email protected]>
This is useful e.g. when the caller dup2's a socket into stdin, or
passes a socket/pipe as /dev/fd/{fd}, because it is impossible to seek
on sockets and pipes.
As the first aligned format this required a fix to reconfig().
Adding the other component-swapped formats in this group would be trivial
but I checked the DRM database [1] and no driver exists that supports
one of those but not YUYV and this is quite fringe as-is, so I opted not to.
[1] <https://drmdb.emersion.fr/formats>
The VO generic code tries to be helpful and resets this after
each reconfig. However for the simpler VOs the target params
are constant after a reconfig or even for the entire lifetime.
So it's clearly better to let the VO decide.
This also allows the VO to use a static buffer instead.
Segfaults otherwise on uninit because some objects are created while
others are not. Move it to the very top since the purpose of this is to
skip wayland initialization entirely while autoprobing.
Fixes f6f1721101.
Currently, Wayland is above X11 and DRM in probe order. The success
of automatic probing depends on the fact that unsuitable backends
would fail to initialize. For example, X11 backend (which uses Xlib)
fails to initialize if DISPLAY environment variable is not set, so
starting mpv in VT console will pick the DRM backend as expected,
even when an X server is running in another VT.
However, libwayland-client used by the Wayland backend has the
"helpful" behavior of falling back to "wayland-0" if WAYLAND_DISPLAY
is not set. This breaks autoprobing if mpv is started from X server
or VT console while a running Wayland compositor running in another
VT (or even running as an X client) is using "wayland-0" for protocol
socket name: mpv will start playing in the Wayland compsitor instead
of using the X11 or DRM backends.
Similar to DISPLAY for X server, We should consider exporting
WAYLAND_DISPLAY to child processes the responsibility of Wayland
compositors, and any compositor not doing this should be considered
broken. Thus we now require WAYLAND_DISPLAY to be set for the
backend initialization to succeed to make sure that autoprobing
works as intended.
It seems that GLX requires us to explicitly set opts.want alpha before
ra_ctx_create is called. b7fd232524
rearranged the function calls in a way made this not work. Fix this by
rearranging it again so the value is set before ra_ctx is created.
For image formats with 2 or more chroma planes such as YU12, there is
a plane merging pass for these planes calling finish_pass_tex which
does a format conversion. After this conversion, the cscale shader
afterwards works properly.
However, for image formats with only 1 chroma plane (semi-planar formats),
including NV12 and P010, this merging pass is never called, which breaks
the cscale shader afterwards if the video is rotated with subsampled
chroma.
Fix this by adding an explicit conversion pass if this situation is
detected after the pre-scale hooks, so if there are shaders hooking on
CHROMA (like the deband filter) and the conversion is done by pass_hook
already, this conversion won't be called.
`--no-config` should prevent loading any user files, whether it be
config, cache, watch_later state etc. This functionality was changed by
df758880e2 because internally `--no-config` is equivalent to passing
`--config-dir=""` which resulted in cache and state being auto-detected
even if `--no-config` was passed.
Fixes: df758880e2 ("path: don't override "cache" and "state" paths with configdir")
76276c9210 introduced a generic filtering
framework which replaced the separate video and audio filter chains.
Additionally, 6d36fad83c and
76e7e78ce9 made the decoder wrappers
a filter.
Add a new section to document this, and corrrect the outdated
audio/video decoder and filter info.
replaces the old focus-on-open option with a more generic focus-on
options that can be extended.
adjust the only platform that uses that option.
Fixes#8337
This should only be a problem during initialization. If in a
multi-monitor setup, mpv guesses the wrong scale value and the user
passes --fs, the scaled size will be wrong and you have to unfullscreen
and fullscreen again to fix it. This is because rescale geometry won't
do anything if the value of hidpi-window-scale is false (the default) so
the geometry is never rescaled to the correct value thus the wrong size.
Normally, mpv will just correct itself after subsequent events occur but
because it is considered a locked size (as it should be), we avoid doing
any other resizing events thus it never gets corrected. Fix this by just
always rescaling the geometry in the locked size case. It shouldn't
matter elsewhere because mpv will always have the correct scale value
and the possibility of having the wrong one is only possible on startup.
Fixes ded181f642
These options were deprecated with the addition of the channel layout
API about a couple of years ago*. Unfortunately, we never saw the
deprecation messages so it went unnoticed until they were completely
removed with the recent major version bump. Fix this by setting
in_chlayout and out_chlayout instead if we have AV_CHANNEL_LAYOUT.
Fixes#13662.
*: https://github.com/FFmpeg/FFmpeg/commit/8a5896ec1f635ccf0d726f7ba7a06649ebeebf25
Convenience to override name if imgfmt is not set.
Allows to create mp_image_params without setting imgfmt. Will be useful
for the next change where mp_imgfmt is not available. This is workaround
that will be remved once all codebase switches to pl_fmt.
mpv isn't really a game and categorising our App bundle as game seems
counterintuitive. though as a video player it does have some
similarities, possibly needing considerably CPU and GPU resources and
low presentation latencies.
the macOS Game Mode promises exactly that, it gives App the highest
priority access to CPU and GPU resources and lowers usage for background
tasks.
sadly the Game Mode can only be activated by categorising the App as a
game and that is only possible with an App bundle and not as a command
line tool.
only add the "Show log File…" menu item config when invoked from the
bundle, instead of testing on menu item creation. this is similar to the
touch bar menu items now.
keeping track of the dynamic menu items lets us directly access them by
key. we don't need to search in the config array for the right config
and menu item.
the check broke when the runtime check was removed, eg the menu item was
never added to the menu. since we only add the menu item to the config
when touch bar support is available the check is completely unnecessary.
Not sure if this is particularly useful, but we might as well generate
these as well. Also use the docutils wrapper since that's what the meson
build does.
Some incorrect syntax is used in DOCS/man/input.rst with https://github.com/mpv-player/mpv/commit/c678033c1d60b48ae02fbbe4815869b9504a17f6
causing failure of PDF manual generation with rst2pdf. There are single
rather than double back-ticks for insert-at and insert-at-play so this
is fixed and a couple of typos are also corrected with this commit.
the render size cached in ctx->vo->dwidth/dheight can be outdated in
some circumstances at the time the context needs resizing. instead use
the current render size.
MoltenVK itself tries to work around a supposedly Metal problem that
itself causes flicker, black screens or broken rendering. it sets the
drawableSize to 1x1 to forcefully complete the presentation. though if
1x1 resolution frame is presented it causes a visual flicker or rather
a solid coloured frame. it causes even more problems since sometimes it
does not reset the drawableSize to the proper resolution and keeps
rendering everything in 1x1.
work around this workaround by discarding drawableSize that are <=1 in
any direction.
Fixes#13505
c2129c18f8 saves the button down serial to
pointer_serial of the seat so that it can be used for window dragging
later. However, this overwrites the serial saved at the enter event.
Since the serial in wl_pointer_set_cursor must be the latest
wl_pointer_enter serial number sent to the client, if a button down
serial overwrites that, setting cursor no longer works until the cursor
enters the window next time.
Fix this by using separate serials for these two types of events.
refqueue gets the field of the frame from mp_image which almost always(if not
always) assumes bottom field order first. By default this behavior should not
change but specifying the field order should bypass this.
Previously there was no way to specify the field order of interlaced videos
when deinterlacing with inbuilt filters. Lavfi deinterlacers seemed to prefer
top field order while inbuilt ones (vdpaupp, vavpp, d3d11vpp) seemed to prefer
bottom field order. The default "auto" option should work exactly as before
while specifying either "tff" or "bff" should force the specified field order
It's been a longstanding issue in wayland* that the first frame on a
hidpi screen will have wrong scaling. A well behaved client immediately
corrects this, but it's noticeable and also can affect window placement
due to the way resizng works. Preferred scale from the fractional
protocol and preferred buffer scale can actually solve this problem. It
depends on compositors mostly, but one could simply send the event
before the client maps its surface so it knows what the correct scale is
in the first place. I'm not sure if any compositors currently behave
like this (sway seems to still require the client to render before
sending any scaling information at least), but it makes to sense to
account for this possibility.
*: https://gitlab.freedesktop.org/wayland/wayland/-/issues/133
Ended up being too flawed and caused trouble in other areas. There's
other approaches to trying to solve the issue this meant to address in
the works that should be better, so let's wait on that. Fixes#13613 and
fixes#13622.
This reverts commit e3af545421.
This seems more robust than relying on the audio status to actually be
playing. For files where there is no audio or the audio start is
delayed, this guards against that but it allows the subtraction to
always occur otherwise on normal files with audio.
avif files will commonly be probed as "mov,mp4,m4a,3gp,3g2,mj2" by
ffmpeg, but demux_lavf currently has some logic to skip
avformat_find_stream_info for these kinds of files. It was introduced in
6f8c953042. Presumably, the optimization
of mentioned in that commit is still valid however for avif we
specifically need to do the avformat_find_stream_info call. Without it,
several codec proprieties like width, height, etc. are unavailable. So
just check the extension type and disable the skipinfo optimization.
Explicitly send an UP event after the client finishes a resize for
touch event, don't resize if locked_size is set for touch event,
and use the correct type for resize edges.
VOCTRLs are processed in the GUI thread through the mp_dispatch mechanism.
Window dragging requests are asynchronous on x11 and wayland, so the item
is processed quickly without problem. However, currently win32 uses the
SendMessage call for this, which is synchronous. This causes the playback
to stop while the dragging request is being processed because the
dispatch queue is blocked.
Work around this by setting a flag instead if the window dragging is
requested, and immediately starts dragging after processing the dispatch
queue. This doesn't block the dispatch queue while also avoiding any
extra latency added by the Windows message queue.
5736737750 removed the check because it was
not needed to prevent fullscreen window from being dragged. However, this
causes an undesirable behavior: when using a touch screen to drag a window
on Windows 11, DWM shrinks the window content a bit with an acrylic
backdrop to indicate that the window is being dragged. This also happens
when trying to drag the window in fullscreen. Add the check to prevent
this from happening.
Currently, VO dragging logic is hardcoded into each VO, where a left mouse
button down event unconditionally begins dragging if the VO dragging test
passes. This method is extremely unflexible as the VO has no knowledge of
what is happening in the input system: while begin dragging with the second
click of a doubleclick is undesired, it cannot determine whether a click
is a double click or not because it's determined by the input system.
The better way to do it is to handle it somewhere in the downstream
consumers of the events instead, as they have more information to make
this decision. The input system is the perfect place for this as the logic
for checking doubleclick already exists. So just issue a begin-vo-dragging
command if it detects a left mouse button down which isn't also a
doubleclick in this case, and delete all hardcoded VO dragging logic
in win32, x11, and wayland.
Note that this solution hardcodes left mouse button down for now, but
because the VO dragging is now centralized, it's possible to make more
improvements, such as a deadzone mechanism to fix the conflict with
MBTN_LEFT mouse bind.
This allows begin-vo-dragging command to initialize a vo dragging request
for wayland. The last mouse button press seat and serial is used for the
request if it is not consumed by interactive resizing.
This allows begin-vo-dragging command to initialize a vo dragging request
for win32. Also set dragging to release all keys like for other platforms.
The hard-coded left mouse button down trigger is scheduled to be removed
in a later commit.
This allows begin-vo-dragging command to initialize a vo dragging request
for x11. The last mouse button press event is used for _NET_WM_MOVERESIZE.
The hard-coded left mouse button down trigger is scheduled to be removed
in a later commit.
This command initializes a vo dragging request for VOs that implement
the new VOCTRL_BEGIN_DRAGGING voctrl. This allows scripts to begin vo
dragging for any button press event.
Ended up being a bad idea. As a property, this inherently has more
functionality and the tradeoff of being able to do --ao-volume wasn't
worth it.
This reverts commit 58ed620c06.
0b35b4c917 originally introduced sd_filter
to make a more general subtitle filter infrastructure. But when doing
so, it directly sets ft->event_format to ass_track->event_format in the
struct. The lifetime of ass_track and the sd_filter are not equivalent
which makes it easy to trigger undefined behavior. Notably, commit
cda8f1613f introduced assobjects_destroy
which can destroy ass_track anytime during runtime which means that the
string in ft->event_format is actually freed and should never be used.
Remedy this by simply doing a proper strdup when the filter inits with
ft as the parent so we avoid this scenario altogether. Fixex #13525.
initially we drew on a dedicated render queue to circumvent certain
bottlenecks on the main queue, like concurrent events that could lead
to late drawing.
though due to the way cocoa works we need to draw an the main queue
otherwise we get undefined behaviour that could lead to crashes.
Fixes#10276
The opt validator functions are casted to generic validator, which has
erased type for value. Calling function by pointer of different
definition is an UB.
Avoid that by generating wrapper function that does proper argument type
conversion and calls validator function. Type erased functions have
mangled type in the name.
Fixes UBSAN failures on Clang 17, which enabled fsanitize=function by
default.
Not sure why all of these single line if's were being braced. Probably
some cargo cult from years ago but might as well fix it now since it's
bothering me.
Could have been done in e32554cd57, but I
skipped it there. However, using viewporter is actually a win here.
There's been a longstanding issue in upstream wayland* exactly related
to this. I even forgot about cd7a7a1de8
which was made for this exactly problem and explains the random
spawn_cursor calls. Anyways, just not using buffer scale and instead
scaling the cursor surface via viewporter works just fine and completely
sidesteps this problem. This means we can drop the random looking
spawn_cursor calls and some additional checks.
*: https://gitlab.freedesktop.org/wayland/wayland/-/issues/194
We don't want to use this if we have fractional scaling or version 6 of
the wl_surface interface which has a preferred buffer scale event which
is superior to this. We were checking in the important place (surface
entrance events) but not technically in the output. So just move the
conditional to set_surface_scaling itself. Also through the VO_EVENT_DPI
in there for convenience.
An ass event like `{\p1\pos{1,1}}m 0 0 l -3 -7 l 11 -7 l 11 -2` ends
the drawing mode started with `\p1` due to `\pos` gets confused with
`\p`, and thus that line is wrongly considered to be visible text.
the swift obj-c bridging header is only included when cocoa-cb is
enabled. cocoa-cb is not the only swift feature anymore and disabling
cocoa-cb leads to a runtime error that specific swift classes could not
be found.
include the swift obj-c bridging header in the case swift features are
enabled.
this logic was copied from the cocoa-cb opengl backend, since it was
assumed both layers work similar. apparently they don't and a nil value
on the metal layer means use the display colour profile, while on the
opengl layer it means undefined behaviour.
this also fixes a problem with the target-colorspace-hint option, since
moltenvk needs to set this colour space itself for a proper hint. both
mechanism would compete to set the colour space.
usually the content scale updates automatically, though on init it is
possible the wrong scale is used for the initial rendering leading to a
wrongly sized surface.
properly set the initial content scale of the layer.
cocoa-cb was always pre-allocated in the Application itself because
libmpv needs to be set up before usage, an opengl context has to be set
and because it was decided mac specific code should be kept out of
libmpv.
this means that a completely working libmpv and opengl renderer was set
up even if it wasn't used. leading to unnecessary log message, resources
being used or reserved on the system that might not be used, triggering
of dedicated GPU unnecessarily and many other things.
even if not optimal, this wasn't the biggest problem since we only had
that one working vo on macOS. though now that we have a vulkan
gpu(-next) backend on macOS that was made the default, we always have
that dangling cocoa-cb instance, which is completely unnecessary.
move the cocoa-cb initialisation into libmpv preinit function and only
init cocoa-cb when we are a standalone App and cocoa-cb support is build
into.
When --osd-blur is set to a nonzero value, the graphs also become
blurry. This is because they are rendered by the osd-overlay command
with the "OSD" style which has OSD blur applied, and are treated no
differently from texts. Fix this by using the "Default" style for
these graphs which uses the default OSD options.
The --alpha option currently covers two related but different concepts:
whether or not to ignore the alpha component and possibly blending it
with a background. Because of the way the option currently works, it is
impossible to have a transparent window (which requires setting
--alpha=yes) while blending it with the background at the same time. To
solve this, let's rework it so it it superseded by the background
option.
--background controls what kind of background to set for the image if
possible. It can be blended with the set background color, with tiles,
or not blended at all (the last one is still broken on X11/mesa except
for GLX, *sigh*). In this new paradigm, --alpha=no has no real purpose
because you can simply set the background to color and whatever color
you want for exactly the same effect. So the option is removed. Instead,
the hint set by windowing backends (i.e. setting
ra_ctx->opts.want_alpha) can by done with the --background option.
As an aside, the colors in vo_gpu are currently bugged due to not
pre-multiplying the alpha and it seems no one ever noticed. The next
commit fixes that. vo_gpu_next support happens latter since it requires
new things from libplacebo.
Fixes#9615.
Currently this was being duplicated on init and on runtime updates
between both VOs. Since the conditions for setting this will get more
complicated in the future commits, it's better to just handle it in one
place. We could combine the vo_gpu and vo_gpu_next handling into one
single function but vo_gpu_next has an additional condition for
determining alpha that vo_gpu_does not, so we'll leave these separate
for simplicity. Also this technically fixes a memory leak where gl_opts
weren't being freed.
As it turns out OES_EGL_image is only defined for OpenGL ES.
OpenGL drivers implement this extension anyway because it used to be
the only way of importing EGLImages into GL.
An equivalent extension for OpenGL was defined with EXT_EGL_image_storage.
The only difference is the interaction with immutability, which requires
textures to be recreated since they can be bound only once.
Note: this commit can in theory cause certain systems to lose vaapi / drmprime
support. Since EXT_EGL_image_storage is 7 years old this hopefully doesn't happen.
If it does, the init checks can be relaxed to still permit OES_EGL_image.
We generally try to avoid that due to the #ifdef mess.
The equivalent format is defined in ffmpeg 4.4 while our interop code
requires a higher version, but that doesn't cause any problems.
Beef up the barebones description for the Mitchell filter and make it
consistent with the other --scale examples. In addition to this, make
some wording changes to make the language in the documentation a bit
more unified.
Before this change it was pretty obvious that multiple authors
contributed to this part of the manual (at completely different
timeframes), so the language was somewhat disjointed. The Mitchell
description was also not very helpful.
It's actually been like this for years, but wlroots doesn't keep track
of resizes a client does independent of the compositor. When using sway,
this leads to weird behavior with floating clients resizing themselves
back to the old size if you unfocus it. mpv has been working around this
for a long time, but it's really annoying to selectively ignore events
based on a weird heuristic. Since Sway finally fixed this bug, let's go
ahead and drop this crap. Note that other wlroots compositors may
possibly experience a regression if they didn't correct for this like
sway does, but it's for their own good.
This came up in #13571. playing_audio_pts does not include mpctx->delay
contray to what that implies. The function is meant to only offset the
written audio pts by whatever the internal AO buffer may be.
mpctx->delay is a combination from both the audio and video code, so it
should not be used here. What is wanted is purely the audio pts.
b74c09efbf, a very controversial commit to
say the least, was what introduced this comment, so removing is probably
OK.
Playback speed changes should be treated as a discontinuity just like
seeking. Previously, this was being treated internally as just plain
normal playback, but that can't really work. The frame timings from
before the speed change and after the speed change are completely
different and shouldn't be compared to each other. This lead to frames
being adjusted to weird places and possibly even being skipped (as if
mpv was seeking) on speed changes. What we should do is clear out and
reset all av related fields like what happens when you seek, but it is
not quite as aggressive. No need to do a full video state reset or such.
We also wait an arbitrary amount of frames before adjusting for av sync
again. compute_audio_drift already used a magic number of 10 which
sounds reasonable enough so define that and use it here. Fixes#13513.
When calculating the audio pts, mpv multiplies the ao delay by the
current audio speed and subtracts it from the written audio pts. This
doesn't really make sense though. mpctx->video_pts is never affected by
the playback speed, and this leads to weird behavior like the audio-pts
property changing values while paused merely because the playback speed
changes. Remove the multiplication and simply subtract the delay by a
factor of 1 instead. When updating the av_diff in player/video, this
does actually need to take in account the audio speed so we do the
calculation there.
This uses an alpine 3.15 container, which should be one of the oldest
distros that mpv master can compile on and that uses ffmpeg 4.4. Some
functionality is missing due to library versions being too old on
alpine, e.g. wayland, mujs, and pipewire.
The alpine build is also explicitly minimal, to test builds in
conditions where many common mpv features may not be available.
All other ao options are documented there so make ALSA the same.
Also remove the (Linux only) wording since some systems (e.g. FreeBSD)
provide compatibility layer for it.
While making this larger do make audio filters react slower, it doesn't
always make softvol react slower. This is because the softvol reaction
speed is related to the ao buffer size which on many systems have an
upper limit, typically much lower than 200 ms. In this case the softvol
won't react slower. Change the wording to clarify this.
98a27b3cd1 changed this to mpv but that's
kind of pointless since the binary is already named mpv so that will be
the default thread name. Evidently, people rename/symlink the binary to
something else so might as well make them happier. Fixes#13469.
Change the `playlist_insert_next` function to `playlist_insert_at` (ie,
insert at the location of an entry, rather than after it, and rename to
be clearer that it doesn't have anything to do with the
currently-playing entry).
Also, replace calls to `playlist_add` with calls to
`playlist_insert_at`, since the former has become redundant.
This commit adds a DND_INSERT_NEXT action option for drag-and-drop,
allows for selecting it through the --drag-and-drop=insert-next option,
and adds the necessary plumbing to make that happen when something is
dragged onto the player.
Analogous changes to the previous commit ("add loadfile insert-next commands"),
but for the `loadlist` command.
This allows us to insert a new playlist next in the current playlist,
rather than just appending it to the end.
This commit adds two new commands (`insert-next` and `insert-next-play`)
which mirror the existing commands, `append` and `append-play` in
functionality, with the difference that they insert directly after the
current playlist entry, rather than at the end of the playlist.
This change gives MPV a piece of functionality already found in (for
example) Spotify's media player: "play next". Additionally, using the
new `insert-next` command, users can trivially write a script to play a
new piece of media immediately without otherwise clearing or altering
the remainder of the playlist.
Currently, the softvol gain control attempts to clip floating point ao
formats within -1 and +1. However, this is "optimized out" at unity gain,
where no clipping is applied. This results in inconsistent behavior when
the source audio is already out of -1 and +1 range, where a gain of 0.99
results in clipping, but not at exactly 1.
Since a big advantage of floating point audio data is that they do not
lose information through out-of-range data because the ao sink can apply
suitable negative gain to prevent clipping before converting them to
integer formats, clipping should not be performed on these data.
Fix this by removing the existing clipping behavior. It now results in
a simple multiplication, which faciliates compiler auto-vectorization
of this operation over audio data.
unlink() was never wrapped in win32, so all usages of it were referring
the ANSI version of the function. This doesn't work properly for Windows
versions before 1903 (where the UTF-8 codepage is requested).
Fix this by adding mp_unlink() which wraps over _wunlink().
LRC subtitles can have lines with multiple timestamps, e.g.
[00:00.00][00:02.00]foo
[00:01.00]bar
Currently mpv shows only the "foo" that was decoded first, because it
compares the packet file position to check if a packet was already seen,
and it is the same for both occurrences of "foo". Fix this by also
comparing the pts.
This keeps comparing the packet position on top of the pts to not break
subtitle lines with the same timestamp, like:
1
00:00:00,000 --> 00:00:01,000
foo
2
00:00:00,000 --> 00:00:01,000
bar
where mpv shows both lines on top of each other. They are common in ASS
subtitles.
Fixes https://github.com/mpv-player/mpv/issues/13497.
This has defaulted to yes for a very long time, but evidentally it
annoys a lot of people (including myself). My argument is that this
makes no sense. mpv is for videos; not text. A 1920x1080 video should
open as 1920x1080 regardless of whatever the DPI settings of the OS is.
This can get very silly when you consider watching a 4k video which will
get this additional scale factor which is virtually never desirable.
Whether or not the OS and/or WM prevents it from getting larger than the
screen depends on a lot of things.
Previously some windowing backends required that this option be set to
yes in order to report a dpi scale value other than 1, but this should
be fixed with the previous commits. The only difference is whether or
not to scale the window by the additional factor.
Fixes#13465.
Wayland was the only backend that attempted this, but it can be done in
a centralized place for anything that supports this. hidpi-window-scale
is just the same as a normal window scale but with the OS DPI as the
factor.
Several related things but in a nutshell makes it more like wayland.
1. Remove unneeded --hidpi-window-scale checks. The backend should
always report the actual dpi value regardless of what this option
says.
2. Remove dpi_scale factors from UNFS_WINDOW_SIZE VOCTRLs. It makes
things more complicated and unintuitive for no reason. A window scale
of 1 should mean 1. It annoyed a few years ago in #9437, and I agree
with them (wayland was never implemented like this).
3. Change the dpi log messages to be more brief and remove the unneeded
comments about prescaling.
Previous fix only worked when the video output doesn't have vertical
black bars. This fixes the cases like fullscreen, video-zoom etc.
Fixes: https://github.com/mpv-player/mpv/pull/13528
before errors and outputs where ignored from the subscript and the main
script didn't fail nor did it output anything.
with this change the script properly outputs everything to stdout and
stderr. in the case the dylib script fails the whole script fails now.
the main function in dylib_unhell was kept since it can still be used
individually without the oscbundle script. the script had to be renamed
with an underscore to make it importable.
Currently, running AO control wakes up the WASAPI renderer thread in the
`WASAPI_THREAD_FEED` state, where `thread_feed` will be called. However,
it seems that in recent Windows versions (tested on Windows 10 build
19044.3930 and Windows 11 build 22631.3007) we can't know if it is safe
to feed more audio data in event-driven exclusive mode:
- `IAudioClient_GetCurrentPadding` always returns `bufferFrameCount`,
even if *NO* data has ever been written. This means we don't know how
much free space we have that is available for writing. This is not the
case in shared mode, where the return value correctly reflects the
size of data waiting to be processed. As a sidenote, MS did not
document the precise definition of the return value for an
event-driven, exclusive stream [1].
- `IAudioRenderClient_GetBuffer` never fails. We can call it for 10
times in a roll, each time requesting an entire buffer (the unit at
which data is exchanged in exclusive mode using event-driven
buffering; there are 2 such buffers) and get a successful return code
everytime. In shared mode, we get `AUDCLNT_E_BUFFER_TOO_LARGE` if we
request a buffer larger than that currently available.
As a result, `thread_feed` will always write `bufferFrameCount` frames
of audio in exclusive mode. There will therefore be glitches each time
`thread_control` is called due to the subsequent `thread_feed`
overwriting frames yet to be processed. Also, an irreversible error is
accumulated to `sample_count` as long as there is no AO reset, leading
to eventual, unbounded A/V desync.
As a fix to the issue, add a dedicated state for dispatch queue
processing so that `thread_feed` is only called when signaled by the OS.
The buffer checks in `thread_feed` that use `GetCurrentPadding` in
exclusive mode are kept in case there are older versions where the two
APIs behave differently.
Closes#12615.
[1] https://learn.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudioclient-getcurrentpadding
With --ignore-path-in-watch-later-config,
--write-filename-in-watch-later-config still writes the absolute path of
files in the comment, even though the hash is calculated from the
basename. Make it write the basename to avoid confusion.
Also stop writing redirect entries for parent directories with
--ignore-path-in-watch-later-config, both because it's redundant, and
because with this patch it would write the basename of directories in
the comment, which would be wrong because their hashes are calculated
from the absolute paths.
There's too many dumb options related to subtitles which have annoying
edge cases. Try to rewrite this completely so it hopefully behaves
normally in every expected scenario. A key goal here is be smarter while
looping through the tracks and avoid selecting the subtitle if it
doesn't meet user's passed options as opposed to clearing the pick after
the fact. Fixes#13280 and fixes#13263.
When using sub-seek without a video track while paused, adding the 0.01
SUB_SEEK_OFFSET to the new timestamp is not enough to show the new
subtitle line. Add 0.1 instead to fix it. 0.01 is already enough for
sub-step.
The purpose of osdep/io is to provide a wrapper for POSIX I/O functions
on Windows. The last 2 functions are utility functions which don't serve
this purpose.
Move them to a separate file.
fopen() with 'x' mode is a non-portable glibc extension, is currently
unused, and should not be used in order to maintain POSIX compatibility.
Thus there is no need for the Windows wrapper mp_fopen() to support it.
When doing the dithering pass, the fragment coordinate is queried, but
doesn't take the fbo texture flipped property into account. This results
in different dithering patterns when toggling between fbo flipped and
non-flipped state. This can be reproduced with --vo=gpu --gpu-api=opengl
and easily seen with --dither-depth=1 when toggling between playing and
pausing.
Fix this by flipping the fragment y coordinate if the fbo is flipped
when calculating dithering coordinate.
When redrawing cached frames while the fbo texture is flipped,
the texture after drawing to screen pass will be flipped when blitting.
However, when rendering the checkerboard, the fragment coordinate
doesn't take this into account, so the coordinate before flipping is used,
resulting in different checkerboard location when toggling between
flipped and non-flipped state. This can be reproduced with --vo=gpu
and --gpu-api=opengl: the checkerboard patterns when playing and
pausing are different (vertically flipped).
Fix this by flipping the fragment y coordinate if the fbo is flipped
when calculating checkerboard coordinate.
Begin the _NET_WM_MOVERESIZE window dragging in ButtonPress event
to match the behavior of win32 and wayland, simplify logic by dropping
the win_drag_button1_down hack required by the old method, and fix a race
condition described in commit 19f101db68,
which happens when moving the mouse and releasing the button at the same time.
The race condition can be easily triggered when using a touch screen
(tested with libinput driver), where a tap is translated to MotionNotify,
ButtonPress, MotionNotify, and ButtonRelease in sequence, with the last 2
events having the same timestamp. This has caused some window managers to
not stop dragging after the ButtonRelease, resulting in window being stuck
in dragging state after a single tap.
There are good reasons to bind Ctrl+WHEEL_UP/WHEEL_DOWN to video-zoom:
- They are ubiquitous and familiar key bindings to represent zooming
operations, which are used in all popular web browsers, document viewers,
and document editors.
- Because WHEEL_UP/WHEEL_DOWN are scaled with high-resolution scrolling
input devices like touchpads, this allows smooth zooming.
- This makes "pinch to zoom" with touchpads and touchscreens work out of
box on Windows, since by default applications receive these key inputs
for pinch gesture.
- It had been considered to bind these keys to window-scale instead.
However, this results in horrible UX as the keybinds work only when the
mouse pointer is over the mpv window, and if the window shrinks during
this operation, the window below mpv now receives these keybinds,
resulting in unwanted zooming for that window, which violates the principle
of least surprise.
this partially reverts commit 7b5a258. back then the only properly
working vo on macOS was cocoa-cb (libmpv). it would always use the
deprecated opengl cocoa backend or no vo at all. because of that libmpv
was moved to the top of the auto-probing order, so the preferred vo
was used on macOS only.
we now have a working vulkan gpu/gpu-next backend on macOS which should
be the new default vo. though disabling the auto-probing again for
libmpv would probably cause the undesired behaviour on macOS that
cocoa-cb would never be auto selected again. especially if not build
with vulkan support or without vulkan driver on macOS, this would lead
to no video output at all. so instead of completely reverting the
mentioned commit, we instead move libmpv to the bottom of the
auto-probing order but only auto select it when mpv was built with
cocoa-cb support. this restores the previous behaviour on all other
platforms besides macOS, but also lets us auto select cocoa-cb if
supported.
this fixes a crash on quit, when a CATransaction from a system owned
thread/event is happening at the same time. locking the context
synchronises these access and prevents the race condition.
the draw operation induced by any display call from the CAOpenGLLayer
doesn't need that lock, since the display function already does lock
that current context.
Fixes#11681
Homebrew finally pulled the plug on lua 5.1*, and it is no more. So we
have to change to a different lua package and the only other choice is
luajit (no 5.2 in homebrew). We used to use luajit for the ci, but
649556b2b6 switched it to lua 5.1. As
explained there, luajit 2.0 was horribly bugged and not usuable for mpv
and the build had to do dumb hacks to work around it. I expected 5.1 to
last a bit longer than a couple of years, but luckily it seems like
luajit in homebrew now pulls a luajit 2.1 version (some rolling release
thing or however upstream works). The details don't really matter for
us since 2.1 does not have all the awful issues that 2.0 used to have.
So just switch to luajit again.
*: https://github.com/Homebrew/homebrew-core/commit/57d73df3ba924c870f4b6d36080e7cb37275367e
Since 03cf150ff3, the only purpose of this
VOCTRL was to signal a redraw to the vo. It actualy could have been
removed in 531868fe0d, but this was
missed. The UPDATE_VIDEO flag is better anyway because it allows us to
handle a wide variety of options scattered around that require the VO to
update itself and redraw. We can remove both of the custom callbacks in
vo.c and only leave the VOCTRL_VO_OPTS_CHANGED one. Additionally, that
commit also introduced vo_set_want_redraw, but this is redundant and not
needed. The VOs that use VOCTRL_UPDATE_RENDER_OPTS already set
vo->want_redraw, and those are the only VOs where these options are
relevant in the first place. So we can remove this as well and just let
the big callback in player/command do everything.
It's only necessary to check the existance of cursor_shape_manager.
Also drop the pointer check to handle multi-seat since a removed seat
sets the cursor_seat to NULL.
For VOCTRL_SET_CURSOR_VISIBILITY, set cursors visibility for all seats.
The return is VO_NOTAVAIL is none of the seats have cursor, and
VO_FALSE if setting visibility failed for at least one seat.
The cursor_shape_device is per pointer, which is per seat. Handle it
together with other seat objects. This in turn also handles cursor
visibility per seat.
On a multi-seat setup, wl_registry_global advertises wl_seat multiple times,
one for each seat. if wl->seat is already set, the previous value will be
overwritten, preventing it from being freed.
Additionally, if the latter seat doesn't have the capabilities of the
former seat, the keyboard/pointer/touch input devices will be destroyed
because the current wl_seat_capabilities doesn't distinguish between
different seats. This casues keyboard/pointer/touch not working if the
latter seat has no such capabilities.
Fix this by implementing multi-seat support.
This allows receiving inputs from all devices on all seats.
All seat-specific objects (wl_keyboard/pointer/touch, wl_data_device)
are grouped with their respective seats so they can be managed together.
Note that currently inputs from all seats are interleaved with each other
and modify the same global input states.
If libplacebo manages to create a vulkan swapchain that allows
alpha composition mode to be controlled by the DWM API,
this makes it runtime changeable.
Specify cAlphaBits in PIXELFORMATDESCRIPTOR makes the pixel format
transparent, as is already the case for d3d11. Also makes the
window transparent when --alpha=yes is used.
Works on --vo=gpu and --vo=gpu-next.
25b66256d7 originally added this
property, but it did not add it to the property notification. This is
possibly because the window id doesn't appear to change on x11 even when
toggling VOs at runtime. However, windows uses this property and
apparently the id changes there so we should signal updates when
appropriate. Fixes#13495.
On wayland, depending on the wl_output protocol version used,
the display-names property can have different values. Mention
this in the documentation, like for other platforms.
Previously, libplacebo would fail to render the image since mpv was
feeding it bogus bitmaps with 0 width/height. An easy way to encounter
this would be to set sub-scale to 0 with bitmap/image subs.
Document the use cases for enabling or disabling the wheel preprocessing.
Also note that this option has no effect on any filtering already done
by the OS/driver.
This adds --input-preprocess-wheel option, which can be used to control
whether to preprocess received wheel events.
Commit 937128697f added preprocessing of
wheel events to prevent the accidental scrolling of another direction
when one direction is being scrolled for touchpads, which is problematic
with the default wheel bindings where unrelated functions (seeking and
volume) are used for the 2 directions.
However, this behavior is undesirable in the following situations:
- When custom wheel bindings are used so that the 2 directions are used
for closely related actions, such as panning. With preprocessing,
diagonal movement is impossible.
- Since the wheel deadzone was introduced to prevent accidental scrolling
for touchpads, this filtering provides no benefit for high resolution
unidirectional mouse wheels, while causing a regression where scrolling at
least 0.125 units is required to trigger the event, causing input delay.
By adding this option, these two use cases are addressed.
The current documentation lacks clarity regarding the interaction
between the `repeatable` and `complex` options. Through an analysis
of the source code (`player/lua/defaults.lua` and
`player/js/defaults.js`), it was observed that the `repeatable` option
is only meaningful when the `complex` option is not enabled.
Additionally, the `complex` option in the existing documentation is
confusing, actually `fn` can be called on key repeat when `complex` is
`true` and `repeatable` is not `true`.
To address these issues, the documentation for the `repeatable` option
was updated to specify that it only applies when the `complex` option is
not set to `true`. Furthermore, the description of the `complex` and
`event` were revised to acknowledge the occurrence of key repeat events.
It is possible to have data with empty block that contains additions. In
which case the block would not be added and the additions would leak.
Found by fuzzing.
This is technically due to the previous commits that made subtitle
rendering more efficient by eliminating redraws, but working around this
particular edge case is useless. The sub-clear-on-seek option was
originally introduced in d5940fabcd and
specifically is a workaround for completely broken mkv files. There is
no reason to use it otherwise. Because that option disables all
duplicate checking and the previous commits rework subtitle rendering in
the still image case to be dependent on keeping track of packets, the
end result is that you will get the same line rendered multiple times.
However the important case of broken mkv files with duplicate ReadOrder
fields still work just fine with --no-video. So instead of bothering
trying to make this option "work", just clarify that stuff can break
since, again, there's no reason to use it other than as a workaround for
broken files.
The previous commits optimized sub redrawing on still images/terminal so
mpv wouldn't redraw so much. There is a gap though. It only assumes
static subtitles. Since ASS can be animated, those types of subtitles
will always need redraws so we need to build in specific detection for
this. We need to build a whitelist of events in ASS that are considered
animations and then flag the packet. Additionally, there's a bunch of
annoying bookkeeping that has to be done since packets can be dropped on
seeks and so on.
This only affects two special cases: printing subtitles to the terminal
and printing subtitles on a still picture. Previously, mpv was very dumb
here and spammed this logic on every single loop. For terminal
subtitles, this isn't as big of a deal, but for the image case this is
pretty bad. The entire VO constantly redrew even when there was no need
to which can be very expensive depending on user settings.
Instead, let's rework sub_read_packets so that it also tells us whether
or not the subtitle packets update in some way in addition to telling us
whether or not to read more. Since we cache all packets thanks to the
previous commit, we can leverage this information to make a guess
whether or not the current subtitle packet is supposed to be visible on
the screen. Because the redraw now only happens when it is needed, the
mp_set_timeout_hack can be removed.
Previously, mpv only saved a strict limit of two packets while decoding
subtitles, but it is a bit incomplete. Firstly, it's certainly possible
for there to be more than two subtitles visible at once. And also, it
did not take into account preloading. Rework this mechanism so that it
is a growable array that can store as many packets as we want. Note that
in this commit, the packets are only ever discarded on reset or destroy,
so in theory it could grow forever. Some discarding logic will be added
in the next commit since it is inherently tied to other things.
This avoids clearing the queued frame and the currently displayed one on
VO reconfiguration requests that happen when new frames arrive. Instead,
let those frames be fully displayed.
Fixes mf:// playback issues introduced after commit ef11d31.
Instead of removing the frame timing check embrace and fix it to wake up
the playloop as needed. The frame display duration is problematic to
handle as both VO and playloop thread would already be sleeping, but in
certain use cases it is needed to display frames in full, so in this
case, let the VO sleep to the end of frame, wake up the core as
requested and go back sleeping.
Note that this patch series reintroduces 0c9ac5835, which is esenitally
fixed in this commit. It is still not perfect, but it is better than
just busy waiting on playloop, even if those events when this would be
needed are quite rare.
the observer is registered on every call of the start function. this
could lead to several registered observers for the same event and
several calls to the make current function, even though we only need it
once per event.
properly remove the observer on stop, so we only ever have one observer
registered.
* Range of accepted values for teletext_page now include 0 and -1.
* 0 means "subtitle" and -1 means "*".
* Make 0 the default.
Signed-off-by: Mohammad AlSaleh <[email protected]>
With 1.3.277 the AV1 decode headers have been upstreamed.
These get preferred over ffmpeg's internal non-standard header
for this extension (same name). FFmpeg currently only builds
using its own header and a patch to work with upstream ones
is in review.
For now pin vulkan at the version before that to unbreak our CI.
This will prevent building demos and link statically with libplacebo by
default if system libplacebo is not found or isn't new enough and a
sufficiently new enough libplacebo exists in `subprojects/libplacebo`.
Since 1f8013ff3f, if you release a modifier before a regular key on
Wayland, that key gets immediately pressed again because
keyboard_handle_modifiers() calls mp_input_put_key() regardless of
whether a modifier is pressed or released, e.g. if you press Ctrl+s it
easy to take an another screenshot with s by accident. Fix this by
releasing keys when releasing modifiers.
Ideally, releasing the modifier should input the key alone after
--input-ar-delay, while this patch disables it forever, e.g. on X11 if
you type something in the console, hold Ctrl+h, and release Ctrl, it
starts typing h instead of deleting characters. This doesn't work
because keyboard_handle_key() is only called when you first press a key,
while on X11 KeyPress keeps getting sent as you hold down the key. But
this difference in behavior between X11 and Wayland can also be
reproduced with GTK and Qt applications, so I guess this is acceptable.
When the mpv surface leaves the output, we no longer mark it as the
current output. However, this implicitly depends on there being a
preceding surface entrance event to a different output. This is not
necessarily the case. Consider moving the window from monitor 1, to
monitor 1-2, and then back to 1 again. mpv gets the entrance event to
monitor 2 and sets that as the current output to work off of. Then when
you move back to only monitor 1, it removes monitor 2 from the current
output. However, monitor 1 is not updated again as the current output
because there is not a new surface entrance event in this case (the
window never left). So the numbers that mpv's core is using are
incorrect and for the wrong monitor. Luckily, we already keep track of
what outputs the mpv surface is currently on no matter how many there
are so it is simply a matter of setting current output again in the
leave event if we have a different output that has the mpv surface.
Ref: https://github.com/swaywm/sway/issues/7932
Before 3250f6e447, secondary subtitles
didn't work properly with sd_lavc at all. They would render but be in
the same position as the primary subtitles. sd_ass used SD_CTRL_SET_TOP
to specifically place secondary subtitles in a different spot, but it
was unused by sd_lavc. With that above mentioned commit, it became
possible to distinguish between the position of primary and secondary
subtitles via mpv's option system. sd_lavc was missed however because at
the time we simply didn't realize this could work and was actually
simple. With some subsequent refactoring that happened later, the fix is
to just use the correct sd->order when accessing the shared subtitle
options instead of hard coding 0. Fixes#13440.
Move common_prefix_length() and related functions before the first call
to common_prefix_length(). It works now because it's global but if we
ever make all functions local for consistency it will stop working.
When mp_output_chain_update_filters() fails, talloc_free() is called on
each mp_user_filter. But because the structure doesn't have a talloc
destructor, the args aren't freed, resulting in stale references.
Fix this by calling the destructor of the wrapped filter instead.
Deinterlacing required that the user set it on/off themselves, but we
actually have handy flags for detecting if a frame is interlaced. So
it's pretty simple to make an auto option using that. Unfortunately,
life is not quite that simple and there are known cases of false
positives from the ffmpeg flags so we can't make auto the default value.
However, it still may have some utility for some people, and the
detection could potentially be improved upon later. Closes#10358.
This reverts commit be0a979a0b.
The list of images codecs is no longer used by demux_mkv.c because
26a51464b6 made it check the number of blocks instead to not misdetect
animations in image codecs, so move it back to demux_mf.c since it is
its only user, so it is easier to understand how it is used, keeping the
jxl addition from e9d0a31dfe.
vo_rpi and its related code has pretty much historically been a
disaster in mpv. The build regularly gets broken and since nobody uses
it, it takes months for anyone to notice. There was also that time where
fullscreen was broken for about a year and a half. Also building in waf
was entirely broken for about a couple of years or so due to mysterious
reasons no one ever figured out (meson magically fixed it).
Anyways, once again the build is broken due to rpi being forgotten about
again, but instead of pretending to support this crap. Just drop it all.
Nowadays, mmal hwdec is a relic since these devices are better off using
the v4l2m2m ffmpeg fork instead which actually uses KMS properly. RPI 1
and 2 probably can't do this and will remain broken but oh well blame
Broadcom for being special snowflakes and not using standard APIs (my
rockpro worked out of the box; just saying). RPI 2 is nearly 10 years
old anyways, so I think you can afford a new SBC by now. If we were
nicer, there would be a deprecation period, but this is broken in the
last major release anyway so too late.
Closes#13402.
As mentioned in [0] the suffix "_locked" would have been the appropriate
naming in line with similar uses inside mpv.
See `mp_abort_recheck_locked()`, `mp_abort_trigger_locked()`,
`retrigger_locked()`, `wakeup_locked()`...
[0] https://github.com/mpv-player/mpv/pull/12811#discussion_r1477518525
When adding things like brightness or gamma, the video obviously needs a
redraw if paused. This happened to work in the normal case because the
OSD notification triggered a redraw, but if you use no-osd the picture
won't change. Fix this by adding another option flag, UPDATE_VIDEO, and
simply signalling we want a redraw. This gets handled along with the
normal osd redrawing check in the playloop so something like "no-osd add
gamma 1" actually works.
df764bc0c3 and
c82c55b4b9 blindly converted the units for
this VO since neither of us actually have the hardware/setup to test the
VO. Well it was not actually correct (maybe just one was wrong or both
who knows) since vo_vdpau using timing very differently than all the
other VOs and no one reported on it until just now. Anyways, just apply
this random patch from @DanOscarsson which apparently works for him and
call it a day. Fixes#13397.
This can be used to auto reload the input configuration file, e.g. in
vim:
autocmd BufWritePost ~/.config/mpv/input.conf silent !echo load-input-conf %:p | socat - /tmp/mpvsocket
Partially fixes#6362.
Additionally this can be used as a replacement for deprecated input
sections if they are ever actually removed. For example, if you want to
define different bindings for images, you can load-input-conf an
input.conf for images, and load the original again when switching to a
video. Though currently you would have to redefine builtin bindings that
were overwritten with image ones in the default input.conf.
Unlike set include mpv.conf, this works after playback has started. It
can be used to auto reload the configuration, e.g. in vim:
autocmd BufWritePost ~/.config/mpv/mpv.conf silent !echo load-config-file %:p | socat - /tmp/mpvsocket
Partially fixes#6362.
Since the scroll event handler is moved to wl_pointer_frame, version 5 of
wl_seat is required. Warn that scrolling is broken if the compositor
doesn't support that verison.
Commit f54ad8eb05 broke high resolution
scrolling because one logical mouse click is generated for every scroll
event, no matter the magnitude. This makes scrolling on trackpad way
too fast.
Revert the axis scaling change in that commit and clamp the resulting
value between -1 and 1 to make sure mouse wheel scrolling works as
intended on compositors which send a value larger than 10 for these events.
Some X11 window managers support controlling the title bar independently
from other window decorations with _MOTIF_WM_HINTS. This allows hiding
the title bar while keeping other decorations like the resizing borders.
Let mpv respect the --title-bar option on X11 so --no-title-bar can hide
the title bar only like on win32.
4709a94aec along with some related commits
added a way to detect image codecs embedded into mkv streams that
weren't tagged with attached picture (arguably a broken file anyways,
but maybe not the worst thing to workaround). Unfortunately, this has
some false positives particularly with mjpeg playback. So, as usual,
revert and rewrite. Instead, we can probe the file and count blocks in
the stream. If the video stream has only 1 block and 1 timecode, then
assume it's a still image.
Save the cache to separate files to avoid loading/saving a huge combined
libplacebo.cache. This approach allows the saving of only new cache
objects and avoids resaving the entire cache, especially even if only a
tiny change was made.
This commit improves the cold start time of mpv and avoids saving data
when it's not necessary.
Number of changes were made:
- each cached object is saved in its own file
- cache files are prefixed with the name of cached object
- cache directory is cleaned on each uninit
- the least recently used cache files are removed if cumulative cache
size is above limit
- files used in the recent 24 hours are not removed to allow changes
to mpv.conf without worrying about the cache being removed during
experimentation
- shader cache size limit is set to 128 MiB
- icc cache size limit is set to 1.5 GiB
- cache objects are loaded/saved as needed
This commit eliminates the runtime performance penalty associated with
the size cache. While we continue to maintain the cache limit to prevent
retaining stale objects, mpv now only loads a small subset of files that
are currently required for playback, instead of loading all files.
Using the 'terminal-default' log level a client can request
to get all messages that would normally appear on the terminal.
8c2d73f112 changed the size of the
relevant buffer to 100 lines, which was prone to quickly overflowing
once you enable verbose or debug output.
This size is kept for the early terminal buffer but now enlarged
once a client actually requests this log level. This fixes the overflow
risk while not consuming more resources if this feature is unused.
32-bit signed integer can hold ~2.1s stored as nanoseconds. While frame
duration doesn't make sense to be this long, the existing clamp is to
10s. Change type to double, which is consistent with other fields in
vo_frame.
Previously, all scaling was forced to 1 with this vo and all coordinates
were calculated as if the scale was 1. This works since viewport relies
on the compositor completely for scaling so it doesn't really matter if
we don't draw directly to the correct size since the compositor will
just scale the rest for us. This does have some downsides however since
the OSD text might not be drawn at the actual resolution of the final
size of the video.
We can instead handle this by getting rid of the dmabuf_wayland specific
scaling logic and using the same values as everything else. In the
resize in vo_dmabuf_wayland, we just need to adjust the viewport
destination calls so they go to the wayland local coordinates and not
the physical ones. This should ensure that vo_dmabuf_wayland directly
goes to the desired size and the compositor doesn't need to operate on
it after the fact.
If the scaling value changed for some reason, the window geometry would
be recalculated with the new scaling even if this option was disabled.
Properly ignore it.
The core wayland protocol way of handling scaling is to use the
buffer_scale mechanism. But this sucks in several ways for reasons I
won't list here and fractional scaling rightly avoids this altogether
and uses a buffer_scale of 1 (i.e. not setting it) along with
viewporter. When originally implemented, this was only specifically used
when the fractional scale protocol was available, but we actually can
use it as a full replacement instead. This means that mpv now hard
requires viewporter, but this protocol is supported by everyone and is
one of the few that is actually stable.
How it works is the same regardless of fractional scaling or not. When
the compositor has a scale value not equal to 1, it will always scale
the client by that factor (unless you set buffer_scale). What we do here
is pass a viewporter size that exactly undos the compositor-side scale
(sans a possible rounding error). So what we are left with is just the
exactly physical pixels we want to display. Fixes#13316.
7b8a30fc81 made it possible for a VO to
have direct ownership of frame objects since the it may be beneficial
for the frame to follow the lifecycle of that particular VO instead
(i.e. the wayland compositor for dmabuf-wayland). But when frames are
dropped, this always has to be unconditionally freed since the VO isn't
aware of it. Fixes#13364.
It is expected. Last argument of validate functions is always a pointer,
but not always void* which triggers UBSAN warning.
meson since 1.3.1 halts on UBSAN errors in tests, which is good thing.
Fix DTS passthrough playback of 44.1 khz content. Also, take into account that there are some DTS variants with a samplerate of 96khz (e.g. DTS 24/96), somehow they are recognized wrongly as 48khz by the code. Don´t rely on this "bug", do it correctly. Now every samplerate above 44.1Khz is correctly treated as 48khz, and 44.1khz files are treated as 44.1khz for bitstreaming.
This workarounds the issue with vo_gpu that would freeze in certain
condition. I haven't go deep inside to understand why, so this should be
considered as a workaround.
Fixes: #13256
This reverts commit cb2b579f61.
This breaks files where the audio starts much later after the video
since mpv reads the first audio packet even if it isn't supposed to
start yet, resulting in the audio_status being STATUS_READY for the
entire time mpv is "waiting" for the first audio packet to be played.
I don't actually deinterlace ever but allegedly this is better than
yadif, and there's no real reason to not have this be the fallback
deinterlace when we're not using hw frames. Also change various mentions
of yadif to bwdif. Ref #12835.
This prevents mp_msg_flush_status_line() from printing an unnecessary
newline when changing file after setting --really-quiet at runtime. If
mpv is backgrounded, this newline garbles the output of TUI programs.
With this change the cursor is not re-enabled after setting
--really-quiet at runtime and quitting with mpv in the foreground, so
enable it on uninit.
If a track's language was guessed from its filename, the commands that
reload the track, like sub-reload, remove it. Fix this by calling
guess_lang_from_filename() again.
Note 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.
This displays the current GPU context when --vo=gpu or --vo=gpu-next
is used, which shows the platform and backend information of the vo
which are previously not available.
This exports `current-gpu-context` property, which is the string
description of the current active GPU context. This allows scripts to
uniquely identify the platform and backend used for --vo=gpu
and --vo=gpu-next.
The lingering cache needs to be cleared so the packets don't stay
forever on the screen past their welcome. Do this by simply refreshing
the stream. Fixes#13148.
mp.observe_property('foo', nil, ...) calls the handler at least 2 times
on each playlist change even when the property doesn't change. This is
dangerous because if you haven't read observe_property's documentation
in a long time this is easy to forget, and you can end up using it for
handlers that are computationally expensive or that cause unintended
side effects.
Therefore, this commit discourages its use more explicitly in the
documentation, and replaces its usages in scripts.
For console.lua, observing focused with type nil leads to calling
mp.osd_message('') when changing file while playing in the terminal with
the console disabled. I don't notice issues from this, but it's safer to
avoid it.
For playlist and track-list this doesn't really matter since they
trigger multiple changes on each new file anyway, but changing it can
avoid encouraging people to imitate the code.
One usage of none in stats.lua is kept because according to b9084dfd47
it is a hack to replicate the deprecated tick event.
When the mouse cursor is hovering over the (CSD) windowcontrols title,
the osc keeps displaying, but the cursor autohide isn't disabled like
other visible regions.
Fix this by disabling the cursor autohide in this region.
All other existing behaviors of the mouse cursor in this region
are unchanged, including triggering main window area input
and allowing VO dragging.
Quickly going through a directory with too many loadable files causes the
autoload tasks to pile up and exiting the player will take forever. Avoid
this by skipping loading when playback is aborted.
This adds volume-gain, volume-gain-max, volume-gain-min options, which
can be used to control audio volume and target dynamic range in decibels.
The gain is applied on top of the existing volume setting.
f9cefbfec4 made it so mp_ass_flush_old_events() is continously called on
subtitles with unknown duration, without explaining why, breaking
sub-seek/step -1 with a VO (the issue does not occur when showing
subtitles in the terminal because get_bitmaps() is not called). I don't
experience any issue after removing the call, so delete it to fix these
commands.
After removing that, you can sub-seek -1 once after regular playback,
but not after seeking and thus not multiple times in a row. This is
caused by a714f8e928 which fixed subtitles with unknown duration being
duplicated when seeking with a VO (it does not happen in the terminal)
by clearing old lines on seeks, which broke sub-seek -1 and sub-step -1
in a second way after any seek. The proper fix is to remove the line
ctx->num_seen_packets = 0 for subtitles with unknown duration instead,
which lets decode() return early when a line has already been shown.
Having removed these 2 lines, I also removed sd->preload_ok = false, and
thus the whole conditional, since according to sub/sd.h preload_ok only
needs to be set to false when old subtitles are discarded, and they are
no longer discarded,
The bug can be reproduced with
mpv --sub-file=<(curl 'https://music.xianqiao.wang/neteaseapiv2/lyric?id=1399616170' | jq -r .lrc.lyric) 'https://www.youtube.com/watch?v=dQw4w9WgXcQ'
Negative values are nonsense to mpv, and can cause protocol error afterwards,
like xdg_surface::set_window_geometry which doesn't accept negative values.
Treat any negative values as zero (client determines size) for now.
Needed in case the timer solution fails. Note that this will leave the
mode indicator in the language bar showing the original mode until
a key is pressed.
The IME is useful for text input. Additionally, Alt+Shift input language
switching doesn't work when IME is disabled even when the languages don't
require IME.
Re-add the VK_PROCESSKEY logic to ensure that IME is handled properly.
Reverts bf6b981367.
strlen is only relevant if the length is less than [1, 4], so this can
be replaced with strnlen instead which will only traverse characters
upto the maxlen insted of the entire string length. It also makes MPMIN
unneeded. Also fix a comment.
commit fa9e1f06f tried to move signal unsafe operations out of
signal handlers but mistakenly introduced a race. before,
sigtstop would process the following in order:
0. do_deactivate_getch2();
1. raise(SIGTSTP)
that commit moved 0 out of the signal handler (due to it being
unsafe) but kept 1 in there. this may mess up the ordering of
these operations. this commit moves everything out of the
handler so that things happen in proper order.
since things are now moved out of the handler, SA_RESETHAND is
no longer being applied to SIGTSTP. since that can result in
races if multiple signals are delivered faster than we can
respond to them.
When running the console in the terminal, style log lines with the same
escape sequences as msg.c.
mp.input can also specify terminal escape sequences, e.g. a script to
select a playlist entry can invert the color of the selection.
Also add a missing newline to help's error message.
This can cause mpv to abruptly quit without following the proper uninit
process when a second `SIGTERM` or `SIGQUIT` is sent and mpv
didn't quit on the first one already. This is because the default action
for these signals is to terminate the program immediately, similar to
`SIGKILL`, and `SA_RESETHAND` resets the `quit_request_sighandler` to
`SIG_DFL` for the default action.
Also keep the `SA_RESETHAND` flag for SIGINT because the current
behavior is to quit after receiving two Ctrl+C no matter what, this is
probably convenient and worth keeping.
This change is because some tools (e.g. GNU timeout) send SIGTERM twice
after the timeout period.
An easy way to reproduce is with `timeout 1 mpv [...]` where mpv would
quit abruptly anywhere from half the time to once every 50 attempts
depending on your luck.
According to the xkbcommon docs, `xkb_state_mod_index_is_consumed` is
true when a modifier *may affect* key translation. A key modifier may
be consumed but not be active. See xkb documentation for this function
for further details. This breaks key modifiers in cases where
L_Shift+R_Shift for example is used to change keyboard layout with
`xkb_options grp:shifts_toggle`. Instead, replace it with a simple
check for a valid modifier.
This doesn't actually work on either Windows or Linux with --terminal.
With --no-terminal or --no-input-terminal the SIGTERM handler is never
registered, so it definitely can't work.
Just remove the note about signals because it would be complicated to
explain that they don't terminate abruptly only with --terminal and only
if that signal has a handler, and it wouldn't be of interest to most
users.
fe875083b3 confused things a bit and made
--no-subs-with-matching-audio actually mean what it says: no subtitles
if the languages match. However, the option actually meant no non-forced
subtitles not no subtitles at all. This isn't really intuitive so
instead of changing the behavior back to the old way (we already have a
release since then), add a third option "forced" which is equivalent to
the old meaning of --no-subs-with-matching audio. Fixes#13151.
The +1 here is not correct. For a 4-byte unicode character, this would
throw a runtime error because the +1 would try to assign the null
terminator past the actual bound of our array. Just remove it since it
should be exactly equal to whatever we have for bytes.
There's a simple check in filter_sdh that gets the bytes of the first
character in a string in order to do pointer arthimetic to filter the
string. The problem is that it is possible for the amount of bytes to be
greater than the actual length of the string for certain unicode
characters. This can't be worked with so enforce the strlen as the
absolute minimum here to avoid overflow situations.
Fixes#13237.
Stopping output implies that it can't be paused anymore.
This is consistent with the documented API in internal.h as well
as the behavior of other AOs.
resolves#13267
Remove this "hack" from 2017 which disabled `advanced_editlist` while
demuxing mov/mp4. See: b7b12c36af as well
as b86a2316df
At present, advanced edit list support seems to be mature enough that it
doesn't need to be disabled by us and disabling it seems to break more
files based on testing with `elist` files in FFmpeg's FATE suite.
Xft.dpi is much more widely used nowadays by GUI programs compared to
the X11 screen DPI.
This is the best we can get for a vendor-neutral scaling preference
value under X11 in terms of adoption.
If Xft.dpi isn't available, the X11 screen DPI is used as a fallback.
~144 DPI displays are pretty common and neither 1x nor 2x scales are
the right size for it. Allow DPI scale in unit of 0.5 to fix this.
Additionally, add a note about the current behavior of the API used
to get the scale factor.
In theory bstr_split_utf8 should skip invalid sequence and move further,
but it doesn't do that currently, so just the string if unsuported code if
found.
Fixes infinite loop on code.len == 0 condition.
Fixes: 5864b72d1a
Currently, libplacebo always tries to reconfigure the d3d11 swapchain
to a 10-bit output format because disable_10bit_sdr isn't set to true,
even when an 8-bit format is explicitly requested via
--d3d11-output-format.
Fix this by passing the requested output format preference to libplacebo.
Document that this option may be ignored.
0.37.0 uses more computationally expensive shaders by default,
which can cause high GPU usage and frame drops even for modern
integrated GPUs, especially with 4K and high fps contents.
Recommend --profile=fast for them.
--ao=pipewire has been preferred on Linux for a long time, and this note
even makes it sound like alsa is preferred on any system. Just say that
the print order is the order in which the drivers are tried so this note
won't have to be updated again in the future, like --gpu-context's
documentation does.
This is commonly done to understand whether a window is focused. This
explicitly checks if focused is false instead of unavailable to not
break the cursor where focused is unimplemented like on --vo=drm.
The cursor is taller than the input text so it is made transparent
instead of completely removing it so that the log doesn't move up and
down while toggling focus. Alternatively, cheight = opts.font_size * 8
can be changed to 7.
43ed0a83d0 avoided reinserting the string that is appended after certain
completions when it is already after the cursor when inserting the
longest common prefix of the suggestions. Do the same when cycling
through them.
This section has no reason to exist anymore because:
- No "desktop issues" sections exist for other platforms, and all other
Linux-specific issues are represented as notes for options. This section
only addressed one specific issue.
- This section was shortened significantly with commit
2c46ae8ea3, so there is no need for
this to be a separate section anymore.
- This section was shortened again with commit
d5e681e95df759a4df8608cc773931e3f97c9460, when the original rationale
behind this section became outdated because GNOME has implemented the
idle inhibit protocol.
The historical info is moved to the documentation of --stop-screensaver.
Some places in the manpage uses `.. admonition:: Warning` instead of
the specific directive type `.. warning::` for warning admonitions.
This causes the "Warning" text appearing in black color instead of red.
Correct them here.
This allows taking more than 99999 screenshots in a single session,
and also for the case when a sequence of 99999 screenshots
already exists on the filesystem.
In commit c09245cdf2
long-path support was enabled for mpv without actually
making sure that there was no code left that used the
old limit (260 Unicode chars) for buffer sizes.
This commit fixes all but one case.
Reuse common_prefix_length() to make find_common_prefix() shorter and
faster by not creating many temporary strings.
The decrease in the average time to run find_common_prefix() over 1000
calls I measured is:
set \<Tab>: 1e-4s -> 1e-5s
set s\Tab>: 1e-5s -> 5e-6s
- --image-display-duration does not hide the OSC.
- Saying "Setting --image-display-duration" makes no sense because it is
not a boolean and it cannot be unset.
When hovering certain elements over the OSC, using the mouse wheel can
result in special commands (such as seeking, changing audio tracks,
etc.) Not everyone neccessarily wants this feature, so add an option to
make it possible to disable all of it. Maybe more fine-tuned control
would be more ideal, but probably not worth it. Fixes#13096.
24270b8587 disabled the cursor while mpv is running, but if you send mpv
to the background, it is not re-enabled until you run bg, and not even
after that if mpv is paused. Fix this by enabling the cursor from the
SIGTSTP handler.
Even for successful calls, utils.format_json returns nil as the second
return value. This doesn't have any purpose and is not documented, and
it is inconvenient for passing JSON to script-message, because
mp.commandv('script-message', 'foo', utils.format_json(...))
errors because mp.commandv receives nil as the fourth argument.
This commit makes format_json return only one value in case of success
to fix this.
Missed in 3250f6e447. Note that the
hardcoded ass alignment value is not used anymore as of that commit, but
we should ideally be moving towards secondary subs actually being
customizable via ASS anyways.
Over the years, we've accumulated several secondary subtitle related
options and properties, but the implementation was not really consistent
and it wasn't clear what the right process for adding more should be. So
to make things nicer, let's refactor all of the subtitle options with
secondary variants (sub-delay, sub-pos, and sub-visibility) and split
them off to a new, separate struct. All of the underlying values are
stored in an array instead for simplicity. Additionally, the
implementation of some secondary-sub-* properties were slightly changed
so there would be less redundancy.
f1c4d20e65 added this option, but the
documentation is actually backwards. --replaygain-clip allows clipping.
Having it disabled, the default, prevents it. Keep the behavior the
same, but change the documentation to reflect reality. Closes#13111.
Fixes crashes in case of unknown subtitle track being found, as
the original ARIB caption logic added in 0da0acdae8
did not attempt to take into mention tracks with unknown type.
Fixes#13106
As a result of the work I did the explicitly check for formats
supported by the vo in the f_autoconvert logic, I introduced a
regression in the handling of the rpi4_8 and rpi4_10 formats. These
require special handling because they only exist in the rpi forks and
not upstream ffmpeg, which means they don't have stable pix fmt values
that we can use directly.
Previously, we simply didn't declare them as supported, which was ok,
as nothing was really enforcing the list of supported formats, but that
has changed.
As we still can't simply use the pix fmts, I had to do a slightly
ridiculous dance to look them up by name, and if they exist, then
register them as supported.
Good times.
It's conceptually broken for an hw format to be identified as a
supported sw format for an hwdec, but in the case of the drm hwdec,
we have no choice but to do so for the weird rpi formats, as these
are declared, incorrectly, as hw formats in their forked ffmpegs.
This means we can't reject such formats as a matter of principle,
as we do today. Instead let's just assume that such formats can always
be accepted as-is, and will never require conversion. In practice, this
is either true or it will fail in the VO, which is the old behaviour
from before I introduced the conversion filter capability.
Clear completion suggestions from functions that move the cursor, so
that you can't insert suggestions at the wrong spot by pressing Tab
again after moving the cursor,
Also clear suggestions from some editing functions that were never
updated. It is not actually necessary to clear suggestions from
functions that remove text in front of the cursor, but since
handle_del() already clears them, let's just clear them everywhere.
This is useful for completing files and more rarely for profiles. It
will also be useful to third-party scripts interacting with the console
once the API to do it is merged.
Add .jxl as a file extension that maps to an image codec. Note that
this will include animated JXL files, but .gif is also on that list so
they are not different in that regard.
I honestly don’t care either way but I also don’t believe this innocent
and cute hat is worth repeatedly having people show up on the issue
tracker to aggressively virtue signal and then shit-talk the project
elsewhere when their “concerns” are ignored and made fun of.
For the record, I approve of neither brand of childish nonsense.
If your workflow depends on December festivities, feel free to use an
alternative OSC implementation.
Fixes#13082 and #9548
When using the --playlist option on the commandline, it would mark all
entries on the command as having the playlist-path of the value of that
passed option, not just the ones that were expanded from it. Fix this by
moving the playlist_populate_playlist_path to the same place where the
playlist file gets expanded.
Ref https://github.com/mpv-player/mpv/issues/13075#issuecomment-1852179164
https://0x0.st/ has a maximum retention period of 1 year, and much less
for larger files. Uploading them directly to github issue avoids this,
which most people are already doing anyway because of greater convenience.
log file: don't request 0x0.st.
sample files: recommend github first.
Add more and unify requested information:
windows, linux, others: request GPU model to provide more info about
known hardware limitations and hardware/driver combo bugs.
windows, others: request general GPU info.
build: request meson version.
windows, linux, others: request backtrace in case of crash.
all: clarify the language of not attaching a log file.
When updating subtitles while paused, mpv waits until a packet is
available. However in the case of a network stream, it is possible that
mpv will pause itself when buffering for cache reasons. This makes that
particular loop do a busy loop and can take a long time depending on
network streams. Simply just don't do the loop here if we are paused for
cache reasons. Fixes#13077.
The dragging hack can cause unwanted aero shake activation.
Prevent this by saving the window arrangement state before dragging,
temporarily disable it while dragging hack is active, and restore to
the original state after dragging ends.
The mouse down handler checks w32->current_fs to determine whether
to begin the dragging hack. Unfortunately, the w32->current_fs value
is stale, because the input is handled asynchronously, and we cannot
wait for an up-to-date value if dragging needs to be kept resonsive.
As a result, when the fullscreen state changes after the dragging
model loop is entered, the opposite value is used, so the window stays
draggable after entering fullscreen, and becomes undraggable after
exiting fullscreen.
With the resonsiveness and model loop constraints, the up-to-date
state must be queried inside WM_MOVING messages which are sent while
dragging. The message handler now checks if the dragging hack is active
while the window is in fullscreen, and overrides the new window position
with the current one, in effect prevents the window from being moved.
The old check is also removed, so the window is now draggable after
exiting fullscreen while dragging hack is active.
Compose key doesn't function in X11 because XFilterEvent() isn't called,
and XNInputStyle is set to a wrong value. This results in KeyPress events
for the separate keyboard inputs in the compose key input sequence
instead of the composed character, making it impossible to input certain
characters which require compose key.
Fix this by calling the required XFilterEvent() and set XNInputStyle
to the correct value.
This filter is a bit complicated, but one of the essential parts of it
is removing text enclosed by particular set of characters (e.g. text
inbetween []). This was previously hardcoded to only take into account
parenthesis and brackets, but people may want to filter more things so
make this customizable. The option only takes "left hand characters" so
the right pair is mapped internally if applicable. If not, then we just
use the same character. Fixes#8268 since the unicode character in
question can just be passed to this option.
These two functions are almost exactly the same. The parenthesis variant
is essentially just a special case with more conditions to not remove
text. These can easily be combined together into one generic
skip_enclosed function to handle both cases. We also use char * instead
of char for the character comparison here since not everything is
neccesarily 1 byte and can fit into a char. This will be useful for the
following commits where we extend this logic further.
A simplified version of the text width estimation code from uosc.
An osd_overlay is created with compute_bounds=true for measuring the
width of the lower case alphabet at what's estimated to be the largest
font size possible without clipping.
The lower case alphabet was chosen to get decent results for proportional
fonts, even if they aren't officially supported.
According to MS documentation, an application should return TRUE from
WM_XBUTTONUP and WM_XBUTTONDOWN if it processes these messages.
DefWindowProc generates the WM_APPCOMMAND message when it processes the
WM_XBUTTONUP message, so if an application properly handles WM_XBUTTONUP
messages, extra WM_APPCOMMAND messages won't be generated.
Because mpv doesn't properly handle these messages,
WM_XBUTTONUP causes APPCOMMAND_BROWSER_BACKWARD to be generated, resulting
in duplicated keys and improper fix 438ead7a, which prevents the processing
of the appcommand from sources other than mouse clicks.
Fix this by following the documentation, and the back and forward
appcommands can be added.
XF86Back and XF86Forward are mostly used to navigate file and web browsers
to go back/forward in history. XF86Forward isn't recognized right now,
so add it.
Because XF86AudioForward already takes the "FORWARD" name, rename the
browse keys to GO_BACK and GO_FORWARD instead.
On practically all platforms and GUI toolkits, a triggered double click
event clears the mouse input buffer so that the next click won't
trigger another double click event. mpv doesn't do this, so a third click
results in another double click event.
Fix this by resetting the double click timer after a double click event
is triggered which achieves the same effect.
in the case the window was already set to a maximized size via geometry
or related options (100%x100%) the maximize function would try to
maximize the window again. this reset the position and slightly
increased the size further.
to prevent this only maximize on init if we really want to maximize. in
the reverse case make a noop call by passing the current zoom state.
Fixes#11193
ca2b05c0fb changed the window size with --force-window and no video
tracks to be closer to 16:9, but I don't see why we shouldn't have an
actual 16:9 ratio. The advantage is that subtitles with fullscreen and
no video tracks will have the same size and position (depending on the
values of --sub-scale-with-window and --sub-use-margins) as with 16:9
videos, because there will be no (invisible) black bars.
As it is now, the FreeBSD CI is failing because meson can't find the
dvb headers.
FreeBSD puts the relevant headers into /usr/local which is bothersome
and in fact required a workaround to be added to the Wayland detection
already (3bdf702b1d) but this should be
addressed by us adding the path to CFLAGS already.
With a more minimal example the detection works fine in my FreeBSD VM.
I'm at my wits end debugging this so just disable it for now.
This was disabled by default in 99cef59fc9 (from 2017)
due to build issues with old kernel headers.
Whatever was considered old at that time will be ancient now
and with the last commit there should be no isses auto-detecting it.
See 1b035402a6. This is only relevant if
you are using d3d11 on --vo=gpu which is windows-only. For all other
platforms, vulkan uses libplacebo which uses shaderc. mpv itself doesn't
need it in those cases.
281b1d8999 introduced a stack use after
scope because dest_fbo can be reassigned a new pointer and then be used
by pass_draw_to_screen outside of that scope where the pointer is no
longer valid. Fix this by rearranging the variables so the assignment is
done in the same scope as the pass_draw_to_screen call instead.
It's not actually related to libplacebo wrap stuff and the swift compile
command needs this to get the right libplacebo include path.
This reverts commit b9d392ecd9.
Meson was pretty strict about target ids and generating the mpv.com in
the same directory as mpv.exe wasn't possible. So as a workaround we
tucked it away in a subdirectory, but that's not really intuitive at
all. Well as of meson 1.3.0, this is now possible so leverage it since
it makes way more sense. We still keep the old workaround for anyone
using older meson versions.
Add --secondary-sub-delay option and decouple --sub-delay from secondary
subtitles. This produces desirable behavior in most cases as secondary
and primary subtitles tracks tend to be timed independently of one
another.
This feature is implemented by turning the sub_delay field in
mp_subtitle_opts into an array of 2 floats. From here the track index is
either passed around or derived when sub_delay is needed. There are some
cases in dec_sub.c where it is possible for dec_sub.order (equivalent to
track index) to be -1. In these cases, sub_delay is inferred as 0.
The info provided for libva might be useful. Specifically on Windows it
seems to not use the error callback for what should be logged as error.
[ 0.080][v][vaapi] libva: VA-API version 1.20.0
[ 0.080][v][vaapi] libva: Trying to open <path>/vaon12_drv_video.dll
[ 0.080][v][vaapi] libva: va_openDriver() returns -1
[ 0.080][e][vaapi] Failed to initialize VAAPI: unknown libva error
As we can see only the "unknown" error is printed to the error callback
and important information is printed on the info callback. Print it to
verbose log to make it easier to find.
the cocoa backend was removed and all functionality is either available
on all macOS backends or explicitly only with cocoa-cb. the manual
should properly reflect that change.
also remove the last mention of the old cocoa backend.
the title is updated on the main thread (mandatory with cocoa)
asynchronously, because otherwise it would either deadlock when done
synchronously, lead to undefined behaviour or just crashes. the problem
here is that the c string was only copied to an NSString within that
asynchronous call, which potentially would access the pointer when it
is accessed, modified or freed by another thread. it is only safe to
access this pointer as long as the control callback wasn't returned yet.
to fix this we move the copying and creation of the String from the
c string pointer outside of the asynchronous call where the conversion
of an untyped pointer to a typed pointer is done too. since the
resulting String is a copy it's safe to be used in the asynchronous
call.
also reverting ee6ad40, since the problem was most likely an SDK problem
or the very same problem as mentioned here. i retested the crash case
again und can't reproduce it anymore. using a swift String again instead
of an NSSstring.
Fixes#12935
NSApp is only an Application when initialised from mpv itself. when used
via libmpv an Application is never initialised and mpv would always
immediately exit.
make the retrieval of the vo and mac options static so they can be
retrieved in all cases.
Fixes#12518
- Don't define _GNU_SOURCE on Windows, no need
- Define WIN32_LEAN_AND_MEAN to strip some unneded headers from
windows.h
- Define NOMINMAX and _USE_MATH_DEFINES as they are common for Windows
headers
We prefer to fail fast rather than degrade in unpredictable ways.
The example in sub/ is particularly egregious because the code just
skips the work it's meant to do when an allocation fails.
This property was never encouraged. The manual even stated that "You
should avoid using it, unless you absolutely have to." Since we now have
user-data which is superior in every single way and replaces this,
delete this property. The manual also has threatened people for years
with the line "It's a makeshift solution which could go away any time
(for example, when a better solution becomes available)." We were nice
and deprecated it in 1d00aee8e1 for a
while to give script authors some time to update. Let's remove it for
good now.
This mostly is added to resolve player command synchronization with VO
thread discussed in 477a0f83.
The current uses does not necessarily need this as they are all managed
by playloop. But for future use with other params that will be handy.
Those params are mostly to observe current state of VO and does not
necessarly need to be locked along with frame drawing, that changes the
params once at the end.
Only vaapi-copy variant as nothing can map D3D12 resources currently.
And even if we would add resource sharing to D3D11 it would invoke copy
at some point, so there is no point really. Maybe in the future when
libplacebo get smarter about resource sharing on Windows, but practical
advantages are really small. I've tested it with Vulkan <-> D3D11
sharing and GPU <-> GPU copy is still invoked. Better than CPU memcpy,
something for the future.
Up to 2x playback rate is the most we can offer currently. Should work
fine for most kernels with radius <= 2.
This avoids limitation of hwdecs number of frames in-flight.
Fixes: #12927
there is 1px border at the top of the window that is not covered by our
title bar and the video below is visible. this broke in some newer macOS
version even so the calculation of size and position of the title bar is
still correct. add 1px the the height of the title bar to cover up the
unwanted border.
Unclear if there are other situations but at least using --force-media-title
this can be called without a playing file, causing a segfault.
fixes: 34a04d0567
The "auto" logic is vastly better than setting a specific size. This
option amounts to "allow users to shoot themselves in the foot" flag,
given that the vast majority of ICC profiles in the wild are fine on
17x17x17 or even smaller 3DLUTs.
Setting stupidly high --3dlut-size is the main source of ICC-related
slow startup issues, and there is absolutely no conceivably benefit to
going above the defaults except for pixel peeping and chasing tiny PSNR
increments.
These are less likely to be modified from run to run, and with the
avoidance of redundant re-saving we can get away with a larger size.
This is enough to save 10 3DLUTs at typical sizes.
D3D11 is actually the main platform that suffers from slow shader
compilation, typical Vulkan/GL drivers are either very fast to begin
with, or already internally cache.
I have no idea why this code is such a convoluted mess of options and
possibilities. First of all, why is dumping both caches to a single file
even a supported use case? Why is the cache path generated multiple
times, once for saving and once for loading, instead of just generated
once and stored? Why even create a pl_cache if you're not going to
save/load it? Why so much code duplication?
I don't know. But I rewrote it in a way that makes far more sense to me.
This change prevents unwanted adjustments. Generally, screenshots
shouldn't invoke pl_queue_update, as this action could cull the already
mapped frames in the queue.
If !display_synced, some values may not be correct or zeroed. Therefore,
it makes no sense to interpolate in this case.
For a non-moving frame, we always want to show an uninterpolated frame.
libplacebo requires additional frames when VPS is lower than FPS and
anti-aliasing is enabled. Supports up to a 1/4 ratio. VO has a limit of
10 frames, so in practice, not many more can fit.
Note that the internal libplacebo mixing limit is 16 frames.
The `current_frame` can be redrawn even if the remaining `num_vsync` is
equal to 0. In this scenario, the vsync offset would be incremented
beyond the target point.
It turns out that mpv will rewrite the entire cache file on every single
quit. It's not so great since after viewing a ton of files, your cache
can grow to massive sizes and slow down quitting the player to a
noticeable amount. Turn down the max size of both caches to 10 MiB for
now as a workaround until this gets improved later.
without a developer license and the corresponding certificate we can't
sign our app bundle properly. instead use the ad-hoc pseudo identity.
there. i am not sure what restrictions we have because of that, but it's
the only way we can pseudo sign the app bundle.
Fixes#12116
Apps on Apple silicon have to be codesigned to run, but you can't
codesign bundles that have a symlink for the main executable.
The "mpv-bundle" symlink was used as the bundle's main executable
because it makes the execution name of the binary different.
Launch Services runs the CFBundleExecutable key from Info.plist when
launching a bundle, so by comparing the execution name to the name of
the symlink, you can check if that's how the binary was launched.
This replaces that detection method by moving the MPVBUNDLE
environmental variable into Info.plist. Launch Services will set
anything in LSEnvironment as environmental variables before launching
the bundle, so we're able to check for it instead of needing to
differentiate the execution name of the binary.
Fixes#12116
not all dependencies are linked with an absolute path but rather are
relatively linked via @rpath or @loader_path. in those cases we have to
resolve the paths to those dependencies ourselves and change the linking
with install_name_tool to be relative to the @executable_path of the
binary within bundle.
Fixes#11897
This filters out vastly inaccurate values from presentation feedback
that can happen shortly after restarting playback or seeking.
Makes estimated vsync converge almost instantly instead of waiting
until those outliers are dropped from the past samples.
The "Resolution" property shows the storage resolution for videos with
non-square pixels.
Currently, display aspect ratio is shown for both "Resolution" and
"Output Resolution" properties which results in a duplicate,
and is incorrect for the "Resolution" property.
The correct aspect ratio is now shown using the sar and sar-name properties.
Display aspect ratio (aspect) and pixel aspect ratio (par) are already
exported, but storage aspect ratio (sar) isn't. This value is needed to
display the storage aspect ratio for non-square pixel sources in stats.lua.
This exports two new properties: video-params/sar and video-params/sar-name.
Docmentation is updated accordingly.
In acac614032, I sort of cargoculted what
I had to do for m3u, but it's actually not needed. bstr_split_tok
unexpectedly doesn't modify the original string. So the line_dup
business in the ini parsing is not needed. Remove it. The part in
parse_ref_init isn't wrong but naming the variable "line_dup" instead of
"value" is stupid so adjust that. And finally, you can actually force a
codepage in mpv (add "+" before the codepage) which will cause every
line to be allocated memory including the header lines even though those
are obviously valid utf8 that should never need conversion. This wasn't
taken into account so add an extra pl_free_line in a couple of places to
make sure they are freed.
Adds:
--secondary-sub-visibility
--video-aspect-method
--video-unscaled
--video-pan-x
--video-pan-y
--video-rotate
--video-crop
--video-zoom
--video-scale-x
--video-scale-y
--video-align-x
--video-align-y
Those properties are related to playback state and are likely expected
to be restored when resuming playback.
Removes:
--border
--fullscreen
--ontop
--osd-level
--pause
Those options are not really content related. I don't see much gain to
save them per each watch later entry.
In commit de6d57f0 libplacebo enabled drift compensation by default.
mpv already tracks error and adjust the speed by itself.
This commit fixes judder visible when slowing video a lot, ex. playing
back at 10% speed.
Set ideal vsync duration also when dropping frames, libplacebo estimate
currently own values anyway, will be useful later...
See: https://code.videolan.org/videolan/libplacebo/-/commit/de6d57f021e2336851f51b1a8538aa1484c56607
During move of this code from vo_gpu_next.c to video.c someone(TM) tried
to be smart and simplify the expression. The num_vsync includes error
compensation which can cause it to display +-1 vsync at the same rate.
We explicitly don't want to include this in "ideal" parameters.
Also num_vsyncs was already rounded so we produced off timings in
general.
Revert back to proper way of translating the time.
Fixes: 5e5a325
b56e63e2a9 removed -del for list options but it is still listed in the
list structs, which means that it is still tab completed on the CLI like
the other actions, and seems to behave like -set. Remove it so it is no
longer tab completed.
Also remove the description of -del from the help output of object
settings lists --(ao|vo|af|vf)-help, and update a comment.
The commit subject sounds reasonable except that frame redraws get
spammed in certain cases (still image with subtitles) all the time
regardless if the subtitle actually has changed or not. So this is
stupid and wasteful, but you'll always see subtitles. vo_gpu currently
has this behavior as well, so we're just matching it but later mpv's
core should be fixed so this works reasonably. Fixes#11335.
cd59ea8afab6381951a3ae19a43e422906d02164 removed an arbitrary start
offset added to the timer. However, it turns out that demux secretly
depends on this. When updating cache to actually read bytes from the
stream, there's a diff >= MP_TIME_S_TO_NS(1) check to make it only
update once every second. With the old MP_START_TIME macro, the initial
time value would always be at least 1e10, so this would also be true.
Since we don't have that offset anymore, now the initial time is less
than that so it is not updated and properties like file-size are 0. Just
be sure to always update if the last_speed_query is 0 (i.e. we just
started the player). Fixes#12869.
Fixes gpu-next completely ignoring any speed adjustment, either DS or
playback.
Frames in pl_queue have raw PTS values, so when querying them we have to
use the same time base. There was misunderstanding between mpv and
libplacebo, where the former was querying the frames based on display
vblank timeline, but this cannot work if the playback speed is adjusted
and display timeline is not aligned with video timelien. In which case
we have to schedule "video vsync" points that we want to display.
Previous code was working only when playback speed was 1.0x, but since
DS almost always changes the speed the interpolation was mostly not
timied correctly.
Relative to frame PTS timeline as oposed to display vblank.
Those values are relative to unadjusted video timeline. They will be
used by gpu-next where it expect virtual frame vsync, not display vblank
time.
Originally suggested by @haasn. Instead of awkwardly using a pts from
the previous render loop, we can just peek into pl_queue and use the pts
of the first frame instead. This eliminates a lot of weird artifacts
that can happen on discontinuities like seeking. Fixes#12355.
Several related things in regards to interpolation. Essentially this
adds more general sanity checking to bring it more in line with what
vo_gpu does.
- Add a can_interpolate bool which determines whether or not this frame
is allowed to interpolate.
- p->is_interpolated was sometimes lying and because you can have a mix
frames greater than 1 depending on the video and settings. Make sure
that vsync_offset is not 0 so we know if it's actually interpolated or
not. This prevents a redundant redraw for those edge cases when
pausing.
- When the vo wants a reset, i.e. some sort of discontinuity, don't try
to interpolate the frame. Interpolation is only valid for
monotonically increasing times.
This fixes#11519 because of the additional check to make sure that we
have more than 1 frame. The PTS clamping part is still not great. That
is for the next commit.
String formatting of Lua crashes with widths greater then 99, so limit
the value to that.
A nicer solution would be to create our own string padding function that
can handle bigger widths, but such long suggestions aren't common enough
to be worth the effort.
In the past, this worked by accident because the initial startup was
racy and sometimes the initial firing of handle_toplevel_config would
happen after reconfig. Since we now properly wait on all compositor
events we can save the initial size hint that is given to us and try to
use that as the window-size/geometry provided the --autofit/geometry
options aren't explictly set. Fixes#11134.
the OpenGL cocoa backend was deprecated in 0.29, it has lot of bugs, is
completely unmaintained and can't properly playback anything anymore on
the newest macOS. it is time to remove it.
the old displayName property via the IODisplay API is not working
anymore on ARM based macs and was broken in at least one other case.
instead we use the new localizedName property introduced in 10.15 of the
NSScreen. we don't need any backwards compatibility since 10.15 is the
oldest version we support now.
configs and scripts that use the options and properties fs-screen-name,
screen-name or display-names need to be adjusted since the names could
differ from the previous implementation via the IODisplay API.
Fixes#9697
this is apparently something that was added with swift 5.5, though it is
hard to find anything officially.
don't capture self in closure but explicitly access all variables by
prepending self.
Fixes#12653
older macOS dev tools were inconsistent with the way how SDK versions
were returned, some truncated the minor versions. in those cases the
SDK version had to be retrieved through the SDK build version.
recently the scheme for the SDK build version changed that our heuristic
for converting it to an SDK version produced wrong version strings.
the stride of the minor version changed from 1 to 2, so SDK versions
ended up higher than they actually were. furthermore macOS 11 was
hardcoded.
since Xcode 12 Apple fixed the SDK version retrieval and it is no longer
truncated when using Xcode as dev tools. Xcode 12 is also the latest
supported version on macOS 10.15, which is also our oldest supported
version. we can remove the old SDK build version conversation and use
the Xcode only tool to retrieve the SDK version in the case Xcode is
used as dev tools. furthermore this als keeps support for Xcode 11 where
the problem wasn't fixed yet, but is still a supported version on macOS
10.15.
Fixes#9907
Having the show-progress command obey no-osd is nonsensical and
unintuitive. The show-text command already ignores no-osd, so there's
precedence for this. Fixes#5662.
Fixes a899e14b which changed clamp from 0 to 1 ms which effectivelly
introduced 1ms sleep always, even if requested until_time_ns is in the
past and should request 0 timeout.
While at it also fix mp_poll wrapper to respect negative timeout which
should mean infinite wait.
Also keep the 37d6604 behaviour for very short timeouts, but round only
the ones > 100us, anything else is 0.
Fixes: a899e14b
Most importantly, the wait_until addition was missed while doing the
unit conversions to nanoseconds which meant mpv woke up roughly every
second since not nearly enough time was added. It was meant to be 1000
seconds (1e9 in microseconds). Use a macro so it's more readable. Also
put some other wild 1e9 calculations inside of a macro as well.
Fixes a899e14bcc.
These have been build options since the waf build, but that doesn't
really make sense. The build can detect whatever macOS sdk version is
available and then use that information to determine whether to enable
the features or not. Potentially disabling multiple sdk versions doesn't
really make any sense. Because f5ca11e12b
effectively made macOS 10.15 the minimum supported version, we can drop
all of these checks and bump the required sdk version to 10.15. The rest
of the build simplifies from there.
No longer needed, wrapped status line is supported now. Also this didn't
work correctly if status were decorated with module name or time.
This reverts commit ab6fac43b4.
- prepare string before printing
- reduce amount of fflush(), especially for multiline messages
- clear status line and keep it always at the bottom
- indent module name to the longest value
- disable cursor for status line
- properly support wrapped status line
Overall makes status line less flickering and remove stray status
instead of scrolling them up.
Currently VOCTRL are completely unusable for frequent data query. Since
the HDR parameter addition to video-params, the parameters can change
each frame. In which case observe on those parameter would be triggered
constantly. The problem is that quering those parameters involves VOCTRL
which in turn involves whole render cycle of delay.
Instead update VO params on each draw_frame. This requires changes to VO
reconfiguration condition, but in practice it should only be triggered
when image size or data layout changes. In other cases it will be
handled internal by VO driver.
I'm not quite happy with this solution, but don't see better one without
changing observe/notify logic significantly. There is no good way
currently to handle VOCTRL that are constantly queried.
This adds unfortunate synchronization of player command with VO thread,
but there is not way around that and if too frequent queries of this
param becomes a problem we can thing of other solutions.
Changes the way to get data from VO driver added by a98c5328dc
Fixes: 84de84bFixes: #12825
Stretch a subtitle duration so it ends when the next one starts.
Should help with subtitles which erroneously have zero durations.
I found such a subrip substitles stream in the wild.
Signed-off-by: Mohammad AlSaleh <[email protected]>
windowrc in vo_w32_state is actually client size, for hit test we need
proper window size. When border is disabled those sizes are the same,
but when only title bar is disabled it is not.
Reduce the hit area to more sane values when the border is not
drawn to minimize amount of covered client area in borderless mode.
The previous commit was already a big improvement, but it was still
somewhat slow on the lua interpreter. By wrapping the table at the top
we loose the consistent placement of items while resizing (at least as
long as the column count didn't change), but we avoid taking all the
off screen items into account.
The fewer items fit on screen the faster this becomes.
Showing all properties was terribly slow.
Instead of starting at one row and increasing the row count until it
fits, the column count can be increased until it doesn't fit anymore.
That alone already reduces the required iterations, but from the column
count an upper and lower bound for the row count can be calculated.
For large tables this dramatically reduces the amount of iterations.
So far completing something like `${some-pro}` with the cursor between
`o}` would result in `${some-property}}`. Adding that superfluous `}` can
be avoided by checking if it's already in the string after the cursor.
This was specifically special logic for drm. Before present_sync, it
would also clear out all of its vsync values like this. The old drm code
would save a bunch of samples which would confuse vo.c when unpausing
since it got old, bogus values. Since we make sure to match successive
vsync samples with the swapchain depth and that present sync samples
also match the swapchain depth, this is unneeded.
There's some geometry-related things that mpv has to calculate before
the window is actually mapped onto the screen in wayland. But there's no
way to know which output the window will end up on before it happens, so
it's possible to calculate it using the wrong values. mpv corrects
itself later when the surface event happens, but making the initial
guess work better can help in certain cases.
find_output is the only thing that needs to be changed here. Its main
purpose is to grab the right output based on user settings when we're
trying to full screen and giving a fallback in case we don't have
wl->current_output yet. The x11 code already does something similar, so
we're basically just copying it. Allow user settings like --screen and
--screen-name to influence the initial wl_output guess. Those options
won't actually place the window on that specific screen since we can't
do that in wayland, but if the user knows where the window will end up
beforehand it makes sense to listen to the arguments they pass. If
something goes wrong, then we just fallback to 0 like before.
In the sub seek code path, there was an arbitrary small offset added to
the pts before the seek. However when seeking backwards, the offset was
an additional subtraction. de6eace6e9
added this logic 10 years ago and perhaps it made sense then, but the
additional subtraction when seeking backwards causes the subtitle seek
to go too far to the previous subtitle if the durations overlap. This
should always be an addition to work correctly. Additionally, the sub
stepping code path also could use this offset for the same reason
(duration overlaps). However, it is only applicable to sd_ass not
sd_lavc. sd_lavc has step_sub support but on a sample it didn't even
work anyway. Perhaps it only works for certain kinds of subtitles
(patches welcome).
Anyways instead of keeping this offset as a magic number, we can define
it in sd.h which is handy for this. For sd_ass, we add the offset when
sub stepping, and the offset is always added for sub seeking like it was
before. Update the comment to be a little more relevant to what actually
happens today. Fixes#11445.
Since 062104d16e, we started saving cached
packets for subtitles. However, these can point to the same address as
what is stored in sub->new_segment. When a segment is updated, the
packet is potentially freed. Later during decoding, this can lead to a
double free since the cached packets will naturally try to free itself
and update. Fix this by simply always making sub->new_segment a full
copy of the packet so its lifetime doesn't have to be tied to the cached
packet stuff.
A ton of code and drm-specific abstractions can be dropped with this.
One important thing to note is that the usage of sbc is completely
dropped here. The utility of that is not particularly clear since the
sbc value was manually incremented before the flip and it's not as if
the drm page flip event gives it to us like it does with the msec and
ust. It can be reintroduced later if there is a need. For drm, we also
add a present_sync_clear_values helper since all presentation feedback
needs to be cleared on pause/resume for it.
When this was originally written, the queuing/list approach was
deliberately removed since it adds more complication and xorg/wayland
don't really use it anyway. In practice, you only really have one frame
in flight with presentation timestamps. However, one slight annoyance is
that the drm code has its own thing which is almost exactly the same and
does its own calculations. Ideally, we'd port drm to this instead, but
the implementation there takes into account N-frames in flight which
probably does actually work. So we need to make present_sync smarter and
be able to handle this.
mpv does actually have its own linked list implementation already which
is a good fit for this. mp_present becomes the list and each
mp_present_entry has its own set of timestamps. During initialization,
we create all the entries we need and then simply treat it like a queue
during the lifecycle of the VO. When an entry is fully used
(present_sync_get_info), then we remove it from the list, zero it out,
and append it to the end for future use. This avoids needing to allocate
memory on every frame (which is what drm currently does) and allows for
a reasonable number of in flight frames at the same time as this should
never grow to some obscene number. The nice thing is that current users
of present_sync don't need to change anything besides the initialization
step.
This would cause mpv to, in some very specific scenarios, have a
negative vsync_offset after seeking which would result in mpv requesting
a pts before the first frame to libplacebo.
Fix it by setting it to 0 when we reset state, such as after seeking.
Fixes: https://github.com/mpv-player/mpv/issues/12813
This commit replaces all uses of sig_peak and maps all HDR metadata.
Form notable changes mixed usage of maxCLL and max_luma is resolved and
not always max_luma is used which makes vo_gpu and vo_gpu_next behave
the same way.
This change essentially removes mp_thread_self() and instead add
mp_thread_id to track threads and have ability to query current thread
id during runtime.
This will be useful for upcoming win32 implementation, where accessing
thread handle is different than on pthreads. Greatly reduces complexity.
Otherweis locked map of tid <-> handle is required which is completely
unnecessary for all mpv use-cases.
Note that this is the mp_thread_id, not to confuse with system tid. For
example on threads-posix implementation it is simply pthread_t.
UPDATE_SUB_HARD causes all of the ass objects to reset in order to apply
the new style. UPDATE_SUB_FILT doesn't actually reset the sd, but it
should in order to update the actual filters so that was added here.
Doing this causes the current subtitle to be dropped. In the paused
cause, this concidentally works because command.c forces a video refresh
which then reloads the subtitle essentially. But while playing, the
subtitle will be dropped and you won't get anything until the next one
appears.
Instead of using video refreshes, what we can do is just always save the
last two subtitle packets in a cache and redecode them if needed. This
is much easier and also allows us to get rid of all the video refresh
logic in command.c. Fixes#12386.
The other options that have to do with ass styles also uses this flag.
It's needed since we have to destroy the ass objects and reinit them.
It's a bit incomplete since it will technically only properly work when
paused (while playing, the current subtitle gets discarded). That fix is
in the next commit.
The old one would actually crash if the libplacebo.cache file was
invalid. Additionally, set a max size of 1 GiB for icc cache and 50 MiB
for gpu shader cache. The per object size limit is removed which puts
mpv in line with plplay. Finally, a few memory leaks are also fixed
since several objects previously were not freed on uninit.
For whatever reason, some of the lua code (particularly the osc and
ytdl_hook) is full of a bunch of stuff like if (foo), if not (foo ==
nil), etc. The parenthesis aren't needed in lua and actually just look
weird since nobody actually writes lua like this. You can see most of
the other conditionals are written normally. So cleanup the style to
match when the parenthesis clearly aren't doing anything. Not directly
related, but also add some spaces on a few math operations while we're
at it.
This avoids a "Redefined local `options`" LSP warning in
list_option_list() after the previous commit. It still works, but
reusing names for local variables is error-prone.
Probably should have actually tested the filter changes but I didn't.
This was the wrong spot anyway since labels are unique. Something like
this should have been done further down when finding it by content. On
second thought, having multiple filters with the same content does have
a usecase (e.g. stacking multiple rotations) so removing all of them at
once probably isn't great. There's no practical usecase for having
duplicates in a string list, so we'll leave that change alone.
Fixes#12791.
Vapoursynth does not provide crop metadata and input one is likely to be
invalidated during filtering. Set crop to full frame if image dimensions
were changed during filtering.
Fixes: #12780
Previously, the av sync change calculation was only done if the
audio_status was STATUS_PLAYING, but there is at least one or two more
states where this should be done. player/audio is capable of adding
delay if the state is anything besides STATUS_EOF. This means that while
calling adjust_sync, the delay value could have changed from the audio
side of the equation from the previous playloop, and it doesn't
necessarily mean that the current audio_status is STATUS_PLAYING either.
So the old code would technically skip this case. In practice, this is
just one frame so it hardly matters, but it should be taken into
account. For example, STATUS_READY is definitely possible here in
adjust_sync. I'm not sure if it's actually possible for STATUS_SYNCING
to happen but the audio code can change add delay with that status, so
it doesn't hurt. STATUS_DRAINING is probably not relevant, but again
include it to mirror the audio code logic. Of course, STATUS_EOF is
obviously a no-no since that means no audio at all, so we return from
there. I didn't take hard measurements or anything, but this does seem
to result in slightly smaller av sync fluctuations on discontinuities
(like seeking) which makes sense because we're now making an additional
correction that wasn't previously done.
Another change is to always try adjust_sync as long as the frame_time is
nonzero. The old logic only did this if the video_status was playing or
greater, but it is possible to get new frames with a different PTS that
do not have that status. The audio is still playing so logically it
should be adjusted as well. Again, this happens for just one frame, so
it doesn't really matter in practice but it should make more sense. A
zero frame_time is skipped since that would mean the pts did not advance
and the previous playloop should have done the adjustment for that time
already.
3038e578af recently changed the logic here
so it wouldn't trigger on still images, but after thinking about the
code here some more, I don't believe it's needed at all. Doing an ao
reset when you flip the video track is very disruptive and not really
desirable at all. Since the ao no longer adds bogus delay values while
the video is off, there should be no need to do a full reset for syncing
reasons. The delay value will be zero, so we can let the audio just play
normally and let the video code do its thing. There is one slight trick
here however. When using a display sync mode, part of the syncing code
will try to update the audio and video playback speed. This can cause an
audio underrun if we're just turning the video back one. An easy way to
avoid most of these is to not update the speed if we are in the
STATUS_SYNCING state for video. This isn't quite perfect and underruns
are still possible, but it actually seems to depend on the AO. e.g. I
couldn't trigger an underrun with alsa but I could with pipewire. In any
case, the audio artifact here is much less noticeable than doing a full
ao reset, so it's still an improvement.
currently hysteresis-secs only works when the demuxer-max-bytes fills
up. but it's possible for the cache-secs/demuxer-readahead-secs to be
reached first.
in those cases, hysteresis-secs doesn't work and keeps buffering
non-stop. but the goal of this option was to save power by avoiding
non-stop buffering so go ahead and make it respect cache-secs as well.
additionally remove some redundant repetition from the docs.
5f74ed5828 deprecated this many years ago.
The utility is questionable at best given that -remove exists and is
more natural to use. Free up some code and drop it.
When using -remove with list options, it previously only removed the
first match. Technically, it is possible for there to be more than entry
with the same name. They should all be removed. key/value lists
specifically only allow unique keys so we don't need to do anything
there.
ytdl lists thumbnails in ascending order according to height/preference.
all_formats=yes adds formats from best to worst, so the same should also
be done for thumbnails.
yt-dlp has a preference field for it's thumbnails, and not all of it's
listed thumbnails have fields with their dimensions.
Therefore prefere the preference field when available and fall back to
height if it's not.
Since we can no longer rely on distuils for a version comparison, let's
modify the macos-sdk-version script so it returns multiple potential
versions to meson. Then use meson's built-in version comparison to pick
the right one instead. This avoids the complication of needing certain
python packages installed since everything simply uses stdlib functions.
Since distutils was dropped from python 3.12, we can't rely on a
standard library implementation for version comparison anymore hence
the switch to packaging instead which is essentially supposed to be the
replacement. This is problematic though because macOS can have several
ways of managing python can result in the build calling the wrong python
binary that doesn't have the actual packaging library installed. This
commit was a workaround for that since it would fetch the python used to
run the build (which is probably the one the user wants), but apparently
upstream doesn't like this and it's subject to change*. So instead,
let's solve try, and solve this a different way.
This reverts commit a57bd8e2b8.
*: https://github.com/mesonbuild/meson/pull/12116#pullrequestreview-1575846647
- Use import to find Python installation.
- Run macos-sdk-version.py with Python provided by meson.
This fixes an error when meson and python-packaging are installed from
Homebrew. Currently, the Python executable from [email protected] is installed as
python3.12 so python3 is referring to system installation, which may not
have packaging module. meson can provide the correct executable via import.
This was originally for the waf build, and then later writing the output
to a file was added for meson. Since the waf build is no longer around
anymore, remove the dead code.
CLOCK_MONOTONIC_RAW is linux-specific (macOS later supported it but it
has its own timer code) and not neccessarily available everywhere like
on BSDs. It makes sense to prefer it because mpv does a lot of
measurements at small intervals (e.g. every frame) so theoretically it
should be more accurate. However if the OS doesn't have it, fallback to
CLOCK_MONOTONIC instead which is almost exactly the same and very widely
supported across unix-like systems. This clock is technically optional
according to POSIX, but any half-decent OS supports it anyway (sorry
Solaris users). As a benefit, we now know that the clock from mp_time is
always monotonic.
I'd like some names to be more descriptive, but to work with 15 chars
limit we have to make some sacrifice.
Also because of the limit, remove the `mpv/` prefix and prioritize
actuall thread name.
Python 3.10 deprecated disutils and then removed it in 3.12. The macos
sdk check uses the version compare from there, so it needs to be
replaced with something else. So instead use the API from the packaging
module which is also widely available and a fit replacement.
Fixes#12762.
dac977193c changed adding delay to only
when the video is playing but this isn't correct. The video frames
adjust themselves based on the audio, so if we still have audio
processing while the video itself happens to be in some non-playing
state (such as STATUS_READY), the delay still needs to be taken into
account. The correct thing to check is to make sure that it is not
STATUS_EOF. STATUS_EOF covers the case where we have still image, and of
course no video at all is STATUS_EOF. So having a massive bogus delay
value is still avoided.
The MPV_LEAK_REPORT environment variable was previously read in order to
determine whether or not to enable memory reporting for javascript
scripts. This is kind of weird and deviates from the norm of exposing an
option to the user. So let's just add --js-memory-report and disable it
by default instead.
--play-dir sounds like it has something to do with directories so change
it. The play_dir variable is used a bunch everywhere internally so
whatever just leave it alone instead of renaming that.
This option has exactly the same semantics are other mpv options that
override a particular thing with something from the user. So instead of
the "force-style" name, use "-overrides" which is more consistent.
The plural form is used since it's a list option.
Other similar options are in the form of --foo-override not
--override-foo. The display-fps one was backwards so flip it around the
other way for consistency reasons.
This better reflects what it actually does. As a bonus, script writers
won't be misled into thinking that fps displays the actual video or
display fps.
The point of the mpctx->delay field is for calculating a/v sync and
adjusting the frame timings appropriately. However, the frame_time was
always subtracted from mpctx->delay regardless of the audio status. This
meant that for a video with no audio, every single frame had a
subtraction with nothing ever added to it meaning that you get massive
negative delay times. For weird videos where the audio starts way later,
the massive delay leads to the VO sleeping for basically about as long
as the video was previously playing without audio. This results in
nothing being rendered during that brief period of time and just overall
badness. When using display-sync, it happens to work since the video
doesn't adjust itself based on audio and it renders anyway.
The fix is to simply not touch mpctx->delay in player/video.c unless
there's actually audio playing. This is what the rest of the code
already does aside from setting it to 0 on resets or EOFs. Move the
calculation into adjust_sync after the audio status check. It works
exactly the same as before except that we don't constantly subtract
bogus values when there's no audio playing. The reverse situation in
player/audio.c also has the same issue. For something that is only
audio, mpctx->delay is always added to but nothing will ever subtract
from it. It's not really clear if this particular version could ever
cause a real bug, but logically it needs to be guarded in the same way.
The field here should only be updated if the video is actually playing.
Fixes#12025.
The end position of the word to be completed is never used because all
patterns end with $. Remove it or it would complicate implementing
completers with more patterns.
This will allow providing more nested completions without pre-generating
an enormous amount of completions, and it is more efficient since it
only generates the completions needed for each completion attempt.
In the pursuit of stability.
It is slower and QEMU-based, but if this isn't stable, I don't know what
will be.
Bump the timeout to 30 minutes, just in case. It seems to take 12-15
minutes to finish.
Peak detection greatly increases HDR experience. Performance hit of
non-delayed detection is not that significant and is in line with
current default settings.
This fixes warnings generated for `-Wunused-result` when mpv is built
with `-O1 -D_FORTIFY_SOURCE=1` or higher on clang since read/write
functions are declared with the `warn_unused_result` attribute.
Cast to void to avoid these warnings.
It was found that this causes issues with at least ao_coreaudio,
essentially revealing a way bigger issue:
Some AOs don't check for 0 and/or have no way to deal with short writes.
Someone will have to figure out a fix later but get rid of the direct
cause for now.
This reverts commit ae908a70ce.
Any track that has attached picture is also always considered an image.
Not every image is neccesarily an attached picture though. So change the
check here to capture more possible cases where we should be updating
the subtitle. With the previous commits, this fixes#12387.
Add a simple helper to codec_tags to check if the codec name matches one
of the images. If so, then we set still_image and image in the stream as
true (slightly different semanatics).
demux_mf has a big const struct which is essentially a nice list handy
list of codecs that are considered images. This is generally useful for
all demuxers (demux_mkv could use this), so instead of making yet
another list, lift it out and put it in a common place. Some things
slightly changed so it matches the very similiar mimetype mapping struct
below it. demux_mf calls a helper mapping function instead.
This actually started having a linking error a few days ago, but the ci
never actually actually exited 1 for some reason so it was never caught.
The actual commits where this started happening are unrelated (reverted
all of the them to be sure) and there's no other obvious things like a
meson update that would cause this. All I can assume is some other
package within BSD itself, but I can't be bothered to debug it. Anyways,
just disable iconv in the build for now so the CI stops failing.
Presumably there's something wrong in the environment with GNU's
libiconv and the built-in one clashing somehow. Also, sdl unbelievably
defines HAVE_ICONV in their public header so we have to disable that
too.
Since vmactions is basically a bootlooping disaster* with no signs of
life from upstream, let's try a different action instead and hope it
works better. We don't need to force the latest release channel, so
delete that part. Also make the pkg install just one command for
simplicity.
*: https://github.com/vmactions/freebsd-vm/issues/74
I won't even comment how terrible this option is and why in 2023 default
is not at least `autocrlf=input`.
Disable the conversion to CRLF. We build everything in MSYS2 sysroot,
which supports/expects LF. While the checkout itself is done with
actions/checkout@v3 and this causes problems.
C standard says that `= {0}` activates and initializes first member of
union. We expect whole union to be zeroed, it is used as default value.
Initialize union with one zeroed default instance to ensure proper init.
Fixes: #12711
Make it not possible to build mpv without the latest libplacebo anymore.
This will allow for less code duplication between mpv and libplacebo,
and in the future also let us delete legacy ifdefs and track libplacebo
better.
Some hwdecs (eg: dxva) have no frames constraints and no static
supported_formats, which ends up segfaulting. This change fixes the
segfault, but also includes additional changes to avoid concluding that
direct output of hardware decoded video is impossible.
In the case where there are no frame constraints and no
supported_formats, we basically have no idea what the hardware actually
supports. Previously, we just tried to display the frame, but all the
work I did to detect incompatible formats causes this scenario to now
conclude that no formats can be displayed, and forces a HW download to
system memory.
I have made a couple of small changes to assume that direct display is
possible. If it's not, the VO will error out down the line, which is
what happened previously.
I'm guilty of violating this, but surely I can't be the only one. 85 is
pretty small and there's plenty of lines in the codebase that go well
over that. Surely nobody programs on tiny screens anymore and the kernel
raised the limit to 100 a few years ago so let's just copy that.
Nobody except a chosen few (I'm not one of them) even knows what it
means. Multiple people thought it was actually some kind of rendering
bug. Just disable it by default. Closes#12671.
currently for a filename such as ".file" mpv incorrectly thinks of the
entire filename as being an extension. skip leading dots to avoid
treating "hidden/dot" files as extension.
Matroska spec says that DisplayWidth and DisplayHeight should be applied
after cropping, but this doesn't adhere to the real files which does not
follow this rule. Revert the change and we can re-evaluate if someone
complains with spec compliant files.
See: https://datatracker.ietf.org/doc/draft-ietf-cellar-matroska/
This reverts commit f8db02b59d.
Unfortunately there are files out there with broken tags where the
width/height doesn't match the actual width/height of the file. That
means the cropping logic which normally should be a no-op resulting in
(0, 0, w, h) ends up being a crop which is probably not wanted by the
user. Workaround this by simply keeping the entire crop rect as 0 when
there is no container cropping. All zeros is internally treated the same
as (0, 0, w, h) and avoids bad container data messing up the width or
height of the window. Also simplify the logic a bit and get rid of some
superflorous bools that had no real use. Fixes#12680.
macOS didn't support clock_gettime until 10.12 which was released
roughly 7 years ago. Since we're breaking support for ancient OSes
anyway, we might as well break some old macOS versions for fun. This
makes 10.12 the minimum supported macOS version.
ao_read_data() is used by pull AOs potentially from threads managed by
external libraries. These threads can be sensitive to blocking.
For example the pipewire ao is using a realtime thread for the
callbacks.
since i was going to fix the include order of stdatomic, might as well
sort the surrouding includes in accordance with the project's coding
style.
some headers can sometime require specific include order. standard
library headers usually don't. but mpv might "hack into" the standard
headers (e.g pthreads) so that complicates things a bit more.
hopefully nothing breaks. if it does, the style guide is to blame.
replace it with <stdatomic.h> and replace the mp_atomic_* typedefs with
explicit _Atomic qualified types.
also add missing config.h includes on some files.
Also apply some fixes to pthread_cond_timedwait while we're at it.
Note that by using GetSystemTimePreciseAsFileTime here we lose support
for Windows 7. This is considered acceptable.
This reverts commit 318b5471a1.
While it may work, changing these two functions in violation of their documented
behaviour for the sake of a shortcut is a hack that will spell disaster sooner or later.
This is a partial revert since the commit in question also contained a hidden
bugfix where it swapped the calculation order for time_rel.
Otherwise acronyms and such would fail the lint, and it doesn't make any
sense to enforce it here. Also make sure that the length of the word is
greater than 1 to avoid something like "foo: A blah blah" from passing.
I started going through the blame but once I got to mplayer commits from
20 years ago, I stopped bothering. This obscure option has always been
disabled by default, but there's zero reason, as far as I know, to not
just enable it today. Some CDs (particularly very old ones) have the
first sector shifted a bit and not starting exactly at 0. This makes the
logic that tries to get all the chapters completely fail and thus you
can't skip through tracks. However if you just enable this obscure
option, it just works. For anything that starts exactly at 0, the
calculated offset is just 0 anyway so it's a no-op and works exactly the
same. So basically, there's literally no reason to not just always try
to correct for the offset of the first sector by default.
Fixes#8777.
It was completely wrong. mpv will buffer data ahead of where the CD
currently is playing. When enough data was buffered into the next track,
the track info is printed regardless of where the stream position
actually is. Depending on the user settings, you can get mpv to buffer
minutes ahead. Printing a message when the track changes might be nice,
but this isn't the right place to do it. Some other mechanism would need
to be leveraged, but I'm not going to bother figuring it out.
CDIO_API_VERSION 6 has been around since libcdio 0.90. That was release
over a decade ago. There's literally no reason to keep the ugly mess of
the old api around so remove it.
Some users report visible black frames during window resize, this should
not happen in most cases. Let's just keep stale content as it is less
distracting. While still clearing on first window paint to avoid white
background.
Fixes: #12642
This is more stable in practice. Avoids switching between possibly
different hwdecs and avoids unnecessary init. Software decoding should be
more stable and possibly faster overall for decoding this small portion
of video needed for cropdetect.
Use mp_tags_move_from_av_dictionary() in place of
mp_tags_copy_from_av_dictionary().
This ensures that when lavf appends metadata
that occurs later in the stream,
it starts from empty each time.
Fixes: <https://github.com/mpv-player/mpv/issues/12559>
Abstracts a common pattern,
in which the av dictionary is cleared
immediately after copying to mp tags,
so that additional tags later in the stream
get appended to empty tags,
instead of being appended to existing tags
that were already copied.
To avoid switching to scientific notation. Apparently it is "jarring"
for some users.
This preserves status quo from before 9dddfc4f where pretty printer were
truncated to 3 decimal places.
Some ffmpeg hwcontexts do not implement frame constraints. That means
they cannot report which formats are support for given configurations.
My previous changes to make hwupload more capable relies on the
constraints to be provided to accurately describe what combinations are
supported, so we will currently see a bunch of errors failing to
configure the hwupload filter on platforms such as v4l2 SoCs with
drmprime. This doesn't break playback, but it's confusing.
To bridge the gap, this change uses the static format metadata that we
include for hwdecs to build a fake constraints struct to keep all the
other code working.
Homebrew has finally given up supporting macOS 11, and all updated
dependencies are being built locally. Additionally, python3.12 - being
a dependency of libass in Homebrew - seems to completely fail under
cairo's meson usage on macOS 11, even if we let it build.
Thus, finally remove macOS 11 from our macOS build matrix, leaving
12 and 13.
ref: Homebrew/brew#16019
With the previous series of commits, all internal usage has been
replaced by the nanosecond functions. There's not really any point in
keeping these around anymore plus there are macros for unit conversions
now so we can just axe them. It's worth noting that mpv_get_time_us()
obviously still needs to work for API reasons, but we can just divide
mp_time_ns() by 1000 to get the same thing.
Pull AOs work off of a callback that relies on mpv's internal timer. So
like with the related video changes, convert all of these to nanoseconds
instead. In many cases, the underlying audio API does actually provide
nanosecond resolution as well.
There's a lot of wild 1e6, 1000, etc. lying around in the code. A macro
is much easier to read and understand at a glance. Add some helpers for
this. We don't need to convert everything now but there's some simple
things that can be done so they are included in this commit.
The whole mess with setting the option value explictly and saving the
old stop_play value only needs to happen if we're at the end of file.
Doing it in general is unneccessary and breaks other things.
Fixes#12424.
These are ancient and have existed since before stats.lua lived in the
mpv repository. We don't need to worry about ancient mpv versions
anymore, so remove these.
Why a bigger search-interval is required:
scaletempo2 doesn't do a good job when the signal contains frequencies
less then 1/search_interval. With a search interval of 30ms that means
anything below 33.333Hz sounds bad.
Depending on the genre it's very for music to contain frequencies down
to 30Hz, and sometimes even a little bit below that. Therefore a higher
default value is needed to handle such cases.
Based on that an argument can be made for a value of 50, as that should
work down to 20Hz, or something even higher because movies sometimes
have some infrasonic content.
However the downside of big search intervals is increased CPU usage and
intelligibility at higher speeds, as it effectively leads to parts of
the audio being skipped.
A value of 40 can handle frequencies down to 25Hz, enough for all music
except very rare edge cases, while still providing decent
intelligibility.
Why a smaller window-size is required:
Large values reduce intelligibility at high speeds and therefore small
values are preferred.
However when values get too small it starts to sound weird
(similar to librubberband).
In my testing a value of 10 already works well, but adding a small
safety margin seems like a good idea, especially since it made no
noticeable difference to intelligibility, which is why 12 was chosen.
The text didn't line up with with the percentages above it because it
didn't use a monospace font.
Instead insert the text at the same position in the template as the
percentages and convert one o.prefix_sep from the percentages into hard
coded \h\h to ensure alignment even when the user changes o.prefix_sep.
add support for vulkan through metal and a translation layer like
MoltenVK. also add the possibility to use different render timing modes
for testing.
i still consider this experimental atm.
add an animation lock to the window to prevent the window from closing
while animating. if this is done while the fs animation is running the
dock will stay hidden. this is not used yet, because it's unnecessary
for cocoa-cb but will be for new vo backends.
Use "%.7g" to show 7 significant digits. Removes the trailing zeros, and
in general makes it more readable, than fixed 3 decimal digits.
For avsync use "%+.2g" to add plus sign, similar to display-sync
values.
- rename prefix to `Framerate:`
- if both estimated and specified values are the same display fps once
- skip the suffix if both the estimated and specified values agrees
Source video parameters are interesting, but we mix them with video
output/target parameters. Which will differ. Add "Display" showing
true output params from VO, including HDR passthrough info and
everything. This makes much more consistent output and alows to quickly
diagnose how is source video translated to target display.
Not both of them. Formating it as `<name> (<desc>)` produced arguably
silly string like `hevc (HEVC (High Efficiency Video Coding))`. Unpack
this to show only description if available or name otherwise. Produces
way nicer results in stats.lua and similar places where this name is
printed.
This was wrongly assuming that playlist_path is always set for the
current playlist entry, but it's only set when a file was added by
expanding a playlist.
The crash in playlist_get_first_in_next_playlist can be reproduced with
mpv foo.mkv foo.zip, playlist-next, playlist-prev,
playlist-next-playlist. You need to run playlist-next, playlist-prev
first because foo.zip's playlist_path is NULL until you do that, which
makes playlist_get_first_in_next_playlist return immediately.
The crash in cmd_playlist_next_prev_playlist can be replicated with mpv
--loop-playlist foo.zip foo.mkv, running playlist-next until foo.mkv,
and playlist-play-next. Again, you need to open foo.zip first or its
playlist_path is NULL which skips running strcmp(entry->playlist_path,
mpctx->playlist->current->playlist_path).
Fixes https://github.com/mpv-player/mpv/issues/12495#issuecomment-1760968608
there are currently some silly data-races in the stop/cont sighandler
due to the fact that the signal handler might get invoked in a different
thread.
this changes those sighandlers to a pipe-based approach similar to the
existing "quit" sighandler.
tio_orig and tio_orig_set are being touched inside of signal handler
which might be invoked from another thread - which makes this a data
race.
there's no real reason to set tio_orig inside of do_activate_getch2()
which is registered as a signal handler. just set it once, in
terminal_init(), before any signal handlers come in play.
this also allows removing the tio_orig_set variable completely.
do_deactivate_getch2() touches some global variables which *might have*
been fine if the terminal thread was the one that received the signal
but AFAIK which thread will handle the signal is not well defined.
in my case, when quitting mpv with CTRL+C the main thread receives the
signal rather than the terminal thread and touches those globals without
synchronization. caught by ThreadSanitizer.
the solution is to move the do_deactivate_getch2() call outside of the
signal handler.
Use EDL for single tracks with metadata to set the uploader, channel url
and description metadata with --ytdl-format=best. Currently, these are
only set with the other ytdl formats with video and audio in different
streams.
The uploader tag is commonly available in sites other than Youtube too,
so it may be simpler to always use EDL with single tracks.
Added to the functions `mp.add_timeout` and `mp.add_periodic_timer`.
If the `disabled` argument is set to `true` or a truthy value, the
timer will wait to be manually started with a call to its `resume()`
method.
Only vpdau-copy works with EGL. 2d1d815cc7 already added this to
manpage, and 1c8d2246bf removed it again, but that seems to be a mistake
because I can only get vdpau to work with GLX, and another user also
reported that only vdpau-copy was working for him with the default EGL.
Several window resizing operations (i.e., --auto-window-resize,
border dragging with --keep-aspect-window, Alt+0/1/2) cause the
window to detach from the snapped borders. This patch resolves
this by recording to which borders the window is snapped, and
using this info to determine how the window should be placed after
resizing.
Closes https://github.com/mpv-player/mpv/issues/6588
Allows higher resolution sleeps than Sleep which has milliseconds
resolution. In practice Windows kernel does not really go below 0.5ms,
but we don't have to limit ourselves on API side of things and do the
best we can.
Linux and macOS already use nanosecond resolution for their sleep
functions. It was just being converted from microseconds before. Since
we have mp_time_ns now, go ahead and bump the precision here. The timer
for windows uses some timeBeginPeriod thing which I'm not sure what it
does really but whatever just convert the units to ms like they were
doing before. There's really no reason to keep the mp_sleep_us helper
around. A multiplication by 1000 is trivial and underlying OS clocks
have nanosecond precision.
9606c3fca9 added mp_time_ns(). Since we
apparently expose the mp_time_us() to clients already, there's no reason
to not also expose the new nanosecond one.
On linux, several platforms poll for events over a fd. This has ms
accuracy, but mpv's timer is in ns now so lots of precision is lost. We
can use an mp_poll wrapper to use ppoll instead which takes a timespec
directly with nanosecond precision. On systems without ppoll this falls
back to old poll behavior. On wayland, we don't actually use this
because ppoll completely messes up the event loop for some unknown
reason.
Originally, this was added as purely a shim for macOS. However since we
want to do high resolution polling which is not neccesarily available on
all platforms, making this a generic wrapper for poll functions is
useful so rename it.
In many cases, this is purely cosmetic because poll still only accepts
microseconds. There's still a gain here however since
pthread_cond_timedwait can take a realtime ts now.
Additionally, 37d6604d70 changed the value
added to timeout_ms in X11 and Wayland to ensure that it would never be
0 and rounded up. This was both incomplete, several other parts of the
player have this same problem like drm, and not really needed. Instead
the MPCLAMP is just adjusted to have a min of 1.
playlist-prev-playlist goes to the beginning of the previous playlist
because this seems more useful and symmetrical to
playlist-next-playlist. It does not go to the beginning when the current
playlist-path starts with the previous playlist-path, e.g. with mpv
--loop-playlist foo/, which expands to foo/{1..9}.zip, the current
playlist path foo/1.zip beings with the playlist-path foo/ of {2..9}.zip
and thus playlist-prev-playlist goes to 9.zip rather than to 2.zip.
Closes#12495.
Lines that would be outside of the visible area are now culled.
The log messages were already culled, however with the introduction
of suggestions, they also needed a small update.
Completion suggestions are now nicely formatted into a table.
Maximum width of the table is estimated based on OSD size and
font size.
This requires a new scaling factor option `font_hw_ratio`.
A factor of 2.15 works great for me,
but the default is 2.0 to avoid problems with other fonts.
The space between columns is automatically adjusted to be
between 2 and 8 spaces.
It tries to use as few rows as possible.
Tab completion now shows a list of all potential completions
between the log messages and prompt.
The text is colored to differentiate it from regular text.
The color matches the theme and is similar to the mpv logo.
The text styles are now in a table.
The color definitions of the theme where the colors were taken from
are now included in a comment for future reference.
The colors have been converted to BGR as is required by ASS.
vo_still_displaying() is racey with vo_request_wakeup_on_done() and above
that it doesn't work as expected. VO can run out of work and go to sleep
for 1000s, while the play thread still returns on vo_still_displaying()
check, because of a check `now < frame_end` so it never advances and go
to sleep itself.
This fixes dead lock that we have when image parameters changes during
playback.
This reverts commit 0c9ac5835b.
Fixes: #12575
It's 2023 and people don't use UTF-8 for their m3u, ini, etc. files.
Well mpv already has the tools in place to try and guess other
codepages, so we might as well use it I guess. This change is pretty
awkward since we have to read line-by-line but mp_iconv_to_utf8 may
sometimes allocate memory. So sometimes the bstr needs to be freed and
sometimes not for every line. Also we need to make another copy of the
line on the stack since splitting by tokens and such will mess up the
original line which may possibly be allocated memory. The ugliness is
mostly hidden in pl_free_line, but it's still weird. Fixes#10911.
There's really no reason not to do this especially since sub-codepage
already defaults to auto. Also change logging in charset_conv since
telling us that the data is UTF-8 if the passed codepage value is "auto"
or "utf-8" is really not useful information (that's the expectation).
What are cue sheets not metadata or something? No reason this needs to
be a separate option so just deprecate it. This does mean that the
default value changes from "auto" to "utf-8" for this obscure fringe
case. I really hope people don't use non-UTF-8 cuesheets, but the next
commit will change the default of --metadata-codepage to "auto" so
there's no actual change in behavior to users.
a343666ab5 made demux options public, so
we can take advantage of that here as well. This lets users guess the
codepage if the stream doesn't use UTF-8 characters. Fixes#8844.
The function called to get sub-start and sub-end returns early when the
subtitle's duration is unknown, but by just removing this check the
properties work fine. The final sub line has a very large sub-end, but
that is much better than not having the properties work at all.
fbe154831a added a new VOCTRL to signal
when the OSD changed for gpu-next's handling of subtitles, but this is
both not necessary and actually incomplete. The VOCTRL would signal OSD
changes, but not all subtitle changes (like selecting another
non-external sub track for example). VOCTRL_OSD_CHANGED was used to
increment p->osd_sync which would then redraw the blended subtitles if
the player was paused.
But there's already a VOCTRL_PAUSE and VOCTRL_RESUME. Plus, the
sub_bitmap_list object will have items in it if it changed in any way,
so we don't need the VOCTRL_OSD_CHANGED method at all. That can be
removed.
The check that fp->osd_sync < p->osd_sync stays in place since that's an
optimization while the video is playing, but we also check the pause
state as well since the VO can know this. If we're paused, then always
do update_overlays since core must be signalling a redraw to us if we
get a draw_frame call here. Additionally in update_overlays itself, the
p->osd_sync counter is incremented if we have any items since the frame
signature will need that. As for the actual bug that is fixed, changing
subtitle tracks while paused with blended subtitles now correctly works.
Previously, it was never updated so the old subtitle stayed there
forever until you deselected it (since VOCTRL_OSD_CHANGED triggered
there).
Also include some cosmetic code fixes that were noticed.
The current calculation makes the implicit assumption that the margins
on both sides are always equal (the 2 times multiplication). This isn't
true though. For example, a 720p video fullscreened on a 1680x1050
display will have a top margin of 52 but a bottom margin of 53. The
current calculation just multiplies 52 by 2, so it's off by one. Fix
this by adding together all the margins together (left + right or top +
bottom) then adding that to the dst window size (width or height). This
way, we get the full size of the window for the viewport. Fixes#12554.
This fixes white background appearing for short period of time before
first frame is drawn. Clear to black as this is way less distracting
than bright white flash.
Borderless window and fullscreen seems to be initially not
drawn/transparent, so no need to clear it to black. Only when
decorations are enabled (--border) the issue happens.
Fixes: #12549
e277fadd60 originally added this but it
never actually did anything in the function... wm4 probably changed his
mind but forget to delete it so just remove it here.
2c6a3cb1f2 originally added this struct
member and then 1be863afdb later added
some more logic to loadfile that uses this. There's been more changes
since then of course, but bits using playback_short and playback_start
have mostly stayed the same. It's a bit strange it's worked this way for
so long since it makes an assumption on how long files should be and
leads to weird, broken behavior on playlists with shorter videos. The
main reason for playlist_short, as far as I can tell, is to deal with
some fringe cases with short videos and trying to go back in the
playlist. More specifically, if you use --loop=inf on a very short video
(say less than 1 second) and try to go back in the playlist, you won't
be able to without any of this special logic that deals with it. But the
current approach has several side effects like going back multiple items
in the playlist instead of just one if the video is less than one
second. This is just bad so delete everything related to playlist_short
and playlist_start.
Instead, let's handle this by keeping track of playlist-prev attempts.
Going forward in the playlist doesn't require any special handling since
a bad/broken file will just advance to the next one. So it's only going
backwards that requires some special consideration. If we're going
backwards and the user isn't using force, then mark the playlist entry
with a special flag. If the file loads successfully in
play_current_file, we can just clear the flag and not worry about it.
However if there's a failure, then we set a bool telling
play_current_file that it should go back one more item in the playlist
if possible and try again. This way, we avoid the previously mentioned
--loop=inf edgecase and the user can still attempt to retry previously
failed items in the playlist (like a url or such).
Fixes#6576, fixes#12548.
Forgotten in 7b8a30fc81. Every other case
either is either a dummy frame (no allocated memory) or we manage it as
part of the usual wayland buffer release.
When implementing vo_dmabuf_wayland, it always did a copy of the image
from the current frame and worked with that. The reason was because
mpv's core held onto the frame and caused some timing issues and
rendering glitches depending on when it freed the image. This is pretty
easy to fix: just make vo_dmabuf_wayland manage the the frames. In vo.h,
we add a boolean that a VO can set to make them manage freeing frames
directly. After doing this, change the buffers in vo_dmabuf_wayland to
store the whole vo_frame instead of just the image. Then, just modify
some things a bit so frame is freed instead of the image. Now, we should
truly have zero-copy playback. Well as long as you don't use libass to
render anything (that's still a copy from system memory).
msg.info for when you're potentially adding hundreds of files is way
too spammy and not really useful (autoload loads files, what?). Bump it
up to msg.verbose. Also bump up the previously existing msg.verbose logs
up to msg.debug to keep the difference in log levels. Fixes#12551.
This allows libmpv users to build it as a subproject easily, i.e. meson
setup build --force-fallback-for=mpv -Dmpv:libmpv=true, if the mpv
source is in the subprojects directory. Mainly useful for development.
e125da2096 changed the z order of the
surfaces a bit, but it turns out this has a side effect. If the aspect
ratio of the actual video doesn't match your display, the osd surface
doesn't scale properly and gets clipped. Put the z ordering back where
it used to be. Instead when we have the force window case, simply attach
the already existing solid buffer to the video surface. This allows the
osd surface to actually draw over it instead of always being obscured so
it satisfies the case of not having any real video frames but still
wanting to draw the osd. Also don't mess with any of the viewport source
setting stuff with force window. Weston complains about it, and it's
nonsensical anyway. Fixes#12547.
This reverts commit 576e86bfa1 (functionally).
Right now, the --config-dir option silently causes all watch_later and cache
files to be written in the --config-dir as well. This is pretty uninitutive
and also not desirable in most cases so get rid of this.
libmpv users will have to set the corresponding options or env vars if they
want to keep the old behaviour.
Previously if the demuxer didn't exist, then it could jump down and try
to free sinfo.filename before it was ever set thus segfaulting. Just
always set the struct unconditionally so we're always sure to free it.
Some demuxers actually close the stream right after they are finished
opening like cue. Since the stream->url is no longer copied with this
commit, that means it gets thrown away after the stream closes. This
leads to a use after free. We still need to allocate stream->url so fix
this another way.
This reverts commit 3e85df3b2d.
Combine the cover art whitelist with the extensions in
--cover-art-auto-exts instead of hardcoding them. This is shorter,
checks for more extensions, saves us from updating the whitelist
everytime we add a new image extension, and since the whitelist had
gotten so big and the priority is calculated as
MP_ARRAY_SIZE(cover_files) - n, files like cover.jpg were taking
priority over cover art loaded by --cover-art-auto=exact.
0739cfc209 added the draw_frame API
deprecated draw_image internally. VOs that still used draw_image were
around, but really there's no reason to not just "upgrade" them anyway.
draw_frame is what the "real" VOs that people care about (gpu/gpu-next)
use. So we can just simplfy the code a bit now. VOCTRL_REDRAW_FRAME is
also no longer needed so that can be completely deleted as well. Note
that several of these VOs are legacy crap anyway (e.g. vaapi) and maybe
should just be deleted but whatever. vo_direct3d was also completely
untested (not that anyone should ever use it).
Remove keybindings for properties that have been removed because they
can no longer be used even if you restore them.
Replace dvb-channel-name with dvbin-channel-switch-offset.
Fix the L keybinding: it was bound to cycle-values loop when loop was an
alias for loop-playlist, but now it's an alias for loop-file.
"osd" was a command that cycles osd-level from 0 to 3.
Keep only the newest I show-text "${filename}" from mpv 0.26, the mpv
0.5 line for it is a mistake because it was bound to that in input.conf
from a749c61437 (2012) until 2e84934be7 (2017), while mpv 0.5 is from
2014.
Yeah another try at this. So when inspecting lazy_stream_needs_wait, I
realized it had a curious !ds->reader_head condition. Actually, this is
what is messing everything up. This was originally added in
cf2b7a4997 for showing large negative sub
delay values correctly. It worked because the packet will eventually be
discarded during playback causing ds->reader_head not exist and thus the
next one will correctly be read ahead as needed.
But for the "switching subtitle tracks while paused" case, this is
actually bad. As the stream is read, eventually you'll find a packet and
set the reader_head. But it's not going to be the correct packet (unless
you're looking for the very first one), so you need to read more. This
won't happen because of the !ds->reader_head check and unlike the sub
delay case, nothing will eventually discard that packet since playback
isn't occuring. So read_packet exits earlier than it should and isn't
tried again, so the subtitle that you want won't show since the
returned packet has the wrong pts. All that needs to be done here is to
delete this one condition. There's already checks in place to make sure
that it's not read past the desired timestamp and for the sub delay case
(the only other time this logic is used), it makes no difference since
you won't read past the specified pts in the first place.
The stream selection state wasn't improved. I didn't realize this messed
with caches. All in all, just not a good idea. Back to drawing board I
guess.
This reverts commit f40bbfec4f.
The timestamps when making a log file is actually dependent on
MP_START_TIME. This is a 10 microsecond offset that was added to the
timer as an offset. With the nanosecond change, this unit needs to be
converted as well so the offset is the same as before. After doing that,
we need to change the various mp_time_us calls in msg to mp_time_ns and
do the right conversion. This fixes the logs timestamps (i.e. so they
aren't negative anymore).
This causes only problems, because we convert mp_time to realtime, which
is not atomic, so we introduce error. And even though on sane platforms
it should work fine, after all the sleep time is in the past.
winpthreads like to sleep for like over 10ms when the time is less than
current time, but not more than 1s.
When seeking chapters, `last_chapter_seek` acts as a projection of
what the current chapter will be once mpv has a chance to seek to it.
This allows for more accurate results from the `chapter` property.
It works by comparing the projection to the actual current chapter
and returning the larger of the two indexes, but this only works when
seeking forward.
If we want it to work for both forward and backward chapter seeking,
we can instead use a boolean called `last_chapter_flag`, which gets
switched on when a chapter seek request is made, and then
switched off when the seek has been performed.
We should also check to ensure that we don't allow the chapter index
to be set to -1 unless there is a span of time between the very
beginning of the track and the start of the first chapter.
Since the new approach to resetting `last_chapter_seek` no longer
depends on `last_chapter_pts`, that member variable can be removed.
In practice, most compositors implement the rotation clockwise which
matches mpv's option, but amusingly this is actually incorrect.
According to the spec*, wayland buffer rotations are counter-clockwise.
So with this assumption in mind, in order for the rotation to match
mpv's usual semantics, the 90 degree and 270 degree positions need to be
flipped. Of course, this will make the VO rotate the wrong way on most
compositors, but this is what the spec says (sway master is known to
currently be correct). Fixes#12508 (sort of but will break the rotation
direction on other compositors. Oh well).
*: https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_output-enum-transform
NV16 is the half subsampled version of NV12 format. Decoders which
support High 4:2:2 of h264 provide the frame in NV16 format to establish
richer colorspace. Similar profiles are also available in HEVC and other
popular codecs. This commit allows NV16 frames to be displayed over
drmprime layers.
Signed-off-by: hbiyik <[email protected]>
This is the most supported in standard layout, if we request more it
tends to fallback to stereo instead. Also channels mask is 32-bit and it
can get truncated.
External subtitles are always read as eager, so they do not need to be
changed on pause/unpause. Don't do the refresh seek since it will just
buffer forever. Fixes f40bbfec4f.
This replaces the previous commit and makes more sense. The internal
demux marked tracks as eager depending on their type and for subtitles
it would always lazily read them unless there happened to be no
available av stream. However, we want the sub stream to be eager if the
player is paused. The existing subtitle is still preserved on the
screen, but if the user changes tracks that's when the problem occurs.
So to handle this case, propagate the mpctx->paused down to the stream
selection logic. This modifies both demuxer_refresh_track and
demuxer_select_track to take that boolean value. A few other parts of
the player use this, but we can just assume false there (no change in
behavior from before) since they should never be related to subtitles.
The core player code is aware of its own state naturally, and can always
pass the appropriate value so go ahead and do so. When we change the
pause state, a refresh seek is done on all existing subtitle tracks to
make sure their eager state is the appropriate value (i.e. so it's not
still set to eager after a pause and a track switch). Slightly invasive
change, but it works with the existing logic instead of going around it
so ultimately it should be a better approach. We can additionally remove
the old force boolean from sub_read_packets since it is no longer
needed.
Actually, I thought of a better way of handling this shortly after
merging this. Revert it and redo it in the next commit.
This reverts commit c2c157ebec.
a323dfae42 almost fixed subtitle tracks
disappearing when paused but it actually missed one part: the behavior
of demux_read_packet_async_until. It's a bit unintuitive, but for
subtitle streams, that function would only return the very first packet
regardless of whatever pts you pass to it. So the previous commit worked
on the very first subtitle, but not actually any of the others (oops).
This is because subtitle streams never marked as eager and thus never
actually read farther ahead. While the video is playing, this is OK, but
if we're paused and switching subtitle tracks then the stream should be
eagerly read. Luckily, the logic is already there in the function for
this. All we have to do add an extra argument to
demux_read_packet_async_until to force the stream to be read eagerly and
then it just works. Be sure to unset the eager flag when we're done.
Actually fixes the bug for real this time.
The default `z` of an overlay is 0, which is used by e.g. console.lua.
Having the idle logo at a `z` of 1000 means that it ends up above the
console (and anything that don't set a value higher then 1000).
It doesn't make sense for the idle logo to overshadow other things, so
put it at -1000 instead to prevent that.
It turns out that iOS doesn't actually need swift so this sdk check was
too strict and the build failed. Instead, only check this if we have
darwin and then make sure that the osdep subdir is only executed if
there are swift sources in the list. Fixes#12161.
Evidently I was wrong and mpv only actually warns once on deprecation
(playlist-pos nor display-fps did not and warned every time, but those
were outliers apparently). Someone complained so just hack it into
command_ctx for now.
Calling wl_display_disconnect closes the file descriptor, no need to
manually do it ourselves beforehand which causes a double close on the
fd.
Signed-off-by: Jack Mitchell <[email protected]>
0b4860248b added user-data which is
completely superior and makes this property obsolete. We've already had
one mpv release with the osc using user-data so drop this.
I removed the previous WHEEL_UP and WHEEL_DOWN bindings because they are
duplicate, and it appears that they were already bound to seek 10 before
7897f79217.
There was a discrepancy in what the keybind was advertised to do in the
manual, and what the comment in input.conf described it to be doing. It
makes very little sense to add a keybind that changes the default and
doesn't allow you to get back to the default. This keybind is much more
useful if it toggles between yes/force instead of no/force.
Copy and pasted from commit msg lint obviously, but I forgot to rename
it. Oops. Capitalize the name field while I'm at it (seems like all the
other workflows do it too).
When someone purely changes some documentation or something similar,
there's no point in having the whole CI build go off. This also leads to
the bot spamming a comment linking to artifacts. This is only useful if
actual source code changes (i.e. so users can test if need). So just add
a path filter to blacklist directories we don't want to consider. If all
changed files match those directories then the CI won't run.
Purely cosmetic, but this weird inconsistency bothered me. There's
techincally vd_lacv_params and ad_lavc_params too, but encode is special
and maybe shouldn't exist so we'll just leave that alone.
Similar to the previous commit. There's no reason for --bluray-device to
be in MPOpts. Make a specific subopt for stream_bluray and use that
instead so we can remove the mp_read_option_raw call.
There is zero reason for this to be an MPOpt. Because of how the
OPT_SUBSTRACT works, the option gets renamed to cdda-device instead, but
probably not a big deal since the old alias is still in place.
With the previous commit, we can just access option values directly now
and avoid a lot of complication. Note that the mp_read_option_raw call
for edition requires calling mp_get_config_group since that option needs
to live in MPOpts.
Several parts of the code need to access options here. There's no point
in hiding it demux.c so just expose it in the demux.h header. This means
pulling it out of demux_internal and putting it in the demuxer struct
instead.
`demux->duration` is set to -1 on initialization, and some checks rely
on it being -1 when unknown. Before this commit, we set
`demux->duration` to 0 when unknown. This is incorrect and breaks rtsp
logic for disabling seeking outside of cached regions.
To fix these issues, initialize `total_duration` and `av_duration` at
-1. They're only changed if a real duration is detected, so in cases
where the duration is unknown, demux->duration is set to -1 correctly.
Fixes: e6afc53e7c ("demux_lavf: get total duration from track durations")
Apparently removing WS_CAPTION disables some window animations. Instead
adjust non-client area to not draw title bar.
Note that we do not account for difference in real border size and
invisible one, but seems to work correctly.
I don't think in fullscreen mode it makes sense to enable rounded corners.
We can add another option if someone needs it, but for now `window_corners`
affects only the window as one would expect.
With the addition of fractional scaling support, wl->scaling was
converted to a double. Some compositors (Plasma) can report values under
1 for fractional scaling, so this meant wl->scaling could be some
small fractional value. This is fine except that when using the legacy
code for drawing the mouse cursor (i.e. not the cursor-shape protocol),
it still uses the old integer scaling method in core wayland. The reason
for this is simply because fractionally scaling the mouse cursor surface
is nonsense and nobody even has cursor images for anything besides a
select few sizes anyways (32x32, 48x48, etc.). The existing integer
scaling sort of works but it's pretty bad too and you can get some weird
sizes anyway. This is why cursor-shape is preferred since it fixes this.
Anyways, since buffer scaling for the cursor only takes integers, there
could be truncation to 0 in the previously mentioned fractional scale
this. This naturally causes the compositor to send us an error and mpv
quits. The fix is to always make sure that the scale value used for the
cursor is at least 1. Anything less makes no sense. Fixes#12309.
There was assumption in the code that default settings are compatible
with dumb mode and are only one that should be used in this case.
Force bilinear if dumb mode is enabled.
ac725764ec originally added these to
prevent those profiles from having auto as a value. However the auto
value was removed in 53d032374d later. So
having these lines here no longer serves any purpose since the default
value for slang is NULL once again (vlang/alang were never needed here).
These were deprecated a long time ago and apparently didn't even work
with lavfi filters. Go ahead and remove them and additionally clean up
some code related to them. m_config_from_obj_desc_and_args becomes much
simpler now and a couple of arguments can be completely removed.
No wonder wm4 wanted to get rid of this. This option requires touching a
bunch of crap in the core player code. --stream-record works perfectly
fine and is a lot nicer so there's no need for this to exist anymore.
A bit different from the OPT_REPLACED/OPT_REMOVED ones in that the
options still possibly do something but they have a deprecation
message. Most of these are old and have no real usage. The only
potentially controversial ones are the removal of --oaffset and
--ovoffset which were deprecated years ago and seemingly have no real
replacement. There's a cryptic message about --audio-delay but who
knows. The less encoding mode code we have, the better so just chuck
it.
e9e93b4dbe added a warning about writing
the same value to the playlist-pos property that in the future it would
stop restarting playback. Instead, you should use the
playlist-play-index command for that. Well go ahead and drop the old
deprecated behavior now and do what wm4 wanted this to do: just ignore
if the same value is written again.
drop-frame-count and vo-drop-frame-count are ancient and have no reason
to exist anymore. The other change is that support for writing to
display-fps has been removed, and the property is strictly read-only
now. 3a2dc8b22e is what deprecated it with
a warning to users, so we can remove it without much trouble.
We've got an ungodly amount of OPT_REPLACED and OPT_REMOVED sitting
around in the code. This is harmless, but the vast majority of these are
ancient. 26f4f18c06 is the last commit
that touched the majority of these and of course that only changed how
options were declared so all of this stuff was deprecated even before
that. No use in keeping these, so just delete them all. As an aside,
there was actually a cocoa_opts but it had only a single option which
was replaced by something else and empty otherwise. So that entire thing
was just simply removed. OPT_REPLACED/OPT_REMOVED declarations that were
added in 0.35 or later were kept as is.
The osd support was originally written with the requirement that we have
actual frames getting delivered to the VO. This isn't always the case
though. If you force a window on a blank audio file for example, then
there will be no frame thus draw_frame did nothing. Since the previous
commit allows us to reliably detect this, we can rearrange the code
around a little bit to make this possible. A key change is to make the
osd_subsurface have wl->surface as the parent. This is seemingly
required otherwise the osd_surface buffers are never visible above the
empty video_surface when we have a black window. Also nuke the desync
call since it's completely pointless. Fixes#12429.
I didn't set file-local-options/hwdec because you have to store the
hwdec value to restore it after cropdetect anyway, and if the user
manually changes hwdec after cropdetect, the new value isn't reset when
changing file.
If you change file while cropdetect is active and you try to crop the
next video, it fails with "Already cropdetecting!". This is because
timers.detect_crop wasn't cleared correctly, only the timer variable
local to the loop was being set to nil.
The defaults were awful and horribly regressed many files while also not
fixing banding on files that actually needed it, sometimes even
*increasing* banding due to the low threshold.
Fixes: 12ffce0f22
See-Also: haasn/libplacebo@e1e43376d1
This probably makes `vo_gpu` tone mapping worse, or something, but who
cares. The status quo for a while now has been to use `vo_gpu_next` if
you care about HDR rendering at all.
See-Also: haasn/libplacebo@ec60dd156b
See-Also: haasn/libplacebo@0903cbd05d
This new filter is slightly sharper, and significantly faster, than
mitchell. It also tends to preserve detail better. All in all, there is
no reason not to use it by default, especially from a performance PoV.
(In vo_gpu_next, hermite is implemented efficiently using hardware
accelerated bilinear interpolation)
See-Also: https://code.videolan.org/videolan/libplacebo/-/commit/75b3947b2c07803456483ec6976c037bad91b5dd
It can hurt people's feelings to refer to scalers as "high quality" and
"low quality", when it is so subjective.
I decided to preserve the lanczos sections at least because it's mostly
talking about the difference between EWA Lanczos and Lanczos, which is
less controversial than the difference between, say, Lanczos and
Catmull.
Avoid generating too much audio after EOF.
Note: This often has no effect, because less audio is produced than
required.
Usually this comes to effect with the userspeed filter at high speed
(4x) and going back to 1x speed to remove the filter.
After the final input packet, the filter padded with silence to allow
one more iteration. That was not enough to process the final frames.
Continue padding the end of `input_buffer` with silence until the final
frames have been processed.
Implementation: Instead of padding when adding final samples, pad before
running WSOLA iteration. Count number of added silent frames and
remaining input frames for time keeping.
This changes the emitted pts values from the start of the search block
to the center of the search block. Change initial `output_time`
accordingly. Initial `search_block_index` is irrelevant, because it's
overwritten before the first iteration.
Using the `output_time` removes the rounding of `search_block_index`,
which also fixes the <20 microsecond gaps in timestamps between output
packets.
Rationale:
The variance in audio position was in the range `0..search-interval`.
With this change, the range is
(- search-interval / 2)..(search-interval / 2)`
which ensures lower maximum offset.
Target block can be anywhere in the previous search-block, varying by
`search-interval` while the filter is active. This resulted in constant
audio offset when returning to 1x playback speed.
- Move the search block to the target block to sync up exactly.
- Drop old frames to minimize input_buffer usage.
The internal time update function involved multiple problems:
- Time was updated after WSOLA iteration. The means speed was updated
one iteration later than it could be.
- The update functions caused spikes of too many or too few samples
advanced, leading to audio glitches on speed changes.
- The inconsistent updates made it very difficult to produce gapless
audio packets.
- The `output_time` update function involved complicated feedback:
`search_block_index` influenced how many frames from `input_buffer`
are retained, which influenced how much `output_time` is changed,
which influenced `search_block_index`.
With these changes:
- Time is updated before WSOLA iterations. Speed changes are effective
instantly.
- There are no spikes in playback speed during speed changes.
- No significant gaps are introduced in output packets.
- The time update function becomes (function calls omitted for brevity)
output_time += ola_hop_size * playback_rate
Functions received a `playback_rate` parameter to check how many samples
are needed before iteration. Internal state is only updated when the
iteration is actually run, so the speed is allowed to change until
enough data is received.
The first WSOLA iteration overlapped audio with whatever was in the
`wsola_output` buffer. This was either silence (if not run before), or
old frames (if switching to 1x and back to a different speed).
Track the state of the output buffer and memcpy the whole window for the
first iteration instead.
`output_time` is used to set the center of the search block. Init of
both `search_block_index` and `output_time` with 0 caused inconsistent
search block movement for the first iterations.
Initialize with `search_block_center_offset` for consistency with initial
`search_block_index`.
Fixes#12028
There was an additional issue that audio was always delayed by half the
configured search-interval. This was caused by the `out` buffer length
not being included in the delay calculation.
Notes:
- Every WSOLA iteration advances the input buffer by _some amount_, and
produces data in the output buffer always of size `ola_hop_size`.
- `mp_scaletempo2_fill_buffer` is always called with `ola_hop_size`
- Thus, the rendered frames are always cleared immediately after
processing, and `num_complete_frames` is 0 in the delay calculation.
- The factors contributing to delay are:
- the pending samples in the input buffer according to the search
block position, and
- the pending rendered samples in the output buffer (always empty in
practice).
The frame_delay code looked like that of the rubberband filter, which
might not work for scaletempo2. Sometimes a different amount of input
audio was consumed by scaletempo2 than expected. It may have been caused
by speed changes being a more dynamic process in scaletempo2. This can
be seen by where `playback_rate` is used in `run_one_wsola_iteration`:
`playback_rate` is only referenced after the iteration, when updating
the time and removing old data from buffers.
In scaletempo2, the playback speed is applied by changing the amount the
search block is moved. That apparently averages out correctly at
constant playback speed, but when the speed changes, the error in this
assumption probably spikes. This error accumulated across all speed
changes because of the persistent `frame_delay` value.
With the removal of the persistent `frame_delay`, there should be no way
for the audio to drift off. By deriving the delay from filter buffer
positions, and the buffers are filled only as much as needed, the delay
always stays within buffer bounds.
Very amusingly, the manual previously said "The rpi VO will be removed
in mpv 0.23.0." Obviously, this didn't happen. It looks like wm4 changed
his mind on this with 51fd8f6fe1, but
never updated the docs. What was the problem? Who knows but allegedly
there are people that use --vo=rpi (it's supposed to work at least).
Actually context_rpi is probably broken since wm4 changed fullscreen
handling in 59cdfe50b2 and no one ever
bothered to fix it after that commit. In fact, that's the last commit
that touched that particular file. Someone did actually fix vo_rpi after
that so that one probably works at least. Anyways, I wouldn't mind just
deleting all rpi stuff, but there's probably some people out there that
use it so whatever. Remove the outdated deprecated language in the
documentation and just accept that we support this unfortunately.
Defining MPV_CPLUGIN_DYNAMIC_SYM during plugin compilation will replace mpv_*
functions with function pointers. Those pointer will be initialized when
loading the plugin.
It is recommended to use this symbol table when targeting Windows. The loader
does not have notion of global symbols. Loading cplugin into mpv process will
not allow this plugin to call any of the symbols that may be available in
other modules. Instead cplugin has to link explicitly to specific PE binary,
libmpv-2.dll/mpv.exe or any other binary that may have linked mpv statically.
This limits portability of cplugin as it would need to be compiled separately
for each of target PE binary that includes mpv's symbols. Which in practice
is unrealictis, as we want one cplugin to be loaded without those restrictions.
Instead of linking to any PE binary, we create function pointer for all mpv's
exported symbols. For convinience names of entrypoints are redefined to those
pointer so no changes are required in cplugin source code, except defining
MPV_CPLUGIN_DYNAMIC_SYM. Those function pointer are exported to make them
available for mpv to init with correct values during runtime, before calling
`mpv_open_cplugin`.
Note that those pointer are decorated with `selectany` attribute, so no need
to worry about multiple definitions, linker will keep only single instance.
This fixes cplugin usability on Windows. Without any API changes, only
recompilation with -DMPV_CPLUGIN_DYNAMIC_SYM is needed.
The goal is to provide simple to understand quality/performance level
profiles for the users.
Instead of default and gpu-hq profile. There main profiles were added:
- fast: can run on any hardware
- default: balanced profile between quality and performance
- high-quality: out of the box high quality experience. Intended
mostly for dGPU.
Summary of three profiles, including default one:
[fast]
scale=bilinear
cscale=bilinear (implicit)
dscale=bilinear
dither=no
correct-downscaling=no
linear-downscaling=no
sigmoid-upscaling=no
hdr-compute-peak=no
[default] (implicit mpv defaults)
scale=lanczos
cscale=lanczos
dscale=mitchell
dither-depth=auto
correct-downscaling=yes
linear-downscaling=yes
sigmoid-upscaling=yes
hdr-compute-peak=yes
[high-quality] (inherits default options)
scale=ewa_lanczossharp
cscale=ewa_lanczossharp (implicit)
hdr-peak-percentile=99.995
hdr-contrast-recovery=0.30
allow-delayed-peak-detect=no
deband=yes
scaler-lut-size=8
296d40dc6f changed how the vo handled
redraw requests in order to fix a race condition that can occur with
pausing. However, there was a slight oversight because a redraw request
that occurred while the core was unlocked and the video was still
playing would still be kept true (previously, this was always cleared).
That redraw is essential if mpv is paused otherwise the old issue comes
back, but if the video is playing it's unnecessary since the next loop
around will simply draw whatever we needed. The extra redraw could cause
a frame drop for some people in certain instances, so the solution is to
simply always clear redraw requests if !in->paused. This eliminates the
extra redraw but still keeps it when pausing.
Fixes#12426 and fixes#11579.
After fixing the B and C params for bcspline, it ended up being the same
thing as bicubic. There's no reason to have two names for the same
filter, so remove bcspline and keep bicubic to match libplacebo.
All we have to do is set VO_CAP_ROTATE90 and then use buffer transform.
Maybe ideally we would rotate with vavpp instead if possible, but this
would be a convoluted mess that I'm not really interested in dealing
with right now.
No need for this since it's entirely redundant with just changing the
filter radius directly. In fact, that's the whole *point* of the filter
radius - it does not modify the filter, it modifies the scaling of the
window.
Of course, this does not work for non-resizable kernels. But, really,
who cares?
Replaced by mathematically and numerically precise constants, the result
of exact computation. Also updates the description to provide more
explanation and motivation.
We currently always scaled the window to the size of the configured
radius. However, this is wrong - we should instead be scaling it to the
size of the sharpened/blurred kernel. Since the window is always
stretched to the configured size of the filter, we can accomplish this
easily by just multiplying the blur value into the filter radius
directly, and then using that adjusted radius in place of `f.radius`
everywhere.
On a side note, this gives a very minor performance boost to
ewa_lanczossharp for no downside.
Upstream finally caved in to peer pressure and added this filter. Of
course, this also removes the fallback for people on older versions of
libplacebo, but people using mpv git master are probably using
libplacebo git master anyway. It's time to debloat this code.
And make it the default. In libplacebo, this uses internal heuristics to
pick a good size based on the actual ICC characteristics. This is
significantly less wasteful than always generating a 64x64x64 3DLUT (the
old status quo).
In vo_gpu, for simplicity, just default to 65x65x65. Note that this
provides slightly better accuracy than the old default of 64x64x64 for
technical reasons, and matches what libplacebo defaults to for typical
display profiles.
Upstream has moved from passing struct pl_icc_profile to directly
attaching a managed pl_icc_object, plus providing a new function
pl_icc_update to update the ICC profile object parameters (if needed).
To facilitate this move, pull our ICC params back out of pl_options and
update the target ICC object directly.
The original OML sync implementation (which is where this calculation
originally comes from) made now_monotonic and ust_mp_time unsigned. This
is fine except it has the assumption that now_monotonic is always
greater than ust. This actually isn't always the case. In wayland, I
observed instances where the reported timestamp is in the future. Of
course, it's a valid question to wonder if this even makes sense but
these UST values are essentially opaque black boxes to us anyways. It's
entirely plausible that the gpu is expecting the actual presentation of
the last swap to be a bit in the future, the compositor gets this and
reports this to us. So we'll consider such stats as valid. Note that
xorg doesn't have this problem because it's roughly one swap buffer call
behind because of how the event loop works (honestly something that
should be fixed).
Of course, the problem with the unsigned type here is that it overflows
on the subtraction so make it signed and allow the appropriate negative
value to happen if it does. Note that this will simply result in a small
addition to mp_time_us() which is exactly what we want here (timestamp
slightly in the future). Some small style changes included just because.
This option behaves the same as the builtin one, and if it's value
is anything other then recursive|lazy|ignore it will fall back on the
builtin one as a sort of "auto" mode. It defaults to that auto mode.
Adds support for adding directories to the playlist in addition to
files. The propertiy `directory-mode` controls if directories get added.
Recursive directory loading will get added in a later commit.
Directories get sorted after files to behave the same way mpv
behaves when it loads directories directly.
The GNOME Nautilus file manager supports browsing of dav:// and davs:// links only. Additionally, dav:// and davs:// are also types of webdav links. Therefore, adding an "or" operation to include support for dav:// and davs:// links.
Adds catmull_rom as an example for --scale in the user manual, alongside
a brief description of the filter.
catmull_rom was only exposed to users as an available filter through
--scale=help. However, catmull_rom is very often aliased as "Bicubic" in
other applications such as GIMP and VapourSynth, and is a relatively
popular resizing filter. The documentation lacked any description of
catmull_rom, outside of a brief mention of it in the --tscale section.
Packet duration is not necessarily related to the display time of the
subtitle. Use start/end_display_time fields as source of the timing.
Fixes subtitles with infinite duration that should be on screen until
next sub is displayed.
While this resolves limitations of lavc decoder crop, it also introduces
artifacts with some of the source files or hwdec.
Depending on chroma sampler it is possible to sample outside the decoder
crop area, pulling dirty pixels into the image. Some decoders left them
zeroed, not black. To fix that we would need specifc solution during
mapping of avframes.
As most of the files require the crop only in bottom/right area, the
AVCodecContext::apply_cropping works ok for those.
For all other cases that require more fancy cropping like 1440x1080+240+0
user can manually set `--vd-apply-cropping=no`.
Limitations of the lavc crop are explained here:
https://ffmpeg.org/doxygen/trunk/structAVCodecContext.html#a4745c7455c317272c4e139d6f369936c
Fixes: 826ce82cad
In the never ending quest of trying to satisfy every possible user
request for subtitle autoselection, I ended up redoing how
--subs-fallback-forced works. The old behavior had it as strictly a
fallback-type option when there were no lang matches, but now we can
make it an active part of compare_track and it works along with slang to
select the desired track. Since it's a three state option, the no option
still works to avoid selecting any forced subtitle tracks. The meaning
of always slightly changes to mean "only select forced subtitle tracks"
and yes remains essentially the same (no special priority given besides
the audio matching subtitle language case).
So strangely enough, estimated_vsync_interval is stored as a double but
nominal_vsync_interval is not and neither is the vsync_interval. Those
are stored as int64_t. This loss of precision can matter even in common
cases. For instance, take a typical 60 Hz monitor. Instead of 16666.6666
(repeating) being calculated as the vsync interval, you would get 16666
since the decimals are truncated. This is not really good at all and
affects the calculated speed values you get when using display sync. For
consistency and better precision, these should all be doubles just like
estimated_vsync_interval. Technically this means that we won't be able
to store as high of an integer value but such values would be absurdly
huge and never actually needed. Also estimated_vsync_interval already
can't handle such a case anyway.
Timestamps are converted from microsecond resolution timestamp, we don't
have more precision, so we have to account for that when comparing the
floating point values as them will slightly be off.
Fixes: #12327
Interrim solution, forwards compatible with new and backwards compatible
with old API. Eventually, we will want to discontinue the use of
deprecated pl_icc_params.save/load and pl_renderer_save/load, but that
requires minimum version bump.
Cropping by decoder has limitations with regards to aligment and hwdec.
It doesn't work to offset top left corner with hwdec and even with
software decoding it don't crop fully when resulting data would not be
aligned.
VO cropping is way more robust.
Setting `--video-crop=0x0+0+0` applies full frame crop, ignoring the
container one. Setting --video-crop=0 disables manual crop and restores
container one if it is available.
This makes it easier to apply crops without need to manually calc the
offset. I wanted for it to be top-left corner based, but maybe it was
not that good idea in retrospect.
Also rename scrw/scrh, since they don't refer to screen. It was copied
form m_geometry apply.
Third try is the charm? I stupidly missed that this option already
existed in my previous commits. Instead, add an auto value to it and
enable it by default for sd_lavc but not sd_ass. On my limited samples,
it seems to fix the gaps issue that can occur but without regressing
some duration timings for sub_lavc subtitles. Well hopefully anyway.
Fixes#12327.
Yet another bad idea. It turns out that there's already a sub-fix-timing
option which logic for this exact thing (overlaps/gaps) fixing. Also it
works better than this since it doesn't appear to artifically increase
sub duration either. Fixes#12327.
This reverts commit 725b631ec3.
mpv saves cache by default nowadays, but vo_gpu is pretty spammy and
saves a bunch of files per shader. If someone is using the non-XDG
config directory, this all gets dumped directly into ~/.mpv which isn't
so nice. Save it to a sub directory called "cache" instead (or
alternatively submit to your XDG overlords). For unfortunate reasons,
macOS uses XDG_CONFIG_HOME and has the same legacy fallback mechanism,
so this applies to it too.
We currently only allow specifying the Vulkan device to use by name. We
did this to avoid confusion around devices being enumerated in an
unpredictable order. However, there is a valid edge case where a system
may contain multiple devices of the same type - which means they will
have the same name, and so you can't control which one is used.
This change implements picking devices by UUID so that if names don't
work, you have some option available. As Vulkan 1.1 is a hard
requirement for libplacebo, we can just use UUIDs without conditional
checks.
Fixes#10898
In the previous change, I added the uuid files. In this change, we
check the libavutil version and if it's too old, we compile in our
local copy.
We have to change the include paths of the uuid code to find some other
libavutil headers, but nothing beyond that.
To avoid taking a dependency on ffmpeg 5.1 before we're ready (we need
a newer Ubuntu LTS release to drop ffmpeg 4.x support), ut not force us
to wait to add support for picking Vulkan devices by UUID, I'm copying
the uuid code from ffmpeg into mpv. It's one file with no private
dependencies, so it's easier to copy than to reimplement in any other
way.
Licence is LGPL so matches us.
We were over-enthusiastic when introducing --no-config into the
autocompletions. When autocompleting profiles, you actually need the
config, because that's where the profiles come from.
zsh is untested - I don't use it.
The old mplayer / zap style format is not fully standardized across
channel scanners, so autodetection may fail if the file name
does not indicate the delivery system.
While ZAP config files should contain strings in most fields,
their field number in the DVB-T / ISDBT case matches the number of fields
for VDR config files, and some channel list writers (namely, dvbv5-scan)
may insert "0" in unused string fields.
To disentangle such config files from real VDR config files,
add a check for the "INVERSION_" field which should always be filled.
dvb_get_channels is expected to append to an existing channel list.
For adapters supporting many delivery systems, a subsequent channel list
may turn up with a non-existent channel config, and the pointer
to the previously parsed channel list may be lost
(i.e. the list will be leaked and no channels detected).
Fix this by passing through the existing list (which may be NULL)
in case no new channels are found.
This is similar to DVB-T, but requires slightly different treatment
as there is no T/T2 differentiation.
Use a new channels.conf.isdbt file as channels config file.
Causes bad performance with interpolation because the changing hue angle
invalidates the mixing cache, as a result of libplacebo implementations
(specifically, the fact that this graph is drawn during the color
management process, instead of as a separate overlay).
Fix it by just hard-coding a particular, relatively interesting plane
(pi/4 approximately maps onto the red-blue axis).
Before this change, mpv used to get the total duration from
`avformat_find_stream_info` and used the per-track duration as a
fallback. This change reverses this order of preference.
The timestamps returned by `avformat_find_stream_info` are truncated or
rounded or floored (depending on the decoder) at the 6th decimal place.
For e.g. `avformat_find_stream_info` may return us a duration like
44.138667, whereas the duration we get from the per-track struct has a
higher degree of precision like 44.13866666666... and so on.
This caused various problems such as the playback_pts being a bigger
value than the duration, which would cause time-remaining to be a
negative value in some cases. Or cause you to reach a negative starting
timestamp when looping on an audio file with `gapless-audio`.
Moreover, we already skipped calling `avformat_find_stream_info` for
mp4, so we had already been utilizing this per-track fallback method for
finding the duration for mp4 files. It should be noted that while this
change is only required for audio-only formats, there is no harm in
doing this for videos as well.
There are way too many preexisting scripts that rely on this behavior
for video panning, like for example scripts that allow you to use mpv as
an image viewer. If this behavior is desired then it may be better to
add a new option for panning relative to the destination instead.
The restriction of video-pan-x/y being clamped to {-3, 3} also results
in the video being impossible to pan if it was zoomed in beyond a
certain degree.
This reverts commit 7d6f9e3739.
the osc currently allows for changing volume via scrolling when on top
of the volume icon. this does the same thing for the seekbar by allowing
seeking via scroll.
The default revert will always add 9 extra characters which means it
could go over the 72 character soft limit if the commit being reverted
has a long subject. We won't fuss about this so just shut up the lint in
this case.
`--vo=gpu-next` no longer uses this option, being replaced entirely by a
luminance-based approach internally. And even for `--vo=gpu`, the values
other than 'hybrid' are universally inferior in quality.
In the interest of gradually reducing the amount of option bloat here,
remove this mostly-pointless option.
fbe8f99194 made it possible for mpv to
autoselect forced subtitles again (it was bugged and would ignore
without slang being specified). Unfortunately, I forgot to take slang
into account here, so it would always autoselect the subtitles if they
are available. Fix this by checking both that it matches the lang and
that the previous track pick wasn't already matched (os_langs being true
is essentially equivalent to there not being any specified slang). This
way, it still respects the order of languages in your slang list.
Probably someone out there will be upset that forced subtitles aren't
always preferred regardless of the order, but that can be another option
for later I guess.
Prevents transient brightness spikes on scene transitions at the cost of
sometimes forcing an extra indirect pass (in particular, when
downscaling). But on GPUs powerful enough to run gpu-hq, the extra
indirect pass shouldn't matter too much. This option mostly exists for
weak iGPUs.
DVD/PGS are definitely not common, and ones that make use of the forced
subpictures flag even less so. For this button to be useful, the
subtitle track would need to be DVD or PGS, the track would need to make
use of the forced flag, the user would have to know what forced
subpictures are, and the user would need to have the preference of only
viewing forced subpictures on a subtitle. The function of this button is
too niche to be on the osc, if this behavior is desired the user can
simply bind a key in their input.conf. Moreover, this button only adds
confusion because there's no intuitive way to show what it does, and
there's no explanation for it anywhere in the manuals. osc real-estate
is quite limited as it is, so let's not waste any space on buttons with
highly questionable utility at best and confusing or bad UX at worst.
Gated behind option for backward compatibility.
Note that this will not magically start working with hwdec, as we do not
have crop detection for hwdec.
64959c450d solved the problems with resuming playback, so default to
--directory-mode=lazy because it's faster, especially on slow drives,
and results in smaller playlists.
Pick a smarter rect, limit it to right half of screen (to allow more
easily using it simultaneously with stats), and also auto-rotate through
the hue plane by default (wrapping once every 10 seconds of playback).
I briefly considered making it based on wallclock time instead of pts,
but this has the rather unfortunate downside of only being updated
sporadically as the user moves the mouse over OSC elements. (Of course,
we could also forcibly redraw the screen continously to avoid it, but
I'd rather not make such an invasive change for no real reason)
This design also allows you to pause and focus on (via framestepping)
individual parts of the hue graph that you're interested in.
Wheel being seek by default is very unintuitive and surprising to a lot
of users. It seems to be one of the things most consistently complained
about in the default UI. I change this on all of my devices, and so do
many others.
It's trivial for users who like the old behavior to change it back.
If --slang was set to some language and it matched the subtitle track,
then --no-subs-with-matching-audio would do nothing. Fix the logic by
doing the --no-subs-with-matching-audio step at the end to ensure that
it always "wins" over whatever --slang or --subs-fallback has set.
Clarify the docs a bit to make it clearer that this is the intended
behavior. Fixes fbe8f99194.
Since we no longer have the auto choice, this is always exactly equal to
the value of the option (sub-forced-events-only). Remove the property
and alias it.
The old name is pretty bad and users mistakenly think it has something
to do with selecting forced subtitles (that would be
--subs-fallback-forced). Instead of giving it such a generic name, make
it clearer that this has to do specifically with forced sub events
which is only relevant for a small minority of subtitles.
First of all, this never worked. Or if it ever did, it was in some
select few scenarios. c9474dc9ed is what
originally added support for the auto choice. However, that commit
worked by propagating a value to a fake option used internally. This
shouldn't have ever worked because the underlying m_config_cache was
never updated so the value shouldn't have been preserved when accessed
in sd_lavc. And indeed with some testing, the value there is always 0
unsurprisingly.
This was later rewritten in ba7cc07106
along with a lot of other sub changes, but with that, it was still
mostly broken. The reason is because one of the key parts of having to
hit this logic (prefer_forced) required `--no-subs-with-matching-audio`
to be set. If the audio language matches the subtitle language (the
requirement also excludes forced subs), the option makes no subtitle
selection in the first place so pick->forced_only_def is not set to true
and nothing even happens. Another way around this would be to attempt to
change your OS language (like with the LANG environment variable) so
that the subtitle track gets selected but then audio_matches mistakenly
becomes false because it compares the OS language to the audio language
which then make preferred_forced 0, so nothing happens. I don't think
there's a scenario where pick->forced_only_def is actually set to true
(thus meaning `auto` is useless), but maybe someone could contrive
something very strange. Regardless, it's definitely not something even
remotely common.
fbe8f99194 changed track selection again
but didn't consider this particular case. The net result is that DVD/PGS
subs become equivalent to --sub-forced-only being yes, so this a change
in behavior and probably not a good one. Note that I wasn't able to
actually observe any difference in a PGS sample. It still displayed
subtitles fine but that sample probably didn't have the right flags to
hit the sub-forced-only logic.
Anyways, the auto feature is extremely questionable at best and in my
view, not actually worth it. It is meant to be used with
`--no-subs-with-matching-audio` to display forced pictures in subtitle
tracks that are not marked as forced, but that contradicts that
particular option's purpose and description in the manual (secretly
selecting a track under certain conditions even though it says not to).
Instead of trying to shove all this logic into select_default_track
which is already insanely complicated as it is, recognize that this is a
trivial lua script. If you absolutely want to turn --sub-forced-only on
under these certain conditions (DVD/PGS subtitles, matching audio and
subtitle languages, etc.), just look at the current-tracks property and
do your thing. The very, very niche behavior that this option tried to
accomplish basically never worked, no user even knows what this option
does, and well it's just not worth supporting in core mpv code. Drop
all this code for sanity's sake and change --sub-forced-only back to a
bool.
The README says Windows 7 and up, but the reality is that Windows
development is not done with 7 in mind and there are several known
issues that nobody is going to fix. Change this to 10 to reflect
reality. Also add a small paragraph explaining that we don't
intentionally break old systems, but don't expect them to always work.
Also change OSX to macOS.
- Move window scale to scaled resolution line
- add deinterlacing display
- rename "Gamma" to "Transfer"
- reorder to colormatrix/primaries/transfer as commonly used by
ffmpeg/ffprobe
In general, forced tracks should only be shown if they match the
language of the audio. However some people do want them no matter what,
so add an always option to this so such tracks are always selected.
This is the replacement for the previous auto option for slang. It
behaves similar however it never overrides slang if that is set and will
instead try to pick the subtitle that matches the user's language if
appropriately flagged by the file.
What was previously there is extremely complicated and really confusing.
Poorly named variables like "prefer_forced" that don't neccesarily have
anything to do with prefering forced tracks didn't help either. Try to
rewrite a few things to be saner. The idea is that after you loop
through the tracks, the special sub-specific options (like subs-fallback
and so on) should be handled and the track should be deselected if
appropriate. Another change is to remove the "prefered_forced" argument
in compare_track. This actually was both not neccessary and caused bad
behavior by always depriortizing forced tracks even when it didn't apply
(e.g. forced video tracks were never selected even though the flag
should simply be ignored for anything that's not a subtitle track).
This proved to be too problematic. Depending on the value of
--subs-with-matching-audio, you could either end up with cases where
--slang wasn't respected and users didn't get subtitles or alternatively
cases where subtitles were given and the user didn't ask for them.
Fundamentally, the OS language functionality doesn't really map well to
slang (and for alang/vlang it makes zero sense; not that anyone actually
used it). Instead of trying to shove it in an option where it doesn't
belong, we should split this off into something else. So for now, just
remove the special handling of "auto" and flip slang back to NULL.
It turns out that the code to track redirects (playlists and
directories) never worked correctly, only the last redirect is
remembered and num_redirects is never greater than 1.
You can see this by doing quit-watch-later with the old watch later
system, before dbf244fd2f, on a m3u playlist of files and a m3u playlist
of directories. Only in the first case a redirect entry for the m3u file
is created, because in the second case the m3u redirect is replaced by
the directory one.
If you did mpv --directory-mode=lazy /foo it did create redirect entries
for all subdirectories e.g. /foo/bar, /foo/bar/baz, /foo/bar/baz/qux,
this made it seem like it worked correctly, but actually
/foo/bar/bar/qux was the only redirect entry and thus it was considered
as the first redirect, and mpv created redirect entries for each segment
of the first redirect only.
In the previous commit dbf244fd2f, rather than figuring out how to fix
the code to track redirects, and since creating redirect entries for
multiple redirects is overkill, I just used the new playlist-path
property which does the same thing but only for the last redirect.
By replacing the only other use of the old redirect code with
playlist-path, we can remove it.
35f43dfacb added a system to write resume files for redirects, i.e.
directories and playlists that mpv expands.
It creates a resume file for each redirect, and for the first redirect
only, it writes a resume file for each segment of its path, without even
converting it to an absolute path if it's relative. This is incomplete:
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
This doesn't save any redirect entry.
mpv --directory-mode=recursive 'Iron Maiden', then quit-watch-later on
Hallowed Be Thy Name
This saves a redirect entry for "Iron Maiden", but not for "1982 The
Number of the Beast". It doesn't save redirect entries for the
directories above "Iron Maiden" either because "Iron Maiden" isn't
converted to an absolute path.
In both of these cases mpv --directory-mode=lazy 'Iron Maiden' won't
resume from "Hallowed Be Thy Name" because "1982 The Number of the
Beast" isn't the first subdirectory and there is no redirect entry for
it.
503dada42f made mpv recursively expand subdirectories precisely to fix
this, and f266eadf1e added back an option not to expand them. But if we
fix how redirect entries are stored, we can make the superior
--directory-mode=lazy (because it's faster and doesn't result in massive
playlists) the default, and also ensure that mpv will resume playback
even when you quit-watch-later a file without redirects and then play
the directories above it.
Fix this by always creating redirect entries for all segments of the absolute
path of the file, so that both
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
and
mpv --directory-mode=lazy 'Iron Maiden'
will create redirect entries for
/$USER
/$USER/music
/$USER/music/Iron Maiden
/$USER/music/Iron Maiden/1982 The Number of the Beast
making mpv --directory-mode=lazy "Iron Maiden" resume from
"Hallowed Be Thy Name".
This commit also makes mpv delete the redirect entries of parent
directories when resuming playback, because if for example you have a
playlist with all the songs in a discography:
1980 Iron Maiden/1 Prowler.mp3
1980 Iron Maiden/2 Remember Tomorrow.mp3
...
1981 Killers/1 The Ides of March.mp3
1981 Killers/2 Wrathchild.mp3
...
Now mpv will eventually create redirect entries for every album. If you
later decide to play the directories instead and there are 20 albums,
you would have to do mpv * 20 times to clear all the redirect entries.
200992f90c stopped linking mpv to
libXinerama so this library isn't needed anymore. However, we do use
xpresent so mention that instead since all the other needed xorg
libraries are listed as well.
Ideally, users should be using lavfi-complex instead of lavfi-bridge
for such a use case, however currently lavfi-complex doesn't support
hwdec. So we can allow filters with dynamic inputs to work with
lavfi-bridge, at the cost of them only being able to take in
only one input. This should probably be reverted when/if lavfi-complex
has hwdec, but for now this allows us to use libplacebo
as a video filter with hwdec in mpv again.
This ensures the spacing between forced-only sub toggle button and the
volume button matches the spacing between the volume and the fullscreen
button on bottombar/topbar layouts
Fixes: 945d7c1eda
Previously, we would have a button with empty string added to the layout
for non DVD/PGS subtitles. This would cause there to be an invisible
button present that would take up space and could still be clicked
despite being invisible when the current subtitle track was not DVD/PGS.
The idea was that the button would be invisible for regular subtitle
tracks, and be visible as "[ ]"/"[F]" for DVD/PGS subtitle tracks.
This commit modifies the bar and box layouts to only add this button if
the current subtitle track is DVD/PGS. This results in there no longer
being an invisible button, and also prevents it from taking up space.
The button is added to layout as before when the current subtitle track
is DVD/PGS, matching the same logic as before.
x11 and wayland had a lot of multimedia keys mapped that were missing
on windows.
Now the only ones they map that windows doesn't are `MP_KEY_WWW`,
`MP_KEY_ZOOMIN` and `MP_KEY_ZOOMOUT`, which apparently don't have any
equivalent ones on windows.
This actually fixes a bug that was present in this code even before the
new pl_options system, which is that `video_screenshot` would
permanently leave `peak_detect_params.allow_delayed` as false, until
something else forced options re-application due to options cache
change.
This may seem obvious in retrospect, but we need to explicitly account
for the case where the source format is supported by the VO, but not
a valid target format for the conversion filter. In that situation, we
would conclude that conversion was necessary, because we relied solely
on the conversion filter to identify acceptable target formats.
To avoid that, we should go through the VO's reported set of supported
formats and if the source format is on the list, ensure that format is
also on the target list.
This is mostly a no-op as most VOs do not report supported formats
(instead assuming that all formats decoders can produce are supported)
and in the case where it matters (vaapi), there is only one format that
the VO supports which the conversion filter does not (yuv444p).
The last piece in the puzzle for doing hardware conversions
automatically is ensuring we only consider valid target formats for the
conversion. Although it is unintuitive, some vaapi drivers can expose a
different set of formats for uploads vs for conversions, and that is
the case on the Intel hardware I have here.
Before this change, we would use the upload target list, and our
selection algorithm would pick a format that doesn't work for
conversions, causing everything to fail. Whoops.
Successfully obtaining the conversion target format list is a bit of a
convoluted process, with only parts of it encapsulated by ffmpeg.
Specifically, ffmpeg understands the concept of hardware configurations
that can affect the constraints of a device, but does not define what
configurations are - that is left up to the specific hwdevice type.
In the case of vaapi, we need to create a config for the video
processing endpoint, and use that when querying for constraints.
I decided to encapsulate creation of the config as part of the hwdec
init process, so that the constraint query can be down in the
hwtransfer code in an opaque way. I don't know if any other hardware
will need this capability, but if so, we'll be able to account for it.
Then, when we look at probing, instead of checking for what formats
are supported for transfers, we use the results of the constraint query
with the conversion config. And as that config doesn't depend on the
source format, we only need to do it once.
I'm currently not convinced that the way the output_chain is handled as
part of reconfiguration is correct. If there is an event requiring
reconfiguration, such as toggling the use of hwdec, we currently do not
ensure that the filter chain is fully drained first. This creates a
situation where the filter chain is invalidated while the autoconvert's
sub filter (that does the real work) still has a frame to process and
pass on.
As the autoconvert code calls mp_subfilter_drain_destroy(), it returns
early to allow for draining before destroying the subfilter, but that
means the subfilter is still present in its original configuration, and
no actually draining is done before the existing filters reinitialise
themselves.
This leads to a situation where, if a hardware scaling filter is being
used by autoconvert, that filter is still present and responds when
told to reinitialise. But it cannot successfully reinitialise if the
triggering event is disabling hw decoding, as the input frame to the
filter will now be a software frame, so reinit fails, leading to total
failure of the filter chain, which is a fatal error, and we exit.
I think this was never noticed before, because I think it's not
possible for the hwtransfer filter to be active in a situation where
you can dynamically change the state such that the input or output
formats of the output chain are invalidated.
eg: If the autoconverter is activated because of `--vf=format=vaapi`,
it is actually not possible to toggle hwdec off, as the explicit user
filter ensure the hwdec is always present and active.
So, my solution here is to destroy the sub filter, regardless of
whether it needs draining or not. We simply have no opportunity to
drain and reconfigure in the correct order, and we must consider the
remaining frame in the filter as a casualty of the toggling process.
I'm sure there is a more substantial rework of the output_chain
reconfiguration process that could ensure draining before
reconfiguration begins, but my ambitions do not currently extend that
far.
This has been a standing behaviour for a long time, but I noticed it
while implementing the hw->hw autoconvert functionality. Today, the
output_chain will reset the autoconvert state when any output_chain
filter sees the input format change. This is wasteful as it leads to
the image converter having to be reinitialised each time it happens,
so we should only do it when the actual "convert" filter sees the
input format change. It doesn't matter if one of the other filters in
the chain sees a change (although in practice, a format change will
basically always propagate down the chain, so they all see a change
at the same time).
The practical effect of the old behaviour was that a format change
would always lead to the image converter being rebuilt twice - once
after the "convert" filter sees the format change, and then again
after the "out" filter (the end of the chain) sees the change.
In this commit, we check which filter is seeing the change, and only
reset the autoconvert state for the "convert" filter itself.
Historically, we have not attempted to support hw->hw format conversion
in the autoconvert logic. If a user needed to do these kinds of
conversions, they needed to manually insert the hw format's conversion
filter manually (eg: scale_vaapi).
This was usually fine because the general rule is that any format
supported by the hardware can be used as well as any other. ie: You
would only need to do conversion if you have a specific goal in mind.
However, we now have two situations where we can find ourselves with a
hardware format being produced by a decoder that cannot be accepted by
a VO via hwdec-interop:
* dmabuf-wayland can only accept formats that the Wayland compositor
accepts. In the case of GNOME, it can only accept a handful of RGB
formats.
* When decoding via VAAPI on Intel hardware, some of the more unusual
video encodings (4:2:2, 10bit 4:4:4) lead to packed frame formats
which gpu-next cannot handle, causing rendering to fail.
In both these cases (at least when using VAAPI with dmabuf-wayland), if
we could detect the failure case and insert a `scale_vaapi` filter, we
could get successful output automatically. For `hwdec=drm`, there is
currently no conversion filter, so dmabuf-wayland is still out of luck
there.
The basic approach to implementing this is to detect the case where we
are evaluating a hardware format where the VO can accept the hardware
format itself, but may not accept the underlying sw format. In the
current code, we bypass autoconvert as soon as we see the hardware
format is compatible.
My first observation was that we actually have logic in autoconvert to
detect when the input sw format is not in the list of allowed sw
formats passed into the autoconverter. Unfortunately, we never populate
this list, and the way you would expect to do that is vo-query-format
returning sw format information, which it does not. We could define an
extended vo-query-format-2, but we'd still need to implement the
probing logic to fill it in.
On the other hand, we already have the probing logic in the hwupload
filter - and most recently I used that logic to implement conversion
on upload. So if we could leverage that, we could both detect when
hw->hw conversion is required, and pick the best target format.
This exercise is then primarily one of detecting when we are in this
case and letting that code run in a useful way. The hwupload filter is
a bit awkward to work with today, and so I refactored a bunch of the
set up code to actually make it more encapsulated. Now, instead of the
caller instantiating it and then triggering the probe, we probe on
creation and instantiate the correct underlying filter (hwupload vs
conversion) automatically.
--audio-file-auto, --cover-art-auto, and --sub-auto all work by using an
internally hardcoded list that determine what file extensions get
recognized. This is fine and people periodically update it, but we can
actually expose this as a stringlist option instead. This way users can
add or remove any file extension for any type. For the most part, this
is pretty pretty easy and involves making sub_exts, etc. the defaults
for the new options (--audio-file-auto-exts, --cover-art-auto-exts, and
--sub-auto-exts). There's actually one slight complication however. The
input code uses mp_might_be_subtitle_file which guesses if the file drag
and dropped file is a subtitle. The input ctx has no access to mpctx so
we have to be clever here.
For this, the trick is to recognize that we can leverage the
m_option_change_callback. We add a new flag, UPDATE_SUB_EXTS, which
fires when the player starts up. Then in the callback, we can set the
value of sub_exts in external_files to opts->sub_auto_exts. Whenever the
option updates, the callback is fired again and sub_exts updates. That
way mp_might_be_subtitle_file can just operate off of this global
variable instead of trying to mess with the core mpv state directly.
Fixes#12000.
We should account for ao queue when setting playback position on EOF,
previously we were using the pts value corresponding to the start of
the ao queue, rather than the currently playing audio.
This fixes time-remaining being a negative number when mpv seeks to EOF
while playback is paused.
So far all the keypad keys except for `0` and `,` mapped to the same
MP_KEY_* independent of numlock state, even though different key codes
are received.
Now all the alternative functions map to appropriate MP_KEY_* defines,
with missing ones added.
There's some cdecl / stdcall linking nonsense breaking the build
which I'm not inclined to debug this Sunday at all.
32-bit is not important anyway, so just disable it there.
On the plus side the new functional structure makes this very painless.
If someone wants to use the CI artifacts for day-to-day usage
or even for certain tests it can be useful to take screenshots
and use e.g. DShow (--disable-devices option), so enable those.
1fa6669bc0 misinterpreted the example and
changed the pixel value from 128 to 168 (thinking that it meant pixels
after scaling), but likely the original calculation was correct because
the line specifically says "of the source video". This is just confusing
not really useful information so instead change the example to a more
common resolution (1920x1080) and remove any references to the source
video resolution. Also mention video-pan-y while we're at it.
It makes it more usable to virtually move dst rect instead of scaled
src.
The issue with the latter is that it is affected by video-zoom
paramters. For example if we do `--video-pan-x=-0.5` in normal case it
will move video -50%, but if we apply video-zoom/scale the video will
float towards the middle in unintuitive way. Extreme case is when one do
--video-zoom-x=0.01, now it is impossible to move video unless you
specify huge video-pan-x value, but it is limited to [-3, 3]. So you
cannot do anything.
With this changes regardless of video scale/zoom, video-pan will keep
center of scaled video in one place.
It doesn't make sense to have zero here and it breaks, logic below.
Width was still campled to 1, but with broken offset.
This fixes things like video-scale-x=0
- uninit gl before the VO
- destroy EGL surface before context: reverse of the creation order.
I also checked other code which doesn't even call this and leaves
it up to eglTerminate, which frees everything anyway. But this
seems more correct since we're destroying the gbm surface afterwards.
- check against at EGL_NO_DISPLAY instead of 0: there is probably no
EGL implementation where this makes a difference, it is more correct
regardless
- remove pointless eglDestroyContext call
- check render_fd before close
The idea behind period_size is that it's the minimum amount of data
that your audio subsystem wants to fetch.
For PulseAudio, this is given by the minreq buffer attribute, which
is in bytes for all channels. Hence the divisions.
This change sets the device_buffer member of the ao struct for
the JACK ao to whatever value we read during init.
While JACK allows changing the audio buffer size on-the-fly
(you can do this for example through DBus), having it somehow
reconfigure the entire audio buffer logic of mpv that depends
on device_buffer in some way when that happens only leads to
audio dropout and weird code. device_buffer's role is mostly for
prebuffer from what I understand, which means that simply setting
it to its current value in the init function is fine.
mpv was taking focus when being started with "--window-minimized=yes". This change stops mpv from taking focus when this option is used.
Resolves: #9641
In addition to the patch, appropriate additions to the mpv.conf file
will of course be needed for this to work. For example on my system:
audio-device=oss//dev/dsp4
audio-spdif=ac3,dts,dts-hd,eac3,truehd
This has been tested using recent FreeBSD-13.1-stable, using external
surround processors (both a Trinnov Altitude 16 and an LG OLED that
supports Dolby Atmos, and connected with HDMI to an NVidia RTX 2070).
Author and tester: David G Lawrence <[email protected]>
It's possible for systems to have multiple cards, and the first capable
card to not have a connected output. Skip such cards and continue
iterating until we find one with a connected output.
Without doing this, --fs --fs-screen=1 wouldn't actually end up on the
desired screen since the sizehint was never sent. Also check the
screen-name variants for an empty string as well so the option can
properly "undo" itself (not sure if this has any practical effect).
mpv mixes xinerama and randr usage together which gets kind of
confusing and is also pretty stupid. Xinerama is completely unneccesary
today since randr can do everything it can do and much more. Remove it.
This reworks a lot of the window/geometry handling stuff to be centered
completely around xrandr_display plus some other tweaks to the geometry
handling. An important concept is that current_icc_screen is changed
into current_screen and used more generously since it is useful for
things besides just icc profiles.
There really is no reason to not just hard require randr 1.4. xorg added
1.4 support in 2012 and someone somehow using an xorg server older than
that today surely has several other problems.
If we failed to create a gbm surface, we would call drm_egl_uninit
to free up any state we had allocated. However, we would segfault if we
tried to cleanup properties there were never initialized. Null checks
have been added to guard against this.
Before d208284, this was implicitly reset back to 0 at the start of
every update_options(). But we no longer explicitly reset par->params,
so we need to do it manually here for the hooks.
Fixes: https://github.com/mpv-player/mpv/issues/12203
It turns out this already exists for sd_ass and is being used there. We
can make use of this arbitrary threshold instead for overlapping
subtitle durations to avoid the weird flashing behavior with some
pgs subtitles.
With a backwards compatibility shim for older versions of libplacebo in
which we simply define the relevant subset of this struct ourselves and
initialize it to known-good values, to be able to continue using our
options assigning code.
It's worth pointing out that our use of scalers deviates from how
pl_options was intended to be used, as a consequence of backwards
compatibility with pre-308 versions of libplacebo. But this should work
fine in practice, since we don't care about serializing these custom
scalers correctly. Users can still override them using the built-in
pl_options scalers when loading custom scalers via --libplacebo-options.
(To be added in the next commit)
Under the current file loading logic, a video file and an external
audio track next to it will both be added to the playlist, which
most users don't wish to happen. Having an option that tells the
script to load only one type of files (video, audio, or image)
can avoid this problem. It may also come in handy for people who
have different types of files mixed in a folder but wish to consume
only one type of media at a time.
This was already correctly freed when acquiring a new profile, but never
freed on uninit. Fix by reparenting the profile onto `p`, which is what
vo_gpu also does.
There are a number of ways one can craft a playlist file that refers to
itself or cleverly goes around in a loop to other playlist files. There
is obviously no use for this, but mpv spins around forever trying to
load the files so you have to just SIGTERM/SIGKILL it. We can be smarter
about this and attempt to detect it. The condition for detecting this is
surprisingly simple: the filename of the first entry in the playlist
must match a previous playlist path we stored. If we get this, we can
then log an error and stop playback. If there is a "real" file loaded at
any point in time, then we know it's not an infinite loop and clear out
the saved playlist paths. Fixes#3967.
At least NetBSD ossaudio(3) right now has SNDCTL_DSP_SETPLAYVOL support
but does not support SNDCTL_DSP_HALT chocking at build time.
NFCI on platforms where oss audio output is supported.
libplacebo doesn't like it when the queue_params PTS is less than the
actual PTS of the frame for the first frame and skips mixing it during
interpolation. This can happen if you seek while paused because mpv will
always keep the vsync_offset value as if it was still playing. So in
some cases, this can be a negative value and thus the PTS will end up
decreasing and libplacebo interprets this frame as a first frame. This
skips mixing the frame and thus you get a black screen. To fix this
this, just realize that vsync timings are completely meaninglessly in
while paused. If you are not actively pushing frames, there's no reason
to care about vsync_offset. So just clear it and make it zero when the
VO's internal state is paused and we're trying to render a frame. Makes
libplacebo happy and fixes#11958.
It was actually always wrong, and no one ever noticed. This currently
returns the size of the entire display area and not one actual monitor.
Fix this by calling get_monitor_info and then doing the appropriate
subtractions. Checked by @CrendKing and fixes#12172.
Discovered by @christoph-heinrich in IRC.
09c701b797 added a fallback for headerless
m3u files. However, it requires that the bstr len be greater than 10.
This means that a m3u playlist with a single entry with a very short
filename (such as "test.flac") will not be recognized as a playlist
since the amount of data is too small. The reason for this restriction
is unexplained and really shouldn't matter given that the important
thing mpv should be doing is checking if the data is text. Instead,
loosen the check so that it only needs to be 2 or greater. This covers a
single byte filename and a line terminator.
Introduced by 1f8013ff3f. We try to save
the mpkey so it can be used in the modifier event that comes next if
appropriate and also clear it when needed. The problem is that the
condition for clearing is too strict and things like mismatched cases
and so on can make mpkey on the corresponding key release event not
match the saved mpkey even though in reality they were the same key.
Loosen the check by simply always clearing the saved mpkey as long as
there was some key found and the state is up. We don't handle multiple
keys at the same time anyways (they're interpreted in a sequence), so it
should be hopefully OK.
During initialization, the mpv window was not available and wayland
simply just reported nothing. But this can be a nuisance and there are
cases where having a values is better than nothing (vapoursynth). So if
current->output isn't available yet, fallback to find_output instead.
This is influenced by what is set by options like --screen and
--screen-name, but we'll consider that a feature not a bug.
This deliberately wasn't being done when mpv was embedded
(fbccddb48b). There are some applications
that would benefit from mpv setting a title since they don't do so
themselves (such as tabbed), but at the same time some others would
probably rather not have this behavior (like smplayer). Add an option
that allows an embedded mpv to set the title if the user wishes.
Fixes#11528.
A bit of a long standing pain with scripting is that when opening a file
that gets interpreted as a playlist (like an m3u), the original path of
the file gets thrown away later. Workarounds basically consist of
getting the filename before mpv expands the path, but that's not really
reliable. Instead of throwing it away, save the original playlist path
by copying to the playlist entries when applicable (demuxer playlist and
the playlist option). Then expose these as properties: playlist-path for
the currently playing entry and playlist/N/playlist-path for each
specific entry. Closes#8508, #7605.
mpv has a generic method for getting the display resolution, so we can
save it in vf_vapoursynth without too much trouble. Unfortunately, the
resolution won't actually be available in many cases (like my own)
because the windowing backend doesn't actually know it yet. It looks
like at least windows always returns the default monitor (maybe we
should do something similar for x11 and wayland), so there's at least
some value. Of course, this still has a bunch of pitfalls like not being
able to cope with multi monitor setups at all but so does display_fps.
As an aside, the vapoursynth API this uses apparently requires R26 (an
ancient version anyway), so bump the build to compensate for this.
Fixes#11510
The OSC reports the speed-adjusted remaining time, but the terminal does
not. This is a weird mismatch and the OSC's default behavior makes
sense, so let's just do some division and add an option to disable it.
Also named "remaining-playtime" after the OSC option. Fixes#10445.
mpv makes this option an integer, but the underlying ass API actually
accepts doubles. From some testing, there is no meaningful precision
difference between float or double (it seems to go in roughly 0.05
steps), so just make it a float. sd_lavc also can handle non-integer
values here. Closes#11583.
XDestroyWindow() is called immediately after, which also unmaps window
if needed. according to the manpage:
> If the window specified by the w argument is mapped, it is unmapped
> automatically.
When printing the name of the video track on the OSC, mpv almost always
prefixes it with "unknown". This is referring to the language tag which
essentially nobody ever does for the video track since it doesn't make
any sense. Instead of putting unknown when there's no language, just
make it an empty string instead. "Unknown" confuses can confuse users
here and practically nobody would guess that it's referring to language.
We still will print the language for a video track in case someone out
there really does tag it, but that should be rare.
When playing a sparse video stream, the debug log gets hit with the
video EOF constantly since the audio is still playing. There's no
practical use for this so just do add some logic to only signal it once
if it is sparse.
There's an edge cause with gapless audio and pausing. Since, gapless
audio works by sending an EOF immediately, it's possible to pause on the
next file before audio actually finishes playing and thus the sound gets
cut off. The fix is to simply just always do an ao_drain if the ao is
about to set a pause on EOF and we still have audio playing.
Fixes#8898.
This is pretty obscure but if you screw around with the play-dir option
to essentially create a ping-pong loop; mpv will get hit by an assertion
error. What's happening here is that changing the play-dir always
requires a seek. This is handled in player/command along with the other
runtime option changes. However, queue_seek can actually clear the value
of mpctx->stop_play if the file is ending. So while loadfile is
terminating playback and the play-dir gets changed, the value of
mpctx->stop_play gets cleared because of seek. This then hits that
assertion later when mpv tries to finish the file.
The fix is to just add some weird logic to play-dir in player/command.
We have to be sure that mpctx->play_dir matches the new direction
immediately when we get the change so explictly set it here and don't
wait for it later. Secondly, keep the old value of mpctx->stop_play
before the seek and restore it afterwards. This ensures that termination
still happens cleanly and allows the ping-pong loop to work. Fixes#10782
When getting subtitles, sd_lavc checks if the current pts plus a small
offset (1e-6) is greater than the sub->pts as well as checking if the
pts is less than the sub->endpts. The problem with the endpts check is
that there are subtitles out there (pgs ones) that have overlapping
durations and thus you'll get a case where pts is greater than endpts
because a new subtitle shows up. However, the old subtitle is still
meant to be on the screen. This results in a flickering effect where the
subtitle flashes and then appears the next frame. The easy enough fix is
to just loosen the condition and remove the endpts check altogether.
That ensures that the subtitle remains selected for the entire duration.
Unsure if this possibly could regress some other kind of subtitle out
that that uses sd_lavc, but this does appear to fix a real issue with
pgs subtitles. Fixes#8202 and #10051.
Internal subtitles were not shown when switching between tracks while
mpv was paused. The reason for this is simply because the demuxer data
isn't available yet when the track switch happens. Fixing it is
basically just retrying until the packet is actually available when the
player is paused. Fixes#8311.
1df0a42a8c changed aspect-ratio from
floats to doubles, but forgot to change this function for
pretty-printing them as fractions for the video-aspect-override property
This specific option type is only used for the video aspect. The
underlying type was a float to represent the inputted value, but it's
actually not precise enough. When using something like 4:3, the values
of the incorrect digits are actually significant enough to make av_d2q
return a very funky numerator and denominator which is close to 4/3 but
not quite. This leads to some "off by one pixel" errors. Weirdly, mpv's
actual calculations for this were already being done as double, but then
converted to floats for this specific type. Just drop the conversion
step and leave it all as double which has the precision we need (i.e.
AVRational is now 4/3 for the this case). Fixes#8190.
983e8f0100 resulted in the correct
dimensions, but it was not actually right because vo_gpu_next still had
the src and dst rects the same. This just needs to work like how vo_gpu
does where the src is the image params and the dst is desired output. So
basically, just copy that code over here. Fixes#12108 and as a bonus,
overriding the aspect ratio now results in correct screenshots
(previously didn't work at now and then with the above commit it had
correct dimensions but still incorrect output).
The difference this makes is that the OS API will notice
when we underrun (as opposed to being fed silence).
Other AOs mostly seem to not do this because they've committed
to filling a buffer of a certain size no matter what, but I have
not observed any ill effects for AudioTrack in my testing.
This looks like a pretty bad bug but only became a problem
with the last commit that allows rates like 22.5kHz to pass through
directly instead of being resampled.
Using the width and height params directly doesn't actually work if PAR
is something other than 1. Instead, use mp_image_params_get_dsize and
calculate the correct dimensions which matches the vo_gpu behavior.
1 is not enough to prevent PL_QUEUE_MORE, because the pl_queue is
designed to always know the next frame (in addition to the current).
Before haasn/libplacebo@112bb886, this was was (wrongly) silently
omitted by the pl_queue code, but that fix exposed this.
While it's technically API misuse on mpv side, due to the mpv vo code
having its own internal queueing and timing control, it shouldn't
actually make any difference in practice (and likely, the error message
showing up is the only meaningful bug here - the issue is entirely
cosmetic).
Fixes: https://github.com/mpv-player/mpv/issues/12101
Configuration of filter parameters was moved from pl_filter_function (of
which the user had to make a copy) to pl_filter_config, with the
pl_filter_function remaining immutable.
Implement this new logic in a way that can reasonably exist side-by-side
with the old configuration API. Once we drop support for PL_API_VER
below 303, we can drastically simplify this code.
The win32 code already updates itself on dpi changes. However, it never
signalled mpv's core when this happened which meant that the
display-hidpi-scale property never changed. Simply send the
VO_EVENT_DPI event when appropriate. Fixes#12081.
Currently relative time parsing is buggy when any of the non-leading
units are non zero. For example, "-1:30" should result in -90 but
currently it results in -30 (as a result of `-60 + 30`).
Also reject timestamps where non-leading units are out of range. E.g.
"1:100" would be rejected, but "100" will still be accepted as 100
seconds.
In the same way that fallback in receive_frame() needs to be repeated
until we get a working decoder, we have to do the same thing in
reinit(). Calling force_fallback() only once can still yield a non
functional decoder.
The reason why we have these multiple paths which each require their
own fallback logic is that we can fail at different stages:
* hwdec init
* decoder init <- repeated fallback was missing here
* frame decoding
Fixes#12084
The manual currently says that if dscale is unset, --scale will be
applied. However, this only works at init time. If you change the dscale
filter to be empty later, vo_gpu will segfault and vo_gpu_next will
throw an error and refuse the changes. That's because when the option is
unset at runtime, the value becomes "" not NULL and the vo's never
accounted for this. Fixes#12031.
This is higher quality but comes with a slight performance hit,
especially for weaker iGPUs, so I don't want to enable it out of the box
even when --hdr-compute-peak=auto.
After second thought version.py does not do anything useful. Meson has
built-in function vcs_tag that mostly replicate what version.py did. For
the build time we can just use __DATE__ and __TIME__. Of course this
changes time string format a little, but in my opinion it looks nicer in
fact.
Also it will use local time, instead UTC. But I would argue that date
string is only informative for users to check how old the specific mpv
build is. It doesn't have to be precise, it weren't for years anyway
before recent change.
Get rid of the time during the while loop and just let this run forever
in case of a failure and also bump the timeout in meson to 60 seconds
since we know it is possible for msys to take a very long time on
occasion. That should be plenty of time for it to finish.
This only existed as essentially a workaround for meson's behavior and
to maintain compatibility with the waf build. Since waf put everything
in a generated subdirectory, we had to put make a subdirectory called
"generated" in the source for meson so stuff could go to the right
place. Well now we don't need to do that anymore. Move the meson.build
files around so they go in the appropriate place in the subdirectory of
the source tree and change the paths of the headers accordingly. A
couple of important things to note.
1. mpv.com now gets made in build/player/mpv.com (necessary because of
a meson limitation)
2. The macos icon generation path is shortened to
TOOLS/osxbundle/icon.icns.inc.
wireplumber uses the media role when the node is first created.
To have the property available at this point reliably we need to set it
directly when creating the stream/node.
This is yet another unfortunate side effect of the width % SLICE_W == 0
special case. While looping through these rectangles, the rc->x1 value
on the final loop can be greater than the actual total width. This will
cause a buffer overflow if using the mp_draw_sub_overlay API. 2 of the
current VOs that use that work around it by adjusting the values
returned, but the better fix is to correct what's actually given in the
rectangles so you can safely use the values. As for the fix, it's simply
ensuring that rc->x1 doesn't extend beyond p->w with a MPCLAMP.
Previously, the code would always naively add SLICE_W (256) to rc->x0
which would easily extend past the actual width in many cases. The
adjustments in vo_vaapi and vo_dmabuf_wayland are dropped and in theory
vo_direct3d should work now since we can just trust the values given to
us in the rectangles. How nice.
As the role property is interpreted by wireplumber it can only be
evaluated when creating the stream. The current, dynamic mechanism is
racy so revert it.
See: #11253Fixes: #12041
This reverts commit 535cd6f313.
On DragonFly and FreeBSD native evdev headers are not not be used
outside of base system. Linux-compatible headers are provided by
evdev-proto package but require extra flags. As evdev-proto lacks
pkg-config support use libwayland prefix as approximation.
meson.build:974:0: ERROR: C header 'linux/input-event-codes.h' not usable
- Use ctime() instead manual format string. Fixes 12-hour format (%I)
without AM/PM (%p) specified. It is 24-hours now, as it should be.
- Avoid naive datetime object.
- Fix timestamp type, it is float in Python.
- Remove dummy fallback branch.
- Use f-strings for readability.
- Always rebuild version.h if repository is dirty.
1669c4698d notably flipped the default of
--subs-with-matching-audio from yes to no as part of a series of changes
that gave more control over sub selection behavior. While the increased
amount of options is definitely nice, changing the default to no results
in very unintuitive behavior. For example, setting alang=en and slang=en
in your config will not show any subtitles since the audio stream is
English as well so --subs-with-matching-audio being no causes the subs
to not be be selected. This is very weird for users who reasonably
expect slang being set to actually result in showing subs and this is
what mpv did for the past decade.
The other case is when a subtitle does not have a language tag but is
flagged as default. Because --subs-fallback (a new option), defaults to
no, these subtitles also will not be loaded. This is also strange for
users since mpv previously loaded these and they would need to change
the value of this option. It's also inconsistent because audio tracks
that are tagged as default are also loaded by default.
The new behavior seems to have mostly just confused users, and it also
regresses their configs for unclear reasons. Let's just set the options
to be back in line with the old behavior with is what most users expect.
--subs-with-matching-audio goes back to being yes and the new option
--subs-fallback should be default. Fixes#11854.
Python 3.11 will be released soon as default Python package, and
actually python3.11 package already disappeared from the repository.
This reverts commit c637beb522.
The avpkt was created once on decoder init but destroyed each time the
filter was destroyed, this obviously can't work. Move the packet alloc
to the filter init function instead.
fixes: 4574dd5dc6
We already have a libmpv test, but it's really basic and barely does
anything. In an effort to hopefully prevent future breakage, lets expand
this to do more stuff. First of all, it simply tests setting a bunch of
properties/options. Secondly, it tries to load a file (the mpv icon that
we already have in the source tree). And then finally it tries the
lavfi-complex filter since this is a known special case where weird
things can happen.
The track during lavfi-complex can actually be NULL which meant that
ca4192e2df regressed lavfi-complex by
causing mpv to crash during runtime changes of the filter. Additionally,
it's possible for the decoder wrapper to also be NULL. check_framedrop
within write_video checks this, but check_for_hwdec_fallback does not.
Perhaps, it's impossible for this to happen, but we might as well add
the check here to be on the safe side since mp_decoder_wrapper_control
is not designed to handle a NULL.
reproduction steps: take any lossy WebP screenshot and check the colors
(or JPEG without libjpeg support, or AVIF with tag-colorspace=no)
fixes: 6d9e72cd89
We make the assumption that there is more buffer available
than indicated, this needs to be considered in this specific
location too as mp_image_crop understandably checks whether
we're about to do something unsafe.
minimal reproducer: mpv av://lavfi:testsrc -vf crop=320:239,format=yuv420p -o test.png
fixes#10469
Curiously, vaapi requiring libdl has always existed ever since support
was added to mpv (2827295703). After some
investigation in IRC from uau and JEEB, it was concluded that the libdl
requirement was blindly copied from the vdpau check above it. At the
time, the vdpau code actually used dlsym so it was needed. The check was
later dropped when waf support was added
(7e2edad8ef). However, the requirement in
vaapi lived on, and actually it was never needed. libva does use dl when
building its libraries unsurprisingly, but this isn't relevant to mpv in
any way. Just drop it.
Can significantly reduce build time, most of dependencies have fixed
versions, so they can be cached fully. Others will be incrementally
build.
Cache is saved on every run and restored from the newest one. Size is
limited to 500M (compressed) to keep cache save/restore fast. Clean
cached build is little over 100M, so we have a headroom as things will
grow. ccache will automatically evict least recently used entries.
It is unlikely that clean build will exceed the limit anytime soon, but
it is something to keep in mind, as we do not want to evict cache
entries from current build, so the cache size need to be set correctly.
If we see "C" in one of the language vars we check, don't treat it as a language tag.
Once we've checked everything, if we don't have any languages, but saw "C" anywhere, fall back on "en".
mpv has a convention of printing everything to stdout. The reasons for
this are pretty unclear and in certain situations rather unintuitive. It
leads to some bad behavior in fringe cases with encoding mode and isn't
the norm for programs so just adjust it so warnings and up are printed
to stderr. Fixes#8608.
2.1.0-beta3 is ancient. Disable unwinding in luajit, as it requires SEH
to be enabled in the image, but it is not on i686 target and it
crashes when luajit tries to use SEH.
In 1f8013ff3f, I mistakenly thought this
was only used for modifier presses way back in the commit it was
introduced in, but it actually also handles non-english keys/letters.
Instead of returning early, we should try xkb_keysym_to_utf8 first and
then return if that doesn't do anything so the modifier can then be
handled in the appropriate event. Fixes#12009.
This has always been a pet peeve of mine and in fact I named the option
in meson "egl-wayland" with the intention of finally doing this. We call
everything that's egl "egl-foo" internally except for wayland.
Remove waf entirely in favor of meson as the only supported build
system. Waf was officially deprecated in 0.36.0, and has not been
preferred over meson since 0.35.0.
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 <[email protected]>
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 <[email protected]>
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. <[email protected]>
Co-authored-by: Niklas Haas <[email protected]>
--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. <[email protected]>
Co-authored-by: Niklas Haas <[email protected]>
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 <[email protected]>
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 <[email protected]>
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.
Apparently, it is possible for touchbar.m to compile on non-macos
machines. Also, the disable switch didn't actually work either. Fix this
by using the require() function and making sure that Cocoa (should be
apple-only) is found in addition to the compile check passing which is
what waf does. Fixes#10847.
This is a very simple but easy way of doing it. Ideally, it would be
nice if we could also add some sort of introspection about shader
parameters at runtime, ideally exposing the entire list of parameters as
a custom property dict. But that is a lot of effort for dubious gain.
It's worth noting that, as currently implemented, re-setting
`glsl-shader-opts` to a new value doesn't reset back previously mutated
values to their defaults.
In practice this never led to any issues due to implementation
details of bstr_sanitize_utf8_latin1, but there's no guarantee that
a bstr is correctly null-terminated.
This allows the core of mpv to know about issues in the AO.
Otherwise playback will just freeze as no more data callbacks are sent
by PipeWire.
Also it allows mpv to try to reconnect the AO or find another, working
AO.
We want to add more logic to the stream event handler.
This logic should not be triggered during normal stream shutdown, so we
remove the listener beforehand.
Workflow virtual machines have now been updated so that moby package
contains rule for the newly added syscalls, such as 'clone3'.
Effectively reverts 64fa440c69 .
This older image has been deprecated and will be removed in December.
The images have also already had planned outages during which the CI
flow has been affected. Thus it feels like a good idea to clean
this up at this point.
Ref: actions/runner-images#5583
It turns out, even xy-VSFilter and XySubFilter do not
mangle colours if the video is native RGB regardless of
the sub's YCbCr header. libass' docs were also updated
to reflect this.
Deduplicate history like the fish shell. So for example
entering "cmd 1" then "cmd 2" then "cmd 3" then "cmd 1"
would result in a history of
[cmd 2][cmd 3][cmd 1]
instead of
[cmd 1][cmd 2][cmd 3][cmd 1]
Adds a function `history_add` to replace directly adding to history.
Adds an option `history_dedup` to activate the deduplication.
Defaults to on.
This was only needed because the mingw CI used to run on Ubuntu 20.04
which had a version of meson too old for mpv. This hasn't been the case
since we switched to 22.04 in f7164fcfac
and can now just use the package manager version.
Only matters when configuring ytdl_hook with `all_formats=yes`.
So far the tracks were ordered from worst to best quality.
Web players with quality selection always show the highest quality
option at the top. Since tracks are usually listed with the first
track at the top, that should also be the highest quality one.
yt-dlp/youtube-dl sorts it's formats from worst to best.
Iterate in reverse to get best track first.
This patch adds support for two extra WAVEFORMATEXTENSIBLE GUID tags
that can appear inside RIFF headers. It also adds support for extra
codec IDs that may appear as their own unique wSubFormats inside RIFF
headers, such as ATRAC9 inside matroska, as one example.
Fixes#10757.
I was confused in d3a28f12c9 why it
actually even worked, but after not being stupid, it's quite obviously
just a dangling pointer. The reason it only happens with
wp_presentation_feedback is because the object and listener actually
created in frame_callback not the presentation events itself (for vsync
timing reasons). So it is possible to free the object, but not
immediately recreate it again before quitting (unlike with the frame
callback). The actual comment is moved into feedback_presented (which is
first) but as of this commit it doesn't have the NULL setting logic
(that's the next one).
964692ad4c added some code to destroy
presentation_feedback we get in the presentation_discarded event. This
is the correct thing to do since the compositor could send us this
instead of feedback_presented. Without that change, mutter could
potentially leak memory on every frame.
Unfortunately, life is not so simple and wlroots and weston act
differently. These compositors only send one presentation_discarded
event if the mpv window is hidden. Not on every single missed frame like
mutter. Now in theory this shouldn't matter, but it also turns out that
mpv attempts to free the presentation feedback twice if you quit it
while it is hidden away (on weston and wlroots compositors only). The
inital wp_presentation_feedback_destroy in feedback_discarded fires, but
then the function goes off again in vo_wayland_uninit because
wl->feedback is apparently not NULL for some reason. Possibly, this is
some race condition but we can't just get rid of what's in
feedback_discarded since mutter needs this line. Instead, just hack it
by explicitly setting wl->feedback to NULL in feedback_discarded after we
destroy the presentation feedback. Some valgrind testing in mutter,
sway, and weston shows that this works correctly on all of those
compositors with various combinations of mpv being visible or not while
quitting. feedback_presented doesn't appear to exhibit this behavior so
we just leave that as-is.
666cb91cf1 added dmabuf_feedback, but it
was never actually free'd on uninit. Because this function requires
wayland protocols 1.24, we have to wrap it in an #if. Also throw in some
minor cosmetic changes in here.
This mapping isn't actually relevant until we have the Vulkan interop
merged, and it requires a newer version of libavutil than our minimum
requirement. So I'm going to remove it from master and put it in the
interop PR.
Fixes#10813
666cb91cf1 added support for v4 of the
dmabuf protocol. This was meant to be optional and the fallback support
for the old v2 (dates back to 2017[0] well before the 1.15
wayland-protocol version we depend on) was maintained. However, v4 added
several new functions and structs that of course aren't defined in old
protocol versions so naturally this breaks the build on those systems.
Since this is just a niche feature and not really critical to overall
wayland support in mpv, just give in and add another check in the build
system and #if out the newer stuff in wayland_common. v4 of linux-dmabuf
depends on wayland protocols 1-24[1], so go ahead and make that our new
check. Fixes#10807.
[0]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/a840b3634ad637b237f238d2efb9ab8f4712d5f4
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/8a5cd28a0e84911a5339855cb32ed63fb57ea40a
mpv has a CONFIGURATION define which is defined at configure time in
both build systems and printed out when you use verbose flags. In waf,
this is line is exactly what the user passes on cli at configure time.
In meson, there's currently no way to do that (someone did recently open
up a PR that would make this possible), so we just hardcode the prefix
and call it a day. This is a bit of a tangent, but the build also
copies waf and sets an optimize variable (true or false) that is also
printed out on verbose output. For waf, this makes some sense because
the build has a specific --optimize option (internally all it does is
pass -O2). In meson, optimizing is a built-in option and we just set
anything that's not -O0 as "optimize". Furthermore, there is a new
optimization option added in meson 0.64 called "plain" which passes no
flags at all* so this logic would need to be updated to account for
this.
In retrospect, this is all just stupid though. optimization is not a
boolean value and there's no real use for treating it like one just
because that's what waf does. Let's remove it from the features array.
Instead, we can expose this information in the CONFIGURATION variable
along with the prefix option so we know exactly what optimization was
used in the compiled executable. For good measure, let's also throw in
buildtype since it's related.
*: https://github.com/mesonbuild/meson/commit/a590cfde0cf719c637b75e4784be0c0ae60e3b1f
Meson's master branch helpfully prints out a warning here now saying
that "find_library('libdl') starting in "lib" only works by accident
and is not portable". We'll go ahead and trust them and instead change
this to dl which works with no issues.
The old "meson build" build command was actually deprecated a few months
ago*. It turns out that you're supposed to use "meson setup build"
instead which has been around for years. Go ahead and be a good citizen
and update this in the CI. Also replace any mention of "meson build"
with "meson setup build" in the documentation as well and change the one
random hardcoded string we have in meson.build to "meson configure
build" (might as well).
*: https://github.com/mesonbuild/meson/commit/3c7ab542c0c4770241eae149b0d4cd8de329aee0
Console already respected the bottom margin to not overlap with the
bottom bar from the OSC, but it would still overlap with the window
decorations from the OSC.
Now everything is clipped above the top margin and no superfluous lines
are drawn.
vo_dmabuf_wayland has its own ra and context so it can handle all the
different hwdec correctly. Unfortunately, this API was pretty clearly
designed with vo_gpu/vo_gpu_next in mind and has a lot of concepts that
don't make sense for vo_dmabuf_wayland. We still want to bolt on a
ra_ctx, but instead let's rework the ra_ctx logic a little bit. First,
this introduces a hidden bool within the ra_ctx_fns that is used to hide
the wldmabuf context from users as an option (unlike the other usual
contexts). We also want to make sure that hidden contexts wouldn't be
autoprobed in the usual ra_ctx_create, so we be sure to skip those in
that function. Additionally, let's create a new ra_ctx_create_by_name
function which does exactly what says. It specifically selects a context
based on a passed string. This function has no probing or option logic
is simplified just for what vo_dmabuf_wayland needs. The api/context
validations functions are modified just a little bit to make sure hidden
contexts are skipped and the documentation is updated to remove this
entries. Fixes#10793.
vo_gpu and vo_gpu_next typically load hwdec interops on demand and
vo_dmabuf_wayland naively copied this logic. This is actually wrong
however since draw_frame in the VO always inherently relies on hwdec
being fully loaded. This can lead to a race condition during startup
which happens with --force-window=immediate. Avoid this by simply always
loading all the interops. In the case of vo_dmabuf_wayland, this is not
really a big deal since there's only vaapi and drmprime to load. Also
fixes#10791 (the other half).
We really need two roundtrips in the init function. The first one is for
running the registry and then second one is for ensuring the xdg_surface
and other potential wayland objects are configured at least once before
mpv does anything. We've been getting away with only doing the first for
a while via luck, but really we should do at least one more wait on the
compositor. Fixes#10791 (half of it).
Despite being run in a VM, the workflow actually copies the files back
to the host. We can then explictly print the error logs on failure in
their own separate section for visibility instead of it being hidden
within all the vm output.
Building on DRM platform without VAAPI broke because of misuse of
HAVE_VAAPI with #ifdef in place of #if. Also, the hwcontext_drm.h
header is not required for VAAPI builds, only DRM builds.
Originally, I considered warning once to be useful for figuring
out whether the change in logic regarding resetting requested
mode actually fixed the reported issue or not, but alas not everyone
was happy with that decision. Thus the log level will always be
debug. This enables us to lose one level of indent as well as a
variable, which is always positive.
Additionally, make the message more explicit regarding what could
possibly be implied by the mismatch, as it seems like this was
not always clear.
Otherwise mpv and the compositor can end up in an eternal loop where
mpv requests one mode, and compositor tells that the mode is not
that (and will most likely not change).
Additionally, log these mismatches - first time as a warning, and
later as debug logging.
It is verbose, but makes it more explicit that requested_decoration
takes in three values:
* 0: no specific mode requested by mpv
* ZXDG_TOPLEVEL_DECORATION_V1_MODE_CLIENT_SIDE: (!border)
* ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE: (border)
Pulled from https://github.com/mpv-player/mpv/pull/10382
The zwp_linux_dmabuf_v1 protocol version 4 provides a file descriptor
containing both formats and modifiers, which makes it possible for the
compositor to import the buffers onto planes using explicit modifiers.
This is an extremely important efficiency improvement, as the 3D
hardware can be left powered off altogether, the vaapi buffer being sent
directly from the video hardware to the display controller.
It could be possible to support zwp_linux_dmabuf_v1 version 3 as well,
but there is no reason beyond compatibility with old stacks. I would
recommend to ditch version 2 as well, as modifier-less formats aren’t
very useful nowadays.
Wayland VO that can display images from either vaapi or drm hwdec
The PR adds the following changes:
1. a context_wldmabuf context with no gl dependencies
2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects
no-op because there is no need to map/unmap the drmprime buffer,
and there is no need to manage any textures.
Tested on both x86_64 and rk3399 AArch64
dmabuf-wayland vo supports both DRMPRIME and VAAPI formats.
If upload filter is needed, we want to try VAAPI hwdec first
since most users will be using VAAPI, and there is a several second
delay when DRMPRIME hwdec is tried and fails.
Pushing E (aka Shift+e) cycles through Editions for containers
that support editions, such as Matroska, although this feature was not
documented before this commit.
The AO is feature-complete now.
As PipeWire also provides compatibility with PulseAudio, ALSA and Jack
we should put it before those for the autodetection to work.
The pure presence of PipeWire does not mean that it is actually driving
the audio session. For example it could only be meant for video.
Currently there is no proper API to detect this (see [0]), so we check
for the presence of audio sinks.
As soon as a proper API exists, we should use that.
[0] https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1835
It turns out that wayland-scanner and wayland-protocols are both exposed
as configure options in waf meaning you can --enable/--disable them at
configure time. This is pretty nonsensical. If you want to control
wayland in the build, you should just use --enable-/--disable-wayland.
wayland-scanner and wayland-protocols should just be typical checks like
in the meson build.
vaapi allows for implicit conversion on upload, which has some
relevance as the set of supported source formats is larger than the
set of displayable formats. In theory, this allows for offloading the
conversion to the GPU - if you have any confidence in the hardware
and/or driver's ability to do the conversion.
Today, we actually track the 'input' and 'output' upload formats
separately all the way up until the point we do a check as to whether
the original source format is an accepted 'output' format and then
reject it if it is not.
This means that we're essentially ignoring all the work we did to track
those 'input' formats in the first place. But it also means that it's a
simple change to compare against the 'input' format instead. The logic
is already in place to do best format selection on both sides.
I imagine that if I read through the history here, wm4 tried to
implement all of this properly and then gave up in disgust after seeing
vaapi mangle various conversions.
This is particularly interesting for vo-dmabuf-wayland where it is only
possible to display the subset of valid vaapi formats that are
supported by the compositor, yet all playback has to go through vaapi.
Users will then be able to take advantage of all possible vaapi formats
to avoid having to do software format conversion.
This has been a long standing problem that I think was the root cause
for wm4's vaapi shitlist. As DRM explicit supports all possible rgba
orderings, but OpenGL only guarantees support for 'rgba8', something
has to happen to support import of dmabufs with non-native ordering.
Although undocumented, it appears that somewhere in the import on the
GL side, the ordering is swizzled to rgba - which makes sense as that's
the only way to be able to support importing all the different formats.
But we didn't know this, and we do our own swizzling based on the
original imgfmt - which matches the drm format. So we get double
swizzling and messed up colours.
As there is no way for us to express that the GL swizzle happened to
the rest of mpv, the easiest thing to do is fudge the format to the
natural ordering so the GL doesn't change anything, then our swizzling
will do the right thing in the end.
Note that this change doesn't handle 0rgb and 0bgr because they seem to
be affected by some additional feature/bug that is mangling the
ordering somewhere that equally affects Vulkan interop. That could be a
vaapi driver bug or something going on in ffmpeg.
A few years ago, wm4 got sufficiently annoyed with how vaapi image
format support was being discovered that he flipped the table and
introduced the shit list (which just included vaapi) to hard-code the
set of supported formats.
While that might have been necessary at the time, I haven't been able
to find a situation where the true list of supported formats was unsafe
to use. We filter down the list based on what the vo reports - and the
vo is already doing a thorough testing of formats, and if a format
makes it through that gauntlet, it does actually work.
Interestingly, as far as I can tell, the hwdec_vaapi probing code was
already good enough at the time (also written by wm4), so perhaps the
key difference here is that the driver side of things has improved.
I dug into this because of the support for the 422/444 high bit depth
vaapi formats I added to ffmpeg. These are obviously not in the hard
coded list today, but they work fine.
Finally, although it's positioned as a vaapi thing, it's really just
Intel specific, as the AMD vaapi driver has never exposed support for
anything except the formats used by the decoder/encoder profiles.
The logic around trying to establish what formats are supported by
vaapi is confusing, and it turns out that we've been doing it wrong.
Up until now, we've been going through the list of decoding profile
endpoints and checking the formats declared in those profiles to build
our list.
However, the set of formats that the vaapi driver can actually support
is potentially a superset of those supported by any given profile
endpoint. This master list is exposed by libavutil via the
av_hwframe_transfer_get_formats() function, and so we should use that
list as our starting point.
Perhaps surprisingly, this change actually removes no code, because we
still want the logic that enumerates endpoints and finds supported
formats for endpoints. We need this because we must have at least one
known sw format to initialise the hwframe_ctx with.
Additionally, while in the general case,
av_hwframe_transfer_get_formats can return different formats depending
on what format you initialise the hwframe_ctx with, I happen to have
read the libavutil code, and it doesn't care, so we just need to call
it once, we know we'll get back all known formats.
In practice, with an Intel vaapi driver, this will result in us
supporting a handful of extra formats for hwuploads - particularly
yuv420p (so no need to convert to nv12 first) and various orderings
of rgb(a).
Commit 740b701 introduced handling for subtitles with unknown duration,
but it came with a minor flaw where a track event that shares identical
start time with following track event will has its Duration value set
to 0, we don't want this to happen since it will prevent simultaneous
rendering of multiple track events.
This commit aims to address this issue.
When the width is exactly a multiple of SLICE_W (currently 256),
heap buffer overflow is reported by Address Sanitizer. So adjust
the maximum index for the line array accordingly.
We've had some annoying names for interops, which we can't simply
rename because that would break config files and command lines. So we
need to put a little more effort in and add a concept of legacy names
that allow us to continue loading them, but with a warning.
The two I'm renaming here are:
* vaapi-egl -> vaapi (vaapi works with Vulkan too)
* drmprime-drm -> drmprime-overlay (actually describes what it does)
* cuda-nvdec -> cuda (cuda interop is not nvdec specific)
mpv set _NET_WM_DESKTOP to 0xFFFFFFFF, which behaves differently with each window manager.
Instead, set the window property to STICKY, and let the window managers deal with it.
The new status quo is simple: all messages coming from libplacebo are
marked "vo/gpu{-next}/libplacebo", regardless of the backend API (vulkan
vs opengl/d3d11).
Messages coming from mpv's internal vulkan code will continue to come
from "vo/gpu{-next}/vulkan", and messages coming from the vo module
itself will be marked "vo/gpu{-next}".
This is significantly better than the old status quo of vulkan messages
coming from "vo/gpu{-next}/vulkan/libplacebo" whereas opengl/d3d11
messages simply came from "vo/gpu{-next}", even when those messages
originated from libplacebo.
(It's worth noting that the the destructor for the log is redundant
because it's attached to the ctx which is freed on uninit anyway)
Managed to go completely unnoticed for months (who was the bad person
that introduced these*). Fairly self-explanatory. After getting
ProviderInfo from randr, we need to free it. The other one is pretty bad
because it leaked every frame (ouch). It turns out that you're supposed
to free any event data after you cast a generic event to an
XGenericEventCookie. Free that as well.
*: It was me.
The wayland presentation time code currently always assumes that only
CLOCK_MONOTONIC can be used. There is a naive attempt to ignore clocks
other than CLOCK_MONOTONIC, but the logic is actually totally wrong and
the timestamps would be used anyway. Fix this by checking a use_present
bool (similar to use_present in xorg) which is set to true if we receive
a valid clock in the clockid event. Additionally, allow
CLOCK_MONOTONIC_RAW as a valid clockid. In practice, it should be the
same as CLOCK_MONOTONIC for us (ntp/adjustime difference wouldn't
matter). Since this is a linux-specific clock, add a define for it if it
is not found.
This has had no effect since libplacebo v4.192.0, and was deprecated
upstream a year ago. No deprecation period in mpv is justified by this
being a debug / work-around option.
Removed the outdated information about environmental brightness
with respect to --gamma-factor, and mention that the option is
deprecated and subject to future removal. Also deprecated the
--gamma-auto option as it relies on the same outdated way of doing
things.
This brings vo_gpu_next's behavior more in line with vo_gpu. Currently,
the status quo was that `vo_gpu_next` generated subtitles with the full
resolution of the dst crop, even though practical limitations of
libplacebo meant that such subtitles inevitably got cut off at the video
boundaries. This was actually a worse status quo than `vo_gpu`, which
simply constrained subtitles to the video dimensions to prevent these
issues.
With this change, the behavior is the same as `vo_gpu`, which has the
exact same problem w.r.t interpolation. Users are back to choosing
between --blend-subtitles=yes and not having subtitles in margins,
and using --blend-subtitles=no and not having subtitle interpolation.
There are different pros and cons to each approach, and I still
ultimately plan on allowing libplacebo to interpolate subtitles even in
the black bars, to solve this issue once and for all. But for now, let's
not let perfect be the enemy of good.
No attempt is made to implement `--blend-subs=video`, which I consider
deprecated.
Fixes: https://github.com/mpv-player/mpv/issues/10272
Specifying the id of the target node during stream connect is
deprecated. Instead the property target.object should be used to link
by target serial or name. Using the name allows us to drop a bunch of
custom code.
I actually don't quite understand why this is needed, since in theory we
should already be doing the rotation as part of applying the crop. But I
guess that code doesn't quite work. This is the only way it works, so
it's probably correct. (And note that `vo_gpu` does the same internally)
This fixes an issue where blend stages with multiple passes got
overwritten by later passes, with only the final pass (typically the
overlayp pass) actually being shown.
Alphabetizing the extensions cleans up the code and makes it less
ambiguous where newer extensions should be added. The video line
also was wrapped to 72 characters for cleanliness.
When af_scaletempo2.c:process() detects a format change, it goes back
through mp_scaletempo2_init() to reinitialize everything. However,
mp_scaletempo2.input_buffer is not necessarily reallocated due to a
check in af_scaletempo2_internals.c:resize_input_buffer(). This is a
problem if the number of audio channels increases, since without
reallocating, the buffer for the new channel(s) will at best point to
NULL, and at worst uninitialized memory.
Since resize_input_buffer() is only called from two places, pull size
check out into mp_scaletempo2_fill_input_buffer(). This allows each
caller to decide whether they want to resize or not. We could be
smarter about when to reallocate, but that would add a lot of machinery
for a case I don't expect to be hit often in practice.
Certain combinations of hardware formats require the use of hwmap to
transfer frames between the formats, rather than hwupload, which will
fail if attempted.
To keep the usage of vf_format for HW -> HW transfers as intuitive as
possible, we should detect these cases and do the map operation instead
of uploading.
For now, the relevant cases are moving between VAAPI and Vulkan, and
VAAPI and DRM Prime, in both directions. I have introduced the IMGFMT
entry for Vulkan here so that I can put in the complete mapping table.
It's actually not useless, as you can map to Vulkan, use a Vulkan
filter and then map back to VAAPI for display output.
Historically, HW -> HW uploads did not exist, so the current code
assumes they will never happen. But as part of introducing Vulkan
support into ffmpeg, we added HW -> HW support to enable transfers
between Vulkan and CUDA.
Today, that means you can use the lavfi hwupload filter with the
correct configuration (and previous changes in this series) but it
would be more convenient to enable HW -> HW in the format filter so
that the transfers can be done more intuitively:
```
--vf=format=fmt=cuda
```
and
```
--vf=format=fmt=vulkan
```
Most of the work here is skipping logic that is specific to SW -> HW
uploads doing format conversion. There is no ability to do inline
conversion when moving between HW formats, so the format must be
mutually understood to begin with.
Additional work needs to be done to enable transfers between VAAPI
and Vulkan which uses mapping, rather than uploads. I'll tackle that
in the next change.
Today, lavfi filters are provided a hw_device from the first
hwdec_interop that was loaded, regardless of whether it's the right one
or not. In most situations where a hardware based filter is used, we
need more control over the device.
In this change, a `hwdec_interop` option is added to the lavfi wrapper
filter configuration and this is used to pick the correct hw_device to
inject into the filter or graph (in the case of a graph, all filters
get the same device).
Note that this requires the use of the explicit lavfi syntax to allow
for the extra configuration.
eg:
```
mpv --vf=hwupload
```
becomes
```
mpv --vf=lavfi=[hwupload]:hwdec_interop=cuda-nvdec
```
or
```
mpv --vf=lavfi-bridge=[hwupload]:hwdec_interop=cuda-nvdec
```
If we want to be able to handle conversion between hw formats in filter
chains, then we need to be able to load hwdec_interops from filters, as
the VO is only ever going to initialise one interop, based on its
configuration. That means that in almost all situations, only one of
the required interops will be loaded at the time the filter is
initialised.
The existing code has some assumptions that new hwdec_interops will not
be loaded after the vo has picked one to use. This change fixes two
instances:
* Refusing to load a new hwdec_interop if there is at least one
loaded already.
* Not recalculating the set of formats known to the autoconvert
filter when a new output format shows up. This leads to autoconvert
not knowing that a new format is supported when the hwdec interop is
lazily loaded.
It turns out that it's generally more useful to look up hwdecs by image
format, rather than device type. In the situations where we need to
find one, we generally know the image format we're dealing with. Doing
this avoids us having to create mappings from image format to device
type.
The most significant part of this change is filling in the image format
for the various hw interops. There is a hw_imgfmt field today today, but
only a couple of the interops fill it in, and that seems to be because
we've never actually used this piece of metadata before. Well, now we
have a good use for it.
ASS must only automatically break at ASCII spaces (\x20), but other
subtitle formats might expect more breaking oppurtinities.
Especially non-ASS subs in scripts, which typically do not use (ASCII)
spaces to seperate words, like e.g. CJK, might overflow the screen
if the conversion didn't insert additional linebreaks (ffmpeg does not).
Thus try to enable Unicode linebreaking for converted subs and the OSD
if libass is new enough. The feature may still be unavailable at runtime
if libass wasn't build with Unicode linebreaking support.
Previously, running a debug build of mpv would crash with this output
when preinit() at vo_libmpv.c:732 calls control(vo, VOCTRL_PREINIT, NULL):
Swift/Optional.swift:247: Fatal error: unsafelyUnwrapped of nil optional
This comes from this line of code:
var data = UnsafeMutableRawPointer.init(bitPattern: 0).unsafelyUnwrapped
Unsafely unwrapping a UnsafeMutableRawPointer.init has always been UB,
but the Swift runtime began asserting on it in debug builds a couple macOS
versions ago.
Previously we would only call list_devs() on available AOs if an AO
*did not* have a hotplug_init() callback or for the first one that *did*
have it.
This is problematic when multiple fully functional hotplug-capable AOs
are available.
The second one would not be able to contribute discovered devices.
This problem prevents ao_pipewire from introducing full hotplug support
with hotplug_init().
When a platform has multiple valid AOs that can provide hotplug events
we should try to use the one that also provides playback.
Concretely this will help when introducing hotplug support for
ao_pipewire.
Currently ao_pulse is probed by ao_hotplug_get_device_list() before
ao_pipewire and on the common setups where both AOs could work pulse
will be selected for hotplug handling.
This means that hotplug_init() of ao_pipewire will never be called and
list_devs() has to do its own initialization.
But if ao_pulse is non-functional or not compiled-in suddenly
ao_pipewire *must* implement hotplug_init() for hotplugging events to
work for all.
Also if the hotplug ao_pulse connects to a PulseAudio instance that is
not emulated by the same PipeWire instance as the playback ao_pipewire
the hotplug events are useless.
30 characters are not a lot.
Also when the name is calculated from the allocation site the line
number will be the at the end of the name, so truncating it is
especially inconvenient.
I'm adding support in ffmpeg for the XV36 format which will be used
by VAAPI for 12bit 4:4:4 content. It's an undefined-alpha channel
variant of Y412 which is itself a 12bit+4bits padding variant of Y416.
We currently have a repacker for full four channel cccc16, and for
three channel ccc16, but nothing for ccc16x16 with the undefined alpha
channel.
It's simple enough to add one using the existing macros.
uau did some investigation and noticed that we do not send a wakeup
event when we encounter end-of-stream in ao_read_data(), in contrast to
the equivalent logic for push AOs in ao_play_data().
Inserting that wakeup fixes the original problem of lack of
reinitialization on a format change without the problems we saw with
the previous attempted fix.
Fixes#10566
We have previously had a problem where pull AOs (such as pipewire)
would not reinitialize on a format change when going between two
audio-only files. In such a situation, playback would stop after the
first file.
We initially attempted to fix this by explicitly draining on EOF, which
solves that problem but introduces a blocking step where we don't
actually want one, breaking gapless audio, and causing dropped frames
at the end of playback for files with video in them too.
So, let's undo these changes and do something better in the next
commit.
The error description in #10545 could indicate that we are overflowing
we are corrupting the buffer metadata ourselves through out-of-bound
writes.
This check is also present in pw-cat so it seems to be expected for
b->requested to exceed the actual available buffer space.
Potential fix for #10545
52aed495cb ("audio: drain ao on EOF") introduced logic to drain an AO
when EOF of the input has been reached.
When no AO however is present this leads to a NULL-dereference.
Fixes#10556
Facing down the multitude of ways to somehow wrangle the get_fn pointer
out of the GL environment and into libplacebo, I decided the easiest is
to just store it inside the GL struct itself.
The lifetime of this get_fn function is a bit murky, since it's not
clear on whether or not it survives the VO init call (especially in the
case of the GL render API, which explicitly states that parameters do
not need to survive the call they're passed to), so just add a
disclaimer.
(It's fine for us to use like this because `gpu_ctx_create` is still
part of VO init)
Closes https://code.videolan.org/videolan/libplacebo/-/issues/216
Every format that was not detected as a video format was added to the
audio tracks. This resulted in e.g. YouTube storyboards from ending up
in the list of audio tracks.
Now formats that are already known to be neither video formats nor audio
formats, will also not end up in any track list.
Formats where it is unknown if they are video or audio get added to
tracks if `force_all_formats` is used, otherwise only
formats that are known to contain video or audio become video or audio
tracks respectively.
https://github.com/yt-dlp/yt-dlp/issues/4373#issuecomment-1186637357
Add xoshiro as a PRNG implementation instead of relying
on srand() and rand() from the C standard library. This,
in particular, lets us avoid platform-defined behavior with
respect to threading.
Since the previous commit introduced the notion of a features dictionary
that conveniently tells us whether or not to use a feature in a simple
yes/no, we can make use of this everywhere in the build. Instead of
doing something like 'if foo.()', change it to 'if feature['foo']
instead. This enforces a consistent standard instead of having a lot of
different possible combinations of booleans that may or may not do
something.
mpv has a ton of defines that are generated during building. Previously,
the meson build just had this as a big giant wall of text that manually
set each one but we can do this smarter. Instead, change the "features"
object to a dictionary and have it hold the name of the feature and its
value (true/false on whether it is enabled). Then at the end, just loop
through it and reformat the name of the feature so it becomes
HAVE_FEATURE. A side effect of this is that a lot of extra defines are
generated that aren't actually used in the code, but the waf build
worked like this for years anyway. A nice result of this is that the use
of foo['use'] internally can be completely eliminated and replaced with
feature['foo'] instead when needed.
The build was a bit overzealous with using dictionaries. These are fine
for when the feature checking is more complicated, but there's no point
in having them for the simplier things. This also eliminates the usage
of the 'name' key completely.
One would expect that e.g.
`--script-opts=ytdl_hook-all_formats=no --ytdl-format=bestaudio` and
`--script-opts=ytdl_hook-all_formats=yes --ytdl-format=bestaudio`
to play the exact same tracks without manual intervention.
This already worked when two formats were requested.
For a single format with `all_formats=yes` it would also play a track
that was not requested when available. This was inconsistant with the
behavior of `all_formats=no` (default), which would not play a second
track when only a single one was requested.
This combined with #10395 now plays the exact same tracks with
`all_formats=yes` as without, even when only one format is requested.
In wayland-protocols 1.25, xdg-shell got a version bump which added the
configure_bounds event. The compositor can send this to clients to
indicate that they should not resize past a certain size. For mpv, we'll
choose to only listen to this on reconfig events (i.e. when the window
first appears and if the video resolution changes later in the
playlist). However, this behavior is still exposed as a user option
(default on) because it will neccesarily conflict with a user setting a
specific geometry size and/or window scale. Presumably, if someone is
setting a really large size that goes beyond the bounds of their
monitor, they actually want it like that. The wayland-protocols version
is newer-ish, but we can get around having to poke the build system by
just using a define that exists in the generated xdg-shell header.
Unexpectedly, x11->screenrc actually doesn't update with randr events.
In a multimonitor configuration it could easily be wrong depending on
the user's layout. While it's tempting to modify the logic so screenrc
changes with randr events, this rectangle is currently used everywhere
and as far as we know, this pretty much works fine. Instead, just loop
over the randr displays that we have and select it if it overlaps with
the winrc. This follows the same logic as the fps selection in the case
of the mpv window overlapping multiple monitors (the last one is
selected).
Tracks are marked as default tracks based on what yt-dlp/youtube-dl
returns in the field `requested_formats`. The problem is that this field
only exists when there is more then one requested format.
So `ytdl-format=bestvideo+bestaudio` would have that field,
but `ytdl-format=bestaudio` would not,
leading to no tracks being marked as default tracks.
The requested formats can also be found under `requested_downloads`,
which exists regardless of the number of requested formats.
However when there is more then one requested format,
`requested_downloads` doesn't contain those formats directly and instead
has a field `requested_formats` that is identical to the other
`requested_formats`. Therefore use `requested_downloads` as a fallback
for when `requested_formats` doesn't exist.
ae768a1e14 forgot to bump the required
libdrm version however Debian 11 just barely misses the requirement,
which is a good reason not to require it unconditionally anyway.
The older overlay based drmprime hwdec should be preferred to the new
texture mapping one. This is for a few reasons:
1. In any situation where both hwdecs work, it's probably right to use
the more mature one by default, for now.
2. It seems like the overlay path primarily works on older SoCs
where the texture path is less performant, and in at least one
tested case is visually buggy, so you definitely want it to be
tried first.
3. In situations where the old hwdec doesn't work, it will fall through
to the new one.
sfan5 found a few things after I pushed the change, so this fixes them.
* Use-after-free on drm_device_Path
* Not comparing render_fd against -1
* Not handling dup() errors
This gives pull-based AOs the chance to play all queued audio.
Also it will make sure that the audio has finished playing so we can
reinitialize the AO if format changes are necessary.
Fixes#10018Fixes#9835Fixes#8904
In the confusing landscape of hardware video decoding APIs, we have had
a long standing support gap for the v4l2 based APIs implemented for the
various SoCs from Rockship, Amlogic, Allwinner, etc. While VAAPI is the
defacto default for desktop GPUs, the developers who work on these SoCs
(who are not the vendors!) have preferred to implement kernel APIs
rather than maintain a userspace driver as VAAPI would require.
While there are two v4l2 APIs (m2m and requests), and multiple forks of
ffmpeg where support for those APIs languishes without reaching
upstream, we can at least say that these APIs export frames as DRMPrime
dmabufs, and that they use the ffmpeg drm hwcontext.
With those two constants, it is possible for us to write a
hwdec-interop without worrying about the mess underneath - for the most
part.
Accordingly, this change implements a hwdec-interop for any decoder
that produces frames as DRMPrime dmabufs. The bulk of the heavy
lifting is done by the dmabuf interop code we already had from
supporting vaapi, and which I refactored for reusability in a previous
set of changes.
When we combine that with the fact that we can't probe for supported
formats, the new code in this change is pretty simple.
This change also includes the hwcontext_fns that are required for us to
be able to configure the hwcontext used by `hwdec=drm-copy`. This is
technically unrelated, but it seemed a good time to fill this gap.
From a testing perspective, I have directly tested on a RockPRO64,
while others have tested with different flavours of Rockchip and on
Amlogic, providing m2m coverage.
I have some other SoCs that I need to spin up to test with, but I don't
expect big surprises, and when we inevitably need to account for new
special cases down the line, we can do so - we won't be able to support
every possible configuration blindly.
Whether or not the GNOME project has a tendency to make life
difficult for anyone outside their ecosystem, the user manual is
no place for childish rants such as this.
Keep it to what is relevant for users.
I already added the equivalent logic for dmabuf_interop_pl previously
but I skipped the GL support because importing dmabufs into GL requires
explicitly providing the DRM format, and if you are taking a
multi-plane format and trying to treat each plane as a separate layer,
you need to come up with a DRM format for each synthetic layer.
But my initial testing has shown that the RockPRO64 board I've got to
work on drmprime hwdec will only produce NV12 in a single layer multi
plane format, and it doesn't have Vulkan support, so I have had to
tackle the GL multi-plane problem.
To that end, this change introduces the infrastructure to provide new
formats for synthetic layers. We only have lookup code for NV12 and
P010 as these were the only ones I could test.
Annoyingly, libva and libdrm use different structs to describe dmabufs
and if we are going to support drmprime, we must pick one format and do
some shuffling in the other case.
I've decided to use AVDRMFrameDescriptor as our internal format as this
removes the libva dependency from dmabuf_interop. That means that the
future drmprime hwdec will be able to populate it directly and the
existing hwdec_vaapi needs to copy the struct members around, but
that's cheap and not a concern.
With the files renamed, we can now disentangle the shared private
struct between the interops and hwdec_vaapi. We need this separation
to allow the future drmprime hwdec to use the interops.
This is the first in a series of changes that will introduce a drmprime
hwdec. As our vaapi hwdec is based around exporting surfaces as
drmprime dmabufs, we've actually got a lot of useful code already in
place in the GL/PL interops. I'm going to reorganise and adjust this
code to make the interops usable with the new hwdec as well.
The first step is to rename the files and functions. There are no
functional or other changes here. They will come next.
Avoids another pitfall on systems where the first card has a primary
node but is not capable of KMS. With this change --drm-context=drm
should work correctly out-of-the-box in all cases.
On S905X (meson) boards drmModeAtomicCommit called from
disable_video_plane in hwdec_drmprime_drm.c might still be running when
another call is made from queue_flip in context_drm_egl.c.
This causes EBUSY error in queue_flip, and causes mpv to hang.
The example given in #3024 would not play the correct video when
combined with `--ytdl-raw-options=yes-playlist=`.
Allowing `youtube:tab` as extractor and correcting the id check fixes
that.
This is somewhat academic for now, as we explicitly ask for separate
layers and the scenarios where multi-plane images are required also use
complex formats that cannot be decomposed after the fact, but
nevertheless it is possible for us to consume simple multi-plane
images where there is one layer with n planes instead of n layers with
one plane each.
In these cases, we just treat the planes the same as we would if they
were each in a separate layer and everything works out.
It ought to be possible to make this work for OpenGL but I couldn't
wrap my head around how to provide the right DRM fourcc when
pretending a plane is a layer by itself. So I've left that
unimplemented.
A VRAM memory leak was present in d3d11 when `idle=yes` and playback
stops for an item. This patch re-enables some of the code which is
only used during diagnostic which fixes the issue.
Generally, the hard-coded sizes used for the OSC elements are
comfortable regardless of the font used, but the timecode fields have
relatively many characters, and so are affected to a greater degree by
fonts with a wider or narrower average character width than expected.
This allow users to adjust the space reserved for the timecode fields to
compensate.
Using cmsFLAGS_HIGHRESPRECALC results in Little-CMS generating an
internal 49x49x49 3DLUT, from which it then samples our own 3DLUT. This
is completely pointless and not only destroys the accuracy of the 3DLUT,
but also results in no additional gain from increasing the 3DLUT
precision further.
The correct flag for us to be using is cmsFLAGS_NOOPTIMIZE, which
suppresses this internal 3DLUT generation and gives us the full
precision. We can also specify cmsFLAGS_NOCACHE, which is negligible but
in theory prevents Little-CMS from unnecessary pixel equality tests.
pw_core_disconnect frees the core, so accessing it afterward to
destroy the context is not allowed.
Instead, just destroy the context, the first thing it does is disconnect
all cores for us.
mpv only remembers volume for two channels.
Always apply the same volume to all channels in case of
non-stereo layout similarly to ao_pulse.
Don't try to do anything smart when averaging volumes,
normally they are equal anyway.
This was introduced in 7fb972fd39 and
later revised in f5a094db04. Transparency
in EGL/X11 has been broken upstream for years in Mesa unfortunately.
However, the first commit claimed to have found a way to preserve
transparency by doing a trick with picking EGLConfigs (the second commit
revises this but keeps the logic in place). However, it doesn't appear
that the first commit actually fixes anything (transparency doesn't work
on my machine) and no one else seems to have reported it working. On the
other hand, if Mesa does ever actually fix this, transparency would
immediately be broken since mpv would always set the EGL_ALPHA_SIZE to
0. Go ahead and remove this since it doesn't seem to have any actual
utility and is technically a bit of a timebomb (not that deleting two
lines is a lot of work but still) if upstream ever does fix this.
The meson build does a lot of checks and if you aren't familiar with the
internals of the meson.build, it may not be clear what is actually
enabled and what isn't. It turns out that meson has a handy function,
summary, exactly for this. This just prints a pretty summary of some
notable features in the build. It's not meant to be a comprehensive
list, but rather just what users are likely to care the most about (i.e.
x11, vulkan, etc.)
This was introduced in 04257417 without a clear explanation of the bug
it was solving, so I have no idea if it's still needed (or why it ever
was). And it definitely creates unexpected behavior, e.g. forced
clipping when converting between float and floatp.
I therefore think we should simply remove this logic and see if it
regresses anything else, then fix those other bugs *properly* (if
they're still around).
Fixes#9979
Commit 7f4841ff sorted the bindings so that if the same key was bound
more than once, then the newest binding takes priority (sorted last).
However, it got the comparison function wrong, which means the result
of the sort depended on the algorithm and not on the actual data, so
the priority for keys with more than one binding was still arbitraty.
Fix the sort function, and finally ensure that later binding acutally
override earlier bindings of the same key.
This commit kind of mixes several related things together. The main
thing is to avoid calling any XPresent functions or internal functions
related to presentation when the feature is not auto-whitelisted or
enabled by the user. Internally rework this so it all works off of a
use_present bool (have_present is eliminated because having a non-zero
present_code covers exactly the same thing) and make sure it updates on
runtime. Finally, put some actual logging in here whenever XPresent is
enabled/disabled. Fixes#10326.
Previously if the raw command_native_async returned an error then the
callback function was run directly. This meant that script writers
potentially had to account for both synchronous and asynchronous logic
in the callback, which can happen even with seemingly 'safe' commands
if the mpv event queue is full.
This was at odds with the Javascript implementation of
the function, which always runs the callback asynchronously.
Now the mp.add_timeout function is used to run the callback
asynchronously on error, replicating the Javascript implementation.
This provides consistency for developers in how the callback is handled
in Lua, and increases consistency between the Lua and Javascript APIs.
With the recent addition of the libxpresent, it should improve frame
timings for most users. However, there were known cases of bad behavior
(Nvidia) which lead to a construction of a whitelist instead of just
enabling this all the time. Since there's no way to predict whatever
combination of hardware/drivers/etc. may work correctly, just give users
an option to switch the usage of xorg's presentation statistics on/off.
The default value, auto, works like before (basically, Mesa drivers and
no Nvidia are allowed), but now one can force it on/off if needed.
The old logic always reset the x11->has_mesa/has_nvidia values on every
loop through the provider. This meant that it would always just match
whatever the last provider happened to be. So in the case of a dual GPU
system, if nvidia was the very first provider and the integrated
intel/amd card was the second (in practice, this is probably mostly the
other way around), then mpv would set has_mesa to true and has_nvidia to
false and thus try to use presentation. This is not the intended
behavior. Just rework this by also checking x11->has_mesa/has_nvidia in
the loop so a true value from the previous iteration is preserved.
This code was taken from the older vo_vaapi driver, which does
use the vaapi format list, but the new driver has no use for
these formats, as it is only interested in va surfaces that
can be mapped to wl buffers. The format doesn't enter into
it at all.
Immediately after this, d3d11 is defined again and the rest of the
meson.build uses that. Probably, this dictionary was from the original
meson PR and removing it was forgotten at some point while stuff was
being rewritten.
This builds off of present_sync which was introduced in a previous
commit to support xorg's present extension in all of the X11 backends
(sans vdpau) in mpv. It turns out there is an Xpresent library that
integrates the xorg present extention with Xlib (which barely anyone
seems to use), so this can be added without too much trouble. The
workflow is to first setup the event by telling Xorg we would like to
receive PresentCompleteNotify (there are others in the extension but
this is the only one we really care about). After that, just call
XPresentNotifyMSC after every buffer swap with a target_msc of 0. Xorg
then returns the last presentation through its usual event loop and we
go ahead and use that information to update mpv's values for vsync
timing purposes. One theoretical weakness of this approach is that the
present event is put on the same queue as the rest of the XEvents. It
would be nicer for it be placed somewhere else so we could just wait
on that queue without having to deal with other possible events in
there. In theory, xcb could do that with special events, but it doesn't
really matter in practice.
Unsurprisingly, this doesn't work on NVIDIA. Well NVIDIA does actually
receive presentation events, but for whatever the calculations used make
timings worse which defeats the purpose. This works perfectly fine on
Mesa however. Utilizing the previous commit that detects Xrandr
providers, we can enable this mechanism for users that have both Mesa
and not NVIDIA (to avoid messing up anyone that has a switchable
graphics system or such). Patches welcome if anyone figures out how to
fix this on NVIDIA.
Unlike the EGL/GLX sync extensions, the present extension works with any
graphics API (good for vulkan since its timing extension has been in
development hell). NVIDIA also happens to have zero support for the
EGL/GLX sync extensions, so we can just remove it with no loss. Only
Xorg ever used it and other backends already have their own present
methods. vo_vdpau VO is a special case that has its own fancying timing
code in its flip_page. This presumably works well, and I have no way of
testing it so just leave it as it is.
Unfortunately there's a certain company that makes graphics drivers that
are harder to deal with. The next commit aims to implement presentation,
but some empirical testing from users show that it's actually broken.
Give up and just tap into Xrandr so we can figure what drivers (or well,
providers by the extension terminology) are driving the screen.
Basically if we find intel, amd, or radeon, assume it's a Mesa driver.
If we find nvidia, then it must be nvidia. This detection requires randr
1.4 (which means using presentation in mpv secretly depends on randr
1.4), but this protocol version is nearly a decade old anyway so
probably 99.9% of users are fine. Do the version query check and all
that anyway just to be on the safe side.
Wayland had some specific code that it used for implementing the
presentation time protocol. It turns out that xorg's present extension
is extremely similar, so it would be silly to duplicate this whole mess
again. Factor this out to separate, independent code and introduce the
mp_present struct which is used for handling the ust/msc values and some
other associated values. Also, add in some helper functions so all the
dirty details live specifically in present_sync. The only
wayland-specific part is actually obtaining ust/msc values. Since only
wayland or xorg are expected to use this, add a conditional to the build
that only adds this file when either one of those are present.
You may observe that sbc is completely omitted. This field existed in
wayland, but was completely unused (presentation time doesn't return
this). Xorg's present extension also doesn't use this so just get rid of
it all together. The actual calculation is slightly altered so it is
correct for our purposes. We want to get the presentation event of the
last frame that was just occured (this function executes right after the
buffer swap). The adjustment is to just remove the vsync_duration
subtraction. Also, The overly-complicated queue approach is removed.
This has no actual use in practice (on wayland or xorg). Presentation
statistics are only ever used after the immediate preceding swap to
update vsync timings or thrown away.
Technically this was wrong. If you passed -Dvdpau=enabled but did not
have x11 (a requirement for this), the build would silently just not
build the vdpau VO. The correct behavior is for it to be a hard error.
Accomplish this by using the require function and making sure that x11
is indeed being used before attempting to find the library.
In win32 build, if libass and libfontconfig appear after libmingwex
during linking, crash happens whenever fontconfig calls to opendir().
Moving them before ffmpeg makes sure they always appear first.
More info on https://github.com/shinchiro/mpv-winbuild-cmake/issues/217.
The first set iterates through all standard FFmpeg layouts and
checks that those which fit MP_NUM_CHANNELS succeed.
The second set iterates through built-in named channel layouts,
and attempts to convert them to AVChannelLayouts.
This is the new FFmpeg channel layout structure, which now
combines channel count and layout into a single location.
Only unspecified (channel count only) and native (channel layout
mask based) layouts are currently supported for the initial move
towards non-deprecated APIs.
This shouldn't have mattered but apparently qtile is unable to get the
app id if you set it after the initial surface commit. Wayland is a mess
anyway so just shuffle this around so that the frame callback and
surface commit are the last things registered in vo_wayland_init. This
works around qtile and, in theory, doesn't appear to break anything
else. Fixes#10280.
Some wayland compositors (i.e. weston) get extremely picky about
committed buffer sizes not matching the configured state. In particular,
weston throws an error on you if you attempt to launch with
--window-maximized and use opengl (vo_vaapi_wayland actually errors as
well in this case, but that's a different issue). The culprit here is
actually wl_egl_window_create. This creates an initial buffer at the
sizes passed in the arguments which is what weston doesn't like.
Instead, move the egl_window creation call to the resize function. This
ensures that mpv is using the size obtained via the toplevel event, and
it should always be the buffer size we want.
The `absolute` value was incorrectly labelled as the default instead of
the value named `default`, which was somewhat confusing. When the newer
default option was added in 679e410 it seems like wm4 forgot to remove
the label in the manual on the previous default.
TL;DR: previously a JavaScript VM was created + destroyed whenever
a sub track was initialized, even if no jsre filter was set.
Now a JS VM is created only if jsre filters were set.
Sub filters are initialized once when a subtitle track is chosen, and
then whenever the sub track changes or when some sub options change.
Sub filters init is synchronous - playback is suspended till it ends.
A filter can abort init early (get disabled) depending on conditions
specific to each filter. The regex and jsre filters aborted early
if the filter is disabled (default is enabled) or if the track is not
ass (relativey rare, e.g. bitmap subs).
The init then iterates over the filter strings, and if the result is
empty (common - no filter was added, but also if all strings failed
regex init) then it's also aborted during init.
While this iteration step is cheap with filter regex, with jsre it
requires instanciating the JS VM (mujs) in advance in order to parse
the filter strings at the list, and the VM is then destroyed if the
list ends up empty.
This VM create+destroy is fast but measurable (0.2 - 0.7 ms, slowest
measured on 2010 MacBook Air), but can be avoided altogether if we
check that the filter list is not empty before we create the VM.
So now we do just that.
This way mingw-w64 becomes the first CI workflow to build gpu-next.
Unfortunately, currently neither wscript or meson has gpu-next or
libplacebo-next as an option that one can require.
This was actually always bugged, but we just got lucky that compositors
ignored it. The egl window was created only using wl->geometry's
coordinates but those do not include the scale factor. So technically,
the initial window creation always had the wrong size (off by whatever
the scaling factor is). The resize call later fixes it because that
correctly uses wl->scaling so in practice nothing bad was seen.
wlroots's master branch has started sending an error in this case
however and this is what trips it. Fix it correctly by using the scale
factor. This is what cd3b4edea0 tried to
fix (but was incorrect).
cd3b4edea0 is not correct and had some
unexpected breakage with geometry/resizing. Rather than completely
revert it, this commit restores the set_surface_scaling call as well as
rearranges some other things in the wayland init/reconfig process to
make it simplier. The next commit properly fixes what
cd3b4edea0 tried to fix.
Just a couple of small changes. First, the obvious one is to remove the
bogus wl->window_size = wl->vdparams; line in the configure conditional.
The reconfig always unconditionally sets the window_size here so there's
no need to duplicate it. The more important change is to remove the
usage of set_surface_scaling. This function is just to handle when
scaling changes and for setting the initial scale, it was called in the
reconfig. This, however, causes some weird issues in the latest
sway/wlroots where it can try to divide a buffer by an inappropriate
scale factor. This is possibly due to some weird ordering of events and
only occured in opengl for some reason.
Luckily, it turns it out it's not neccessary to set the scaling here at
all. The surface enter event is already setup to handle scale changes.
On an HIDPI display, mpv will initially assume a scale of 1 but the
surface actually enters the wl_output, it will automatically readjust
and resize itself to the appropriate scale value. This works on the
initial launch of the mpv window as well, so there's no need to special
case this in the reconfig event. This has the nice bonus of avoiding
that sway/wlroots issue as well since the buffer_scale is set much
later. Fixes#10263.
One downside of this approach is that it bypasses the mixer cache, but
while this is not ideal for performance reasons, the status quo is also
simply broken so I'd rather have a slower implementation that works than
a faster implementation that does not.
And as it turns out, updating the OSD state and invalidating the mixer
cache correctly is sufficiently nontrivial to do in a clean way, so I'd
rather have this code that I can be reasonably certain does the right
thing.
Fixes#9923 as discussed. Also fixes#9928.
This is mainly for other user scripts that may conflict with the osc
logo in some way. Although it is possible to listen for
shared-script-properties, this has many edge cases that could easily pop
up. A user could want other OSC things to happen at the same time (say
osc-message). They just don't want the logo. The idlescreen option
disables all idlescreen related things (including the santa hat) if it
is set to "no". A new script message (osc-idlescreen) is also added so
users can easily toggle the value (passing "cycle" or just explictly
setting "yes" or "no"). Some more discussion on this is found in the
below github issues.
https://github.com/mpv-player/mpv/issues/10201https://github.com/CogentRedTester/mpv-file-browser/issues/55
Apparently _t names are reserved, and in this case it wasn't very
useful anymore (it was useful while developing it, but this code is
almost 10 years old now).
Fixes a compilation error on Solaris.
The wayland stuff is designed to update/rescale itself whenever the
wl_output scale changes. This is great, but vo_vaapi_wayland should not
actually attempt to handle any hidpi stuff. The point of this VO is to
hand off as much to the compositor as possible, so we do want the
compositor to do the scaling here (enjoy your bilinear). This fixes some
incorrect rendering that could occur with scaling values not equal 1 due
to mismatches between buffer coordinates and the surface local
coordinates. It also eliminates the need to specify
--no-hidpi-window-scale on hidpi displays (has the same practical
effect).
A bad person (AKA me) merged this stuff without paying close enough
attention to the code style. Reformat this to be in-line with the rest
of the wayland code and general mpv style (braces for functions on the
next line, horizontally aligning arguments, some cosmetic cleanups for
wayland_common.h, etc.).
So it turns out that mpv already has an mp_tag_str which makes a
readable string out of fourccs (drm formats are these).
drm_format_string, on the other hand, has a ton of baggage with having
to check different libdrm versions for certain headers, adding
compile-time defines (because there are no version defines in the libdrm
headers), etc. It's a lot simpler to just use what mpv already has and
it returns what you actually care about: i.e. is this format supported
or not. Fixes https://github.com/mpv-player/mpv-build/issues/184
This driver makes use of dmabuffer and viewporter interfaces
to enable efficient display of vaapi surfaces, avoiding
any unnecessary colour space conversion, and avoiding scaling
or colour conversion using GPU shader resources.
If the player is started with --idle and the osc-tracklist script-message
is called then the tracks_osc table will be nil,
which caused the OSC to crash due to attempting to index a nil value.
This appears to be because the osc_tracklist variable is both
initialised and updated by (ultimately) the render() function, which
is not run when the player is idling.
Rather than mess with the existing OSC logic it's easier to either
add this single check, or alternatively to initialise the the tracks_osc
table somewhere before this.
Both mpv's main function and the client API use mp_initialize to start
up. In general, these work the same however the client API had one
slight, unnecessary limitation: you can't start it up with idle=no. In
practice, the libmpv profile (used with the client API) sets idle to
yes, so it's rarely encountered, but there's no particular reason why
this policy needs to be enforced. It turns out that mp_initialize does a
quick check to see if there are any entries in the playlist and if idle
mode is set. If not, it prints the help message and exits. Basically,
it's just the part that handles the terminal message when you type "mpv"
with no arguments. Unfortunately with idle=no, the client API also hits
this code path, exits prematurely with 1 and thus returns an API error.
Fortunately, the fix is very simple. If the client API is used instead
of the "normal" mpv executable, then the mp_initialize function gets a
NULL for the options argument. When starting mpv from the terminal (when
you would want to see the before mentioned help text), there will always
be at least an argv[0] (the mpv executable name itself) so we can
reliably distinguish between the two. The other case where there could
be no argv is if the pseudo-gui profile is used, but this always
enforces idle so we don't have to worry about it either. In other words,
with this combination of conditions (options, no idle, and no playlist
entries), we can be sure this is from a user calling mpv in the terminal
with no arguments. Therefore, other cases can be allowed which means
client API users can initialize with idle=no. Fixes#10162.
Normally with the keep-open option, mpv is supposed to set the
eof-reached property to true so clients can possibly do interesting
things at this step. However, there was actually an edge case where this
property notification did not occur. If you use keep-open and then seek
in the file past the end (so mpv stops), property notification is not
actually sent in this case. Internally, mpv does a very exact seek at
this step which also ends playback, but it does not set STATUS_EOF to
the ao and vo before the core idle state is updated. To fix this edge
case, it's simply just a matter of explictly setting STATUS_EOF after
seek_to_last_frame in handle_keep_open. This logic will only ever
trigger if keep-open is being used and the seek goes past the end of the
file, so we know that there will always be an EOF here.
5774ce759a added the new output name event
and used them for the --fs-screen-name option. It turns out that the
display-names property could also make use of these names, so go ahead
and use output->name in this case if we have them. If not, fallback to
output->model like before.
Windows is weird and symbols weren't actually being exported. This is
because __GNUC__ is defined and picked up in the conditional, but
__attribute__((visibility("default"))) doesn't actually export anything
to the dll. Instead, just check if we have win32 defined first and then
always set __declspec(dllexport). Fixes#10171.
ffmpeg 5.1 adds support for IPFS (the ipns:// and ipfs:// protocols).
This patch enables those protocols to be fist-class citizens in mpv.
Thus allowing for playing IPFS resources on mpv like:
"mpv ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T"
Some compiler flags were passed to mpv in order to get it to build as a
gui application on windows. However on the meson build, this always
resulted in mpv being built as a console application. This is because
the function for making executables in meson specifically has a kwarg
called win_subsystem* which defaults to 'console'. That always added
link arguments at the end which compiled mpv.exe as a console
application. The correct thing to do is to remove all of the
subsystem-related flags in the meson build and use the win_subsystem
kwarg as intended by setting it to 'windows,6.0'. For mpv.com, we can
remove the -Wl,--subsystem,console flag since meson will set this by
default in that executable. This makes mpv.exe function correctly and
open with the pseudo-gui while mpv.com acts as a console wrapper.
https://github.com/mesonbuild/meson/commit/1a0603835e3c9f1047d9b7694efc996219a422e4
These values and options were simply never looked at in the drm egl
context. This pretty much is just a copy and paste of what is in vo_drm.
Fixes#10157.
09ea3a424f moved the console above the OSC when it is visible so they
don't overlap, but only changed the first ass:pos() call and forgot to
update the second one, which redraws the cursor on top of the text, so
when both the OSC and the console are visible, a second cursor is drawn
on the OSC. You have to type past where the buttons are to notice it.
This commit synchronizes the position of the 2 ASS events.
Allow screenshot-high-bit-depth=yes to work with JPEG XL
screenshots when screenshot-sw=no is set. They already work
as expected when screenshot-sw=yes is set, but this allows
the hardware screenshots to work this way too.
Since 2018, wl_surface_damage_buffer has been explicitly preferred and
recommended over wl_surface_damage*. mpv was still using the old
function in a couple of spots. The only difference is that we need to
pass buffer coordinates instead of surface coordinates. In vo_wlshm,
this is done by using vo->dwidth/vo->dheight since that is always used
whenever wl_buffers are created. In the case of the cursor surfaace, we
actually already passed buffer coordinates to it (img->width/height)
which was probablly technically wrong with wl_surface_damage, but it
doesn't really matter in practice. This requires bumping wl_compositor
to version 4 which is no problem since this dates back to 2015*.
https://gitlab.freedesktop.org/wayland/wayland/-/commit/921d0548035673a1bf6aeb9396b9bc728133411ehttps://gitlab.freedesktop.org/wayland/wayland/-/commit/3384f69ecf043d62a4e036c0353c2daa01d7c4d0
Add Jpeg XL as a possible output format for screenshots, which
should make it possible to take fast screenshots with much better
quality than JPEG, or take lossless high-bit-depth screenshots
with lower file sizes than PNG.
It is possible for vo_gpu_next to attempt a resize before the windowing
backend is fully initialized. In practice, this can happen on wayland
which means libplacebo attempts a 0x0 resize. Depending on the API, a
0x0 resize may be allowed (vulkan or d3d11), but libplacebo just returns
a 0 in this case which mpv doesn't do anything with anyway. In the case
of opengl, this usage is explictly forbidden and will result in a
warning which may confuse users. Solve this by just not trying a resize
if dwidth and dheight in the vo are not available. Fixes#10083.
Recently, git patched a CVE which makes it much more strict about
different users operating on directories they don't own. For us, this
causes breakage with version.sh and version.py since they both run a git
describe command to fetch the commit hash. Currently, this only affects
the tumbleweed container (likely because it was recently changed) and
thus the git describe command always errors out. Workaround this by just
explictly adding the mpv directory as a safe directory for git.
- Say built-in which is more common than builtin
- Move "By default" because only the key to open the console is
customizable, and fix the punctuation and case of the sentence
- ` opens the console, not ´
- Remove the sentences that explains which user script console.lua is
based on since it's no longer relevant now that the console has been
part of mpv for over 2 years.
Now that a separate --cover-art-whitelist option exists, files like
cover.jpg are loaded even without setting --cover-art-auto to fuzzy, so
only load files that have exactly the media filename by default, since
fuzzy loading is probably more likely to load unwanted images than to
load cover art that the user intended to display, especially if you play
audio files with a short filename like a.mp3.
This allows more fine grained control over which cover art to load. With
--cover-art-auto=exact and --cover-art-whitelist=yes, you can now load
cover art with the exact media filename and the whitelisted filenames,
but not cover art that contains the media filename
(--cover-art-auto=fuzzy).
This adds a section to the documentation to explain how resuming
playback works, and in particular it explains how it affects which
playlist entry mpv starts playing from, since this feature was only
implied in the --playlist-start documentation.
It also groups the documentation of the watch later options together to
make them easier to find.
draw_image is an old API that was deprecated long ago. However when
wlshm was originally added, it used draw_image. There's no particular
reason for this and it can trivially be switched to draw_frame instead.
This has some real advantages (notably --vo=wlshm --idle --force-window
actually works).
This fixes build failures with avcodec 58.113.100 or before,
matching FFmpeg release versions 4.0 to 4.3.
This flag was added in between avcodec 58.113.100 and 58.114.100
during the FFmpeg 4.4 development cycle. It lacks its own version bump,
so instead a check for the define is utilized instead.
Additionally, warn the user if they request GPU film grain with
too old of an FFmpeg.
Fixes#10088
The VO is available during decoder initialization mostly for direct
rendering purposes, so if f.ex. a complex filter chain is utilized,
there is no video renderer information available via
mp_filter_find_stream_info during creation of the decoder filter.
Thus, check for whether the VO is available before attempting to
check the capabilities flag from it.
Additionally - to simplify logic - makes explicitly requesting GPU
film grain to always disable decoder film grain functionality. The
warning is still shown if the VO is available and no support for
film grain application is available.
Fixes#10079
In wayland 1.20.0, a couple of new events, name and description, were
added to the interface. Description is not particularly useful, but name
returns back nice names for the output like "DP-1" and so on. It makes
sense to use these for fs-screen-name and prefer them over the model
name (old way of doing it) if they are available. The only problem is
that 1.20.0 is pretty new so old distros aren't going to have it anytime
soon. Deal with this by adding some defines.
Because wayland is a special snowflake, mpv wound up incorporating a lot
of logic into its render loop where visibilty checks are performed
before rendering anything (in the name of efficiency of course). Only
wayland actually uses this, but there's no reason why other backends
(x11 in this commit) can't be smarter. It's far easier on xorg since we
can just query _NET_WM_STATE_HIDDEN directly and not have to do silly
callback dances.
The function, vo_x11_check_net_wm_state_change, already tracks net wm
changes, including _NET_WM_STATE_HIDDEN. There is an already existing
window_hidden variable but that is actually just for checking if the
window was mapped and has nothing to do with this particular atom. mpv
also currently assumes that a _NET_WM_STATE_HIDDEN is exactly the same
as being minimized but according to the spec, that's not neccesarily
true (in practice, it's likely that these are the same though). Anyways,
just keep track of this state in a new variable (hidden) and use that
for determing if mpv should render or not.
There is one catch though: this cannot work if a display sync mode is
used. This is why the previous commit is needed. The display sync modes
in mpv require a blocking vsync implementation since its render loop is
directly driven by vsync. In xorg, if nothing is actually rendered, then
there's nothing for eglSwapBuffers (or FIFO for vulkan) to block on so
it returns immediately. This, of course, results in completely broken
video. We just need to check to make sure that we aren't in a display
sync mode before trying to be smart about rendering. Display sync is
power inefficient anyways, so no one is really being hurt here. As an
aside, this happens to work in wayland because there's basically a
custom (and ugly) vsync blocking function + timeout but that's off
topic.
The video sync logic for mpv lies completely within its core at
essentially the highest layer of abstraction. The problem with this is
that it is impossible for VOs to know what video sync mode mpv is
currently using since it has no access to the opts. Because different
video sync modes completely changes how mpv's render loop operates, it's
reasonable that a VO may want to change how it renders based on the
current mode (see the next commit for an example).
Let's just move the video sync option to mp_vo_opts. MPContext, of
course, can still access the value of the option so it only requires
minor changes in player/video.c. Additionally, move the VS_IS_DISP
define from to player/core.h to common/common.h. All VOs already have
access to common/common.h, and there's no need for them to gain access
to everything that's in player/core.h.
A bit of a personal pet peeve. vulkan, opengl, and wlshm all had
different methods for doing wayland's "check for visibility before
drawing" thing. The specific backend doesn't matter in this case and the
logic should all be shared. Additionally, the external swapchain that
the opengl code on wayland uses is done away with and it instead copies
vulkan by using a param. This keeps things looking more uniform across
backends and also makes it easier to extend to other platforms (see the
next couple of commits).
This lets us remap various messages which might now be happening at
each frame onto the trace level, thus unaffecting the initial debug
log level.
Additionally - thanks to this ability - the previously globally denied
message queue abandonment messages can now be handled and mapped to
trace log level, as on that log level they may be of use.
Recommended by rossy and based on his libplacebo commit
6d72f6445566eddb0493447d0bda72d98a99d40c .
Instead of always having the reference outside of calling resize,
request a backbuffer at start and relieve the backbuffer at
submission for presentation.
Query the description of the swap chain, which should in all theory
contain the format of the backbuffer. Then utilize a newly added
ra_d3d11 function to map the format to an ra_format. After that,
utilize the depth of the first plane of the format, as previously.
This makes use of the new frame acquire/release callbacks to hold on to
hwdec images only as long as necessary. This should greatly improve the
smoothness/efficiency of hwdec interop, by not holding on to them for
longer than needed.
This also avoids the need to pool hwdec mappers altogether.
Should fix#10067 as well, since frames are now only mapped when we
actually use them.
9a7b2015e1 added the --screen-name option
for x11, but it was unfortunately broken. The commit does correctly
handle vo_x11_update_screeninfo and select the correct screen. However,
vo_x11_sizehint was missed. Specifically, the force_pos bool was always
false because it only took into account --screen being set and not
--screen-name. To fix this, just add an extra condition to the force_pos
bool so it becomes true if there's a string in --screen_name. Fixes
issue #9877.
Previously on wayland, it would result in an egl config with only 2 alpha
bits, which technically matches what was requested, but is not very useful.
Fixes#9862
Variable Refresh Rate (VRR), aka Freesync or Adaptive Sync can be used
with DRM by setting the VRR_ENABLED property on a crtc if the
connector reports that it is VRR_CAPABLE. This is a useful feature
for us as it is common to play 24/25/50 fps content on displays that
are nominally locked to 60Hz. VRR can allow this content to play at
native framerates.
This is a simple change as we just need to check the capability
and set the enabled property if requested by the user. I've defaulted
it to disabled for now, but it might make sense to default to auto
in the long term.
The field has been deprecated, yet the upcoming new default is not yet
the default. Thus, until lavc major hits 60 and the default behavior
finally gets changed, we have to explicitly set the field's value.
The deprecation had already been handled by adding the required
version limitation for this code in bbbf3571ed ,
this change merely just removes the warning which would otherwise
appear until lavc major version gets bumped to 60.
this field is used only in a special vo draining edge case.
switching to an atomic reduces osd->lock contention
between the mpv core (in write_video) and vo threads
which are managing osd rendering manually (such as vo_rpi).
Signed-off-by: Aman Karmani <[email protected]>
Pulling in <libplacebo/utils/libav.h> in particular triggers the
notorious _av_vkfmt_from_pixfmt linking issue when FFmpeg is built
without Vulkan support.
When I introduced the concept of lazy loading of hwdecs by img format,
I did not propagate the probing flag correctly, leading to the new
normal loading path not runnng with probing set, meaning that any
errors would show up, creating unnecessary noise.
This change fixes this regression.
FFmpeg recently split version.h into version.h and
version_major.h, and no longer automatically includes
version.h in avcodec.h (and the other libraries). This
should allow mpv to build against ffmpeg git master. See
FFmpeg/ffmpeg@f2da2e1458
These headers are not new, so their inclusion should not affect
backwards compatibility.
As found out by @philipl, failing to pass this from the VkInstance to
the VkDevice is bad style. We might want to override the get_proc_addr
pointer in the future.
20c4036daa switched to hiding all symbols
by default and exporting the ones we want with MPV_EXPORT.
However, the mpv_stream_cb_add_ro function was missed and it is part of
the client API. Export it too. Fixes#9971.
Our logging here today is very poor. We don't make it clear what
formats we are probing, or even that a certain format failed in most
cases. In the case where we do log the error, we don't make it clear
which format it was that failed.
The end result is that we have no idea what the possible and final
format spaces are, which makes it very hard to debug whether things are
working correctly, or to work on supporting additional formats.
The documentation's current discussion of hwdec usage is out of date,
and unnecessarily pessemistic when applied to modern hardware. The
reality is that modern APIs on modern hardware produce reasonable
results and there's no need to pretend otherwise. The current language
that tries to drive people away from using hwdecs at all leads to them
making bad choices when they do try to use it.
Let's also make it clearer that users should use vo=gpu with hwdecs
rather than vo=vaapi or vo=vdpau. Even the existing admonitions have
proven insufficient, so let's strengthen that language.
This code fails if we have DR buffers, but none of them correspond to
the current frame. Normally only happens if e.g. changing the decoder at
runtime, since DR buffers are not properly reinit in that case.
(Arguably a separate bug)
The current map_frame() code fails to clean up after itself on the
failure paths. But if map_frame returns false, no cleanup code is ever
attempted. Add the relevant calls to clean up state manually,
throughout.
So, turns out the approach in 7f67a553f doesn't work for all codecs. In
particular, sometimes lavc will internally allocate a new AVBuffer that
just points at the old AVBuffer but has a different opaque field for
some reason. In these cases, the DR metadata doesn't survive the
round-trip through libavcodec.
I explored several alternative ways of solving this problem, including
adding new mp_image fields, but in the end none of them survived the
round-trip through AVFrame and back. The `priv` and `opaque` fields
in respectively `mp_image` and `AVFrame` are also too heavily overloaded
to be of much help.
In the end, bite the bullet and use the same approach as done in
`vo_gpu`, which is to just keep track of a list of all allocations. This
is a really ugly way of doing things IMO, but ultimately, completely
safe.
Previously, when mpv was invoked with unsupported hwdec value, such
as --hwdec=foobar, there was no indication that it doesn't exist.
The reason it's not validated during options parsing is that the name
is only evaluated when selecting hwdec for actual decoding, by
matching it against runtime list of names from ffmpeg.
Additionally, when selecting hwdec for decoding, matching the name
came after filtering by codec, hence overall never-matched-name did
not necessarily indicate it's unsupported (doesn't exist at all).
Now we check the name before filtering by codec, and when done,
warn if no hwdec with that name exists at all.
This means that an unsupported name will now generate such warning
whenever we try to choose a hwdec, i.e. possibly more than once.
It's much better than no notification at all, and arguably adequate
for a sort of configuration error (linked ffmpeg has no such hwdec
name) which we don't validate during option parsing.
Some decoders, notably hevcdec, will unconditionally memset() the entire
AVBufferRef based on the AVBufferRef size. This is bad news for us,
since it also overwrites our `struct dr_buf`.
Rewrite this code to make it more robust - keep track of the DR buf
metadata in a separate allocation instead. Has the unfortunate downside
of technically being undefined behavior if `opaque` is not at least 64
bits in size, though, but avoids this issue.
Maybe there's a better way for us to unconditionally keep track of DR
allocation metadata. I could try adding it into the `mp_image` itself.
Maybe on a rainy day. For now, this works.
Fixes#9949
Might fix#9526
Previously only status<0 was considered as error, but status>0 is
also an error (the process exit code). Change to status != 0.
This likely makes little to no difference in practice, because if
stdout is empty or can't be parsed as JSON then it's considered
an error anyway, but still, this is more correct.
Also, on error, add the complete subprocess result to the verbose log.
There are two major ways of going about this:
1. Expose the native ra_gl/ra_pl/ra_d3d11 objects to the pre-existing
hwdec mappers, and then add code in vo_gpu_next to rewrap those
ra_tex objects into pl_tex.
2. Wrap the underlying pl_opengl/pl_d3d11 into a ra_pl object and expose
it to the hwdec mappers, then directly use the resulting pl_tex.
I ultimately opted for approach 1 because it enables compatibility with
more hardware decoders, specifically including ones that use native
OpenGL calls currently. The second approach only really works with
cuda_vk and vaapi_pl.
I was initially hesitant to link to an external article from the manpage
but a lot of other places in the man page already do something like
this, and it really makes more sense to have this as a wiki article
rather than trying to keep the manpage up-to-date by hand, since this
evolves quickly and the two are expected to converge over time.
This avoids decoding/caching more frames in advance than necessary. In
particular, this is very important for hwdec, which generally can't have
too many decoded frames in a pool at the same time.
So I can reuse it in vo_gpu_next without having to reinvent the wheel.
In theory, a lot of the stuff could be made more private inside the
hwdec code itself, but for the time being I don't care about refactoring
this code, merely sharing it.
We don't need to hold on to buffers longer than necessary. Doesn't
matter for vo_gpu but greatly matters for vo_gpu_next, since it persists
hwdec mapped textures for longer periods.
Unfortunately, only provides benefits for hwdecs which do explicit
copies in their decode path, which currently just means cuda and
d3d11va.
There's really nothing vulkan-specific about this hwdec wrapper, and it
actually works perfectly fine with an OpenGL-based ra_pl. This is not
hugely important at the time, but I still think it makes sense in case
we ever decide to make vo_gpu_next wrap OpenGL contexts to ra_pl instead
of exposing the underlying ra_gl.
Easiest way is by just using a designated struct initializer. If we
don't, `p->images` ends up inheriting random data, which leaks into e.g.
eglDestroyImageKHR.
It's a small miracle this never blew up before. Or maybe it did. Who
knows.
A few years ago, in 25e70f4743, we
disabled the vavpp deinterlacing auto-filter on the basis that it
caused crashes on _some_ hardware with _some_ driver version(s). But
since then, the situation has improved. There is still a limitation
where you can't turn deinterlacing on on the fly with AMD, but it
doesn't crash anymore (That is #7388).
So, given that AMD users have to set up the deinterlacing filter
manually either way, let's re-add the auto-filter for Intel users.
Some youtube_dl extractors retrieve URLs which contain other URLs
inside of them, for example Funimation, like this:
https://example.com/video?parameter=https://example.net/something
The url_is_safe function uses a pattern to match the protocol at the
start of the URL. Before this commit, this pattern was not compliant
with the URL spec (see the definition of "A URL-scheme string"):
https://url.spec.whatwg.org/#url-writing
Therefore it would match any characters, including "://", until the
last occurence of "://" in the string. Thus the above URL would match
https://example.com/video?parameter=https
which is not in safe_protos so the video will not play.
Now the protocol can only start with a letter and only contain
alphanumerics, "." "+" or "-" as the spec says, so it will only match
the first protocol in the URL ("https" in the above example.)
Previously the URL also had to contain "//" after the ":". Data URLs
do not contain "//": https://datatracker.ietf.org/doc/html/rfc2397
so now the pattern does not look for "//", only ":".
libplacebo v198 fixed this properly by adding the ability to flip planes
directly, which is done automatically by the swapchain helpers.
As such, we no longer need to concern ourselves with hacky logic to flip
planes using the crop. This also removes the need for the OSD coordinate
hack on OpenGL.
These helpers, for some reason, decided to round the returned values up
to multiples of the nearest plane alignment. This logic makes no sense
to me, and completely breaks any sort of oddly-sized mp_image.
This logic was introduced, presumably in error and without real
justification, as part of a major refactor commit (caee8748), As far as
I can tell, removing it again doesn't regress anything.
Fixes several serious bugs including buffer underflows and GPU crashes
in vo_gpu and vo_gpu_next.
Page 2 displays the frame timing info for each type (currently "Fresh"
and "Redraw"), but since they're unordered keys of a map, their
iteration order and hence their order on screen could (and did) change
depending on $things, which was annoying.
haasn thinks none of them should be considered more important (and
therefore maybe worthy of being displayed on top), so we go with
lexicographic order, which currently means that "Fresh" is first.
Fixes#9901
This fixes two potential divisions by 0 at generate_graph(...):
- If v_avg is (given and) 0.
- if v_max is 0.
The former doesn't seem to happen in practice because v_avg is only
used at one generate_gpah call, where it's apparently not 0.
The latter triggers if all the graph values are 0 (hence v_max is
also 0).
The implication of these divisions by 0 is an invalid y-value which
ends up at the ASS coordinates string for the graph inner content.
On linux the value ends as "nan" (luajit) or "-nan" (lua 5.1/5.2), and
on Windows it's "nan" (luajit) or "-1.#IND00" (lua 5.1/5.2), maybe due
to msvcrt's snprintf.
All these strings are wrong as ASS numbers, but due to luck in how
libass parses the coordinates, "nan" and "-nan" result in empty graph
(which looks OK for "all values are 0"), while "-1.#IND00" is parsed
as -1, which breaks the graph rendering (affects other graphs too).
One example of "all values are 0" is at page 0 (internal performance
graphs) on Windows - because the cpu metrics don't work.
So this fixes at least page 0 on Windows with lua 5.1/5.2.
While at it, move the scale calculations to one place, which now
avoids division by 0, instead of duplicating this calculation.
In the future, we can consider improving the generate_graph API:
- It needs one peak value, but takes 3 (v_max, v_avg, scale) which
are meshed into one final value.
- v_avg is only used in 1 of 6 call sites, but at the middle of the
arguments, so all other call sites need to pass explicit "nil".
- "scale" is arbitrary and used to leave some space at the top of the
graph. 5 places use 0.8, one uses 0.9. Could probably be unified.
Render subs at the output resolution, rather than the video resolution.
Uses the new APIs found in libplacebo 197+, to allow controlling the OSD
resolution even for image-attached overlays.
Also fixes an issue where the overlay state did not get correctly
updated while paused. To avoid regenerating the OSD / flushing the cache
constantly, we keep track of OSD changes and only regenerate the OSD
when the OSD state is expected to change in some way (e.g. resolution
change). This requires introducing a new VOCTRL to inform the VO when
the UPDATE_OSD-tagged options have changed.
Fixes#9744, #9524, #9399 and #9398.
The stop-screensaver option is currently limited to a simple yes/no
option. While the no option does always disable mpv trying to stop the
screensaver, yes does not mean the screensaver is always stopped. The
screensaver will be enabled again depending on certain conditions (like
if the player is paused). Simply introduce a new value for this option,
always, which does exactly what the name implies: the screensaver will
always be disabled.
- Make it clearer that playback_only affects subprocess' behavior when
the playback of the current playlist entry terminates, rather than
when mpv quits.
- Explain when status is positive and when it is negative.
- Replace "exited gracefully" in status' and error_string's
documentation with "terminated normally" so it can't be misinterpreted
as exiting successfully.
- Reword the playback_only warning
Historically, we have treated hwdec interop loading as a completely
separate step from loading the hwdecs themselves. Some hwdecs need an
interop, and some don't, and users generally configure the exact
hwdec they want, so interops that aren't relevant for that hwdec
shouldn't be loaded to save time and avoid warning/error spam.
The basic approach here is to recognise that interops are tied to
hwdecs by imgfmt. The hwdec outputs some format, and an interop is
needed to get that format to the vo without read back.
So, when we try to load an hwdec, instead of just blindly loading all
interops as we do today, let's pass the imgfmt in and only load
interops that work for that format. If more than one interop is
available for the format, the existing logic (whatever it is) will
continue to be used to pick one.
We also have one callsite in filters where we seem to pre-emptively
load all the interops. It's probably possible to trace down a specific
format but for now I'm just letting it keep loading all of them; it's
no worse than before.
You may notice there is no documentation update - and that's because
the current docs say that when the interop mode is `auto`, the interop
is loaded on demand. So reality now reflects the docs. How nice.
Pass channel volumes to `pw_stream_set_control` as array.
This is correct calling conventions and prevents
right channel muting every time ao-volume property is changed.
Terminate `pw_stream_set_control` calls with 0.
This is an annoying special case only really needed because of the
`vflip` filter. mpv handles this by directly adjusting the plane
transform. The libplacebo API, unfortunately, does not allow passing the
required information for this to work smoothly.
Long-term I plan on adding support for plane flipping in libplacebo
directly, but for the meantime, we will have to work-around it by moving
the flipping to the whole-image `crop` instead. Not an ideal solution
but better than crashing.
Fixes#9855
We're getting bug reports that the recent change to add extra usage
flags to swapchain buffers (for gpu-next) breaks mpv on some Windows 7
systems, and it seems like this is only happening with flip-model
swapchains.
Creating swapchains with DXGI_USAGE_UNORDERED_ACCESS should be valid. At
least, it's not specifically disallowed, unlike some other flags[1]. So,
just disable it for flip-model swapchains in Windows 7, rather than
disabling it everywhere.
[1]: https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/dxgi-usage
See the previous commit for the full explanation. Basically, luajit 2.0
has a bad pc file on macos that causes libmpv to fail during build. The
workaround was, if the os was darwin and luajit was found, to save a
full luajit dep and a partial luajit dep with the link args removed. The
partial dep was used for compiling libmpv, and the full dep was used for
the actual mpv executable. This worked and was needed for the CI to pass
but it sucked. Since the previous commit now makes the CI grab lua 5.1,
we don't need all this crap anymore. Just delete it and treat the
dependency normally.
This does effectively mean that building libmpv with luajit 2.0 on macOS
will no longer work with the meson build. However libraries not being
built correctly is not a mpv-specific issue. The waf build will succeed
for some reason, but it has known issues and it would be better if it
just failed honestly. An upstream developer said years ago that that
macOS users should use the 2.1 branch (and there's no release of
course). In any case, no macOS user should be building mpv with luajit
2.0, so we shouldn't be going out of our way to support this.
https://github.com/mpv-player/mpv/issues/7512https://github.com/LuaJIT/LuaJIT/issues/521#issuecomment-562999247
LuaJIT is still actively developed, but upstream is allergic to making
new releases for whatever reason. The last tagged release was in May of
2017, so we probably shouldn't expect a new release anytime soon. Now
for mpv, this doesn't really matter except in the case of macOS where
2.0.5 is actually a bit broken (and of course the CI uses luajit). More
specifically, the 2.0.5 pc is broken and has a "-pagezero_size 10000"
flag which causes libmpv to fail (only executables are allowed to use
this). This magically works on waf. It's possible that it just happens
to ignore the link arguments. However on the meson build, this is broken
and led to a really ugly hack using a partial dependency so both mpv and
libmpv succeed. Fortunately, the 2.1 luajit branch fixes this.
Unfortunately, there's no actual release.
Instead, just use Lua 5.1. Note that lua 5.1 is technically deprecated
in homebrew, but the chances of this going away is pretty slim since
everyone knows that new lua versions are not backwards compatible.
Anyways, using 5.1 works fine and lets us get rid of a terrible hack in
the meson build. People really shouldn't be using 2.0 LuaJIT anyway.
We have a few examples with vf=rotate=90, but libavfilter's rotate
accepts radians - not degrees, so a value of 90 is valid but misleading
because it's not 90 degrees.
Change the value of 90 at those examples.
Also replace "vf-add=hflip" with "vf add hflip", since that example
lists commands, not options, to run.
Drag and drop in wayland is weird and it seems everyone does this
slightly differently (fun). In the past, there was a crash that
occured (fixed by 700f4ef5fa) which
involved using the wl_data_offer_finish in an incorrect way that
triggered a protocol error (always fatal). The fix involved moving the
function call to data_device_handle_drop which seemingly works, but it
has an unfortunate side effect. It appears like GTK applications (or at
least firefox) close the pipe after this function is called which makes
it impossible for mpv to read data from the fd (well you could force it
open again in theory but let's not do that). Who knows if that was the
case when that commit was made (probably not because I'd think I would
have noticed; could just be a dummy though), but obviously having broken
dnd for a major application isn't so fun (this works with QT and
chromium anyway).
Ideally one would just simply check the pipe in data_device_handle_drop,
but this doesn't work because it doesn't seem the compositor actually
sends mpv the data by then. There's not actually a defined event when
you're supposed to be able to read data from this pipe, so we wait for
the usual event checking loop later for this. In that case,
wl_data_offer_finish needs to go back into check_dnd_fd, but we have to
be careful when calling it otherwise we'd just commit protocol errors
like before. We check to make sure we even have a valid wl->dnd_offer
before trying to indicate that it is finished and additionally make sure
there is a valid dnd_action (after checking the fd, it's always set back
to -1).
This doesn't fix everything though. Specifically, sway with
focus_follows_mouse (the default) and GTK as the data source still
doesn't work. The reason is that when you do a drag and drop in sway
with that option on, a new wl_data_device.data_offer event is sent out
instantly after the drop event. This happens before any data is sent
across the fd and before mpv even has a chance to check it. What GTK
does, when getting this new data_offer event, is close the pipe
(POLLHUP). This means mpv can't read it when we reach the event loop and
thus no data is ever read and broken drag and drop. From the client
side, this isn't really fixable since the wayland protocol doesn't have
a clear indication of when clients are supposed to read from the fd and
both the compositor and data source are doing things totally out of our
control. So we'll consider this weird case, "not our bug" at least. The
rest should work.
By receiving the graphics API-specific contexts from the generic
pl_gpu instance, it is not necessary to store them separately.
As the current priv struct stores nothing else, this allows its
removal. This removal cleans up related compiler warnings regarding
unused variables in case of opengl and d3d11 being disabled in
mpv/libplacebo.
Functions to receive the underlying vulkan,gl,d3d11 structure were
added in libplacebo version 4.182. Our current requirement for
gpu-next is 4.190, and thus we can freely utilize these helper
functions.
We only wish to touch actual video frames, which should have an
allocated image attached to them, so just check the frame type
early, and exit by passing through such non-video frames to further
filters in the chain without attempting to process them.
Fixes a crash in case of non-video (EOF/NONE) frames being passed
onto the filter when the dovi option was set to false since
05ccc51d53 .
While testing support for the exotic formats used by Intel vaapi for
4:2:2 and 4:4:4 surfaces, I realised that we were enumerating all
endpoints and checking formats for them. The problem with this is
that decoding (VLD) endpoints are only a subset of what vaapi exposes.
All the encoding endpoints are there too, and there is also the
None profile that we don't care about, but which generates ffmpeg
warnings if you try and examine it.
So, let's only look at VLD endpoints. This will speed things up a
little bit and make the logging less noisy.
This speeds up chapter name access while hovering the seekbar:
- Fetch the chapter-list property using observation rather than on
every render while hovering the bar. Property access, especially
with potentially lots of values (chapters), can be expensive-ish,
and can involve locking, so the less per-render the better.
- Sort the list once (on change) to simplify the iteration logic when
searching the chapter which matches the mouse position. It's still
O(N) (no binary search currently), but with less work.
The cached sorted list is stored at the state. While there are other
places which access this property and could use this cache, for now we
don't touch them, because they're not performance-critical (on init
for the chapter markers, on ch_{prev,next} button click for OSD).
Caching properties using observation instead of using mp.get_property
can indeed speedup other places too, but it should be part of a system
rather than implemented per-property. Maybe some day.
When utils.get_user_path was added, the expand-path command didn't
exist. Now it does, so remove the C code, make it a trivial wrapper.
Keep this function for backward compat to not break scripts, but
technically it's not required anymore.
This has been the latest stable release for about half a year now. This
version in particular lets us get rid of all the deprecation warnings in
the older code. (See the following commits)
The wayland backend contains logic to detect if the window is hidden. If
so, we skip rendering as an optimization. However, if we receive
multiple resize events in rapid succession, we will send the compositor
new buffers faster than the refresh rate of the monitor. Therefore the
compositor will not send us frame events which we incorrectly interpret
as the window being hidden.
Once the last buffer has actually been rendered, the compositor sends us
a frame event. However, if at that point playback is paused, there is no
logic to restart rendering of frames that we skipped due to the above
optimization. Therefore we never send the compositor new buffers
corresponding to the new size of the window and the surface will either
be too small or too large.
The simplest solution is to always render a few frames after we receive
a resize event.
vo_gpu_next and libplacebo expect swapchain images to be able to be
blitted to, which for libplacebo on FL11_0 and up means they have to
have DXGI_USAGE_UNORDERED_ACCESS, since libplacebo uses a compute shader
to emulate certain kinds of blits. For libplacebo's benefit, set all
applicable usage flags on swapchain images.
The docs specify that the +-X+-Y geometry values position the content.
This used to work correctly but got broken at 8fb4fd9a .
Geometry size is unaffected - this only concerns position.
Commit 8fb4fd9a made it center the window rather than the content by
taking the borders into account during positioning, but forgot to make
an exception when a position is specified explicitly.
This commit adds this exception, and now if a specific position is
requested then the borders are ignored, and the content is positioned
correctly.
The code assumed that the value of the profile-restore field is
"default" for such profiles, but the C implementation is such
that the field is intentionally omitted in such case.
This resulted in incorrectly trying to restore such profiles. However,
there are no stored values with profile-restore=default, so it only
resulted in a harmless warning, but otherwise behaved correctly (i.e.
nothing is restored).
Fix the condition by taking into account that missing field means
"default", so that it doesn't try to restore in such case, and
avoid the warning.
Currently the profile-restore field is intentionally omitted if it
holds the default value (i.e. no values are stored for the profile,
and trying to restore would only warn).
See m_config_get_profiles at command.c .
a02901cae7 changed how mpv was handling
wl_surface_set_buffer_scale. It's correct in that constantly setting the
surface scale on every resize (which mpv was previously doing) is
unneccessary and not right. However, it introduced a slight regression
if someone moved a surface to a new monitor with the same resolution but
a different scale. It did not trigger a resize and thus the video would
have incorrect dimensions. A later refactor changed how things looked
inside here, but this regression wasn't fixed. A resize should always be
triggered if the scale changes in this surface event. Fixes#9426.
Mouse button event codes above `BTN_EXTRA` (the ones currently defined
in `input-event-codes.h` are `BTN_FORWARD`, `BTN_BACK`, and `BTN_TASK`)
are mapped to `MP_MBTN9` and up. (Reminder that due to historical
reasons, the names `BTN_FORWARD` and `BTN_BACK` are completely
misleading; the real forward and back buttons are `BTN_SIDE` and
`BTN_EXTRA` and are already mapped correctly by mpv.)
This functionality is analogous to what the X11 backend supports in
`video/out/x11_common.c` and what the Cocoa backend supports in
`video/out/cocoa/events_view.m`.
According to the xdg-shell protocol spec, a 0x0 size from the compositor
means that "the client should decide its own window dimension". We were
not doing this correctly. What should happen is that mpv should simply
reuse the old window size if it is not maximized or fullscreened. This
should work on all (reasonably recent) versions of mutter and an
compositor that follows the spec.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml#L1050
So actually according to the xdg-shell spec, a 0x0 resize is meant to
indicate that "the client should decide its own window dimension".
Previously, this just accidentally worked. In mutter 41.3, they changed
how 0x0 resizes were sent and what actually happened was that mpv tried
to resize itself to 0x0. This was obviously broken, so the reverted
commit naively just ignored 0x0. It actually seemed to work, but it
ended up breaking older versions of mutter. It's also not exactly the
correct fix so it deserves a revert.
This reverts commit d16defac27.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml#L1050
This define was always just a stopgap for that two month period (August
2021 - October 2021) where the bytes_read field in ffmpeg was completely
missing. Before that time, it was a private member in a struct (which
mpv used). Afterwards, it officially became public. Fortunately, the
lack of this field never actually made it into a release, so it could
have only possibly affected people building from the master branch.
Since ffmpeg 5.0 came out recently, and it's been plenty of months since
that two month window, we can go ahead and drop this check. This
finishes up the work done in 78cfeee2b9.
Sidenote: the cached ffmpeg version in the mingw ci were from that time
period when the bytes_read field was missing. The N in the workflow is
bumped to force a full rebuild and fresh clone of ffmpeg.
Both _NET_WM_NAME and _NET_WM_ICON_NAME (part of Extended Window Manager
Hints) require that the string is UTF-8*. mpv was not doing this and
thus violating the spec. Just sanitize the title for these two atoms.
Note that XA_WM_NAME and XA_WM_ICON_NAME have no such requirement so
those atoms are left the same. Fixes#8812.
*: https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html
Apparently mutter can send us 0x0 resizes* for whatever reason. Probably
there's some interal reason why this occurs, but for us trying to resize
to 0x0 is obviously terrible and results in all kinds of brokenness.
Just ignore any 0 values. Fixes#9748.
*: https://gitlab.gnome.org/GNOME/mutter/-/issues/2091
Changes:
* fixed hangups in the loop function and in some other cases
* refactoring according to @michaelforney's recommendations in #8314
* a few minor and/or cosmetic changes
* ability to build ao_sndio using meson
Changes:
- rewrite to use new internal MPV API;
- code refactoring;
- fix buffers size calculations;
- buffer set to auto;
- reset() - clean/reinit device only after errors;
Previously, the sub-visibility option changed the visibility of all
subtitles including secondary ones. This meant that it was not possible
to only display secondary subtitles while hiding the primary ones. This
modifies the sub-visibility option so that it only affects primary
subtitles which allows only secondary subtitles to be displayed.
This reverts commit 04f0b0abe4.
It's not a good idea to unify the names only for visibility, while
keeping secondary-* for everything else.
This needs a bit more thought before we allow secondary sub to be
visible on its own.
Adds --sub-visibility choices 'primary-only' for only displaying the
primary subtitle track, and 'secondary-only' for only displaying
secondary subtitle track.
Removes --secondary-sub-visibility and displays a message telling the
user to use --sub-visibility=yes/primary-only instead.
These changes make it so that the default 'sub-visibility' bind 'v'
cycles through all the 'sub-visibility' choices, 'no', 'yes',
'primary-only', and 'secondary-only'.
Was tripping -Wparantheses as the && after the || was not explicitly
wrapped. However, due to operator precedence the intended effect was
still correct.
Warning from meson:
WARNING: You should add the boolean check kwarg to the run_command call.
It currently defaults to false,
but it will default to true in future releases of meson.
See also: https://github.com/mesonbuild/meson/issues/9300
All of the run_command() calls currently use need to succeed for the
build to work properly.
The AO provides a way for mpv to directly submit audio to the PipeWire
audio server.
Doing this directly instead of going through the various compatibility
layers provided by PipeWire has the following advantages:
* It reduces complexity of going through the compatibility layers
* It allows a richer integration between mpv and PipeWire
(for example for metadata)
* Some users report issues with the compatibility layers that to not
occur with the native AO
For now the AO is ordered after all the other relevant AOs, so it will
most probably not be picked up by default.
This is for the following reasons:
* Currently it is not possible to detect if the PipeWire daemon that mpv
connects to is actually driving the system audio.
(https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1835)
* It gives the AO time to stabilize before it is used by everyone.
Based-on-patch-by: Oschowa <[email protected]>
Based-on-patch-by: Andreas Kempf <[email protected]>
Helped-by: Ivan <[email protected]>
The only way to fix the channel order here is to create the texture with
bgra format. Incidentally, there used to be a way to set the component
map for overlays directly, but no more. Shouldn't matter since
everything supports bgra8 anyways, though.
Fixes#9699
These got added upstream a while ago. Need to be added to the mapping
helpers.
It might be time to think about bumping the minimum dependency here.
Reported-by: Uoti Urpala <[email protected]>
There was some breakage with regards to the iconv detection in some
older meson versions. This was all settled in 0.60.3 and now it simply
just works. Remove the workarounds and bump the needed meson version to
0.60.3.
When this was originally added, some OS package managers were slow and
behind the required meson version needed for mpv to build. Both opensuse
tumbleweed and freebsd now appear to carry meson 0.60.3 in their repos
so we no longer need to do the two-step process of installing pip3 and
then installing meson via pip. Instead, just use the OS package manager
version.
Useful to strip dolbyvision from the output, in cases where the user
does not want it applied. Doing this as a video filter gives users the
abiilty to easily toggle this stripping at runtime in a way that
properly propagates to any (potentially stateful) VO.
It also thematically fits the rest of the options in vf_format, which
are similarly concerned with modifying the video image parameters.
This needs to be forwarded from the AVStream to the AVPacket itself, so
that it reaches the decoder. There exists an FFmpeg function for this,
we just need to call it. (Also add some logging)
Instead of `xkb_keymap_new_from_string`. The protocol does not require
the keymap to be null terminated and if the size of the keymap is a
multiple of the page size, using `_from_string` could lead to problems.
Some compositors include a null byte and even include the null byte in
`size`. Therefore we have to use `strnlen` to find the real length of
the string. Note that `_from_string` internally uses `strlen` and then
calls `_from_buffer`.
While mpv uses version 1 of the `wl_seat` protocol and `MAP_PRIVATE` is
only required from version 7 on, using `MAP_PRIVATE` allows us to be
compatible with compositors that have only been tested with newer
applications.
Since the keymap is not modified after `mmap`, using `MAP_SHARED` has no
advantage over `MAP_PRIVATE`.
This merges the old desaturation control options into a single
enumeration, with the goal of both simplifying how these options work
and also making this list more extensible (including, notably, new
options only supported by vo_gpu_next).
For the hybrid option, I decided to port the (slightly tweaked) values
from libplacebo's pre-refactor defaults, rather than the old values we
had in mpv, to more visually match the look of the vo_gpu_next hybrid.
Merge --gamut-clipping and --gamut-warning into a single option,
--gamut-mapping-mode, better corresponding to the new vo_gpu_next APIs
and allowing us to easily extend this option as new modes are added in
the future.
image2D is only defined from GLSL ES 3.1 onwards, so those statements
broke GLES 2.0. Move the qualifier to a place that is only reached with
the right version requirements.
fixes commit 584ab29c88
This commit is mainly for correcting the previous commit message.
The previous commit fixed an issue where [un]registering events above
the first event ID "hole" is not requested from libmpv, and that's
indeed true.
However, this had nearly zero impact in practice, because libmpv
enables all events by default anyway (except TICK).
Therefore, above the first ID "hole" [un]register requests are not
sent to libmpv, and the events just keep arriving.
But the callback functions are still added/removed correctly (at
defaults.js), and so the script is not called back even if unregister
did not actually happen with libmpv.
The only event which was affected is TICK - which is not enabled by
default as it's deprecated, and before the previous commit could not
be enabled.
So the fix is more a general correctness fix now that the IDs array
can have "holes", but with effctively no impact in practice.
Commit 63205981 removed some events but left all other event IDs at
their original values, which created "holes" at the events IDs array.
The JS backend for mp.register_event maps a name to an ID by scanning
all IDs and stopping when the name was found or a NULL name was
returned. Lua does the same except that it doesn't stop on NULL name.
Previously it was not possible to have a NULL name before the end of
the array, but now it is possible due to the enumeration holes.
Fix by skipping missing names, like lua does.
Back when the meson build was still in the PR state, this particular
variable was a dictionary. Later, it was refactored to simply be a
feature object instead. All uses of egl_drm['use'] should have been
replaced with egl_drm.allowed() but this particular line was missed
(that's what I get for not just doing find/replace). The conditional in
this line is usually satisified before egl_drm ever needs to be checked
which was why no one noticed until now. Fixes#9631.
Commits 04018c3061cd7a7a1de8 introduced behavior that
updated window geometry during wayland events (specifically surface and
output). This is good but they also are too aggressive with
automatically resizing. For example, if a window is manually resized by
the user and then dragged to a different monitor with different geometry
than the initial monitor, mpv will automatically resize itself to the
window's resolution. The initial thought behind this logic was for
autofit to automatically readjust itself on a new monitor, but doing
that breaks other common use cases. An attempt could be made to
distinguish between autofit and a manual resize but that introduces a
lot of complexity for an edge case. It's better to simply not change the
window geometry here. Internal values are recalculated and scaled of
course, but wl->window_size and wl->geometry should not change.
shaderc is a special case dependency in meson. According to the
documentation*, it first checks for shaderc_shared and will fallback to
shaderc_combined (the order is reversed if the static keyword is true).
However, shaderc also has a third .pc file (shaderc_static) which should
be checked. The meson documentation doesn't indicate this, but it also
actually checks shaderc_static*. shaderc_combined is first checked if
meson looks for static libs and if that is not found it tries
shaderc_static. So this extra fallback check is not needed.
*: https://mesonbuild.com/Dependencies.html#shaderc
*: https://github.com/mesonbuild/meson/blob/a2934ca9d13ede4eb97b320bc768319ecad7b525/mesonbuild/dependencies/misc.py#L539
Shaderc has been shipping .pc files for almost three years and we all
know of the advantages. If this turns out to be problematic the old checks
can be re-added but I'd like to avoid doing this preemptively.
During execve() ignored and blocked signals carry over to the child
process, though apparently for SIGCHLD (which the bug report was about)
this is implementation-defined.
fixes#9613
We've been assuming that maximum number of compute group threads is
never less than the 1024 defined by the desktop GL spec. Given that we
haven't had working compute shaders for GLES and I guess the Vulkan
spec defines at least as high a value, we've gotten away with it so
far.
But we should really look the value up and respect it.
This is only needed on Android and supposed to handle a context
resize without reconfiguring the image parameters. reconfig()
already does exactly this so plug it in there.
Not all deprecated symbols were removed. Only three events were removed for now
since these are not used internally.
This bumps the library version to 2.0.
Simply returning out of this function leaks avpkt, need to always "goto
done".
Rewrite the logic a bit to make it more clear what's going on (IMO).
Fixes#9593
It's supposed to work with GLES >= 3.1 but we had all sorts of bad
assumptions in our version handling, and then our compute shaders
turn out not to be GLSL-ES compliant.
This change contains some necessary, but insufficient, tweaks to the
shaders. Perhaps we'll make it actually work some day.
Some of the extension declarations did not include the ES version where
they became core functionality, and in some of these cases, there was
never actually an ES extension - it first appeared in core. We also had
a number of buggy version checks where ES versions were compared
against required desktop GL versions.
nvidia follow the OpenGL spec very strictly, with two particular
consequences:
* They will give you the exact context version that you ask for,
rather than the highest possible version that meets your request.
* They will hide extensions that the specs say require a higher
version than you request, even if it's technically possible to
provide the extension at lower versions.
In our case, we really want a variety of extensions, particularly
compute shaders that are only available in 4.2 or higher. That means
that we must explicitly include a high enough version in our list of
versions to check for us to be able to get a 'good' enough context.
As for which version? We restore the 4.4 version that we had in the
old version selection logic. This is the highest version we ever asked
for, and we have separate logic that clamps the GLSL version to 4.4,
so anything newer wouldn't make a difference.
Since libavcodec major version 59, the requested "ass" format became
the default as the old timing-included format was disabled starting
with that version. Additionally, this option by itself has since
been deprecated as it no longer serves any purpose.
References:
FFmpeg/FFmpeg@1f63665ca5FFmpeg/FFmpeg@176b8d785bFixes#9413
`plane_data_from_imgfmt` doesn't zero-initialize the struct, so this
contained invalid values for e.g. `row_stride`, causing formats to
*randomly* fail. (Especially any formats with specific alignment
requirements)
Might fix#9424 and #9425.
This is a workaround for nvidia proprietary drivers. The authors of
those drivers interpret the spec such that eglMakeCurrent will not
reconfigure the read and draw buffers. Thus windows wont display
anything drawn by opengl. nvidia authors refer to
https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_no_config_context.txt
specifically Issues 2/3 which reference eglMakeCurrent.
On mesa this is a non-issue and the read/draw targets are assigned with
eglMakeCurrent.
The context must be made current in order to query OpenGL strings. An
earlier proposal to create the wayland window surface similarly to X11
during init was deemed inappropriate so instead we manually set the
targets once we have created a window surface.
Allow --keep-open=always to work with --loop-playlist, where
before this patch it would work only on the last playthrough of the
playlist. This patch allows it to work on all playthroughs.
Fixes#9470.
Somewhat annoying but still relatively straightforward. There are
several ways to approach this, but I settled on reusing the pl_queue as
a cheap way to get access to the currently mapped frame. This saves us
from having to process `vo_frame` at all, and also avoids any overhead
from re-uploading the same frame twice.
(However maybe there's some circumstance in which `vo_frame` needs to be
queried/updated first, to get a screenshot of the correct frame? I'm not
sure.)
I also had the option of going with either pl_render_image() on the
extract pl_frame, or just calling pl_render_image_mix directly on it. I
went for the latter, because in the optimal case, this allows the
rendered frame to be directly retrieved from the cache, actually
entirely avoiding any sort of recompute overhead. This makes e.g. ctrl+s
during playback essentially free. (Except for the download cost,
obviously)
It would be even neater if we could make this VOCTRL asynchronous and
thereby leverage libplacebo's asynchronous download capabilities. But oh
well. That will have to wait for a sufficiently rainy day.
Closes#9388
20c4036daa switched to using symbol
visibility attributes for mpv client api functions (for the meson build
at least). Unfortunately mpv_client_api_version was mistakenly missed.
We need to export this function as well. Fixes#9531.
As noticed in #9526, apparently there's some case in which DR buffers
get corrupted. Add an explicit sentinel check to try and figure out
which cases these are.
The initial iconv dependency worked everywhere but was broken on
freebsd. This was fixed in 0.60.2 but the fix accidentally broke mingw
(ouch; kind of my fault for not double checking). There's another PR to
fix this but that won't land until 0.60.3 so for the meantime just
if/else this (both freebsd and windows work with the system method)
until we want to bump the meson version (probably not for a while since
opensuse tumbleweed is weirdly slow).
Previously OSD was always displayed on {ch,pl}_{next,prev} left-click,
and seekbar-hover-chapter was always enabled and with fixed format.
Now it can be controlled with:
- chapters_osd, playlist_osd: yes/no (only affects left-click).
- chapter_fmt: lua string.format template, or "no" to disable.
Fixes#4675
This commit sucks bad, but everything else is worse is other ways.
Basically, the current vblank waiting time in the vo_wayland_wait_frame
function (calculated very carefully using presentation statistics) is
randomly too short. Some compositors are quite variable when they
actually return callback so our timeout expires too quickly and throws
everything off. The fix? Add an arbitrary 5% to the vblank value and
pray that nothing gets off that much. Why did they have to make
swapinterval 1/fifo mode indefinitely block? Fixes#9504.
Better to avoid any wonky calculations on startup with garbage values.
The others end up being derived from last_ust/last_msc. refresh_interval
is referenced exactly once and could, in theory, result in some terribly
erroneous vblank time.
A read can be prepared on the wayland display FD that is never actually
read. This occurs when events are triggered on other FDs in the fd set.
This change cancels a prepared read if poll reported no events for it.
This fixes some hangs due to how nvidia's EGL implementation polls on
the wayland fd unlike mesa implementations. It is based on nvidia's
proposed fix for qt's similar message pump in
https://codereview.qt-project.org/c/qt/qtwayland/+/373473
Signed-off-by: Kurt Kartaltepe <[email protected]>
This is done to avoid cluttering vo_gpu_next.c with more ifdeffery and context-specific code
when additional backends are added in the near future.
Eventually gpu_ctx is intended to take the place of ra_ctx to further separate gpu and gpu_next.
This case was added in 662c793a55
for use in vo_gpu_next as a visibility test before rendering a frame.
The OpenGL context doesn't have this so it just returns true.
This is needed when the color system is not explicitly tagged, but
instead needs to be inferred by the VO.
Note that there exists the function mp_image_params_guess_csp for this
sort of stuff, but it contains a lot of baggage that I don't want to
replicate, in order to move as much of this logic into pl_renderer as
possible, and therefore also give it the best chance of knowing what
shortcuts it can and can't take.
Fixes the other half of https://github.com/mpv-player/mpv/issues/9499
Adding vsync_offset to the pts in pl_queue_update actually messes up
frame timings if one isn't using interpolation. The easiest way to see
this is to have the monitor's refresh rate at an integer multiple of a
video during a panning shot (classic case). There will be very visible
judder/stutter in this case that does not happen in vo_gpu. The cause of
this is the addition of the extra vsync_offset. Just match the semantics
of vo_gpu where this is only used when interpolating.
This possibility actually existed for years. The wayland protocol is
asynchronous and there's no restriction on when a compositor can send a
surface enter event. In mpv's case, the surface enter event is used to
set some vital things regarded geometry/scaling etc. However, this
implictly assumes that wl->current_output is actually initialized. The
vast majority of the time, vo_wayland_reconfig will happen first which
is where wl->current_output is, and should, be created. There's no
rule/law that the ordering of events will always occur in this order.
Plasma with certain auto-profile conditions can send the surface enter
event before mpv does its initial reconfig. That segfaults of course.
Just add a check to make sure we have wl->current_output here and return
if we don't. This assumes that the compositor will send us another
surface enterance event when mpv actually does the initial surface
commit and roundtrip request later. Wayland logs indicate this does
happen. Fixes#9492.
It was never implemented before but it's trivial. As an aside, touch
events currently don't support modifiers either (is this a thing?). Well
if someone complains that can be done later. Fixes#9490.
The audio rewrite in d27ad96542 originally
broke this ao. However, 0ac724f002 fixed
and the documentation was never updated to reflect that. OpenAL has
worked fine for a while not. Just remove this sentence.
Even when not display synced. Prevents redraw overhead for refreshes
while paused.
Also make the logic slightly clearer to follow (since it's inverted).
Following the previous commit, we can just set gnu_symbol_visibility to
'hidden' to hide everything except for the symbols we explictly want to
export. This should work on gcc, clang, and msvc.
In mpv, the only symbols we want to export are the functions from the
client API. This is accomplised using a specific .def whitelist, but the
main compilers people use (gcc or clang) like these attributes since it
allows for further optimizations. MSVC also allegedly supports this as
well (untested of course), so use __declspec for tht case.
This almost perfectly recreates the semantics of --vo=gpu, i.e.:
- still frames are never interpolated
- non-repeated frames bypass single frame cache
The only difference is that libplacebo doesn't do a cache/blit on the
full output image, but rather it re-runs the last rendering step. This
has some advantages and some drawbacks. The most notable advantage is
that it also allows re-using the image contents when the only thing that
changes is the OSD (whereas `--vo=gpu` would force a full re-render for
that). The most notable drawback is that it also implies going through
the dithering and output LUT logic on redraws. All in all, I think this
is a pretty good trade-off in favor of `--vo=gpu-next`.
Fully fixes the last remaining performance difference in #9430.
GLX_CONTEXT_PROFILE_MASK_ARB and related constants are provided by
GLX_ARB_create_context_profile but the check was for _create_context.
The former implies the latter (which we also need) so just replace
the checked extension.
It abstracts EGL 1.5, extension checks and other inconsistencies away.
This can be used in context code as the (preferred) alternative to
eglCreateWindowSurface().
Using a simple substring match for extension checks is considered bad practice
because it's incorrect when one extension is a prefix of another's name.
This will almost surely not make a difference in practice but do it for correctness anyway.
Although there are no known problems with this, using the helper should
be more portable. It will also prefer EGL 1.5's eglGetPlatformDisplay
over eglGetPlatformDisplayEXT if available.
The original implementation had some errors with regards to android. Add
a couple of missing files, add the android library, fix the aviocontext
bytes_read check, fix egl-android, and rearrange/tidy up the vulkan
handling.
While the basic Vulkan Display context can theoretically drive the
display without the involvement of any non-Vulkan code, that prevents
us from using VAAPI acceleration. When initialising VAAPI without a
window system, we need to provide it with an opened DRM render fd
corresponding to the device to use.
In the context of using VK_KHR_display, that means we need to identify
which DRM device matches the selected Vulkan device, and then open its
render fd and set the necessary state that VAAPI expects to find.
With that done, the normal VAAPI<->Vulkan interop can kick in and we
get working acceleration
A few custom targets had some less than optimal names which created some
misleading "Generating custom-target-name with a custom command"
messages. Change those to be more descriptive/correct. In a few other
places, some checks were being done that could easily be
skipped/ignored in certain cases (like checking for windows-related
headers when gl-win32 isn't true). Also rearrange that to be smarter.
Finally, print some extra libplacebo messages for enabling/disabling
vo_gpu_next.
This test fails because the compiler object does not have -Wformat when
it tries this flag. To fix this this, we have to pass both -Wformat and
-Werror=format-security at the same time during the test. This requires
us to use has_multi_arguments so this flag needs to be pulled out of
this array and tested separately.
youtube-dl and yt-dlp both support --sub-langs and --srt-lang in
addition to --sub-lang for defining languages of subtitles. This hook
only checked for sub-lang in --ytdl-raw-options and inserted --all-subs
in its absence.
Nearly all the code base correctly references the data as constant. But
a couple of instances - fix those.
Signed-off-by: Emil Velikov <[email protected]>
Ever instance of m_obj_list is a constant and for all of them, the field
is true. Just remove the field all together.
Signed-off-by: Emil Velikov <[email protected]>
Update the github workflows to also do meson builds for every OS.
Additionally, make every workflow execute the built mpv executable
(except for windows and FreeBSD's waf executable) to make sure that it
runs. As an aside, FreeBSD unfortunately is a bit less elegant since it
is in a VM.
The extension is completely arbitrary since ebml_defs.c isn't a real c
file that actually is compiled at any point in time. It's just used as
an include. The reason for changing the extension is because meson needs
to add this to its list of sources for dependency/ordering purposes.
Understandably, meson will try to compile any .c file added to a c
project executable object. Obviously, this compilation will never
succeed, and this shouldn't be compiled anyways. Just make it .inc
instead.
Another modification for the upcoming meson build. Meson can capture the
stdout and redirect it to a file. However, this is considered a hack.
It's better to just add a few lines to this script and write a file
directly.
Apple is great and forces us to do a lot of weird checks because they
randomly move the location of the swift libraries around. Make a
specific python script for checking various locations and write the
output to stdout for meson.
Building for macos requires us to check the macos sdk path as well as
the sdk version that is on the system. To do this, let's steal the logic
that's in the compiler_swift.py check from the waf build. This returns a
comma-delinated string. The first entry is the absolute path to the sdk.
The second entry is the detected macos sdk version.
version.h is essential for building, and its generation was done by a
shell script. Strictly speaking, python should in general be more
portable (windows), and would be better for the upcoming meson build to
simply just execute a python script. version.py has some small
differences with version.sh which shouldn't matter but they are noted
below.
- version.sh accepted several arguments that seemed useless (like
--cwd). These were removed from version.py.
- version.py takes either no arguments (prints the version) or it takes
exactly one argument specifying the complete path of where the header
should be generated.
- version.sh attempted to read a file named "snapshot_version". The
comments noted that this was for "daily tarball snapshots". Such a
file does not exist in the source tree, and it's not really clear that
anyone actually uses this. This logic was removed from version.py.
- version.py reads the SOURCE_DATE_EPOCH environment variable. Some
distros use this for reproducible builds. Technically you could also
just disable the build date but this is only a couple of extra lines
and maybe it's prettier than UNKNOWN.
- version.py also doesn't attempt to display timezone information in the
build date. It only shows UTC time.
d2e8bc4499 was the the commit that
originally introduced the usage of this bit. As the message states, the
purpose was to force creating GLES 3 contexts on drivers that do not
return a higher version context than what was requested. With the recent
opengl refactors, mpv's gl selection has already moved away from such
complicated queries. Perhaps when that commit was added things were
different, but nowadays it seems like Mesa simply returns the highest
driver version available that is compatibile with the request (i.e.
requesting GLES 2 returns a GLES 3 context on my machine). In that case,
let's just simply drop EGL_OPENGL_ES3_BIT altogether as it does break
GLES 2 only machines. Fixes#9431.
The new GBM supporting nvidia drivers declare support for 10bit
surfaces using BGR ordering, rather than RGB, so add support for them.
We've also seen examples of hardware supporting BGR8888 but not
RGB8888 so let's support those too.
Of course, the nvidia EGL driver doesn't publish support for any 10bit
formats so you can't actually do 10bit display. Perhaps they'll
eventually fix that.
The GBM supporting nvidia driver doesn't support creating surfaces
without modifiers and using modifiers is more and more recommended as
the right way to do this.
Enumerating modifiers is painfully verbose, but necessary if we are to
allow the driver to pick the best possible one.
This fixes a mismatch between configure working and build time
failing with Linux + OSSv4, enabling compilation on Debian based
Linux systems with the oss4-dev package.
Fixes#9378
This logic, which was working around a libplacebo bug, ended up always
alpha blending - even for sources without an alpha channel. This caused
a minor slowdown to be constantly enabled.
Due to the recent bump to libplacebo v170, this is no longer needed.
Completely untested, since Linux still can't into HDR in 2021. Somebody
please make sure it works.
Technically covers #8219, since gpu-context=drm can be combined with
vo=gpu-next.
This required an upstream API change to implement in a way that doesn't
unnecessarily re-push or upload frames that won't be used. I consider
this a big enough bug to justify bumping the minimum version for it.
Closes#9401
This was originally added in f2afae55e9
for unclear reasons (way to go me). This concept is clearly incorrect.
It doesn't matter what state the window is in. As soon as mpv detects a
scale change, it needs to reset the buffer scale of the window. Just
remove all this junk and put wl_surface_set_buffer_scale in
set_surface_scaling like it should be. Related issue: #9426.
Looking at this again I'm not sure it does anything useful at all. The
man page entry is also wrong: `bicubic` is not affected, only
`bicubic_fast`, and those filters are not configurable anyways.
So this would only ever be a debugging option, and I don't see a
pressing need for it.
No interface-change.rst update because it only just got added anyways.
In practice, this is for wayland. vo_gpu_next doesn't check the
check_visible parameter since it didn't descend into the
vulkan/context.c file when starting a frame. To make this happen, just
call the start_frame function pointer but pass NULL as the ra_fbo. In
there, we can do the visibility checks and after that bail out of the
start_frame function if ra_fbo is NULL.
This vulkan-specific parameter was poorly named and probably causes
confusion. Just rename it to check_visible instead to make clear what is
going on here. Only wayland uses it for now but in theory anyone else
can. As an aside, wayland egl accomplishes this by using an external
swapchain instead (an opengl-only concept in the mpv code). This may or
may not need to be changed in the future when gpu-next gets opengl
support.
As discussed in #8799, this will eventually replace vo_gpu. However, it
is not yet complete. Currently missing:
- OpenGL contexts
- hardware decoding
- blend-subtitles=video
- VOCTRL_SCREENSHOT
However, it's usable enough to cover most use cases, and as such is
enough to start getting in some crucial testing.
This seems to work on gcc, clang and mingw as-is, but I made it
conditional on __GNUC__ just in case, even though I can't figure out
which compilers we care about that don't export this define.
Also replace all instances of assert(0) in the code by MP_UNREACHABLE(),
which is a strict improvement.
A lot of people seem to do something like --tscale=box
--tscale-window=<function>. Just let them use --tscale=<function>
directly, by also accepting raw windows.
Kinda hacky but needed for feature parity with vo_gpu_next, which no
longer has `--tscale=box`. Note that because the option struct is still
shared, vo_gpu_next inherits the same option handling code, so we have
to export this feature for vo_gpu as well.
Back when runtime updating of autofit/geometry was added for wayland and
x11 (commits: 4445ac828dca0298543103094357e64f8828ef56 and
ced92ba607ebd98687b26ef3d8c09d5f6e22cf4b respectively), the naive
assumption was that window-related geometry would always be available.
While this is true 99% of the time, this isn't a guarentee. It is
possible for certain things such as loading shaders to delay starting up
the player. This causes autofit/geometry options to be registered as a
runtime update and triggers VOCTRL_VO_OPTS_CHANGED. This ends up calling
some geometry-related functions but this happens before the actual
values are available. Hence, a nullptr was accessed which segfaults. At
least one user experienced this with a combination of options in wayland
but in theory the same thing could happen under x11.
The fix is simple. Just be sure to check that the required geometry is
available before doing any calculations. In wayland, this would be
wl->current_output. Additionally add an assert to set_geometry (we
should never use this function without wl->current_output) to be extra
sure. In x11, the check is on x11->window. Later when the reconfig for
each backend actually happens, the autofit/geometry set by the user
happens anyway so ignoring it in this case does no harm. Fixes#9381.
- Latest version of mpv you know without the problem
- The time when the problem started to happen (after updating mpv, system, driver, etc.)
- Possible screenshot or video of visual glitches
If you're not using git master or the latest release, update.
Nightly builds from master can be found [here](https://github.com/mpv-player/mpv/actions/workflows/build.yml?query=branch%3Amaster+event%3Apush),
click on the latest workflow run, scroll down to the Artifacts section and download the
appropriate build. Packages and builds can be found [here](https://mpv.io/installation/).
value:|-
- macOS version:
- Source of mpv:
- Latest known working version:
- Issue started after the following happened:
render:text
validations:
required:true
- type:textarea
id:reproduction_steps
attributes:
label:"Reproduction Steps"
description:>
Try to reproduce your issue with `--no-config` first. If it isn't reproducible
with `--no-config` try to find out which option or script causes your issue.
If the issue is render performance-related, try to reproduce it with `--no-config
--profile=fast`, which is designed to work on lower-end mobile devices.
For decoding performance-related issues, additionally try to enable hardware
decoding with `--hwdec=yes` or the `Ctrl+h` shortcut.
Describe the reproduction steps as precise as possible. It's very likely that
the bug you experience wasn't reproduced by the developer because the workflow
differs from your own.
validations:
required:true
- type:textarea
id:expected_behavior
attributes:
label:"Expected Behavior"
placeholder:"What were you expecting?"
validations:
required:true
- type:textarea
id:actual_behavior
attributes:
label:"Actual Behavior"
placeholder:"What happened instead?"
validations:
required:true
- type:textarea
id:log_file
attributes:
label:"Log File"
placeholder:"Drag and drop log file here (Don't paste content directly)"
description:>
Make a log file with `--gpu-debug --log-file=output.txt`, which is our preferred way, and
attach it to the issue. If you use the Bundle, a default log is created for your last run
at `~/Library/Logs/mpv.log`. You can jump to that file via the `Help > Show log File…` menu.
If you have trouble producing a log file, you can alternatively use `--gpu-debug --msg-time -v -v`,
save the terminal output to a file, and attach it to the issue.
In the case of a crash, please provide the macOS Crash Report or create a [backtrace](https://developer.apple.com/library/archive/documentation/General/Conceptual/lldb-guide/chapters/C5-Examining-The-Call-Stack.html)
yourself.
Without the log file, this issue will be closed for ignoring the issue template.
Disclaimer: The log file may contain identifiable information, such as your username.
Review the log file before sharing and redact any sensitive data if necessary.
validations:
required:true
- type:textarea
id:sample_files
attributes:
label:"Sample Files"
placeholder:"Drag and drop sample files here"
description:>
Please provide sample files for a minimal reproduction case, if the issue can't be
reproduced without it or it is helpful to demonstrate the issue.
Preferably files should be attached directly within the text field below. Due to GitHub's
upload restriction, you may need to archive the sample file first and upload it as `.zip`
file. If the sample file is too big to attach directly, use a solution that is easy to
access with possible long-term retention. Possible services include, but are not limited
to, the following:
- [0x0.st](https://0x0.st/) (no long-term retention)
Shows a limited view of the respective type of list using the OSC. First
argument is duration in seconds.
``osc-idlescreen``
Controls the visibility of the mpv logo on idle. Valid arguments are ``yes``,
``no``, and ``cycle`` to toggle between yes and no. If a second argument is
passed (any value), then the output on the OSD will be silenced.
OSC Preview API
~~~~~~~~~~~~~~~
The OSC supports displaying preview thumbnails when hovering over the seekbar if
a compatible thumbnailer script is installed. It communicates with a thumbnailer
script via the following ``user-data`` properties:
``user-data/osc/draw-preview``
Set by the OSC to request a thumbnail within the currently playing file.
The ``draw-preview`` property is a table with the following fields:
``x``, ``y``
Top-left coordinates (positive integers) to draw the thumbnail at.
``w``, ``h``
Width and height (positive non-zero integers) of the area to draw the
thumbnail in. Note that this only specifies the drawing width and
height, the actual backing thumbnail size may differ.
``hover-sec``
Requested thumbnail timestamp in seconds.
``ass``
Optional ASS string to render alongside the thumbnail, using OSD
coordinates. This can be used for decorations such as a thumbnail
border.
The OSC sets this property to ``nil`` to signal the thumbnailer to clear
the displayed thumbnail.
Avoid installing/enabling multiple thumbnailer script since this api expects
only one to be active at a time.
Loaded 100 of 906 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.
Kacper Michajłow
