Add HDMV menu support to stream_bluray, activated by opening with
"bd://menu/..." or the global --disc-menu option.
The IG overlay plane arrives through the libbluray YUV overlay
callback. Decode the palettized RLE into a BGRA plane (premultiplied
alpha) and hand it to the player via STREAM_CTRL_GET_NAV_OVERLAY.
STREAM_CTRL_NAV_CMD maps arrow/select/menu/popup/mouse actions onto
bd_user_input() and bd_mouse_select(). Events relevant to the menu
state (title, playlist, menu on/off) are tracked so
STREAM_CTRL_GET_NAV_STATE can report an active menu, and playlist
changes bump discontinuity_id so the player flushes stale packets.
Drive libdvdnav's menu state through the new disc-nav protocol so the
player can show and interact with VMGM and VTSM menus.
STREAM_CTRL_NAV_CMD maps the nav actions onto libdvdnav.
STREAM_CTRL_GET_NAV_STATE reports whether a menu with buttons is on
screen, the highlight rectangle and palette of the focused button, and
the ids of the disc-selected audio/SPU streams.
Menu mode is entered by opening with dvd://menu or --disc-menu, which
starts at the disc's root menu instead of a title.
Define three new stream controls so disc backends (libdvdnav, libbluray)
can expose their in-disc menu/highlight state to the player.
Not used yet, the next commits add the backends and the player side.
Disc demuxers switch titles and playlists at runtime, which changes the
duration and replaces the chapter/edition lists. Add
demux_set_duration() and demux_lists_changed() for demuxers to publish
such updates, and DEMUX_EVENT_LISTS for the player to react.
While here, drop the message to MP_VERBOSE and fix its wording.
"switched to title" is misleading because this is a VTS-change event,
not a title change.
Let the caller pick the OSD object instead of hardcoding EXTERNAL2, so
other bitmap overlay sources can reuse the same path. No functional
change, EXTERNAL2 is still the only user.
Add primaries, transfer, max_luma and video_colorspace arguments.
Allows tagging the colorspace of the overlay bitmap instead of assuming
sRGB. video_colorspace interprets the bitmap in the video's colorspace,
so it is tone mapped exactly like the video. max_luma overrides the
luminance peak of the bitmap. Currently only vo_gpu_next honors these
parameters. vo_gpu keeps its sRGB assumption regardless of the tag.
Fixes#10678
The union member is only valid for SUBBITMAP_LIBASS. The resulting data
is only read for PL_OVERLAY_MONOCHROME, so there was no risk of using
garbage data, but we can make it explicit.
The queue-full fallback could fire during startup (and after seeks),
before the enhancement-layer decoder produced its first frame.
Gate the fallback on the EL pipeline having delivered at least one
frame since the last reset. Until then a full queue only means the EL
decoder is still spinning up.
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.
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
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.
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.
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
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.
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.
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.
This joins Dolby Vision EL track with base one. libbluray current (as of
1.4.1) doesn't even expose this info, it will be available in next
version, but it is less code to ask lavf for this info in fact.
Don't try to select dependent track as main and feedback to base track.
To avoid situations where tracks are deselected only to select the same
group again.
This filter only converts SDR to HDR, so disable it if we have already
HDR on input. Note that it also seems to be disabled if HDR is disabled
in Windows, but we don't check that, because filters are not related to
display. Use conditional profile to enable this filter when needed, this
commit is only small convenience change.
Fixes: #17800
This is mostly useful for SDR mode where previously we would output 203
nits, which on Windows is considered HDR, because reference white is
fixed at 80 nits in SDR mode. Which in turn causes additional
tone-mapping when using scRGB output.
Note that for SDR transfers this doesn't change the luminance, but
instead causes more aggressive tone-mapping, might not be fully
expected. But maybe we should follow system setting for better of for
worse.
Fixes: https://github.com/mpv-player/mpv/issues/17850
Not fully, because when ICC profile is embeded in content, libplacebo
will override our luminance, this will be fixed separately.
In case when during parse and initial item creation there is only single
property evaluated, in case like `prop1 or prop2`. Only `prop1` is
evaluated and added to observe that will make item dirty. However, when
item is dirty, we may need to evaluate the rest of the expression,
especially important to add it to observe, so we mark it dirty next
time.
Fixes: #18153
Older versions ship separate `vapoursynth-script.pc` and
`vapoursynth.pc`, we want to use `script` one. Try it first, if not
available use `vapoursynth`, which is the only one new version ships.
This mirrors `crypto+` protocol from ffmpeg, which is used in HLS
demuxer. Unfortunatelly ffmpeg doesn't use custom io_open in their
crypto.c, so we spin our own decryption.
Kacper Michajłow