Previously, you could only provide a CRT FD, which works great for the
most part, but when using CreateProcess on Windows, it requires the use
of the reserved fields of STARTUPINFO to inherit the FD to a child mpv
process. This becomes a problem for example if you use Go's os/exec API,
which does not expose a way to set those reserved fields. Exposing a way
to allow passing handles directly fixes the mentioned scenario, and
makes --input-ipc-client more flexible at no cost.
Removes one redundant deep-copy. For example this makes playlist with
300_000 elements conversion to node from 800 ms to 470 ms. Not a big
improvement, but still it's free to do.
Make the filtering and user input render asynchronously, such that there
is no latency penalty for user typing.
A single keystroke with hundreds of thousands of selectable items blocks
the script for significant time. Especially filtering by single letter
which would produce a lot of matches. This could be fixed by delaying
filtering by the time user "stops" typing, but this adds artificial
delay on top of the filtering delay itself. Instead we start the
filtering always, but have a deadline of 5 ms, at which point the
coroutine is paused and script is allowed to process user events again.
If user typed or closed the dialog, we simply abort the filtering and
start new one. Instead of waiting for full filtering to finish when the
result is already stale.
The first slice runs synchronously, so anything but huge item lists is
still filtered within the keypress handler exactly as before.
Fixes: #18268
Store just the indices of the matching items in matches. The text is
looked up in selectable_items, and the positions to highlight are
computed in get_matches_to_print() only for the rendered matches, using
the query that produced the current matches. This reduces useless work
of computing highlight positions when only handful of items can be
displayed at the time on screen in practice.
Sort matches without lua comparator, this significantly speeds up
sorting of big lists, where C->Lua round-trip was problematic.
Overall it's 10x-20x times faster in my testcase.
Replace those conditions with precomputed lookup. It's not huge win, but
it's free, so we can do it.
JIT:
* score() x 44875 matches: 35 -> 25 ms
* filter_range 'p': 50 -> 25 ms
* filter_range 'pf': 61 -> 37 ms
interpreter:
* score() x 44875 matches: 295 -> 254 ms
* filter_range 'p': 412 -> 284 ms
* filter_range 'pf': 531 -> 388 ms
The lookup is dense, to avoid hash tables, which makes things slower,
but in fact the tables are reused, so it's low on memory.
Add fzy.filter_range() which computes only scores, appends to
caller-provided arrays instead of allocating tables per match, takes
an inclusive range so callers can process a large list in slices while
handling pending input in between, and accepts optional pre-lowercased
haystacks so repeated calls don't allocate a lowercase copy of the whole
list each time.
There could be a lot more done if we target luajit only. Or if we port
this to C. But for now let's keep it this way. It's 2-3x faster than
before, and the issue is mostly only on very big inputs, which are not
that common in practice.
Previously computing scores allocated two matrices of lua tables per
call. With hundreds of thousands of items this made fuzzy matching in
console.lua GC-bound.
When only the score is needed, keep two reused rolling matrix rows,
making repeated scoring allocation-free. positions() still keeps all
rows since tracing back the matched positions requires them.
fzy.filter() of 300000 items drops from 1013 ms to 356 ms (on my setup)
for a worst-case single-character needle, and a standalone score() call
no longer allocates at all.
This are char comparisions, but in lua they are expressed as full string
compare. Compare as bytes instead, this is significantly faster,
especially with luajit compiled code.
This allows scaling secondary subtitles independently from primary subtitles. The option defaults to 1 like --sub-scale and follows the other secondary-sub-* options by not inheriting from the primary subtitle setting.
Fixes#14989.
Back when reselect_demux_stream call was added in this path in 700f72f,
sub_redecode_cached_packets only retained the last two packets. The
subtitle decoder cache was changed in 0a4b098 to retain the whole packet
sequence. Therefore sub_redecode_cached_packets by itself can rebuild
the new decoder state entirely from packets held in memory, and we no
longer need the demuxer to refresh the track.
This fixes expensive track refresh for network streams, where changing
some sub-* options during runtime of network streams would cause the
cache to be dropped
When wait_for_init_done times out, init_state remains INIT_STATE_NONE.
The original check only handled INIT_STATE_ERROR, allowing init() to
return 0 (success) even though the stream was never properly initialized.
This could lead to an infinite reload loop when the partially initialized
stream later enters an error state.
Fix by checking for INIT_STATE_SUCCESS instead of INIT_STATE_ERROR,
so that any state other than SUCCESS (including NONE due to timeout)
is correctly treated as a failure.
lavf basically always provide tracks in order as they appear, so this
will match it. There is no hard guarantee, but this is documented.
`ff-index` is now optional, but both demux_mkv and demux_lavf set it, so
it should cover most cases where it's used. In all other cases it would
be wrong anyway.
The `ff-index` is just a index of in the track order as seen by lavf.
However, there are many cases where tracks are not related to lavf, when
it's not used or there are virtual tracks addded like DOVI EL track or
merged image tile grid. Don't conjure `ff-index` out of nothing.
Some scripts may be confused when this index does not much ffmpeg. Even
though it has always stated in docs.
Fixes#18244
The `ff-index` is just a index of in the track order, it doesn't carry
much meaning and may be wrong or unavailable when other than lavf
demuxer is used. Additionally some tracks may be virtual like DOVI EL
track or merged image tile grid. In which case those track are not
related to lavf at all.
No deprecation period. It was never guaranteed to match FFmpeg anyway,
so anyone who has a hard dependency on this property should reconsider.
It's not really possible to provide backward compatibility given the
ambiguity of this index. It's better to make it unavailable than making
mismatch. For user it's clear when it's not available, but not possible
to know when it's wrong.
If `is_preempted` flag is set during init we need to try again, but if
we do it too fast, we never let the init to finish and constantly gets
the flag re-set.
Fix this by throttling the same as error path. It's not perfect, because
we rely on init timing, but was confirmed working and this restores the
previous status quo.
Fixes: d9f27bd0f1Fixes: #18161
When changing MPEG-TS program (edition) it may have completelly
different time base and duration, on live, non-seekable streams we would
just hang trying to resync to revious PTS, which is not valid. Reset the
state on edition change.
AVProgram array contains programs in order as they were discovered by
lavf. For MPEG-TS depending on the point where we start demuxing it is
effectivelly random. Sort by the id, so we have consistent order of our
editions, regardless of probing.
It's way easier to type 10M instead of typing all those zeros.
Our C API uses int64_t for properties and string for setting options, so
it's safe to bump this option type.
the old check stopped at the first occurrence of a vulkan loader path.
though it's possible different vulkan loaders are installed in different
paths, leading to not found vulkan loaders.
to prevent this, also check if the needed vulkan loader is actually
installed to that path.
specific case is when installing MoltenVK and KosmicKrisp at the same
time. the former is installed in the homebrew prefix under etc/ the
latter under share/. the latter wasn't found previous, since the former
was found first.
The feature test macro is nonstandard and not available on older GCC
version, which causes build failure despite the compiler does support
__builtin_mul_overflow.
Since there are no fallback when __builtin_mul_overflow is not
available, there is no need to check, so simply remove it.
If __builtin_mul_overflow is not supported compilation will still fail
just like currently.
Instead of using zero initialized value. Otherwise an early init failure
calls close(0), a descriptor we don't own, breaking whatever else
happens to hold it.
This is bit defensive, but I want to init those just after allocation,
so we don't have to trace whether they are initalized correctly or not.
Instead of using zero initialized value. Otherwise an early init failure
calls close(0), a descriptor we don't own, breaking whatever else
happens to hold it.
Also add missing check before close() call.
Instead of using zero initialized value. Otherwise an early init failure
calls close(0), a descriptor we don't own, breaking whatever else
happens to hold it.
This is bit defensive, but I want to init those just after allocation,
so we don't have to trace whether they are initalized correctly or not.
The software renderer backend is not capable of using any of the VO
capabilities set globally by vo_libmpv. This can lead to assertion
errors when trying to render a video with 90 degree rotation metadata.
Instead use the ctx->renderer->driver_caps value so the source frame
doesn't have its params rotated when it's not desired.
An `--audio-file` could be sourced from a stream. A stream could be
using timestamps that match unix time in their segments. In that
case, setting `audio-delay` will lead to a big unexpected A/V desync
due to the limited precision of floats.
This commit changes `--audio-delay` (and --sub-delay while at it) to be
stored in `double` instead of `float`.
`audio_delay` was already up-casted to `double` wherever it was
evaluated. Same for `sub-delay`, except its own value was getting
adjusted based on `double` values in one place (bad!):
player/command.c:6297
mpctx->opts->subs_shared->sub_delay[track_ind] -= a[0] - refpts;
A showcase:
mkfifo /tmp/mpv
date=$(date +'%s')
Before:
mpv --input-ipc-server=/tmp/mpv -
echo 'print-text '"${date}" | socat - /tmp/mpv # 1782890841
echo 'set audio-delay '"${date}" | socat - /tmp/mpv
echo 'set sub-delay '"${date}" | socat - /tmp/mpv
echo 'print-text ${=audio-delay}' | socat - /tmp/mpv # 1782890880.000000
echo 'print-text ${=sub-delay}' | socat - /tmp/mpv # 1782890880.000000
After:
mpv --input-ipc-server=/tmp/mpv -
echo 'print-text '"${date}" | socat - /tmp/mpv # 1782890841
echo 'set audio-delay '"${date}" | socat - /tmp/mpv
echo 'set sub-delay '"${date}" | socat - /tmp/mpv
echo 'print-text ${=audio-delay}' | socat - /tmp/mpv # 1782890841.000000
echo 'print-text ${=sub-delay}' | socat - /tmp/mpv # 1782890841.000000
Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
Implement `lavfi-tempo` audio filter, which uses `atempo` or `ascale`
form libavfilter for setting the tempo.
Users (myself included) seem to be always looking for alternative tempo
scalers to try, and this provides a faster implementation (or two), and
may prove useful beyond performance/speed.
`atempo` is picked as a default, and as a fall-back if `ascale` is not
available.
Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
The XDG Base Directory specification says “All paths set in these
environment variables must be absolute. If an implementation encounters
a relative path in any of these variables it should consider the path
invalid and ignore it.”
In the 2020s, now known as "the twilight years of modern
civilization", Silicon Valley's two most morbidly obese failsons
finally found their niche: a product that lets complete imbeciles
pretend to be software developers. This was, at least for a
while, a smash hit. Hordes of claudecucked vibechuds began
spamming free software projects with bogus "security bugs" and
associated even worse fixes, both of which they did not know how
to reason about, and definitely did not care to learn how to
reason about. The entire exercise, after all, was to get one's
name into the list of contributors, to get ahead in a highly
competitive job market of economies with equally torturous
education systems.
To the disturbingly moist-looking tech oligarchs recording
Goldman Sachs jerk-off instructons on their podcasts, this was a
profound shift in software development. Now, they no longer had
to pay 6 figures to some idiot who doesn't know how to program so
chooses React, and instead they can pay 6 figures to some
application that doesn't know how to program so chooses React.
For everyone else, it just added to the torment that is life in a
modern globalised service economy, where the fruits of their
labour are siphoned off and directed towards building ever
grander and more opulent paedophile island resorts.
But back to the code. Someone submitted a slop issue about how
there's UB if you run an input command with bogus parameters.
This is hardly a bug, since the commands are trusted, so the fix
is "don't do dumb shit". However, contextless vibechuddies saw
this as an opportunity to fire up their deeply subsidized
planet-burners and shit out some code they had no idea about what
it did.
LLMs, failing to have any real reasoning, tried twice, and failed
twice, to find the real """fix""" here. #18144 decided that
another condition needed to be added to the logical OR, whereas
the subsequent #18211 instead wanted to do an explicit cast to
size_t for no fucking reason. Funnily enough, the unsignedness of
size_t doesn't cause any problems here, because of the earlier
check to make sure `w` is positive.
Both of them missed that if `foo < bar * 4` overflows `bar`, you
can just check for `foo / 4 < bar`, which is an efficient
division as 4 is a power of 2, and the integer division here does
not lead to any problems because the check is a range check.
Do that, just to stop these stupid fucking PRs from popping up,
and deny these dumb shitheads the satisfaction of getting their
name into the contributor stats.
Closes#18128.
nanahi