Use the demux_set_ts_offset() added in the previous commit to base each
timeline segment to use timestamps according to its relative position
within the overall timeline. As a consequence we don't need to care
about these timestamps anymore, and everything becomes simpler.
(Another minor but delicious nugget of sanity.)
Most of this is explained in the DOCS additions.
This gives us slightly more sanity, because there is less interaction
between the various parts. The goal is getting rid of the video_offset
entirely.
The simplification extends to the user API. In particular, we don't need
to fix missing parts in the API, such as the lack for a seek command
that seeks relatively to the start time. All these things are now
transparent.
(If someone really wants to know the real timestamps/start time, new
properties would have to be added.)
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
Let's hope this doesn't confuse client API users too much. It's still
the best solution to get rid of corner cases where it actually return
the wrong timestamp on start, and then suddenly jump.
This parameter has been unused for years (the last flag was removed in
commit d658b115). Get rid of it.
This affects the general VO API, as well as the vo_opengl backend API,
so it touches a lot of files.
The VOFLAGs are still used to control OpenGL context creation, so move
them to the OpenGL backend code.
Sigh... After the recent changes, another regression appeared. This
time, the VO window wasn't cleared when changing from video to a non-
video file (such as audio-only with no cover art). Fix this by properly
taking the handle_force_window() bool parameter into account.
Also, the info message could be printed twice, which is harmless but
ugly. So just remove the message.
Also, do some more minor cleanups (like fixing the comment, which was
completely outdated).
If --force-window wasn't used, this would destroy the VO while a file
is still being loaded, resulting in flicker and other interruptions
when switching from one playlist entry to another. Recent regression.
The condition used here is pretty tricky, but it boils down to that it
should trigger either in idle mode, or when loading has been fully done
(at these points we definitely know whether the VO will be needed).
The previous commit was incomplete (and I didn't notice due to a broken
test procedure).
The annoying part is that actually creating the VO was separate; redo
this and merge the code for this into handle_force_window() as well.
This will also make implementing proper reaction to runtime option
changes easier. (Only the part for actually listening to option changes
is missing.)
Always compute the estimated absolute time of the seek target, and
display this as playback time during seeks.
Improves behavior with e.g. .ts files, for which we try to avoid seeks
by timestamp.
A client API user might count on the fact that audio and video outputs
have already been uninitialized. (They remain uninitialized before
entering idle mode in order to allow smooth transition to the next
playlist entry.) Since event delivery is asynchronous, this has to
happen after actually doing the uninitialization, or the client will
essentially run into a race condition.
Instead, force everyone to use the metadata struct and set a "title"
field. This is only a problem for the timeline producers, which set up
chapters manually. (They do this because a timeline is a separate
struct.)
This fixes the behavior of the chapter-metadata property, which never
returned a "title" property for e.g. ordered chapters.
Nobody wanted to restore this, so it gets the boot.
If anyone still wants to volunteer to restore menu support, this would
be welcome. (I might even try it myself if I feel masochistic and like
wasting a lot of time for nothing.) But if it does get restored, it
should be done differently. There were many stupid things about how it
was done. For example, it somehow tried to pull mp_nav_events through
all the layers (including needing to "buffer" them in the demuxer),
which was needlessly complicated. It could be done simpler.
This code was already inactive, so this commit actually changes nothing.
Also keep in mind that normal DVD/BD playback still works.
mp_seek_chapter() had only 1 caller. Also the code was rather
roundabout; the entire function can be compressed to 5 lines of code.
(The new code is functionally the same - "mpctx->last_chapter_seek =
-2;" was effectively a dead assingment.)
This is a real pain: if a quit command is received, it's set to PT_QUIT.
And then other code could overwrite it, making it not quit. The annoying
bit is that stop_play is written and read in many places. Just not
overwriting it unconditionally seems to be the best course of action.
500ms is a bit too high. Change it to 50ms. This improves client API
(and Lua) playback state update frequency.
Updating absolutely every time the audio PTS changes would be possible,
but is not helpful. Audio samplerates are high to trigger a wakeup
feedback loop, so the process would waste CPU time on updating the
playback position all the time.
(If a client application wants to ensure smooth update of the playback
position, it should update the position manually using a timer and by
reading the property - the application can make a much better decision
at how often the playback has to happen.)
The previous behavior is confusing if the B point is near EOF (consider
B being the duration of the file, which is strictly speaking past the
last video timestamp). The new behavior is fine as well for B being far
past EOF.
Achieve this by checking the EOF state in addition to whether playback
has reached the B point. Also, move the A-B loop code out of
command_event(). It just isn't useful anymore, and obfuscates the code
more than it makes it loop simple.
Fixes#2046.
Seems logical.
Note that if playback otherwise ends while playback is active and a seek
is still queued, we still exit. Otherwise you couldn't end playback by
seeking past the end of the file (which is classic MPlayer and mpv
behavior).
During seeking, and there is momemtarily no new data available yet, the
player will display the seek target as current time. Clamp this time to
the known time range as implied by the start time and the duration of
the file.
This improves behavior especially when seeking in audio files, for which
this for some reason triggers rather often. There were some users
complaining about this.
This makes behavior worse for files with timestamp resets, or
incorrectly reported duration. (The latter is relatively common,
e.g. libavformat shortcomings, or incomplete files.)
The options don't change, but they're now declared and used privately by
demux_mkv.c. This also brings with it a minor refactor of the subpreroll
seek handling - merge the code from playloop.c into demux_mkv.c. The
change in demux.c is pretty much equivalent as well.
Treat an empty string as unset. The fact that the option values can be
NULL is merely weirdness due to how the option parser works (it
unfortunately doesn't initialize string fields to non-NULL).
The way the AO wakes up the playloop has nothing to do with events;
instead we must query the events on the AO once the playloop was woken
up. Querying the events in every playloop iteration is thus the correct
way to do this.
Requested. See manpage additions.
This also makes the magical loop_times constants slightly saner, but
shouldn't change the semantics of any existing --loop option values.
...into its own functions. The central playloop function is still too
big, but looks much cleaner now.
No changes in functionality. The code moved to handle_playback_restart()
is unindented by 1 level and moving it out of the if condition around.
The if condition is inverted and early-exits from the function. Also
some comments are changed.
This was subtly broken by commit a937ba20. Instead of framestepping over
the timeline segment boundary, it would just unpause playback, because
seeking now resets mpctx->step_frames. This was especially apparent when
doing something like "mpv *.jpg --merge-files".
Fix by restoring the step_frames field specifically if the seek is done
for switching segment boundaries. Hopefully the number fields which need
such an exception on seeking won't grow and turn this code into a mess.
`core-idle` depends on seeking state `mpctx->restart_complete`,
so make `core-idle` notified whenever `seeking` is notified, too.
`paused-for-cache` can be changed on MPV_EVENT_CACHE_UPDATE obviously.
Finally, `MPV_EVENT_PLAYBACK_RESTART` should be notified after
`mpctx->restart_complete` changed.
Pass through the seek flags to the stream layer. The STREAM_CTRL
semantics become a bit awkward, but that's still the least awkward
part about optical disc media.
Make demux_disc.c request relative seeks. Now the player will use
relative seeks if the user sends relative seek commands, and the
demuxer announces it wants these by setting rel_seeks to true. This
change probably changes seek behavior for dvd, dvdnav, bluray, cdda,
and possibly makes seeking useless if the demuxer-cache is set to
a high value.
Will be used in the next commit. (Split to make reverting the next
commit easier.)
The percent-pos property normally goes by time, except for file formats
like .ts or .ogg, where you can't trust the timestamps and duration info
to compute the position in the overall files. These use the byte
position and size instead.
When the file position was unavailable (e.g. due to an ongoing seek),
the percent-pos was unknown. Change it to use the time position instead.
In most cases, it's actually accurate enough, and the temporary
unavailability of the property can be annoying, e.g. on the terminal
status line.
There are currently 568 pixel formats (actually fewer, but the namespace
is this big), and for each format elaborate synchronization was done to
call it synchronously on the VO. This is completely unnecessary, and we
can do with just a single call.
If a file (or a demuxer) is broken, seeking close to the end of the file
doesn't work, and seek_to_last_frame() will be called over and over
again, burning CPU for no reason.
Observed with incomplete mp4 files. That this can happen was already
mentioned in commit 090f6cfc, but I guess now I'll do something against
it.
hrseek_lastframe is cleared by reset_playback_state(), so it's only set
if seek_to_last_frame() was called, and no other seek happened since
then. If finding the last frame succeeds, no EOF will happen (unless the
user unpauses, but then it will simply remain at the last frame). If it
fails, then it will return immediately, without retrying.
The --keep-open behavior was recently changed to act only on the last
file due to user requests (see commit 735a9c39). But the old behavior
was useful too, so bring it back as an additional mode.
Fixes#1332 (or rather, should help with it).
There were complaints that a chapter seek past the last chapter was
quitting the player. Change the behavior to what is expected: the last
frame.
If no chapters are available, this still does nothing.
It feels strange that seeking past EOF with --keep-open actually leaves
the player at a random position. You can't even unpause, because the
demuxer is in the EOF state, and what you see on screen is just what was
around before the seek.
Improve this by attempting to seek to the last video frame if EOF
happens. We explicitly don't do this if EOF was reached normally to
increase robustness (if the VO got a frame since the last seek, it
obviously means we had normal playback before EOF).
If an error happens when trying to find the last frame (such as not
actually finding a last frame because e.g. the demuxer misbehaves), this
will probably turn your CPU into a heater. There is no logic to prevent
reinitiating the last-frame search if the last-frame search reached EOF.
(Pausing usually prevents that EOF is reached again after a successful
last-frame search.)
Fixes#819.
I don't know why this done; most likely it had no real reason.
Remove it because it breaks "refresh seeks" to the same position.
(Although the refresh seeks mpv sometimes does were fine.)
Ordered chapter EOF was handled as special-case of ending the last
segment. This broke --kee-open, because it set AT_END_OF_FILE in an
"inconvenient" place (after checking for --keep-open, and before the
code that exits playback if EOF is reached).
We don't actually need to handle the last segment specially. Instead, we
remain in the same segment if it ends. The normal playback logic will
recognize EOF, because the end of the segment "cuts off" the file.
Now timeline_set_from_time() never "fails", and we can remove the old
segment EOF handling code in mp_seek().
Add a generic mechanism to the VO to relay "extra" events from VO to
player. Use it to notify the core of window resizes, which in turn will
be used to mark all affected properties ("window-scale" in this case) as
changed.
(I refrained from hacking this as internal command into input_ctx, or to
poll the state change, etc. - but in the end, maybe it would be best to
actually pass the client API context directly to the places where events
can happen.)
