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.
It's useful for user scripts to be able to use the same ytdl binary that
ytdl_hook uses without having to replicate ytdl_hook's process of
searching for the ytdl binary.
Some user scripts might also find it useful to be able to access ytdl's
json output that the ytdl_hook already receives, sparing user scripts
from having to make a duplicate ytdl binary invocation to get the json
output.
Providing just the json output is not enough though, as ytdl doesn't communicate
errors though it -- if an error occurs, ytdl provides no json output and instead
prints to stderr. So without stderr, there is no way for user scripts to figure
out why ytdl has failed: no such username / video id, the channel is not live
yet, etc. Because of that, the entire result of the subprocess call is provided
to the user scripts, containing stdout (json), stderr, ytdl's exit code, etc.
There's no advantage in using the forced version here. It is a leftover
from when this was an external script and forced was necessary to bind
key sequences reliably until 3f83671f20.
This results in all image params not being restored even if only one is
unknown. In particular params->color.hdr isn't cleared, causing
overblown color for some samples.
It should be safe to restore even unknown values.
mp_image_params_guess_csp will handle that.
This reverts commit 3acd253e89.
With the previous change, it is possible that the mp_hwdec_ctx contains
a list of known supported hwuploads. Take this into account when adding
to the p->fmts list. We want to be sure to select only something that is
actually possible to use. If the hwdec does not implement
supported_hwupload_formats, then all are assumed to work.
This is probably fringe, but I encountered it on my machine. The
hwupload filter happily does conversions all on the GPU side if
possible. Makes sense. However, it turns out that there is a difference
between e.g.yuv420p -> vaapi[bgr0] and a vaapi[yuv420p] -> vaapi[bgr0].
The latter worked without any issues on my hardware, but the first
example fails. To remedy this, we need to also do hardware uploads
during probing against formats and track what actually works (i.e.
vaSurfaceExportHandle). This commit only implements it in vaapi since it
is the only known place where this edge case is relevant. But other
hardware decoding drivers could easily add support later if needed.
It's a bit roundabout, but we were doing this incorrectly before. The
format table alone isn't good enough because it is possible the the
compositor may advertise different formats for a specific device which
is a subset of the format table. What we need to do is add formats based
on the array in tranche_formats. Note that it is possible for the
compositor to send multiple tranches (was not able to simulate this but
it's allowed by the protocol). For mpv, we only care about the very
first one which is supposed to be the most preferred one. The compositor
can also send the entire chain of events (main device, format_table,
tranches, etc.) all over again. We handle this in the wayland code, but
handling this in mpv's core code isn't done. e.g. say a format in use
was suddenly no longer supported. We ideally should do a full reconfig
in this case, but that gets complicated and is pretty niche so save that
for another day. Multiple GPUs isn't taken into account either. We just
pick the first one. Not strictly correct, but close enough for us.
Fixes#14544.
The linux-dmabuf protocol gives us the main device being used. Using
that along with some drm code, we can get what drm formats are supported
by the GPU. This is pretty crude as we just check against the first
primary plane we find and hope for the best. Also the protocol can
technically update formats at any time (e.g. if the device changes). We
do update what gets stored in wl->gpu_formats but the next commit won't
make any attempt to address this hypothetical scenario. It's complicated
and this is better than nothing. In practice, this will only work
against one constant device during VO runtime. Additionally, we can add
this check to ra_compatible_format to filter out additional unsupported
formats.
ASS_OVERRIDE_BIT_STYLE includes ASS_OVERRIDE_BIT_ATTRIBUTES, which we
don't want.
This prevents --sub-ass-override=force from overriding attributes such
as bold, italics, underline or strikeout to mpv defaults.
Apparently for an user mpv would crash on startup if built with asan and
mpv attemps to load mpv-mpris. Just set --no-config so we don't load
anything external since this is more correct anyway.
Kacper Michajłow
Misaki Kasumi
Andreas Klauer
nanahi
Guido Cella
Dudemanguy
llyyr
sfan5
Maxim Biro
Oneric