The run input is deprecated. Split the monolithic scripts into the same
step layout as the other jobs. Sync the sources once at VM start and
skip the per-step file synchronization, since everything runs inside the
VM anyway.
This will make reading logs easier.
Terminate the block of environment variables with NUL. Previously the block was left unterminated which could cause subprocess spawn failures depending on the array contents after the last item.
The per-stream variant_bitrate is not a reliable selection key. FFmpeg
attributes the whole variant's bandwidth to individual streams, and for
streams shared by multiple variants the value was bogus or missing
depending on the number of variants sharing the stream. The program
metadata always carries the exact HLS variant BANDWIDTH, so use it as
the only key and drop the per-stream fallback.
Note that with `--flatten-editions` tracks are selected by their own
tags, so they may still use bogus values.
For context, there is currently a bug in lavf where, depending on the
number of variants sharing a stream, the stream may or may not get
`variant_bitrate`. This will be fixed in a future FFmpeg release.
An EBML element is permitted to have a zero-length data payload. It's
then interpreted as the element's RFC declared default value, or zero.
Before this change all zero-length elements were initialized to empty or
rejected in case of uint.
Fixes: #18351
x2bgr10/x2rgb10 are packed formats that do not automatically get mapped by the
existing ra_pl logic. They are more useful than other non-byte-aligned packed
formats because they show up when dealing with > 8bit RGB content, which is
more common in an HDR context.
In practice, x2bgr10 is probably the only one that's going to get used, but
I figured there's no harm in supporting both.
seekRangesF() accepts a zero duration and produces NaN/Inf coordinates,
which assdraw cannot format. Ignore seek-range metadata when the native
duration property is unavailable or zero.
Fixes#18344
The special-options regex decided which options are completed without
a trailing '=', but it only covered Print options and "not in config
files" flags. As a result, two groups of no-argument options still got
'=' appended:
(1) *-clr / *-help sub-options (e.g. --af-clr, --vo-help) which are
mpv list-type sub-options taking no argument.
(2) --help/--h which is String-typed in --list-options but actually
accepts a substring filter to narrow down the option listing.
Extend the regex to cover (1). For (2), keep '=' appended (it does take
an argument) and route completion through a new Help branch that mirrors
the zsh help-options state: complete bare option names (no "--"
prefix), excluding no-* negations and list-type sub-options
(-add/-append/-clr/-pre/-set/-remove/-toggle). Bare names are needed
because --help=<substring> matches within the option name body.
After ANGLE commit 56663dbfa780 EGL_EXT_device_query is listed in the
client extension string instead of the display one. The display string
check always failed, silently disabling native d3d11va interop.
This fixes `hwdec` with `gpu-context=angle`.
setup-msys2 saves the pacman package cache under a key ending in a hash
of its contents. So with each update it saves more caches, what's more
important it saves it per each PR ref. We don't want that. Keep only the
msys2 cache on main branch and only the latest one per each
configuration. If PR saves new one, it will be dropped, we prefer master
branch case that can be used by all PR, rather then per PR cache of
this. The few packages that will be refetched are ok.
This change is an atempt to keep our cache under 10GB limit, to avoid
evicting more important ccache caches.
The nested jq invocations were hard to extend and left no trace of what
they decided. Delete by id rather than by key, since a key is only
unique per ref, and log each deletion.
No change in which caches are selected.
It appears this time GNU broke their ftpmirror, while the primary one is working again.
download.savannah.gnu.org also seems to be having issues.
Never thought I'd see the day where sourceforge is more reliable.
determine_codec_params() warns when it cannot determine a codec profile.
Some passthrough formats use fixed output parameters and do not require
the probed profile or sample rate making the warning misleading.
Warn only when a value used to configure the selected passthrough format
is missing: the profile for DTS-HD, or the sample rate for core DTS and
AC-3.
Signed-off-by: Nathan Lucas <nlucasgit@gmail.com>
The spdif decoder uses avformat/spdifenc. Some spdifenc paths keep
muxer state across packets, such as partial TrueHD MAT frames. After a
seek, that state belongs to the old stream position and can cause the
next packet to be muxed with stale timing or buffering state.
On decoder reset, discard the current spdif muxer context. The next
usable input packet will recreate the muxer through the existing
initialization path.
Cache codec parameters from the initial probe so recreating the muxer
does not probe a partial packet after a seek or replace known values
with fallbacks.
A fresh TrueHD spdif muxer needs a TrueHD major sync before it can begin
muxing the stream. Startup or post-seek playback may begin on a TrueHD
access unit that does not have major sync, so drop TrueHD packets until
a major sync access unit is seen. This also gives the downstream decoder
a clean restart point after seeks. Warn periodically if no major sync
has been found.
Partially addresses: https://trac.ffmpeg.org/ticket/9569
Signed-off-by: Nathan Lucas <nlucasgit@gmail.com>
Change --hwdec-extra-frames default to auto, which sizes fixed hw frame
pools from the number of frames the VO declares to reference, instead of
a static guess. Fixes pool exhaustion with e.g. --interpolation and a
tscale filter with larger radius.
Fixes: #18205
VOs can hold more frames than the requested lookahead. vo_gpu_next's
pl_queue retains past frames for the interpolation mixing window. Let
VOs declare the total number of frames they may reference at the same
time, so fixed hwdec surface pools can be sized accordingly.
Add demux_read_interrupted(), true when the demuxer is being canceled,
its thread is terminating, or a seek is queued. Poll it from
demux_lavf's AVIO interrupt callback so blocking network I/O (e.g. the
HLS demuxer waiting on a live playlist reload) doesn't stall queued
seeks or shutdown for multiple seconds. The aborted read's result is
discarded in all of these cases anyway.
In normal operation demuxer reads are fast enough to not notice the
issue. However, in the HLS/DASH demuxers, FFmpeg blocks read() calls
on the playlist reload timeout. This is expected, but can mean multiple
seconds of dummy wait before we can actually proceed. This change
significantly speeds up seeking in HLS playback when it hits a playlist
reload.
Up until now, we have not bothered to propagate queue creation flags when
setting up the ffmpeg device context, but with libplacebo setting flags like
VK_DEVICE_QUEUE_CREATE_INTERNALLY_SYNCHRONIZED_BIT_KHR and newer nvidia drivers
actually supporting this feature, I've now managed to run into this. If the
flags aren't put into the context, ffmpeg code can end up calling
vkGetDeviceQueue2 with the wrong flags, and the driver will return a NULL
queue instead.
I suspect we got this far without hitting this because the only filter that
can currently end up calling vkGetDeviceQueue2 is vf_libplacebo and then only
with the new `inherit_device=1` where the device we set up _from_ libplacebo
goes back to libplacebo. The oroborus is complete.
Each probe attempt assumes it reads from position 0. If the rewind
fails, the demuxer would silently misparse the stream from a wrong
position.
On non-seekable streams this may fail when the probe size > buffer size,
which would cause us to drop the buffered data and not allow to rewind
the stream. This can be improved in the future.
request_start is producer state, a fast transfer can complete and roll it
forward before curl_open gets to read it, mislabeling all stream offsets.
Store the requested offset separately and use it for the initial pos.
Fixes: 289723b41a
The file-local-options property sets options that are reset when file
change occurs. This is different from per-file options which are set with
--{ commandline arguments and options parameter of the loadfile command.
Per-file options use file-local option mechanism for setting options when
the file is loaded, but they are persistent and stay with the playlist
entries, unlike file-local-options set at runtime.
This corrects the on_load hook documentation about the effect of setting
file-local-options.
This allows controlling whether the files in a playlist inherit the
per-file options of the playlist file itself. For playlists created
by --autocreate-playlist, --playlist-inherit-options=current allows
inheriting only for the item the playlist is created from.
Currently, if a playlist file is played and replaced by its contents,
the per-file options of the playlist file are ignored.
This commit makes these options inherited for its contents so they work
as expected.
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.
Kacper Michajłow