This put some effort into distinguishing between two messages to print -
all worthless. Even more so, this kept printing the message, which
doesn't feel overly useful either. (The message will be printed
repeatedly anyway if network recovers for a while and then gets stuck
again.)
All in all, the demuxer cache triggering the buffering state does a
better job here. But don't remove it completely, since knowing that the
network did nothing for a relatively short time is still useful.
It's annoying and unnecessary. They can be manually loaded if really
needed (for things like previewing).
Also remove the #if. It was for suppressing warnings, and we don't need
to be so careful about this in the relatively obscure encoding mode.
Approximate time of video buffered in the demuxer, in seconds. Same as
`demuxer-cache-duration` but returns the last timestamp of bufferred
data in demuxer.
Signed-off-by: wm4 <wm4@nowhere>
If user switched terminals frantically, mpv could get SIGUSR1 twice in a
row, which, up until now, resulted in destroying CRTC twice. This caused
it to segfault. After this fix, double SIGUSR1 should be ignored.
This will be used in the following commit, which adds screenshot_raw.
The reasoning is that this will be better for binding scripting
languages.
One could special-case the screenshot_raw commit and define fixed
semantics for passing through a pointer using the current API, like
formatting a pointer as string. But that would be ridiculous and
unclean.
On EOF, this stopped reporting the actual cache duration, and just
signalled unknown duration. Fix this and keep reporting whatever is left
in the packet queue.
This reverts commit 5438a8b3. The commit doesn't give a good explanation
as to why it is needed, but I guess it was because the reporting was
imperfect (it switched between unknown or 0, and the correct duration).
This also removes a line added in commit 848546f2. The line is
ds->active = false;
The "active" flag basically says that data from this stream is actively
needed, and it's used to calculate the minimum data that can actually be
played (approximately). If this were ignored, a sparse subtitle stream
would set the cache duration to 0s. The commit message adding the line
says "actually does nothing, but in theory it's cleaner". Well, screw
it.
Vapoursynth made an incompatible API change: clips with unknown length
are not supported anymore. In fact, Vapoursynth abort()s the program
(which by the way invalidate all of its claims of API/ABI stability).
So add some nonsense to make it work again.
Remove the old implementation for these properties. It was never very
good, often returned very innaccurate values or just 0, and was static
even if the source was variable bitrate. Replace it with the
implementation of "packet-video-bitrate". Mark the "packet-..."
properties as deprecated. (The effective difference is different
formatting, and returning the raw value in bits instead of kilobits.)
Also extend the documentation a little.
It appears at least some decoders (sipr?) need the
AVCodecContext.bit_rate field set, so this one is still passed through.
This prevents the machine from going to sleep while a video-only stream
is playing. When audio is playing, the audio stack should make this
request for us.
Useful for dealing with libavfilter's terrible graph syntax.
Not strictly backwards compatible (for example "[a[b]" fails now - the
"[" within the quote is interpreted now). But hopefully it's obscure
enough not to warrant any kind of compatibility hacks.
Logging was meant to be silenced only when user uses connector
auto-detection feature. If user supplies connector ID manually, he
should see exact reason why connecting to this specific connector
failed.
If a directory is encountered, replace it with its contents in the
internal playlist.
This is messed into demux_playlist.c, because why not. STREAMTYPE_DIR
could be avoided by unconditonally trying opendir() in demux_playlist.c,
but it seems nicer not to do weird things like calling it on real files.
This does not work on Windows, because msvcrt is retarded.
It's entirely useless, especially now that vo.c handles screenshots in a
generic way, and requires no special VO support. There are some
potential weird use-cases, but actually I've never seen it being used.
The old behavior does not make too much sense after all. If you don't
want to file to be overwritten, the user can check this manually.
This is a change in behavior - let's hope nobody actually relied on it.
libavcodec makes it impossible to distinguish dropped frames (requested
with AVCodecContext.skip_frame), and cases when the decoder simply does
not return a frame by default (such as with VP9, which has invisible
reference frames).
This confuses users when decoding VP9 video. It's basically a cosmetic
issue, so just paint it over by ignoring them if framedropping is
disabled.
It appears youtube-dl sometimes asks for a password on stdin. This won't
work, because mpv already uses the terminal.
(I wonder if this could be simpler, like simply closing FD 0, but let's
not. The FD would be reused by something random.)
We already use 2 screensaver APIs when attempting to disable the
screensaver: XResetScreenSaver() (from xlib) and XScreenSaverSuspend
(from the X11 Screen Saver extension). None of these actually work.
On modern desktop Linux, we are expected to make dbus calls using some
freedesktop-defined protocol (and possibly we'd have to fallback to a
Gnome specific one). At least xscreensaver doesn't respect the "old"
APIs either.
Solve this by running the xdg-screensaver script. It's a terrible, ugly
piece of shit (just read the script if you disagree), but at least it
appears to work everywhere. It's also simpler than involving various
dbus client libraries.
I hope this can replace the --heartbeat-cmd option, and maybe we could
remove our own DPMS/XSS code too.
