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 <ricardofonseca94321@tecnico.ulisboa.pt>
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)
Kacper Michajłow
nanahi
NRK
arch1t3cht
verygoodlee
Chainik
Ricardo Fonseca
llyyr
Philip Langdale
dependabot[bot]
Guido Cella
Mikael Magnusson
Lynne
sfan5
Clinton Phillips