Previously, the default behavior of frame-step and frame-back-step is to
play forward 1 frame or seek back 1 frame. We keep this behavior but
introduce additional flags to control the exact behavior of the frame
stepping. The first argument simply specifies how many frames to go
through. The second argument specifies whether to play video to step
through frames or to seek to step through frames. Playing through the
video to step through frames only works going forwards (otherwise it
will always seek). In theory we could use backwards playback for this,
but that can be decided later.
As a minor note, MPSEEK_BACKSTEP is renamed to MPSEEK_FRAMESTEP since
forward seeks can use this as well. Fixes#10128.
When using --prefetch-playlist, if demuxer options are changed in the
time window between the start of prefetching and the playback of the
next file, the old values are used. This includes setting demuxer
options in legacy extension auto profiles.
Fix this by setting a flag when demuxer options change and not using the
prefetched data when that flag is true.
UPDATE_DEMUXER is not added to demux.c's options because those already
support updates while playing.
With --prefetch-playlist and --loop-playlist, mp_next_file() is called
continously since the last second of playback or when viewing an image,
which decreases --loop-playlist=N to 1.
Fix this by adding a flag to mp_next_file() to specify whether to
decrement --loop-playlist=N. The first playlist entry is still
prefetched when it's the next one, but without decrementing
--loop-playlist=N.
This adds a clipboard API with multiple backend and format support.
--clipboard-enable option can be toggled at runtime to turn native
clipboard on and off.
Waiting for audio_started to be set to true takes too long which causes
us to miss it for the first frame, instead invert the condition so it's
set on the first frame.
Fixes#14615
Follow up to the previous commit. Stop decreasing --ab-loop-count=N on
each iteration so it is preserved across different loops. In particular
it is preserved between different files without adding it to
--reset-on-next-file. Add a property to expose the remaning A-B loop
count instead.
The current behavior of --ab-loop-count=N is even worse than --loop-file
since it also doesn't reset when defining a new A-B loop in the same
file. Defining it has no effect after --ab-loop-count has decreased to
0, and this can't be fixed by adding it to --reset-on-next-file. This
commit also resets remaining-ab-loops every time --ab-loop-a and
--ab-loop-b are set to fix this.
This change removes convoluted core thread extraction through dispatch
added in 500ce69a06.
Currently we fully control this thread, create it and join, there is no
reason not to keep the handle of it in the player context.
As a bonus to code simplification this also fixes thread handle leak on
Windows.
Fixes: #14472
This adds script messages to select playlist entries, tracks, chapters,
subtitle lines, bindings and properties using the newly introduced
mp.input.select().
This fully closes#13964.
If the player is paused, switching subtitle track requires us to read
subs packets for an indefinite amount of time in order to actually
display the subtitles. The problem with this is that it puts a blocking
loop in the play thread which can be slow in cases where it takes a long
time to fetch the subtitle (e.g. over a network).
9e27b1f523 alleviates this when a pause
happens because of buffering, but it's not complete. One could encounter
this if the user pauses the video first manually and then switches the
subtitle track.
To solve this better, make it so the loop has a time out (totally
arbitrary number) so the player isn't blocked forever. If subtitles are
not fetched within that time, we flag the track and try again later in
the playloop.
Ended up being too flawed and caused trouble in other areas. There's
other approaches to trying to solve the issue this meant to address in
the works that should be better, so let's wait on that. Fixes#13613 and
fixes#13622.
This reverts commit e3af545421.
This seems more robust than relying on the audio status to actually be
playing. For files where there is no audio or the audio start is
delayed, this guards against that but it allows the subtraction to
always occur otherwise on normal files with audio.
Ended up being a bad idea. As a property, this inherently has more
functionality and the tradeoff of being able to do --ao-volume wasn't
worth it.
This reverts commit 58ed620c06.
Playback speed changes should be treated as a discontinuity just like
seeking. Previously, this was being treated internally as just plain
normal playback, but that can't really work. The frame timings from
before the speed change and after the speed change are completely
different and shouldn't be compared to each other. This lead to frames
being adjusted to weird places and possibly even being skipped (as if
mpv was seeking) on speed changes. What we should do is clear out and
reset all av related fields like what happens when you seek, but it is
not quite as aggressive. No need to do a full video state reset or such.
We also wait an arbitrary amount of frames before adjusting for av sync
again. compute_audio_drift already used a magic number of 10 which
sounds reasonable enough so define that and use it here. Fixes#13513.
There's too many dumb options related to subtitles which have annoying
edge cases. Try to rewrite this completely so it hopefully behaves
normally in every expected scenario. A key goal here is be smarter while
looping through the tracks and avoid selecting the subtitle if it
doesn't meet user's passed options as opposed to clearing the pick after
the fact. Fixes#13280 and fixes#13263.
This only affects two special cases: printing subtitles to the terminal
and printing subtitles on a still picture. Previously, mpv was very dumb
here and spammed this logic on every single loop. For terminal
subtitles, this isn't as big of a deal, but for the image case this is
pretty bad. The entire VO constantly redrew even when there was no need
to which can be very expensive depending on user settings.
Instead, let's rework sub_read_packets so that it also tells us whether
or not the subtitle packets update in some way in addition to telling us
whether or not to read more. Since we cache all packets thanks to the
previous commit, we can leverage this information to make a guess
whether or not the current subtitle packet is supposed to be visible on
the screen. Because the redraw now only happens when it is needed, the
mp_set_timeout_hack can be removed.
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.
e277fadd60 originally added this but it
never actually did anything in the function... wm4 probably changed his
mind but forget to delete it so just remove it here.
When seeking chapters, `last_chapter_seek` acts as a projection of
what the current chapter will be once mpv has a chance to seek to it.
This allows for more accurate results from the `chapter` property.
It works by comparing the projection to the actual current chapter
and returning the larger of the two indexes, but this only works when
seeking forward.
If we want it to work for both forward and backward chapter seeking,
we can instead use a boolean called `last_chapter_flag`, which gets
switched on when a chapter seek request is made, and then
switched off when the seek has been performed.
We should also check to ensure that we don't allow the chapter index
to be set to -1 unless there is a span of time between the very
beginning of the track and the start of the first chapter.
Since the new approach to resetting `last_chapter_seek` no longer
depends on `last_chapter_pts`, that member variable can be removed.
No wonder wm4 wanted to get rid of this. This option requires touching a
bunch of crap in the core player code. --stream-record works perfectly
fine and is a lot nicer so there's no need for this to exist anymore.
First of all, this never worked. Or if it ever did, it was in some
select few scenarios. c9474dc9ed is what
originally added support for the auto choice. However, that commit
worked by propagating a value to a fake option used internally. This
shouldn't have ever worked because the underlying m_config_cache was
never updated so the value shouldn't have been preserved when accessed
in sd_lavc. And indeed with some testing, the value there is always 0
unsurprisingly.
This was later rewritten in ba7cc07106
along with a lot of other sub changes, but with that, it was still
mostly broken. The reason is because one of the key parts of having to
hit this logic (prefer_forced) required `--no-subs-with-matching-audio`
to be set. If the audio language matches the subtitle language (the
requirement also excludes forced subs), the option makes no subtitle
selection in the first place so pick->forced_only_def is not set to true
and nothing even happens. Another way around this would be to attempt to
change your OS language (like with the LANG environment variable) so
that the subtitle track gets selected but then audio_matches mistakenly
becomes false because it compares the OS language to the audio language
which then make preferred_forced 0, so nothing happens. I don't think
there's a scenario where pick->forced_only_def is actually set to true
(thus meaning `auto` is useless), but maybe someone could contrive
something very strange. Regardless, it's definitely not something even
remotely common.
fbe8f99194 changed track selection again
but didn't consider this particular case. The net result is that DVD/PGS
subs become equivalent to --sub-forced-only being yes, so this a change
in behavior and probably not a good one. Note that I wasn't able to
actually observe any difference in a PGS sample. It still displayed
subtitles fine but that sample probably didn't have the right flags to
hit the sub-forced-only logic.
Anyways, the auto feature is extremely questionable at best and in my
view, not actually worth it. It is meant to be used with
`--no-subs-with-matching-audio` to display forced pictures in subtitle
tracks that are not marked as forced, but that contradicts that
particular option's purpose and description in the manual (secretly
selecting a track under certain conditions even though it says not to).
Instead of trying to shove all this logic into select_default_track
which is already insanely complicated as it is, recognize that this is a
trivial lua script. If you absolutely want to turn --sub-forced-only on
under these certain conditions (DVD/PGS subtitles, matching audio and
subtitle languages, etc.), just look at the current-tracks property and
do your thing. The very, very niche behavior that this option tried to
accomplish basically never worked, no user even knows what this option
does, and well it's just not worth supporting in core mpv code. Drop
all this code for sanity's sake and change --sub-forced-only back to a
bool.
There are a number of ways one can craft a playlist file that refers to
itself or cleverly goes around in a loop to other playlist files. There
is obviously no use for this, but mpv spins around forever trying to
load the files so you have to just SIGTERM/SIGKILL it. We can be smarter
about this and attempt to detect it. The condition for detecting this is
surprisingly simple: the filename of the first entry in the playlist
must match a previous playlist path we stored. If we get this, we can
then log an error and stop playback. If there is a "real" file loaded at
any point in time, then we know it's not an infinite loop and clear out
the saved playlist paths. Fixes#3967.
When playing a sparse video stream, the debug log gets hit with the
video EOF constantly since the audio is still playing. There's no
practical use for this so just do add some logic to only signal it once
if it is sparse.
Currently, mpv immediately deletes the watch_later file after an attempt
at playing the file is made. This is not really ideal because the file
may fail to load for a variety of reasons (including not even existing),
but the state is cleared anyway unconditionally. Instead, just wait
until after playback is successfully initialized before deleting it.
This way silly mistakes like forgetting to mount the drive doesn't
result in deleting your watch_later data. Fixes#3427.
A pain point for some users is the fact that watch_later is stored in
the ~/.config directory when it's really not configuration data. Roughly
2 years ago, XDG_STATE_DIR was added to the XDG Base Directory
Specification[0] and its description, user-specific state data, actually
perfectly matches what watch_later data is for. Let's go ahead and use
this directory as the default for watch_later. This change only affects
non-darwin unix-like systems (i.e. Linux, BSDs, etc.). The directory
doesn't move for anyone else.
Internally, quite a few things change with regards to the path
selection. If the platform in question does not have a statedir concept,
then the path selection will simply return "home" instead (old
behavior). Fixes#9147.
[0]: https://gitlab.freedesktop.org/xdg/xdg-specs/-/commit/4f2884e16db35f2962d9b64312917c81be5cb54b
mpv's core already keeps track of whether or not it thinks a track is an
image. Some VOs (i.e. wayland) would benefit from knowing if what is
currently being displayed is an image or not so add a new VOCTRL that
signals this anytime we load a new file with a VO. Additionally, let's
add a helper enum for signaling the kind of content that is being
displayed. There is now MP_CONTENT_NONE (strictly for force window being
used on a track with no image/video), MP_CONTENT_IMAGE, and
MP_CONTENT_VIDEO. See the next commit for the actual usage of this (with
wayland).
The video sync logic for mpv lies completely within its core at
essentially the highest layer of abstraction. The problem with this is
that it is impossible for VOs to know what video sync mode mpv is
currently using since it has no access to the opts. Because different
video sync modes completely changes how mpv's render loop operates, it's
reasonable that a VO may want to change how it renders based on the
current mode (see the next commit for an example).
Let's just move the video sync option to mp_vo_opts. MPContext, of
course, can still access the value of the option so it only requires
minor changes in player/video.c. Additionally, move the VS_IS_DISP
define from to player/core.h to common/common.h. All VOs already have
access to common/common.h, and there's no need for them to gain access
to everything that's in player/core.h.
This exposes whether a video track is detected as an image, which is
useful for profile conditions, property expansion and lavfi-complex.
The lavf demuxer sets image to true when the existing check detects an
image.
When the lavf demuxer fails, the mf one guesses if the file is an image
by its extension, so sh->image is set to true when the mf demuxer
succeds and there's only one file.
The mkv demuxer just sets image to true for any attached picture.
The timeline demuxer just copies the value of image from source to
destination. This sets image to true for attached pictures, standalone
images and images added with !new_stream in EDL playlists, but it is
imperfect since you could concatenate multiple images in an EDL playlist
(which should be done with the mf demuxer anyway). This is good enough
anyway since the comment of the modified function already says it is
"Imperfect and arbitrary".
Unfortunately, this functionality in large part based on a struct
member that was made private in FFmpeg/FFmpeg@7489f63281
in May. Unfortunately, this was not noticed during review.
This reverts commit 0862664ac9.
This exposes whether a video track is detected as an image. This is
useful for profile conditions, property expansion and lavfi-complex, and
is more accurate than any detection even Lua scripts can perform, since
they can't differentiate between images and videos without container-fps
and audio and with duration 1 (which is the duration set by the mf
demuxer with the default --mf-fps=1).
The lavf demuxer image check is moved to where the number of frames is
available for comparison, and is modified to check the number of frames
and duration instead of the video codec. This doesn't misdetect videos
in a codec commonly used for images (e.g. mjpeg) as images, and can
detect images in a codec commonly used for videos (e.g. 1-frame gifs).
pix files are also now detected as images, while before they weren't
since the condition was checking if the AVInputFormat name ends with
_pipe, and alias_pix doesn't.
Both nb_frames and codec_info_nb_frames are checked because nb_frames is
0 for some video codecs (hevc, av1, vc1, mpeg1video, vp9 if forcing
--demuxer=lavf), and codec_info_nb_frames is 1 for others (mpeg, mpeg4,
wmv3).
The duration is checked as well because for some uncommon codecs and
containers found in FFMpeg's FATE suite, libavformat returns nb_frames =
0 and codec_info_nb_frames = 1. For some of them it even returns
duration = 0, so they are blacklisted in order to never be considered
images.
The extra codecs that would have to be blacklisted without checking the
duration are AV_CODEC_ID_4XM, AV_CODEC_ID_BINKVIDEO,
AV_CODEC_ID_DSICINVIDEO, AV_CODEC_ID_ESCAPE130, AV_CODEC_ID_MMVIDEO,
AV_CODEC_ID_NUV, AV_CODEC_ID_RL2, AV_CODEC_ID_SMACKVIDEO and
AV_CODEC_ID_XAN_WC3, while the containers are film-cpk, ivf and ogg.
The lower limit for duration is 10 because that's the duration of
1-frame gifs.
Streams with codec_info_nb_frames 0 are not considered images because
vp9 and av1 have nb_frames = 0 and codec_info_nb_frames = 0, and we
can't rely on just the duration to detect them because they could be
livestreams without an initial duration, and actually even if we could
for these codecs libavformat returns huge negative durations like
-9223372036854775808.
Some more images in the FATE suite that are really frames cut from a
video in an uncommon codec and container, like cine/bayer_gbrg8.cine,
could be detected by allowing codec_info_nb_frames = 0, but then any
present and future video codec with nb_frames = 0 and
codec_info_nb_frames = 0 would need to be added to the blacklist. Some
even have duration > 10, so to detect these images the duration check
would have to be removed, and all the previously mentioned extra codecs
and containers would have to be added added to the blacklists, which
means that images that use them (if they exist anywhere) will never be
detected. These FATE images aren't detected as such by mediainfo either
anyway, nor can a Lua script reliably detect them as images since they
have container-fps and duration > 0 and != 1, and you probably will
never see files like them anywhere else.
For attached pictures the lavf demuxer always set image to true, which
is necessary because they have duration > 10. There is a minor change in
behavior for which audio with attached pictures now has mf-fps as
container-fps instead of unavailable, but this makes it consistent with
external cover art, which was already being assigned mf-fps.
When the lavf demuxer fails, the mf one guesses if the file is an image
by its extension, so sh->image is set to true when the mf demuxer
succeds and there's only one file.
Even if you add a video's file type to --mf-type and open it with the mf
protocol, only the first frame is used, so setting image to true is
still accurate.
When converting an image to the extensions listed in demux/demux_mf.c,
tga and pam files are currently the only ones detected by the mf demuxer
rather than lavf. Actually they are detected with the image2 format, but
it is blacklisted; see d0fee0ac33.
The mkv demuxer just sets image to true for any attached picture.
The timeline demuxer just copies the value of image from source to
destination. This sets image to true for attached pictures, standalone
images and images added with !new_stream in EDL playlists, but it is
imperfect since you could concatenate multiple images in an EDL playlist
(which should be done with the mf demuxer anyway). This is good enough
anyway since the comment of the modified function already says it is
"Imperfect and arbitrary".
This allows configuring which options are saved by quit-watch-later.
Fixes#4126, #4641 and #5567.
Toggling a video or audio filter twice would treat the option as changed
because the backup value is NULL, and the current value of vf/af is a
list with one empty item, so obj_settings_list_equal had to be changed.
Now loading cover art through mp_add_external_file requires an
additional argument to be set to true. This way not all video-add
commands end up being marked as cover art when they move through
mp_add_external_file, as originally changed in 55d7f9ded1 .
Additionally, this lets us clean up some logic that would otherwise be
duplicated between open_external_files and autoload_external_files, if
the logic had been kept split from mp_add_external_file.
Fixes#8358
Dudemanguy