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
The FILE field in a CUE sheet may contain a relative path with
subdirectories. It's not clear if this usecase is intended to be
supported, as none of the usual CD/DVD ripping tool generates this type
of FILE field in the CUE sheet. The specification is old and abandoned,
so this will likely never be clarified and it doesn't cost much to
support it so might as well...
Hook AVFormatContext.io_open so HLS/DASH segment fetches and other
nested FFmpeg I/O go through stream_http when libcurl is available.
This lets segments inherit the connection reuse, HTTP/2 multiplexing,
mid-stream resume and conditional compression of the top-level stream.
Falls back to FFmpeg's default I/O for non-HTTP URLs and when the curl
backend is not built in.
Until now the pool only released its packets on shutdown or when the
cache size was reduced at runtime, so it kept growing across a session.
The amount of packets would be indirectly bound by demuxer cache size,
else the packets are reused. Still over long playback or switching
files, this may give impression of elevated memory usage, or even memory
leak. This was particularly visible with cache-on-disk, where users
reasonably expect RAM usage to stay low.
Pop now keeps the first POOL_HOT_RESERVE packets at the head of the
freelist for fast reuse, and frees up to POOL_GC_BATCH packets from
beyond that on each call. Bulk pushes (e.g. cache reset on file end)
remain no-work policy. The pool drains across subsequent allocations
rather than stalling on a single huge free. Self-balancing without any
size tracking.
This drains the pool in steady state. Note that on file switch we
effectively reuse only ~N / POOL_GC_BATCH packets from the old cache,
because each pop reuses just one packet while freeing up to
POOL_GC_BATCH. That's fine, both free and alloc calls are throttled to
the same per-pop rate, so allocator pressure stays bounded even though
not all packets get reused.
Lavf exposes programs/renditions as a flat track list tagged with
program_id. We respect this metadata and group tracks into their
respective programs, as tracks from different programs may be completely
unrelated to each other.
This commits adds an option to flatten the editions and ignore the
grouping.
Fixes: https://github.com/mpv-player/mpv/issues/17836#issuecomment-4345930205
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.
The .strm format consists of a URI or local path as the sole contents
of a text file, this is parsed by software like Emby or Jellyfin to
treat remote streams or paths as if they are in the local filesystem.
This commit adds .strm to mpv's internal list of playlist file formats,
and points it to the handler for .m3u files as they should be
compatible. .strm doesn't need all the features of .m3u/.m3u8, but the
features do not cause issues with the relatively barebones playlist
format of .strm.
The delay_open mechanism used by
--script-opt=ytdl_hook-all_formats=yes breaks setting metadata with
global_tags because tl->track_layout is NULL. See adcf51dccdcbb8f534b08ea7aa5471.
Fix this by applying tags to the EDL timeline in this case.
Tags must still be applied to tl->track_layout when available for them
to work with local EDL files.
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.
trying to autocreate playlist when the file is a fifo breaks
playback. the bug report is a special case of `/dev/fd/*` but
even for named fifos, opening and closing them can cause the
other end to stop writing.
Closes: https://github.com/mpv-player/mpv/issues/17682
Since we call bstr0 on the string anyway, might as well use it for
printing which implicitly includes a null check that gcc can see so it
doesn't produce the warning as seen in the next commit anymore
Since the previous commit normalized playlist filenames when they are
stored, the code normalizing them can be simplified back to how it was
before implementing normalization.
Currently entries in playlist files like m3u are first added to the
playlist, and then if they were relative paths the playlist file's
dirname is prepended to them.
Change it to directly add entries with the correct path. This will be
needed to normalize playlist entries as soon as they are added, else
normalization would prepend the working directory to entries with
relative paths.
demux_cue, demux_edl and demux_mkv_timeline don't need to be modified to
work with the next commit.
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.
Kacper Michajłow