When the file is in the current working directory, stream->path points
the path user passed as arg, so it may or may not include './'.
Strip it from both to make the comparison work
Fixes: c201c4874d
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.
Also rename the field to appropriately reflect what it is supposed to be
used for. The only other use of this was to search for ordered chapter
sources, and that makes no sense for mkv files from stdin.
This also fixes autocreate-playlist loading in the current directory
when the input file is stdin.
While the code before 571f9b0f23 had a
typo and it was intended to be 100 MB, there are files that exceed this
limit, like 147 MiB. Increase the limit to 512 MiB which should be more
than enough for valid files.
From quick look ffmpeg limits to 1<<8 bytes, so we should be good with
our new limit.
In theory this limit could be removed, but it is better to play the
file, possibly with skipped some corrupted block of data, instead OOM.
Fixes: 571f9b0f23
This allows playing arguments like
mf://https://foo.jpg,https://bar.jpg
and also URLs within @listfiles (files with 1 image per line).
URLs still don't work with globs and printf-formats.
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.
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.
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.
Since d41f0a54b0, enabling a stream will
no longer perform a refresh seek, to fix issues with switching video
tracks. Additionally, 62e9a0c5f6 also
prevents refresh seek on track switching when it happens right after a
seek.
Unfortunately, when external audio files are loaded, preventing refresh
seeks can cause A-V sync issues. Since external tracks have separate demuxer
instances from the internal tracks, the demuxer instances from both
internal and external tracks are explicitly sought to the same pts when
seeking is performed. When enabling an external audio track for the first
time, the existing logic prevents refresh seek because no packets have ever
been read, so the track ends up not being sought. This means that switching
the track in the middle of playback results in a huge A-V desync.
To make it worse, unlike one demuxer instance with multiple tracks,
tracks from multiple demuxer instances are not synced in any meaningful
way beyond the separate explicit seeking. The only thing which keeps these
tracks synced is the generic A-V sync logic, which is unfit for such large
desync above. This means the audio is at the start position after the track
is switched, behind the video, so the audio is not considered ready, and
audio is continuously filtered sequentially until it is synced to the video.
While this is happening, the audio filtering exhausts all CPU resources.
There is also a case with cache enabled: if a seek causes some new data to
be cached, the demuxer is sought to the end of joined cache range.
If track is switched after this, the existing logic prevents a refresh seek,
so the demuxer is at a wrong position after the track is switched.
Fix this by allowing refresh seek for non-video streams, even when no packets
have been read yet or immediately after a seek.
The options parameter here can be NULL. It's NULL checked a few lines down,
but not for the propagate_opts loop. This results in null derefence with
--demuxer-lavf-format=image2.
Fixes: b6413f82b2
There are jpg files out there that have extra embedded metadata
(pictures from smartphones commonly have an embedded gain map). ffmpeg
doesn't currently support this, so mpv currently sees the extra metadata
as essentially another frame. This results in weird video-like behavior.
Until ffmpeg support this more properly, we can work around this by
simply discarding extra packets and not sending the new frame to the
internal playloop. If demux_lavf detects that the stream is a
single-frame jpg, then we only accepts the packet at pos 0. Anything
else is discarded. Ref #13192.
Passing jpg filenames to ffmpeg is actually quite bad. This causes all
jpg images (at least in my testing) to be probed as image2 which is
blacklisted in demux_lavf since it's completely broken (see commit
74e62ed2d1 for some details). What happens
in practice is that the lavf demxuer fails and the it opens in the mf
demuxer instead. This is OK for simple viewing, but because that demuxer
is limited, many specific file properities and other things are
completely unavailable which breaks any script that may depend on them
(e.g. width, height, etc.) For the small subset of files that this
commit appeared to "fix" (in reality, it just fell back to the mf
demuxer) is not worth breaking property usage in the vast majority of
normal proper files. Ideally ffmpeg should fix this but some other
workaround on our end can be used instead.
This reverts commit d0aeca5918.
4e5d996c3a added this as part of a series
of patches written to avoid wasteful sub redraws when playing a still
image with subs. The is_animated special case was specifically for ASS
subtitles that have animations/effects and would need repeated redraws
in the still image case. This check was done unconditionally for all ASS
subtitles, but for very big ASS subtitles, this text parsing can get a
bit expensive.
Because this function call is only ever needed for the weird edge case
of ASS subtitles over a still image, some additional logic can be added
to avoid calling is_animated in the vast majority of cases. The animated
field in demux_packet can be changed to a tristate instead where -1
indicates "unknown" (the default state). In update_subtitle, we can look
at the current state of the video tracks and decide whether or not it is
neccesary to perform is_animated and pass that knowledge to sd_ass
before any subtitle packets are decoded and thus save us from doing this
potentially expensive call.
If blocks were already demuxed we would skip them and ask for new ones.
For files with few blocks it would return EOF without actually checking
the content.
Also make demux limit higher. In practice it doesn't matter, because if
it is image, video track will have only 1 block. And if it is not image
it will break on 2nd video block.
Fixes: #13975
Kacper Michajłow
llyyr
nanahi
Dudemanguy
Guido Cella
sfan5
Aman Karmani
MartinEesmaa
