Caused by one of the --force-window commits. The unconditional
uninit_video_out() call (which normally should be idempotent) raised
sporadic MPV_EVENT_VIDEO_RECONFIG events. This is ok, except for the
fact that clients (like a Lua script or libmpv users) would cause the
event loop to run again after receiving it, triggering a feedback loop.
Fix it by sending the events really only on a change.
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).
This was in sub/, because the code used to be specific to subtitles. It
was extended to automatically load external audio files too, and moving
the file and renaming it was long overdue.
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.)
This is a bad hack; the correct way to handle this would be implementing
profiles differently, and then listen to option changes and act on them
dynamically.
The value 0 was treated specially, and effectively forced the increment
to 1. Interestingly, passing 0 or no value also does not include the
scale (from touchpads etc.), but this is probably an accidental behavior
that was never intentionally added.
Simplify it and make the default increment 1. 0 now means what it
should: the value will not be changed. This is not particularly useful,
but on the other hand there is no need for surprising and unintuitive
semantics.
OARG_CYCLEDIR() failed to apply the default value, because
m_option_type_cycle_dir was missing a copy handler - add this too.
Until now, most OSD objects created the associated ASS_Renderer instance
as soon as possible, even if nothing was going to be rendered. Maybe
this was even intentional.
Change this for the sake of lowering resource usage, and strictly
initialize ASS_Renderer only when it's really needed.
For the OSC, initialization has to be forced, because of the insane
mechanism for translating mouse coordinates to OSD coordinates.
This was completely broken. It was checked manually in some config
loading paths, so it appeared to work. But the intention was always to
completely disable reading from the normal config dir. This logic was
broken in commit 2263f37d.
The manual checks are actually redundant, and are not needed if
--no-config is implemented properly - remove them.
Additionally, the change to load the libmpv defaults from an embedded
profile also failed to set "config=no". The option is marked as not
being settable by a config file, and the libmpv default profile is
parsed as a config file, so this option was rejected. Fix it by removing
the CONF_NOCFG flag. (Alternatively, m_config_set_profile() could be
changed not to set the "config file" flag by default, but I'm not
bothering with this.)
Previously, with mpv --force-window=yes --idle=yes --screenshot-template="%f",
mpv would display an error saying that the template was incorrect, which it
isn't, there's just no file to put in the format. In this case, just use the
string "NO_FILE".
This takes care of the corner case where the player is started with a
single playlist entry so that the next/prev arrows are greyed out, but
remain that way even after new elements are added to the playlist.
Even after it has been disabled with the `disable-osc` message, the OSC
continues to run the tick function. Completely preventing tick from
being called is impractical since there are several different places
that it's called in the code, so just make it immediately return if the
OSC has been disabled.
This prevents the OSC from continuing the clear the OSD on every tick,
allowing other scripts to disable it so that they may draw to the OSD.
This should avoid unnecessary sleeping when audio playback start resync
has finished and goes into the normal playback state.
This is tricky; see e.g. commit 402fe381.
Provides a simplistic way to seek without having to care about weird
situations like timestamp vs. playback time. This is good, because the
seek command is currently timestamp based, so when using the seek
command the user _does_ have to care.
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.
enable_key_bindings()/disable_key_bindings() now prints a log message on
each call, thus we should avoid makign redundant calls.
This could probably be solved more elegantly, but since this is all
legacy/private API, don't bother.
If this mode is enabled, the player tries to strictly synchronize video
to display refresh. It will adjust playback speed to match the display,
so if you play 23.976 fps video on a 24 Hz screen, playback speed is
increased by approximately 1/1000. Audio wll be resampled to keep up
with playback.
This is different from the default sync mode, which will sync video to
audio, with the consequence that video might skip or repeat a frame once
in a while to make video keep up with audio.
This is still unpolished. There are some major problems as well; in
particular, mkv VFR files won't work well. The reason is that Matroska
is terrible and rounds timestamps to milliseconds. This makes it rather
hard to guess the framerate of a section of video that is playing. We
could probably fix this by just accepting jittery timestamps (instead
of explicitly disabling the sync code in this case), but I'm not ready
to accept such a solution yet.
Another issue is that we are extremely reliant on OS video and audio
APIs working in an expected manner, which of course is not too often
the case. Consequently, the new sync mode is a bit fragile.
For video sync, we want separate playback speed controls for user-
requested speed and the "correction" speed for video timing. Further, we
use this separation to make sure only a resampler is inserted if
playback speed is only changed for video sync correction.
As of this commit, this is basically inactive code. It's just
preparation for the video sync code (the following commit).
Additionally to taking the average, this tries to use the demuxer FPS to
eliminate jitter, and applies some other heuristics to check if the
result is sane.
This code will also be used for the display sync code (it will actually
make use of the require_exact parameter).
(The value of doing this over keeping the simpler demux_mkv hack is
somewhat questionable. But at least it allows us to deal with other
container formats that use jittery timestamps, such as mp4 remuxed
from mkv.)
Removes some more internal API calls from the Lua scripting backend.
Which is good, because ideally the scripting backend would use libmpv
functions only.
One awkwardness is that mouse sections are still not supported by the
public commands (and probably will never), so flags like allow-hide-
cursor make no sense to an outside user.
Also, the way flags are passed to the Lua function changes. But that's
ok, because they're only undocumented internal functions, and not
supposed to be used by script users. osc.lua only does due to historical
reasons.
This was requested. It was more or less present internally already and
used for Lua scripting. Lua will switch to the "public" functions in
the following commits.
Now it can always be read. Normally returns the value of the video-
aspect option. Writing it sets the option. If the aspect is not forced,
it will attempt to return whatever is the current video aspect.
Instead of opening a stream and then a demuxer, do both at once with
demux_open_url().
This requires some awkward additions to demuxer_params, because there
are some weird features associated with opening the main file. E.g. the
relatively useless --stream-capture features requires enabling capturing
on the stream before the demuxer is opened, but on the other hand
shouldn't be done on secondary files like external subtitles.
Also relatively bad: since demux_open_url() returns just a demuxer
pointer or NULL, additional error reporting is done via demuxer_params.
Still, at least conceptually, it's ok, and simpler than before.
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.
Normally when there's a timestamp reset, we make audio resync to make
sure audio and video line up (again). But in video-only mode, just
setting audio to resyncing breaks EOF detection, because there's no code
which would get audio_status out of this bogus state.
Commit c5818046 fixed one case of audio EOF handling, and caused a new
one. This time, the ao_buffer doesn't actually contain everyting that
should be played - because if --end is used, only a part of it is
played. Of course this is stupid, and it will be changed later. For now,
this smaller change fixes the bug.
Fixes#2189.
time_frame is when the next video frame should be shown. It's normally
overwritten by the video timing code. This also says something about
"nosound mode" (--no-audio today), but at least these days we don't use
it at all if video is disabled.
Remove it; it likely has no function at all.
