The previous commit to avoid refresh seeking video streams has an edge
case when enabling tracks when loading files. Since the streams are
initially unselected and then multiple streams are enabled, the detection
only works reliably when video tracks are enabled first.
This makes sure that loading file enables tracks in a predictable order.
940854c86f added this logic, but when the
demuxer contains a selected video stream, it causes a seek for the video
stream. This is unnecessary since the problems that commit fixed are only
relevant for external audio streams. For a demuxer with a video stream
selected, the synchronization is done by the demuxer implementation.
Add a check to prevent this.
This follows up 96e1f1dfa5 which converted --gpu-context, and has the
same advantages as listed there.
Unlike with --gpu-context auto can be used anywhere in the list, e.g.
--gpu-api=d3d11,auto works.
I wanted to use the list of GPU contexts as the description in
get_type_desc(), but there is no talloc context to allocate it to, so I
set a print_help_list to print them. The APIs go before the contexts so
that etc/_mpv.zsh doesn't try to complete the contexts.
This function is used to reject invalid context names early, and without
it the context fails to create and only audio is played, but it doesn't
need to check for known entries again.
We wrap the default Lua allocator to allow used memory tracking. This
works well, except that we never destroy the default allocator or notify
it that we are closing. Since we override it for the current Lua state,
it is reasonable that the Lua engine does not expect it to be used. We
get and pass through a free call, but in the case of LuaJIT, the
internal allocator has additional state and is freed differently. So, in
fact, it is a LuaJIT leak because once we replace the allocator with our
custom one, they should clean its internal state. I guess the assumption
is to override allocator only before any allocation happen. To work
around this issue, restore the default allocator, the one that we use,
before closing the state. This way, everything is cleared as expected.
Note that the current solution of wrapping the default allocator works
only because none of the supported Lua engines actually invalidate the
allocator on the lua_setallocf() call. However, they could, so keep in
mind that we are currently depending on an implementation detail.
Thanks to @Dudemanguy for help with finding the changes that introduced
the leak.
Fixes: a67bda2840Fixes: #14451
Mainly for debugging. It might be handy to disable presentation feedback
on wayland to make sure something isn't going wrong with the
calculations somewhere.
Before a7158ceec0, string comparision was
done with strcmp, which does unsigned comparison. The natural sort
implementation instead compares on char values.
This causes implementation-defined behavior in comparison, depending on
the signedness of char type.
Fix this by using unsigned comparison instead.
Adding base path make sense only if it is a real directory or url
location. In case of protocols like memory adding base path to playlist
entry in facts adds the whole playlist to that entry.
For example `mpv $'memory://#EXTM3U\na/b'` produces infinite loop,
expanding playlist, adding more to it.
open_file adds the dirname to support relative playlist enties, however,
the dirname is invalid when the name doesn't represent a path, such as
with memory://..., so avoid taking the dirname with such protocols.
Found by OSS-Fuzz.
`:` were not escaped correctly. Also while at it clear other external
file lists, as we don't want to load any. Subtitle fuzzer will be added
in the future.
It is surprisingly hard to clear the list with C API. That needs whole
mpv_node_list with 0 elements, to make it clear it.
Similar to the previous commit but the other way around. If you start
mpv as idle, load up a playlist without immediately hitting play and
then try to go to the next item, nothing happens. Naturally, you would
expect this to go to the first item. Fix this detecting if the playlist
has not started yet, the direction, and going to the first item in the
list.
Previously, playlist-prev didn't work if you played a playlist to
completion using --idle and tried to go back. Naturally, one would
expect this to bring up the last item in the playlist, but nothing
happens. This is just because playlist_get_next is stupid and doesn't
take this into account since pl->current is NULL and thus returns NULL.
Fix this by considering the direction, checking if the playlist was
played to completion and grabbing the last entry in the index.
Most of these are pretty obscure things that were replaced a long time
ago. The special messages they were printing are also not really useful
at all so just remove them.
These were all deprecated in mpv 0.37.0 or earlier and are not
considered common enough options to warrant keeping the deprecated
mapping longer. Since demux_cue had only a single option in it, the
entire option substract is removed. This can be readded later if someone
wants to introduce a specific option to it again.
This prevents line wraps in select mode with terminal output which hide
the top items (OSD output no longer uses truncate_utf8 since the
previous commit). This is not ideal as even accented letters are assumed
to be 2 cells wide. The alternative is using \e[?7l and \e[?7h to
disable and enable text wrapping, but it won't work in Windows console
with VT processing disabled.
In select mode and when printing the OSD, use \q2 to let libass clip
lines longer than the OSD. This works around having to leave a large
horizontal space unused due to libass subtracting the left margin from
the max text width even though the ASS event is anchored to the bottom
left. It also fixes truncating wide Unicode characters.
Even if ass:pos() hardcodes the position at 6px from the left, we still
need to subtract the left --osd-margin-x from the available text width.
See how libass/ass_render.c:ass_render_event() subtracts it from
max_text_width without checking if the event is positioned.
The calculation is still not perfect as the width could be made a bit
larger before the text wraps.
Stop making unselected tracks and editions grey because they can be hard
to read over a dark background (\033[2m would be hard to differentiate
from regular text with a light theme instead), and because there is no
way to not print the escape sequences in --log-file.
Just use the same circles as the OSD and OSC. We need to print the empty
circles for alignment on mlterm with East Asian fonts (we could also
make them invisible with \033[8m but it would still get added to log
files).
Add back the space before tracks and editions when printed after
"Playing..." or "Track switched" and similar, so they look like a
sub-section of it, consistently with the metadata which starts with
space which makes it look like a sub-section of the "File tags" line.
Leave 2 spaces between track columns.
Make the lang options only as long as the longest language.
Place hls-bitrate within the same parentheses as the other data.
Replace the incomprehensible (*) (f) and [P] with textual descriptions
within []. Also place external there.
Stop converting Hz to kHz for consistency with other log messages, e.g.
AO: [pipewire] 48000Hz stereo 2ch floatp
Remove the space in "2 ch" so it doesn't look like 2 separate values (We
considered using mp_chmap_to_str(&s->codec->channels) but it prints
values like "unknown2").
Previously, using m_option_type_alias required that the alias have the
full name of the option value. This is limited if you are reusing the
same opts struct in different sub options. Fix this by add an additional
field to m_option to signal whether or not prefixes should be taken into
account for the alias option. Instead of blindly using whatever is
stored in opt->priv as the name, we can construct the desired option
name for either case (using the prefix or not).
It makes sense to allow the first part of the list. There are
warnings about excessive elements already. This also allows overriding
elements with the same label.
It fixes stack-overflow with keys that contains hundreds of splits. 100
is more than enough for any valid use of user-data, normally key
shouldn't contain more than a few splits.
Found by OSS-Fuzz.
Fuzzing expect deterministic behavior. While we don't use this random
generator for anything significant, still good to set the seed, in case
of future usage.
