This was always a legacy thing. Remove it by applying an orgy of
mp_get_config_group() calls, and sometimes m_config_cache_alloc() or
mp_read_option_raw().
win32 changes untested.
Until now, stopping playback aborted the demuxer and I/O layer violently
by signaling mp_cancel (bound to libavformat's AVIOInterruptCB
mechanism). Change it to try closing them gracefully.
The main purpose is to silence those libavformat errors that happen when
you request termination. Most of libavformat barely cares about the
termination mechanism (AVIOInterruptCB), and essentially it's like the
network connection is abruptly severed, or file I/O suddenly returns I/O
errors. There were issues with dumb TLS warnings, parsers complaining
about incomplete data, and some special protocols that require server
communication to gracefully disconnect.
We still want to abort it forcefully if it refuses to terminate on its
own, so a timeout is required. Users can set the timeout to 0, which
should give them the old behavior.
This also removes the old mechanism that treats certain commands (like
"quit") specially, and tries to terminate the demuxers even if the core
is currently frozen. This is for situations where the core synchronized
to the demuxer or stream layer while network is unresponsive. This in
turn can only happen due to the "program" or "cache-size" properties in
the current code (see one of the previous commits). Also, the old
mechanism doesn't fit particularly well with the new one. We wouldn't
want to abort playback immediately on a "quit" command - the new code is
all about giving it a chance to end it gracefully. We'd need some sort
of watchdog thread or something equally complicated to handle this. So
just remove it.
The change in osd.c is to prevent that it clears the status line while
waiting for termination. The normal status line code doesn't output
anything useful at this point, and the code path taken clears it, both
of which is an annoying behavior change, so just let it show the old
one.
Before this, mpctx->playing was often used to determine whether certain
new state could be added to the playback state. In particular this
affected external files (which added tracks and demuxers). The variable
was checked to prevent that they were added before the corresponding
uninit code. We want to make a small part of uninit asynchronous, but
mpctx->playing needs to stay in the place where it is. It can't be used
for this purpose anymore.
Use mpctx->stop_play instead. Make it never have the value 0 outside of
loading/playback. On unloading, it obviously has to be non-0.
Change some other code in playloop.c to use this, because it seems
slightly more correct. But mostly this is preparation for the following
commit.
Alway give each demuxer its own mp_cancel instance. This makes
management of the mp_cancel things much easier. Also, instead of having
add/remove functions for mp_cancel slaves, replace them with a simpler
to use set_parent function. Remove cancel_and_free_demuxer(), which had
mpctx as parameter only to check an assumption. With this commit,
demuxers have their own mp_cancel, so add demux_cancel_and_free() which
makes use of it.
Them being separate is just dumb. Replace them with a single
demux_free() function, and free its stream by default. Not freeing the
stream is only needed in 1 special case (demux_disc.c), use a special
flag to not free the stream in this case.
The player fully restarts playback when the edition or disk title is
changed. Before this, the player tried to reinitialized playback
partially. For example, it did not print a new "Playing: <file>"
message, and did not send playback end to libmpv users (scripts or
applications).
This playback restart code was a bit messy and could have unforeseen
interactions with various state. There have been bugs before. Since it's
a mostly cosmetic thing for an obscure feature, just change it to a full
restart. This works well, though since it may have consequences for
scripts or client API users, mention it in interface-changes.rst.
Until now, they could be aborted only by ending playback, and calling
mpv_abort_async_command didn't do anything.
This requires furthering the mess how playback abort is done. The main
reason why mp_cancel exists at all is to avoid that a "frozen" demuxer
(blocked on network I/O or whatever) cannot freeze the core. The core
should always get its way. Previously, there was a single mp_cancel
handle, that could be signaled, and all demuxers would unfreeze. With
external files, we might want to abort loading of a certain external
file, which automatically means they need a separate mp_cancel. So give
every demuxer its own mp_cancel, and "slave" it to whatever parent
mp_cancel handles aborting.
Since the mpv demuxer API conflates creating the demuxer and reading the
file headers, mp_cancel strictly need to be created before the demuxer
is created (or we couldn't abort loading). Although we give every
demuxer its own mp_cancel (as "enforced" by cancel_and_free_demuxer),
it's still rather messy to create/destroy it along with the demuxer.
This is nonsense. Didn't matter in most situations, because seeking
itself set this after it was cleared. But some callers don't do this,
see e.g. commit ed73ba8964. There is no need to clear it at all, and
it causes issues with the next commit. It only needs to be reset on
loading.
Also move the initialization on loading up, which doesn't change
behavior, but makes the intention clearer.
This affects async commands started by client API, commands with async
capability run in a sync way by client API (think mpv_command_node()
with "subprocess"), and detached async work.
Since scripts might want to do some cleanup work (that might involve
launching processes, don't ask), we don't unconditionally kill
everything on exit, but apply an arbitrary timeout of 2 seconds until
async commands are aborted.
Many asynchronous commands are potentially long running operations, such
as loading something from network or running a foreign process.
Obviously it shouldn't just be possible for them to freeze the player if
they don't terminate as expected. Also, there will be situations where
you want to explicitly stop some of those operations explicitly. So add
an infrastructure for this.
Commands have to support this explicitly. The next commit uses this to
actually add support to a command.
If a struct as large as MPContext contains a field named "lock", it
creates the impression that it is the primary lock for MPContext. This
is wrong, the lock just protects a single field.
Basically, the ytdl_hook script will not terminate the script, even if
you change to a new playlist entry. This happens because ytdl_hook keeps
the player core in an early loading stage, and the forceful playback
abort is done only in the ermination code.
This does not handle the "stop" and "quit" commands, which can still
take longer than expected, but on the other hand have some weird special
handling (see below). I'm not doing this out of laziness. Playback
stopping will have to be somewhat redone anyway. Basically we want to
give everything a chance to terminate, and if it doesn't work, we want
to stop loading or playback forcefully after a small timeout. We also
want to remove the mess with input.c's special handling of "quit" and
some other commands (see abort_playback_cb stuff).
It seems the ytdl script like to continue loading external tracks even
if loading was aborted. Trying to do so will still quickly fail, but not
without a load of log noise. So check and error out early.
Pretty trivial, since commands can be async now, and the common code
even provides convenience like running commands on a worker thread.
The only ugly thing is that mp_add_external_file() needs an extra flag
for locking. This is because there's still some code which calls this
synchronously from the main thread, and unlocking the core makes no
sense there.
The main change is that we wait with opening the muxer ("writing
headers") until we have data from all streams. This fixes race
conditions at init due to broken assumptions in the old code.
This also changes a lot of other stuff. I found and fixed a few API
violations (often things for which better mechanisms were invented, and
the old ones are not valid anymore). I try to get away from the public
mutex and shared fields in encode_lavc_context. For now it's still
needed for some timestamp-related fields, but most are gone. It also
removes some bad code duplication between audio and video paths.
Fundamentally, scripts are loaded asynchronously, but as a feature,
there was code to wait until a script is loaded (for a certain arbitrary
definition of "loaded"). This was done in scripting.c with the
wait_loaded() function.
This called mp_idle(), and since there are commands to load/unload
scripts, it meant the player core loop could be entered recursively. I
think this is a major complication and has some problems. For example,
if you had a script that does 'os.execute("sleep inf")', then every time
you ran a command to load an instance of the script would add a new
stack frame of mp_idle(). This would lead to some sort of reentrancy
horror that is hard to debug. Also misc/dispatch.c contains a somewhat
tricky mess to support such recursive invocations. There were also some
bugs due to this and due to unforeseen interactions with other messes.
This scripting stuff was the only thing making use of that reentrancy,
and future commands that have "logical" waiting for something should be
implemented differently. So get rid of it.
Change the code to wait only in the player initialization phase: the
only place where it really has to wait is before playback is started,
because scripts might want to set options or hooks that interact with
playback initialization. Unloading of builtin scripts (can happen with
e.g. "set osc no") is left asynchronous; the unloading wasn't too robust
anyway, and this change won't make a difference if someone is trying to
break it intentionally. Note that this is not in mp_initialize(),
because mpv_initialize() uses this by locking the core, which would have
the same problem.
In the future, commands which logically wait should use different
mechanisms. Originally I thought the current approach (that is removed
with this commit) should be used, but it's too much of a mess and can't
even be used in some cases. Examples are:
- "loadfile" should be made blocking (needs to run the normal player
code and manually unblock the thread issuing the command)
- "add-sub" should not freeze the player until the URL is opened (needs
to run opening on a separate thread)
Possibly the current scripting behavior could be restored once new
mechanisms exist, and if it turns out that anyone needs it.
With this commit there should be no further instances of recursive
playloop invocations (other than the case in the following commit),
since all mp_idle()/mp_wait_events() calls are done strictly from the
main thread (and not commands/properties or libmpv client API that
"lock" the main thread).
There was a "generic" function to run a hook and to wait for its
completion, yet there were two duplicated functions doing the same
anyway. Replace them with a single function.
They differed in how stop_play was handled, but it was broken anyway.
stop_play is set when playback is stopped due to quitting or changing
the playlist entry - but we still can't stop hook processing, because
that would mean asynchronously doing something else while the user hook
code is still busy and might still have the expectation that running the
hook stops everything else. So not waiting until the hook ends properly
is against the whole hook idea. That this was done inconsistently is
even worse. (Though it could be argued that when quitting the player,
everything should just be stopped violently. But I still think that's
up to the hook handler.)
process_hooks() does not return anything, since hook processing doesn't
really have a result (it's all about blocking and letting some other
code synchronously do something). Just let the caller check whether
loading was aborted in the meantime.
Also change the potentially misleading name of mp_hook_run().
As it turns out, there are multiple libmpv users who saw a need to
use the hook API. The API is kind of shitty and was never meant to be
actually public (it was mostly a hack for the ytdl script).
Introduce a proper API and deprecate the old one. The old one will
probably continue to work for a few releases, but will be removed
eventually.
There are some slight changes to the old API, but if a user followed
the manual properly, it won't break.
Mostly untested. Appears to work with ytdl_hook.
After switching, the playback state was not reset, which could leave it
in a strange, pause like state, that could be fixed by e.g. seeking.
This seems to be an older regression - it's even in 0.27.
Sometimes, playback needs to be fully uninitialized and reinitialized
without "officially" closing and reopening the playlist entry. This
happens with PT_RELOAD_FILE, which is triggered by edition switching and
also DVD/BD title switching. (Not really sure why it goes through so
much pain for such obscure cases. All it gains is not resetting "local"
options, and not signaling a reload to the client API. Whatever.)
The recent filter change freed filter_root too early without recreating
it, so it crashed on edition switching.
Fixes#5587.
If you used --aufio-file=file.mkv, and file.mkv included a video track
marked as default, then the logic in select_default_track() would pick
the video track from file.mkv. This is 100% broken, so fix it.
Before this commit, auto_loaded and lang were only set for the first
track in auto-loaded external files. Likewise, for the title and
lang arguments to the sub-add and audio-add commands.
Fixes#5432
Setting lavfi-complex at runtime will now forcefully reselect the tracks
as needed, even if it was a "proper" track selection via --aid or --vid.
Before this commit, it just failed and complained that the VO/AO was
already "used".
Requested.
This makes it actually somewhat simpler, and doesn't have any
disadvantages. It should also make some new features easier.
Mostly just moves code around.
The somewhat confusing thing is that many filters (including track->dec)
have a public struct, but to free them, you need to free the mp_filter
pointer itself (track->dec->f). The assignment wrote to a dangling
pointer, instead of removing the dangling pointer.
(Other than that, this idiom is actually nice.)
Use the decoder wrapper that was introduced for video. This removes all
code duplication the old audio decoder wrapper had with the video code.
(The audio wrapper was copy pasted from the video one over a decade ago,
and has been kept in sync ever since by the power of copy&paste. Since
the original copy&paste was possibly done by someone who did not answer
to the LGPL relicensing, this should also remove all doubts about
whether any of this code is left, since we now completely remove any
code that could possibly have been based on it.)
There is some complication with spdif handling, and a minor behavior
change (it will restrict the list of codecs to spdif if spdif is to be
used), but there should not be any difference in practice.
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
If you play a video with an external audio track, and do backwards
keyframe seeks, then audio can be missing. This is because a backwards
seek can end up way before the seek target (this is just how this seek
mode works). The audio file will be seeked at the correct seek target
(since audio usually has a much higher seek granularity), which results
in silence being played until the video reaches the originally intended
seek target.
There was a hack in audio.c to deal with this. Replace it with a
different hack. The new hack probably works about as well as the old
hack, except it doesn't add weird crap to the audio resync path (which
is some of the worst code here, so this is some nice preparation for
rewriting it). As a more practical advantage, it doesn't discard the
audio demuxer packet cache. The old code did, which probably ruined
seeking in youtube DASH streams.
A non-hacky solution would be handling external files in the demuxer
layer. Then chaining the seeks would be pretty easy. But we're pretty
far from that, because it would either require intrusive changes to the
demuxer layer, or wouldn't be flexible enough to load/unload external
files at runtime. Maybe later.
The underlying logic is still the same (basically pausing if the demuxer
cache underruns), but clean up the higher level logic a bit. It goes
from 3 levels of nested if statements to 1.
Also remove the code duplication for the --cache-pause-initial logic.
In addition, make sure an earlier buffering state has no influence on
the new state after a seek (this is also why some of the state resetting
can be removed from loadfile.c).
Initialize cache_buffer always to 100. It basically means we start out
assuming all buffers are filled enough. This actually matters for
verbose messages only, but removes some weird special casing.
Before this commit, some autoselection of tracks coming from files
loaded with --external-files was still done. This commit removes all of
it, and the only way to select a track is via the explicit stream
selection options like --vid/--sid/--aid.
I think this was always the original intention. The change could in
theory still unintentionally surprise some users, so add a changelog
entry.
This does not affect --audio-file/--sub-file, even if these contain
mismatching track types. E.g. if audio files passed to --audio-file
contain subtitles, these should still be selected. Past feature requests
indicate that users want this.
A release has been made, so drop options deprecated for that release.
Also drop some options which have been deprecated a much longer time
before.
Also fix a typo in client-api-changes.rst.
This will help with things like livestreams.
As a minor detail, subtitles are excluded, because they sometimes have
"unused" events after video and audio ends. To avoid this annoying
corner case, just ignore them.
Until now, using --sub-file would add only subtitle tracks from the
given file. (E.g. if you passed a video file, only the subtitle tracks
from it were added, not the video or audio tracks.)
This is slightly messy (because streams are hidden), and users don't
even want it, as shown by #5132. Change it to always add all streams.
But if there's no stream of the wanted type, we still report an error
and do not add any streams. It's also made sure none of the other track
types are autoselected.
Also adjust the error messages on load failure slightly.
Fixes#5132.
It appears libavformat never sets the file start time for subtitles, so
this special check is not needed. The original idea was probably that
_if_ the demuxer set the start time to the first subtitle packet, the
subtitles would be shifted incorrectly.
Added a get_play_start_pts function to coincide with the
already-existing get_play_end_pts. This prevents code duplication
and also serves to make it so code that probes the start time
(such as get_current_pos_ratio) will work correctly with chapters.
Included is a bug fix for misc.c/rel_time_to_abs that makes it work
correctly with chapters when --rebase-start-time=no is set.
Always display the duration as "unknown" if the duration is known. Also
fix that at least demux_lavf reported unknown duration as 0 (fix by
setting the default to unknown in demux.c).
Remove the dumb _u formatter function, and use a different approach to
avoiding displaying "unknown" as playback time on playback start (set
last_seek_pts for that).
This is pretty pointless, but I believe it allows us to claim that the
new code is not affected by the copyright of the old code. This is
needed, because the original mp_audio struct was written by someone who
has disagreed with LGPL relicensing (it was called af_data at the time,
and was defined in af.h).
The "GPL'ed" struct contents that surive are pretty trivial: just the
data pointer, and some metadata like the format, samplerate, etc. - but
at least in this case, any new code would be extremely similar anyway,
and I'm not really sure whether it's OK to claim different copyright. So
what we do is we just use AVFrame (which of course is LGPL with 100%
certainty), and add some accessors around it to adapt it to mpv
conventions.
Also, this gets rid of some annoying conventions of mp_audio, like the
struct fields that require using an accessor to write to them anyway.
For the most part, this change is only dumb replacements of mp_audio
related functions and fields. One minor actual change is that you can't
allocate the new type on the stack anymore.
Some code still uses mp_audio. All audio filter code will be deleted, so
it makes no sense to convert this code. (Audio filters which are LGPL
and which we keep will have to be ported to a new filter infrastructure
anyway.) player/audio.c uses it because it interacts with the old filter
code. push.c has some complex use of mp_audio and mp_audio_buffer, but
this and pull.c will most likely be rewritten to do something else.
Refresh seeks are automatically issued when changing filters, which
improves user experience if these filters change buffering or such.
The refresh seek could actually overwrite a previously ongoing seek:
set pause yes
set time-pos 10
set vf ""
Here, the video code issued a refresh seek to the previous video
position, which could be different from the previously triggered (and
still ongoing) seek, this overwriting the seek.
Factor all refresh seek handling into a new function, and make it handle
ongoing seeks correctly.
Remove the weird new canonical_pts field, which actually had no use.
Fixes#4757.
wm4
Zehua Chen
Ricardo Constantino
Leo Izen
Nicolas F