Media can stop providing a stream mid-playback, for example a disc
program that does not carry the Dolby Vision enhancement layer the
previous one had. Since mpv always try to keep at least 1 packet
buffered in all tracks, it can keep reading it till EOF.
Whether a DVD title's video track consists of sparse still images (a
slideshow) is only observable from the packet timestamps after
streaming started, and demux_disc wants to flip sh->still_image
accordingly, so that the stream stops being read eagerly.
still_image streams (AV_DISPOSITION_STILL_IMAGE) consist of sparse
frames that can be minutes apart. When such a stream was selected
alongside an eager audio/video stream, its empty packet queue forced
the demuxer to keep reading ahead, buffering the whole file trying to
chase min_secs of "video". Read them lazily when other eager streams
exist, so playback drives read-ahead instead.
Keep DVD SPU streams always enabled at the slave level and retain the
last subpicture per substream. Re-deliver the retained copy when a sub
track is (re)selected and when the player resets playback state.
demux_disc replaces the chapter list at runtime. Parent each chapter's
tags to the list that contains them, so a replaced list keeps owning
its metadata instead of accumulating it on the demuxer.
The disc VM advances when the stream is read, so in nav mode the cache
must not run ahead of what the user is seeing. Never read ahead (a
looping menu is endless). Never satisfy seeks from the cache either.
This applies to the whole disc session, not only while a menu is on
screen. The VM can jump at any time (BD-J timers, end of title), so
the cache must never run ahead of playback.
Activations still must be able to drive the VM while nothing is
consumed. demux_drive_nav() forces a single read for them.
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.
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.
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
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.
queue->is_bof is set optimistically after a seek to start, assuming
demuxing began at the start of the file. That is wrong for streams
opened mid-content, which can happen in unfinished event HLS playlists,
which starts at live-edge, but the seekable range in the past is still
valid.
For full support this also require change in lavf [1] to fix the overall
duration of the stream and seeking.
[1] https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/6d98a9a2e8757d6eb616501ade06877389a31597Fixes: #11990
Extract the codec descriptor out of mp_format_track_metadata into a
shared demux_append_codec_desc() helper, and use it from a new
demux_compose_edition_title() composer that both demux_timeline.c and
demux_lavf.c call when building editions. Codec block is only added
when the program has exactly one stream of that kind, and fields
already present in the prefix (e.g. WxH from yt-dlp's format label)
are skipped to avoid duplication.
This adds proper support for MPEG-TS programs and HLS variants. Now
program selection is exposed as editions and tracks are grouped under
such edition. If there are external tracks added, they are available in
all editions.
subrandr is a subtitle rendering library which aims to render
SRV3 (YouTube) subtitles and WebVTT subtitles accurately.
Currently in mpv WebVTT subs are rendered via ffmpeg conversion to ASS
which throws away a lot of the style and completely disregards
the WebVTT non-region-cue positioning algorithm. Furthermore if
one wants to render some more complex SRV3 subtitles one has to
resort to external converters since it's not even supported by ffmpeg.
However subrandr is able to render SRV3 subtitles natively with support
for the most commonly used features. It can render ruby text without
relying on font metrics during conversion which is obviously fragile,
and it can perform correct scaling using the exact calculations used by
YouTube instead of making up ASS approximations. Similarly it follows
the WebVTT spec for the features of WebVTT that it supports (mostly).
It's not perfect of course and there's still many things it doesn't do
or does wrong but those are things that can be incrementally improved
outside of mpv.
This clears packets from the pool, that would never be reused under new
settings. Note that depending on demuxer state this clears only unused
packets, in some cases demuxer may still hold more packets than the new
limit. Fox example demuxer doesn't forcefully clear forward cache when
reducing the size.
Also keep packet pool, even if current file is not cached, this is
useful for all sorts of things and may be useful for next file.
This act only on user options values, regardless of internal demuxer
caching state, which can vary depending on track type or source.
Useful for demux_edl where it is possible to have huge nested tree of
demuxers and they are added recursively, which causes stack overflow in
some cases.
Found by OSS-Fuzz.
Fixes excessive memory usage with avdevice input. After [1] packets
returned from avdevice contains wrapped AVFrame. mpv estimates packet
size to limit how many of them are cached. The size were not correctly
calculated, because packed contained only AVFrame* and not the actual
data in buffer. Fix this by calculating wrapped size and add it to our
size estimation.
[1] https://github.com/FFmpeg/FFmpeg/commit/6ca43a9675d651d7ea47c7ba2fafb1bf831c4d0b
This is useful to run mpv from URL handler. Can be used to start mpv
from you web browser or anything that would trigger url handler for
given protocol. Only safe protocols are allowed.
Current solutions to run mpv in such context are to spawn IPC proxy and
run mpv when requested, but this is in most cases not necessary.
Currently the protocol is added in mpv.desktop. Windows related
registration will follow in future changes.
Basically just bits of a9d83eac40 that was
removed and ported to here. Not really smart but it seems like flushing
buffers during seek generally leads to better behavior and avoids some
errors. The additional stream_seek call that was being performed is
definitely bogus (will never work and spams errors). So that is skipped
for bd/dvd. SEEK_FORCE is no longer needed. Instead demux_disc calls
drop_buffers on the slave demuxer (i.e. lavf).
This update introduces a demux_packet_pool, allowing for the reuse of
previously allocated packets when needed.
sizeof(AVPacket) is not a part of the lavc public ABI, which prevents us
to allocate memory in larger blocks. However, we can substantially
decrease the amount of alloc/free operations during playback by reusing
both mpv's demux_packet and AVPacket.
This adjustment addresses the root cause of issue #12076, which,
although resolved upstream, did not fully tackle the persistent problem
of allocating small blocks of aligned memory. This issue largely stems
from the FFmpeg design of the AVPacket API. After this change memory
will no longer be allocated once cache limits is reached.
The demux_packet_pool is shared as a global pool of packets for a given
MPContext.
This change significantly speeds up the demuxer deinitialization,
benefiting file switching scenarios, especially when a large demuxer
cache is used.
See: #12294
See: #12563
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
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.
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.
When a video-reconfig occurs with an image, the cache is not used
because find_cache_seek_range() checks if the start time was
initialized, but for images it stays at MP_NOPTS_VALUE. This makes
rotating large network images slow because they are re-downloaded on
every rotation.
Fix this by setting the timestamps of image cache ranges by altering a
condition.
cd59ea8afab6381951a3ae19a43e422906d02164 removed an arbitrary start
offset added to the timer. However, it turns out that demux secretly
depends on this. When updating cache to actually read bytes from the
stream, there's a diff >= MP_TIME_S_TO_NS(1) check to make it only
update once every second. With the old MP_START_TIME macro, the initial
time value would always be at least 1e10, so this would also be true.
Since we don't have that offset anymore, now the initial time is less
than that so it is not updated and properties like file-size are 0. Just
be sure to always update if the last_speed_query is 0 (i.e. we just
started the player). Fixes#12869.
currently hysteresis-secs only works when the demuxer-max-bytes fills
up. but it's possible for the cache-secs/demuxer-readahead-secs to be
reached first.
in those cases, hysteresis-secs doesn't work and keeps buffering
non-stop. but the goal of this option was to save power by avoiding
non-stop buffering so go ahead and make it respect cache-secs as well.
additionally remove some redundant repetition from the docs.
since i was going to fix the include order of stdatomic, might as well
sort the surrouding includes in accordance with the project's coding
style.
some headers can sometime require specific include order. standard
library headers usually don't. but mpv might "hack into" the standard
headers (e.g pthreads) so that complicates things a bit more.
hopefully nothing breaks. if it does, the style guide is to blame.
replace it with <stdatomic.h> and replace the mp_atomic_* typedefs with
explicit _Atomic qualified types.
also add missing config.h includes on some files.
Kacper Michajłow