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
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
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
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.
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
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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/
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
NRK