summaryrefslogtreecommitdiffstats
path: root/DOCS
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2020-02-29 21:40:52 +0100
committerwm4 <wm4@nowhere>2020-02-29 21:52:00 +0100
commita3823ce0e0353fa4ae4b75b0ff2cc17e61969005 (patch)
tree7d2ebbf91040c39fdfe6a7d7c56e0414bc511bee /DOCS
parent485f335b697069a04516beaa4e3cc118d92789e5 (diff)
downloadmpv-a3823ce0e0353fa4ae4b75b0ff2cc17e61969005.tar.bz2
mpv-a3823ce0e0353fa4ae4b75b0ff2cc17e61969005.tar.xz
player: add optional separate video decoding thread
See manpage additions. This has been a topic in MPlayer/mplayer2/mpv since forever. But since libavcodec multi-threaded decoding was added, I've always considered this pointless. libavcodec requires you to "preload" it with packets, and then you can pretty much avoid blocking on it, if decoding is fast enough. But in some cases, a decoupled decoder thread _might_ help. Users have for example come up with cases where decoding video in a separate process and piping it as raw video to mpv helped. (Or my memory is false, and it was about vapoursynth filtering, who knows.) So let's just see whether this helps with anything. Note that this would have been _much_ easier if libavcodec had an asynchronous (or rather, non-blocking) API. It could probably have easily gained that with a small change to its multi-threading code and a small extension to its API, but I guess not. Unfortunately, this uglifies f_decoder_wrapper quite a lot. Part of this is due to annoying corner cases like legacy frame dropping and hardware decoder state. These could probably be prettified later on. There is also a change in playloop.c: this is because there is a need to coordinate playback resets between demuxer thread, decoder thread, and playback logic. I think this SEEK_BLOCK idea worked out reasonably well. There are still a number of problems. For example, if the demuxer cache is full, the decoder thread will simply block hard until the output queue is full, which interferes with seeking. Could also be improved later. Hardware decoding will probably die in a fire, because it will run out of surfaces quickly. We could reduce the queue to size 1... maybe later. We could update the queue options at runtime easily, but currently I'm not going to bother. I could only have put the lavc wrapper itself on a separate thread. But there is some annoying interaction with EDL and backward playback shit, and also you would have had to loop demuxer packets through the playloop, so this sounded less annoying. The food my mother made for us today was delicious. Because audio uses the same code, also for audio (even if completely pointless). Fixes: #6926
Diffstat (limited to 'DOCS')
-rw-r--r--DOCS/man/options.rst40
1 files changed, 40 insertions, 0 deletions
diff --git a/DOCS/man/options.rst b/DOCS/man/options.rst
index 59cd66ccbc..982e8c1830 100644
--- a/DOCS/man/options.rst
+++ b/DOCS/man/options.rst
@@ -4504,6 +4504,46 @@ Cache
See ``--list-options`` for defaults and value range. ``<bytesize>`` options
accept suffixes such as ``KiB`` and ``MiB``.
+``--vd-queue-enable=<yes|no>, --ad-queue-enable``
+ Enable running the video/audio decoder on a separate thread (default: no).
+ If enabled, the decoder is run on a separate thread, and a frame queue is
+ put between decoder and higher level playback logic. The size of the frame
+ queue is defined by the other options below.
+
+ This is probably quite pointless. libavcodec already has multithreaded
+ decoding (enabled by default), which makes this largely unnecessary. It
+ might help in some corner cases with high bandwidth video that is slow to
+ decode (in these cases libavcodec would block the playback logic, while
+ using a decoding thread would distribute the decoding time evenly without
+ affecting the playback logic). In other situations, it will simply make
+ seeking slower and use significantly more memory.
+
+ In specific situations, this still makes the player wait on the decoder,
+ such as seeking, switching hardware decoding modes, and more.
+
+ This should not be used with hardware decoding. It is possible to enable
+ this for audio, but it makes even less sense.
+
+``--vd-queue-max-bytes=<bytesize>``, ``--ad-queue-max-bytes``
+ Maximum approximate allowed size of the queue. If exceeded, decoding will
+ be stopped. The maximum size can be exceeded by about 1 frame.
+
+ See ``--list-options`` for defaults and value range. ``<bytesize>`` options
+ accept suffixes such as ``KiB`` and ``MiB``.
+
+``--vd-queue-max-samples=<int>``, ``--ad-queue-max-samples``
+ Maximum number of frames (video) or samples (audio) of the queue. The audio
+ size may be exceeded by about 1 frame.
+
+ See ``--list-options`` for defaults and value range.
+
+``--vd-queue-max-secs=<seconds>``, ``--ad-queue-max-secs``
+ Maximum number of seconds of media in the queue. The special value 0 means
+ no limit is set. The queue size may be exceeded by about 2 frames. Timestamp
+ resets may lead to random queue size usage.
+
+ See ``--list-options`` for defaults and value range.
+
Network
-------