Coverart mode has the same issue as no-video mode, except that the video
chain is fully active. It shows only 1 frame at the start, which would
normally mean that only the subtitle at timestamp 0 is shown. Use the
no-video subtitle rendering mode in this case instead.
(This still doesn't handle subtitle display when playing cover-art
without audio, or playing a single image. This is because there's
nothing that will advance playback_pts.)
This code would just keep it busy while e.g. being paused. Even if it's
not paused, it couldn't help with anything since we obviously still lock
display to the externally updated PTS.
This way people can still use the mouse to quickly check the elapsed time
without moving it all the way to the bottom while still having half the screen
to ignore mouse movement.
If a VO is created, but no video is playing (i.e. --force-window is
used), then until now no subtitles were shown. This is because VO
subtitle display normally depends on video frame timing. If there are no
video frames, there can be no subtitles.
Change this and add some code to handle this situation specifically. Set
a subtitle PTS manually and request VO redrawing manually, which gets
the subtitles rendered somehow.
This is kind of shaky. The subtitles are essentially sampled at
arbitrary times (such as when new audio data is decoded and pushed to
the AO, or on user interaction). To make a it slightly more consistent,
force a completely arbitrary minimum FPS of 10.
Other solutions (such as creating fake video) would be more intrusive or
would require VO-level API changes.
Fixes#3684.
* Fixes: when on the end of playlist only half of entries are displayed.
* Simplifies the logic of limited_list so it's easy to follow.
* limited_list's pos parameter is now 1 based which seem more natural.
* Few changes to comply with code style thorough the file.
* Small format change:
"Playlist: (%d/%d):" -> "Playlist [%d/%d]:"
"Chapters: (%d/%d):" -> "Chapters [%d/%d]:"
These can be used in input.conf for pretty formatting of lists as
with shift+clicking the OSC buttons.
Ex:
z script-message osc-playlist
Z script-message osc-chapterlist
x script-message osc-tracklist
--reset-on-next-file=all triggers m_config_backup_all_opts(), which
backups all options (even deprecated ones). Later, when the option
values are reset with m_config_restore_backups(), mp_on_set_option() is
called, which in turn calls mp_property_do_silent(), which in turn will
call mp_property_generic_option() and m_config_get_co(), which triggers
the deprecation message.
Unfortunately there's no good way to determine whether an option has
actually changed (there's no option value compare operation), so the
deprecated options have to be set no matter what. On the other hand, we
can't pass through additional flags through the property layer. So we
add a dumb global flag to silence the deprecation warnings in these
cases.
Fortunately m_config_get_co_raw() works to silence the warnings.
m_config_get_co() also resolves aliases (deprecated and non-deprecated),
but aliased options are handled differently by the option-property
bridge, so we don't need to do that here, so the only purpose of it is
to trigger a warning for deprecated (non-alias) options.
The tv-freq options and properties use different types, thus must be
treated as incompatible. Fixes an assertion with reset-on-next-file=all,
which tries to set the option.
Fixes#3708.
Don't leave the buffering state while the demuxer is still marked as
having underflowed. It's unclear why this hasn't been done before - with
the logic being complicated as it is, maybe there was a reason for this.
This is actually still not very reliable, but should be better than what
was before: on stream switching decoders can read packets all while the
demuxer is executing a refresh seek, which creates the underrun
situation - but nothing really totally guarantees that the underrun
state remains stable when the demuxer is back at the current demuxer
position. Anyway, it's an improvement.
The rest of the touched condition is not changed, just moved around for
cosmetic reasons.
in very rare circumstances, doing a relative seek like +1s will end up
doing an absolute seek to 00:01. this guards against that possibility.
so far i've only ever seen this issue when using --ad=lavc:ac3_at and
doing several relative seeks in quick succession. this is likely either
a bug in the audiotoolbox decoder in ffmpeg, or simply due to inherent
latency in that hardware decoder which causes brief periods of time
where the current audio pts is unknown.
i've seen several mpegts samples where pts jumps backwards and repeats
itself. this usually happens on live tv streams from cable providers,
particularly when the stream switches from one advertisement to another.
when there is a huge delay between audio/video sync, it can take a
really long time to converge back. this speeds up the resync time by
increasing the max_change allowed per iteration.
Signed-off-by: wm4 <wm4@nowhere>
Had only tested with luajit which supports the \xHH syntax added
in Lua 5.2.
The arrow is troublesome to use since the ideal way to use it, as
the OSD code uses it, needs \alpha&H00<arrow>\r to work, which
does not in OSC's way of showing messages.
Change a few other defaults accordingly:
- seekbarstyle=bar looks better with bottombar.
- Bigger scalewindowed and scalefullscreen make bottom/topbar more readable.
Don't require special property code for handling updates, and simply use
the UPDATE_AUDIO flag instead. Also make runtime changes to
--audio-client-name take effect.
Now a reload requested by an AO behaves in exactly the same way as
changing an AO-related options (like --audio-channels or
--audio-exclusive). This is good for testing and uniform behavior. (You
could go as far as saying it's a necessity, because the spotty and
obscure AO reload behavior is hard to reproduce and thus hard to test at
all.)
This affects changing audio configuration options. Explicitly flush and
uninitialize the audio output first before doing the rest. This should
ensure all state attached to the audio output is discarded and not used
during the reconfiguration.
Also add a comment to the reinit_audio_filters() call. It doesn't
necessarily restore the audio chain fully, but makes sure a seek is
issued if the amnount of buffered audio discarded was huge enough to
cause "problems".
If we really want client API users to use mpv_set_property() instead of
mpv_set_option(), then compatibility handling of deprecated options
should be included. Otherwise, there's the danger that client API users
either break too early (and without a warning), or mpv_set_option() will
continue to have a reason to exist.
"seek -10 absolute" will seek to 10 seconds before the end. This more or less
matches the --start option and negative seeks were otherwise useless (they just
clipped to 0).
Regression since commit bbcd0b6a. This code is just cursed, because it's
a fragile state machine with no proper tests, and which could be done in
a much simpler way. Without doubt this change will cause a regression in
some ridiculous corner case as well.
Fixes#3610 (the cause of it, not the behavior it resulted in).
Move the screensaver enable/disable determination to a central place,
and call it if the stop-screensaver property is changed.
Also, do not stop the screensaver when in idle mode (i.e. no file is
loaded).
Fixes#3615.
