Useful for distinguishing bit depth when hardware decoding. (To the
degree it's useful to show it at all. This just brings the hardware
decoding case on the same level of showing information as the software
decode call.)
A hacky, convoluted, half-working mess that attempts to cut off overlong
playlists.
It does so by relying on the ASS formatting rule that the font size is
specified in the virtual PlayResY resolution. This means we can
(normally) easily tell how many lines fit on the screen. On the other
hand, this does not work if the text is wrapped.
This as a kludge until a Better™ solution is available.
I'm still getting some crashes after issue #3210 was fixed in commit
5beb230690. It's hard to reproduce those
crashes, they happen maybe once a month, so I guess it could be a race
condition. But in any case, I don't see anything wrong in applying some
defensive programming here.
For reference, here is what was happening on 0.23.0-1 from Debian
testing:
Playing: ytdl://usL5CeP_row
(+) Video --vid=1 (*) (h264)
(+) Audio --aid=1 --alang=und (*) (aac)
[osc]
[osc] stack traceback:
[osc] @osc.lua:2074: in function 'process_event'
[osc] @osc.lua:2246: in function 'cb'
[osc] mp.defaults:107: in function 'fn'
[osc] mp.defaults:60: in function 'handler'
[osc] mp.defaults:339: in function 'handler'
[osc] mp.defaults:448: in function 'call_event_handlers'
[osc] mp.defaults:485: in function 'dispatch_events'
[osc] mp.defaults:441: in function <mp.defaults:440>
[osc] [C]: in ?
[osc] [C]: in ?
[osc] Lua error: @osc.lua:2074: attempt to index field 'eventresponder' (a nil value)
Note that the location is different from where issue #3210 happens.
Signed-off-by: Roland Hieber <rohieb@rohieb.name>
"show-text test; script-binding display_stats" can potentially crash. It
sends a message event. None of the string arguments can be NULL, which
fails if cmd->key_name is NULL. This in turn can be due to commands
combined with ";" (basically the key association doesn't consider nested
commands).
Seems like quite on oversight.
For most of the better pthread implementations, pthread_mutex_init() on
an already 0-initialized memory block is probably a no-op, but of course
we should do things correctly. Also could setup analysis tools.
This was excessively useless, and I want my time back that was needed to
explain users why they don't want to use it.
It captured the byte stream only, and even for types of streams it was
designed for (like transport streams), it was rather questionable.
As part of the removal, un-inline demux_run_on_thread() (which has only
1 call-site now), and sort of reimplement --stream-dump to write the
data directly instead of using the removed capture code.
(--stream-dump is also very useless, and I struggled coming up with an
explanation for it in the manpage.)
"drop-frame-count" -> "decoder-frame-drop-count"
"vo-drop-frame-count" -> "frame-drop-count"
This gets rid of the backwards "drop-frame" part in the name.
Maybe calling the new property "frame-drops" would be better, but there
are already a bunch of similar properties that end in "-count".
Disabling cache readahead by default until at least 1 track is selected
is mainly for external files and such, where you don't want them to use
up resources until they're actually used.
It doesn't make sense to disable the cache for the demuxer opened for
prefetch. Also, it's fine to let it do that for the main file too (doing
or not doing it is of little consequence). That saves us from having to
distinguish them.
Since for mpv CLI, the player state is a singleton, full prefetching is
a bit tricky. We do it only on the demuxer layer.
The implementation reuses the old "open thread". This means there is
significant potential for regressions even if the new option is not
used. This is made worse by the fact that I barely tested this code.
The generic mpctx_run_reentrant() wrapper is also removed - this was its
only user, and its remains become part of the new implementation.
As preparation for file prefetching, we basically have to get rid of
using mpctx->playback_abort for the main demuxer (i.e. the thing that
can be prefetched). It can't be changed on a running demuxer, and always
using the same cancel handle would either mean aborting playback would
also abort prefetching, or that playback can't be aborted anymore.
Make this more flexible with some refactoring.
Thi is a quite shitty solution if you ask me, but YOLO.
Requires a bunch of hacks:
- we access AVFilterLink.hw_frames_ctx. This is not a public API in
FFmpeg and Libav. Newer FFmpeg provides an accessor
(av_buffersink_get_hw_frames_ctx), but it's not available in Libav or
the current FFmpeg release or Libav. We need this value after filter
graph creation, so We have no choice but to access this.
One alternative is making filter creation and format negotiation
fully lazy (i.e. delay it and do it as filters are output), but this
would be a huge change.
So for now, we knowingly violate FFmpeg's and Libav's ABI and API
constraints because they don't provide anything better.
On newer FFmpeg, we use the (quite ugly) accessor, though.
- mp_image_params doesn't (and can't) have a field for the frames
context AVBufferRef. So we pass it via vf_set_proto_frame(), and even
more hacks.
- if a filter needs a hw context, but we haven't created one yet
(because normally we create them lazily), it will fail at init.
- we allow any hw format now, although this could go horrible wrong.
Why all this effort? We could move hw deinterlacing filters etc. to
FFmpeg, which is a very worthy goal.
Can break things quite badly.
Example: reloading a plugin linked against GTK 3.x can cause a segfault
if you call dlclose() on it. According to GTK developers, unloading the
GTK library is unsupported.
Give scripting backends a proper name, instead of calling everything
"scripts".
Log client exit directly in client.c, as that is more general (doesn't
change actual output).
This basically reuses the scripting infrastructure.
Note that this needs to be explicitly enabled at compilation. For one,
enabling export for certain symbols from an executable seems to be quite
toolchain-specific. It might not work outside of Linux and cause random
problems within Linux.
If C plugins actually become commonly used and this approach is starting
to turn out as a problem, we can build mpv CLI as a wrapper for libmpv,
which would remove the requirement that plugins pick up host symbols.
I'm being lazy, so implementation/documentation are parked in existing
files, even if that stuff doesn't necessarily belong there. Sue me, or
better send patches.
We have to perform some silly acrobatics to make the playback_thread()
exit, as the mpv_command() will error out with MPV_ERROR_UNINITIALIZED.
Test case: mpv_terminate_destroy(mpv_create())
Reported by a user on IRC.
mp_image_hw_download() is a libavutil wrapper added in the previous
commit. We drop our own code completely, as everything is provided by
libavutil and our helper wrapper.
This breaks the screenshot code, so that has to be adjusted as well.
Cover art handling is a disgusting hack that causes a mess in all
components. And this will stay this way. This is the Xth time I've
changed cover art handling, and that will probably also continue.
But change the code such that cover art is injected into the demux
packet stream, instead of having an explicit special case it in the
decoder glue code. (This is somewhat more similar to the cover art hack
in libavformat.)
To avoid that the over art picture is decoded again on each seek, we
need some additional "caching" in player/video.c. Decoding it after each
seek would work as well, but since cover art pictures can be pretty
huge, it's probably ok to invest some lines of code into caching it.
One weird thing is that the cover art packet will remain queued after
seeks, but that is probably not an issue.
In exchange, we can drop the dec_video.c code, which is pretty
convenient for one of the following commits. This code duplicates a
bunch of lower-level decode calls and does icky messing with this weird
state stuff, so I'm glad it goes away.
The property calls will always succeed anyway. On the other hand, the
error handling is kind of incomplete (doesn't check setting ab-loop-a
when ab-loop-b is also set), so drop this code.
Since there's no property yet that uses this type, and the code is used
for property change detection only. this is dead code. Add it anyway for
completeness.
Obvious mistake: we entered EOF drain mode if the decoder returned
AD_WAIT, which is very wrong. AD_WAIT means we should retry after
waiting for a while (or to be precise, until the demuxer/decoder
have more data). We should just pass down this status, and not
change the audio chain state.
This was exposed by a libavfilter EOF handling bug. Feeding a filter
chain with af_dynaudnorm, and sending an EOF before a frame is returned
makes it stuck and keeps returning EAGAIN, instead of returning the
buffered audio. In combination with the bug at hand, which entered
EOG drain mode, it could happen that it got stuck due to libavfilter
discarding buffered data each time the demuxer ran out of data.
Fixes#3997.
Was intended to show a "nice" message on edition switching. In practice,
the message was never visible. The OSD code checks whether a demuxer is
loaded, and if not, discards the message - meaning if the OSD code
happened to run before the demuxer was fully loaded, no message was
shown. This is apparently a regression due to extensions to the OSD and
the situations in which it can be used.
Remove the broken code since it's too annoying to fix. Instead, a
default property message will be shown, which is a bit uglier, but
actually not too unuseful.
Helps with gif, probably does unwanted things with other formats.
This doesn't handle --end quite correctly, but this could be added
later.
Fixes#3924.
Length property is deprecated and no longer works. This fixes
a bug when the total file duration wasn't visible if the
option to display milliseconds was activated.
Having empty space before the title in layout=*bar looks worse
than the floating buttons in layout=box.
Also disable both playlist buttons selectively according to the
current position.
The way playback/loading is stopped on the demuxer layer makes it report
an error to the higher levels of the player. But if playback/loading was
explicitly aborted, printing such an error is confusing and misleading.
This was probably just an oversight anyway. Fix it by using the libmpv
API reported error field instead, which handles this better.
Remove more stuff that was needed only for legacy suboptions.
One user-visible change is that parent-options like --tv are now not
visible anymore. They lead to a special error message when used before,
but now they're simply not part of the option list anymore.
For some reason, some types of accesses didn't warn, for example when
using mp.observe_property() in Lua. This was because the deprecation
handling code explicitly checks certain accesses. I'm not quite certain
why it was done this way. Just make it warn always.
This could be backported to the current release, if we cared.
As threatened by the API changes document.
We can actually keep the deprecated --playlist-pos and --cache options,
since they are aliases and not used by the corresponding properties.
They are inconsistent, but do no harm. Keep them for now for the sake of
the command line user.
mpv_identify.sh partially stopped working, because it was never updated.
The shell magic can't deal with property names that contain "/", so we
can't replace "samplerate" with "audio-params/samplerate" - just remove
these properties. (How about you use ffprobe?)
As threatened by the API changes document.
This commit also removes or stubs equivalent calls in IPC and Lua
scripting.
The stubs are left to maintain ABI compatibility. The semantics of the
API functions have been close enough to doing nothing that this probably
won't even break existing API users. Probably.
Run "playlist-remove current" while the last playlist entry is being
played stopped playback. Fix this and return to the first entry instead.
Fixes#3808.
If video reaches EOF, subtitle timing will be switched to timing without
video frames. This means it calls osd_set_force_video_pts() and
overrides the PTS of whatever video frame is current (since the video
frame's PTS has nothing to do with the current playback position
anymore).
This was not reset when seeking back into video. Subtitles wouldn't show
up, or if there was a subtitle displayed, it would get stuck with it. In
particular, this could happen even if EOF was only temporary (such as
with --keep-open).
Fix this by clearing the override PTS whenever a video frame is shown.
Fixes#3770.
