Packet pool is useful to avoid work and additional allocations when
switching files, going to idle should free the pool as those packets may
not be used for some time.
Fixes: #17525
813c112329 moved force window to option
callback. This happens before the loading of the file has finished
(which is supposed to trigger handle_force_window) so it is too early to
handle certain cases, such as loading of album art failed and therefore
window will never be created because there is no video track.
Adding force window check in playloop to make sure window is always
initialized after file loading is complete.
Fixes: 813c112329
This fixes a race condition where if a non-chapter seek is queued
immediately after a chapter seek is queued, the chapter property may
become unavailable until a new file is loaded.
If multiple seeks are queued within the same playloop iteration, only
the last seek is executed. Because the chapter seek is never executed,
last_chapter_flag remains set and last_chapter_seek becomes -2, which
causes get_current_chapter to return -2, which makes the chapter
property unavailable.
Unset this (and also last_chapter_seek) immediately rather than
wait for seek execution, like chapter seeks set these immediately.
Fixes: 233f1e46f6 ("playloop: make chapter property more accurate when seeking chapters")
handle_force_window() is called in play_current_file() and
run_playloop(), so it is never triggered if you do mpv --idle and then
change force-window at runtime. Move the playloop call to the option
callbacks to fix this.
Fixes https://github.com/mpv-player/mpv/discussions/16956.
Giving the UPDATE_VO flag to --force-window would not fix this due to it
having no effect if there's isn't already a window, which prevents the
bug described in 544240c829. It would also reinit the VO unnecessarily
when cycling between force-window yes and immediate.
MP_EVENT_INPUT_PROCESSED is used to notify mouse and touch position
updates, but it is currently notified for all input commands even when
they have nothing to do with mouse position. This results in unnecessary
acquisition and comparision of mouse and touch positions for all commands.
Optimize this by checking whether the command is marked as requiring the
event notification, and only notify if that is true.
This relaxes what bbac628a1b introduced.
Although it is rare, there may be scripts out there that depend on the
old timing. We'd still like to process config files in a sane manner and
not cause OOMs so keep the general coalescing mechanism in place but use
it selectively. There is one special case with the --input-commands
option. We want this coalesced as well so some special handling needs to
be added for that.
Need to shuffle some stuff around but it's pretty simple. Mute the
audio stream before the frame step and then unmute it when we're done.
It's exactly the same as the default play mode otherwise.
The refactoring in bbac628a1b missed that
the initial update handler didn't immediately run all the triggered
callbacks but would instead delay it until the next playloop. This
subtly breaks things of course like hooks, force window handling, etc.
Ensure that we immediately run all the callbacks like before on startup.
Fixes bbac628a1b
Fixes https://github.com/mpv-player/mpv/pull/15828#issuecomment-2663830477
The big option callback in player/command will trigger on every single
update. This is not so great when several heavy option changes are
called in rapid succession and operations are pointlessly repeated. Try
to copy the approach that input commands do and run the actual callbacks
during the playloop. This is not really a smart or sophisticated
mechanism. It also only works for the main option cache. In theory,
other option caches like vo_opts could get spammed too and this makes no
attempt on those. But regardless, this is probably good enough for us.
mp_option_change_callback now tries to group together any new callbacks
with existing unprocessed ones and drop redundant ones whenever
something new arrives.
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.
This adds a clipboard monitoring API for backends which use polling
to monitor clipboard updates. --clipboard-monitor option can turn
clipboard monitoring on and off at runtime.
Putting this in handle_osd_redraw was strange and my own comments didn't
help me remember what this was even for. The actual purpose here is that
the osd needs to be redrawn in the still image edge case as you go
through a playlist. This is because all the logic with checking
timestamps isn't applicable and we need to essentially clear the screen
with another redraw. Clearly, it makes more sense for this to be done
when a new file is successfully loaded and not in the osd_redraw where
that happens to work but was called repeatedly pointlessly.
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.
Except for MP_NOPTS_VALUE. We keep that as is. When this was originally
added in a73415584c, it appears like
having the time always start at 0 was the intent. In cases where
get_current_time returns a negative that isn't MP_NOPTS_VALUE, force
this to 0.
Fix the bug that seeking to the end of cover art while paused goes back
to the beginning of the file because of this condition meant for videos.
This doesn't check mpctx->vo_chain->is_sparse because prevent_eof should
be true with actual sparse videos.
handle_osd_redraw is called while we're in the middle of the cleanup portion
of play_current_file (via kill_demuxers_reentrant and mp_idle). This happens
after we've torn down the subtitle track, so we end up requesting a redraw
from the vo, which results in a 1-frame flash of the video without subs
before we either quit or switch to the next file (or the force-window state).
This detects that condition and skips the redraw, without interfering with
drawing the osd during idle (eg for pseudo-gui mode).
In various edge cases, this causes an assertion that was added later in
8816e1117e to be hit. The actual purpose
of the special case is not really clear. mp_seek already will change the
mpctx->stop_play value, so there shouldn't be any need to do it in
queue_seek. And it is known to cause problems so revert it. Also, remove
the special play direction logic that works around this behavior.
Fixes#13778.
This reverts commit dbdc46c97a.
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.
Basically a simple way to perform any command/property action from the
command line. This takes the exact same syntax as input.conf but not
including the key naturally. Potentially useful for weird properties
that don't map well to options (like ao-volume). Fixes#12353.
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.
ca2b05c0fb changed the window size with --force-window and no video
tracks to be closer to 16:9, but I don't see why we shouldn't have an
actual 16:9 ratio. The advantage is that subtitles with fullscreen and
no video tracks will have the same size and position (depending on the
values of --sub-scale-with-window and --sub-use-margins) as with 16:9
videos, because there will be no (invisible) black bars.
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.
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.
External subtitles are always read as eager, so they do not need to be
changed on pause/unpause. Don't do the refresh seek since it will just
buffer forever. Fixes 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.
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.
We should account for ao queue when setting playback position on EOF,
previously we were using the pts value corresponding to the start of
the ao queue, rather than the currently playing audio.
This fixes time-remaining being a negative number when mpv seeks to EOF
while playback is paused.
There's an edge cause with gapless audio and pausing. Since, gapless
audio works by sending an EOF immediately, it's possible to pause on the
next file before audio actually finishes playing and thus the sound gets
cut off. The fix is to simply just always do an ao_drain if the ao is
about to set a pause on EOF and we still have audio playing.
Fixes#8898.
In debug mode the macro causes an assertion failure.
In release mode it works differently and tells the compiler that it can
assume the codepath will never execute. For this reason I was conversative
in replacing it, e.g. in mpv-internal code that exhausts all valid values
of an enum or when a condition is clear from directly preceding code.
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).
Normally with the keep-open option, mpv is supposed to set the
eof-reached property to true so clients can possibly do interesting
things at this step. However, there was actually an edge case where this
property notification did not occur. If you use keep-open and then seek
in the file past the end (so mpv stops), property notification is not
actually sent in this case. Internally, mpv does a very exact seek at
this step which also ends playback, but it does not set STATUS_EOF to
the ao and vo before the core idle state is updated. To fix this edge
case, it's simply just a matter of explictly setting STATUS_EOF after
seek_to_last_frame in handle_keep_open. This logic will only ever
trigger if keep-open is being used and the seek goes past the end of the
file, so we know that there will always be an EOF here.
The stop-screensaver option is currently limited to a simple yes/no
option. While the no option does always disable mpv trying to stop the
screensaver, yes does not mean the screensaver is always stopped. The
screensaver will be enabled again depending on certain conditions (like
if the player is paused). Simply introduce a new value for this option,
always, which does exactly what the name implies: the screensaver will
always be disabled.
Was tripping -Wparantheses as the && after the || was not explicitly
wrapped. However, due to operator precedence the intended effect was
still correct.
Not all deprecated symbols were removed. Only three events were removed for now
since these are not used internally.
This bumps the library version to 2.0.
Allow --keep-open=always to work with --loop-playlist, where
before this patch it would work only on the last playthrough of the
playlist. This patch allows it to work on all playthroughs.
Fixes#9470.
Kacper Michajłow