Matroska spec says that DisplayWidth and DisplayHeight should be applied
after cropping, but this doesn't adhere to the real files which does not
follow this rule. Revert the change and we can re-evaluate if someone
complains with spec compliant files.
See: https://datatracker.ietf.org/doc/draft-ietf-cellar-matroska/
This reverts commit f8db02b59d.
Unfortunately there are files out there with broken tags where the
width/height doesn't match the actual width/height of the file. That
means the cropping logic which normally should be a no-op resulting in
(0, 0, w, h) ends up being a crop which is probably not wanted by the
user. Workaround this by simply keeping the entire crop rect as 0 when
there is no container cropping. All zeros is internally treated the same
as (0, 0, w, h) and avoids bad container data messing up the width or
height of the window. Also simplify the logic a bit and get rid of some
superflorous bools that had no real use. Fixes#12680.
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.
Use mp_tags_move_from_av_dictionary() in place of
mp_tags_copy_from_av_dictionary().
This ensures that when lavf appends metadata
that occurs later in the stream,
it starts from empty each time.
Fixes: <https://github.com/mpv-player/mpv/issues/12559>
It's 2023 and people don't use UTF-8 for their m3u, ini, etc. files.
Well mpv already has the tools in place to try and guess other
codepages, so we might as well use it I guess. This change is pretty
awkward since we have to read line-by-line but mp_iconv_to_utf8 may
sometimes allocate memory. So sometimes the bstr needs to be freed and
sometimes not for every line. Also we need to make another copy of the
line on the stack since splitting by tokens and such will mess up the
original line which may possibly be allocated memory. The ugliness is
mostly hidden in pl_free_line, but it's still weird. Fixes#10911.
There's really no reason not to do this especially since sub-codepage
already defaults to auto. Also change logging in charset_conv since
telling us that the data is UTF-8 if the passed codepage value is "auto"
or "utf-8" is really not useful information (that's the expectation).
What are cue sheets not metadata or something? No reason this needs to
be a separate option so just deprecate it. This does mean that the
default value changes from "auto" to "utf-8" for this obscure fringe
case. I really hope people don't use non-UTF-8 cuesheets, but the next
commit will change the default of --metadata-codepage to "auto" so
there's no actual change in behavior to users.
Previously if the demuxer didn't exist, then it could jump down and try
to free sinfo.filename before it was ever set thus segfaulting. Just
always set the struct unconditionally so we're always sure to free it.
Some demuxers actually close the stream right after they are finished
opening like cue. Since the stream->url is no longer copied with this
commit, that means it gets thrown away after the stream closes. This
leads to a use after free. We still need to allocate stream->url so fix
this another way.
This reverts commit 3e85df3b2d.
Yeah another try at this. So when inspecting lazy_stream_needs_wait, I
realized it had a curious !ds->reader_head condition. Actually, this is
what is messing everything up. This was originally added in
cf2b7a4997 for showing large negative sub
delay values correctly. It worked because the packet will eventually be
discarded during playback causing ds->reader_head not exist and thus the
next one will correctly be read ahead as needed.
But for the "switching subtitle tracks while paused" case, this is
actually bad. As the stream is read, eventually you'll find a packet and
set the reader_head. But it's not going to be the correct packet (unless
you're looking for the very first one), so you need to read more. This
won't happen because of the !ds->reader_head check and unlike the sub
delay case, nothing will eventually discard that packet since playback
isn't occuring. So read_packet exits earlier than it should and isn't
tried again, so the subtitle that you want won't show since the
returned packet has the wrong pts. All that needs to be done here is to
delete this one condition. There's already checks in place to make sure
that it's not read past the desired timestamp and for the sub delay case
(the only other time this logic is used), it makes no difference since
you won't read past the specified pts in the first place.
The stream selection state wasn't improved. I didn't realize this messed
with caches. All in all, just not a good idea. Back to drawing board I
guess.
This reverts commit f40bbfec4f.
This replaces the previous commit and makes more sense. The internal
demux marked tracks as eager depending on their type and for subtitles
it would always lazily read them unless there happened to be no
available av stream. However, we want the sub stream to be eager if the
player is paused. The existing subtitle is still preserved on the
screen, but if the user changes tracks that's when the problem occurs.
So to handle this case, propagate the mpctx->paused down to the stream
selection logic. This modifies both demuxer_refresh_track and
demuxer_select_track to take that boolean value. A few other parts of
the player use this, but we can just assume false there (no change in
behavior from before) since they should never be related to subtitles.
The core player code is aware of its own state naturally, and can always
pass the appropriate value so go ahead and do so. When we change the
pause state, a refresh seek is done on all existing subtitle tracks to
make sure their eager state is the appropriate value (i.e. so it's not
still set to eager after a pause and a track switch). Slightly invasive
change, but it works with the existing logic instead of going around it
so ultimately it should be a better approach. We can additionally remove
the old force boolean from sub_read_packets since it is no longer
needed.
Actually, I thought of a better way of handling this shortly after
merging this. Revert it and redo it in the next commit.
This reverts commit c2c157ebec.
a323dfae42 almost fixed subtitle tracks
disappearing when paused but it actually missed one part: the behavior
of demux_read_packet_async_until. It's a bit unintuitive, but for
subtitle streams, that function would only return the very first packet
regardless of whatever pts you pass to it. So the previous commit worked
on the very first subtitle, but not actually any of the others (oops).
This is because subtitle streams never marked as eager and thus never
actually read farther ahead. While the video is playing, this is OK, but
if we're paused and switching subtitle tracks then the stream should be
eagerly read. Luckily, the logic is already there in the function for
this. All we have to do add an extra argument to
demux_read_packet_async_until to force the stream to be read eagerly and
then it just works. Be sure to unset the eager flag when we're done.
Actually fixes the bug for real this time.
With the previous commit, we can just access option values directly now
and avoid a lot of complication. Note that the mp_read_option_raw call
for edition requires calling mp_get_config_group since that option needs
to live in MPOpts.
Several parts of the code need to access options here. There's no point
in hiding it demux.c so just expose it in the demux.h header. This means
pulling it out of demux_internal and putting it in the demuxer struct
instead.
`demux->duration` is set to -1 on initialization, and some checks rely
on it being -1 when unknown. Before this commit, we set
`demux->duration` to 0 when unknown. This is incorrect and breaks rtsp
logic for disabling seeking outside of cached regions.
To fix these issues, initialize `total_duration` and `av_duration` at
-1. They're only changed if a real duration is detected, so in cases
where the duration is unknown, demux->duration is set to -1 correctly.
Fixes: e6afc53e7c ("demux_lavf: get total duration from track durations")
A bit different from the OPT_REPLACED/OPT_REMOVED ones in that the
options still possibly do something but they have a deprecation
message. Most of these are old and have no real usage. The only
potentially controversial ones are the removal of --oaffset and
--ovoffset which were deprecated years ago and seemingly have no real
replacement. There's a cryptic message about --audio-delay but who
knows. The less encoding mode code we have, the better so just chuck
it.
Before this change, mpv used to get the total duration from
`avformat_find_stream_info` and used the per-track duration as a
fallback. This change reverses this order of preference.
The timestamps returned by `avformat_find_stream_info` are truncated or
rounded or floored (depending on the decoder) at the 6th decimal place.
For e.g. `avformat_find_stream_info` may return us a duration like
44.138667, whereas the duration we get from the per-track struct has a
higher degree of precision like 44.13866666666... and so on.
This caused various problems such as the playback_pts being a bigger
value than the duration, which would cause time-remaining to be a
negative value in some cases. Or cause you to reach a negative starting
timestamp when looping on an audio file with `gapless-audio`.
Moreover, we already skipped calling `avformat_find_stream_info` for
mp4, so we had already been utilizing this per-track fallback method for
finding the duration for mp4 files. It should be noted that while this
change is only required for audio-only formats, there is no harm in
doing this for videos as well.
64959c450d solved the problems with resuming playback, so default to
--directory-mode=lazy because it's faster, especially on slow drives,
and results in smaller playlists.
Discovered by @christoph-heinrich in IRC.
09c701b797 added a fallback for headerless
m3u files. However, it requires that the bstr len be greater than 10.
This means that a m3u playlist with a single entry with a very short
filename (such as "test.flac") will not be recognized as a playlist
since the amount of data is too small. The reason for this restriction
is unexplained and really shouldn't matter given that the important
thing mpv should be doing is checking if the data is text. Instead,
loosen the check so that it only needs to be 2 or greater. This covers a
single byte filename and a line terminator.
This only existed as essentially a workaround for meson's behavior and
to maintain compatibility with the waf build. Since waf put everything
in a generated subdirectory, we had to put make a subdirectory called
"generated" in the source for meson so stuff could go to the right
place. Well now we don't need to do that anymore. Move the meson.build
files around so they go in the appropriate place in the subdirectory of
the source tree and change the paths of the headers accordingly. A
couple of important things to note.
1. mpv.com now gets made in build/player/mpv.com (necessary because of
a meson limitation)
2. The macos icon generation path is shortened to
TOOLS/osxbundle/icon.icns.inc.
Directories were always loaded recursively, which can be slow
(e.g. one of the subdirectories is a mounting point to a slow device)
and can unexpectedly expand into a massive playlist.
Due to the problems described in 503dada42f,
this defaults to recursive loading.
ref. https://github.com/mpv-player/mpv/issues/9652
--no-config should prevent loading user files of any type: configs,
cache, etc. For cache files, this case wasn't properly handled and it
was assumed they would always get something. vo_gpu's shader cache
actually already handles this, so it was left untouched. In theory,
demuxer cache should never have this issue because saving it to disk is
disabled by default (and likely that will never change), but go ahead
and change it for consistency's sake. Fixes some segfaults with
--no-config and various combinations of settings (particularly
--vo=gpu-next).
If demux_open_lavf fails between calling avformat_alloc_context() and
assigning the context to priv->avfc, it will never be properly freed.
Fixes#11793.
Pass "dummy.m3u8" filename to work around FFmpeg commit
6b1f68ccb04d791f0250e05687c346a99ff47ea1 which broke their HLS demuxer
and its ability to probe.
Since the above commit, libavformat will check the filename of the file
to be probed and reject it if it doesn't end with a valid HLS extension
i.e. m3u8,hls,m3u (never mind that .hls is not a valid HLS extension).
In addition to a bug with query strings, this also breaks mpv
functionality as mpv explicitly doesn't tell libavformat the filename
when probing, in order to properly detect the file based only on their
contents.
The [HLS specification](https://www.rfc-editor.org/rfc/rfc8216.txt) aka
RFC 8216, specifies in section 4 that "Each Playlist file MUST be
identifiable either by the path component of its URI or by HTTP
Content-Type." Notably, it does not require both, so this FFmpeg commit
is noncompliant. We work around this noncompliance by checking the MIME
type ourselves. If the mimetype matches one of the valid HLS mimetypes
(and also application/x-mpegurl, a legacy pre-standardization type),
then we pass "dummy.m3u8" to libavformat in order to work around its
overly strict checking of filenames.
Without this patch, we are unable to play many HLS streams, including a
few from the ytdl hook. This patch restores those ability to play those
streams when built against FFmpeg master. Do note that if the server
sends an invalid content-type header then we cannot implement this
workaround so those streams will still fail to play.
This adds cache as a possible path for mpv to internally pick
(~/.cache/mpv for non-darwin unix-like systems, the usual config
directory for everyone else). For gpu shader cache and icc cache,
controlling whether or not to write such files is done with the new
--gpu-shader-cache and --icc-cache options respectively. Additionally,
--cache-on-disk no longer requires explicitly setting the --cache-dir
option. The old options, --cache-dir, --gpu-shader-cache-dir, and
--icc-cache-dir simply set an override for the directory to save cache
files. If unset, then the cache is saved in XDG_CACHE_HOME.
