diff options
author | wm4 <wm4@nowhere> | 2020-02-29 21:40:52 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2020-02-29 21:52:00 +0100 |
commit | a3823ce0e0353fa4ae4b75b0ff2cc17e61969005 (patch) | |
tree | 7d2ebbf91040c39fdfe6a7d7c56e0414bc511bee /DOCS/man | |
parent | 485f335b697069a04516beaa4e3cc118d92789e5 (diff) | |
download | mpv-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/man')
-rw-r--r-- | DOCS/man/options.rst | 40 |
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 ------- |