console.lua binds up and down to navigate its history. Add a private
flag to mp.input.get to instruct console.lua not to bind up and down, so
you can use them to scroll the keybindings page while filtering
keybindings.
If it is requested, this can be replaced with an argument to input.get
to not bind arbitrary keys.
Fixes#14966.
Pass everything in the tables passed by mp.input callers to console.lua
so new flags can be added without modifying these clients.
In Lua, callbacks have to be excluded from the argument tables to not
make utils.format_json() error, while with JSON.stringify they are
automatically omitted.
There was mixup between upload formats and device formats. Instead of
filtering the device formats with VO constraints, upload formats were
affected. It was working, because most of the time the upload is using
the same formats. But if there is conversion on the fly needed we were
filtering wrong list of formats. Upload formats are those that can be
used to upload to the given hardware frame, conversion during upload are
allowed if possible. The main fix is in select_format() which were using
device formats as input, instead of ouptut formats and upload formats as
output, instead of input.
The multi device part is mostly theoretical, but it turns out that
plasma does send multiple tranches to the same device so we have to take
that into account. And that means taking into account multiple devices
as well. In theory, a compositor should give us tranches for any device
that will work so as long as we find a match it should be OK. This is
still technically incomplete since mpv's core wouldn't react to a device
being hotplugged.
Both of these VOs draw buffers in software via wl_shm to an mp_image, so
they are affected by the internals of whatever mpv does for alignment.
When wlshm was originally written, mp_sws was aligning to 16 bytes and
thus it chose this value but it was hardcoded. vo_dmabuf_wayland later
blindly copied this value. e1157cb6e8
actually changed the internal value to 64 bytes. In theory, this doesn't
probably doesn't really matter since 16 should also work in most cases,
but we might as well stop using a magic number and be consistent.
Additionally, wl_shm did some funny alignments that no other software
output did. The reasoning was apparently due to warning messages from
ffmpeg while cropping*. This was left in at the time, but I'm not able
to reproduce any such warning messages on my end when I make this match
other software VOs. Go ahead and remove the MP_MAX business and align to
the fmt x/y like the other VOs do.
*: https://github.com/mpv-player/mpv/pull/6240#discussion_r227930233
The list options --screenshot-avif-opts and --vo-image-opts are
completed with an extra 8), e.g. --screenshot-avif-opts-add=8), because
*= in
screenshot-avif-opts=-:Key/value list (default\: usage=allintra,crf=0,cpu-used=8):
matches up to cpu-used= instead of instead of up to
screenshot-avif-opts=.
Fix this by enabling non-greedy matching.
4d09cde8f9 added this behavior and made
the format filtering more aggressive, but it's over correcting. The
misunderstanding on my part is that the problem was with modifiers not
with formats. There is hardware that do not have any valid modifiers
which means certain formats cannot possibly work correctly with
vo_dmabuf_wayland (broken colors etc.). Formats on the primary plane do
not require modifiers so if it happens to be a planar format, we can
accept it and possibly use mpv's autoconverter. If we do get a valid
format + modifier pair from the compositor, then we should always accept
it regardless if it is planar or not.
The old name is misleading. We do want these formats, but it is not
accurate to call them "gpu formats". Call it "planar" instead so it's
more obvious these come from drm primary planes.
When starting multiple processes of `mpv --shuffle` in parallel,
sometimes the random seed happens to be identical, so files are
played in the same random order.
mp_rand_seed(0) now uses a random seed provided by libavutil,
and only falls back to time in case of failure.
Since f411f3145b, these properties
no longer change with each loop. This however caused a regression
on the behavior of resetting loop count by resetting these
properties.
Previously, after the loop count is decreased, it is possible to
reset these properties back their original values and thus reset
the remaining loop count. Currently, because setting properties
has no effect if the new value is the same as the existing value
(which no longer changes), resetting these properties does nothing,
and remaining-*-loops (which are read-only) remain unchanged.
There is no way to reset them other than temporarily setting them
to a different value, which is awkward.
Fortunately, this can be fixed by marking these properties as
force_update, which always notifies changes when being set.
It turns out that probing too many blocks is bad. I did not attempt to
go through all the logic but reading that many blocks causes the
demux_reader_state have some pretty funny values which then makes the
playloop think it needs to buffer for cache. It's probably fixable...
but seems hard admittedly so I'll be lazy. Just take out a magnitude off
the probing down to 10000. These seems to be more than sufficient. The
sample in #13975 where we had the opposite issue only needs somewhere
between 1700 and 1750 blocks to be properly detected. Crudely looking
at the demuxer values, 10000 here doesn't appear to alter anything
meaningfully so it does not have the "too many blocks problem".
Hopefully this is a perfect medium? Further improvements to the probe
can always be added later. Or maybe we decide this is all a giant
mistake and delete it. Fixes#14924.
Newer meson versions added support for features that mpv has been using
for a long time. Annoying fallbacks were left in place to not break old
versions but ideally everyone should be using the newer build features.
Both the latest ubuntu LTS and debian stable (in backports) have 1.5.0
in their repos, so go ahead and bump the version so we can drop some old
code and let developers use newer meson features if applicable.
Key names are already required be UTF-8 like everything else
in mpv other than media file formats which support other encodings.
stream_skip_bom is the wrong function for this, since it also skips
UTF-16 BOM.
mpv only supports UTF-8 for configuration files. Other ASCII-compatible
encodings may "work" to some limited extent, but strings likely won't
as many places assume that all internal strings are UTF-8.
It makes sense to only descend into the subdirectory meson build file on
windows, but we should always make sure HAVE_WIN32_SMTC is 0 for other
platforms. Otherwise, it gets unneccesarily awkward to work with.
