mpv/DOCS
wm4 a3823ce0e0 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
2020-02-29 21:52:00 +01:00
..
man player: add optional separate video decoding thread 2020-02-29 21:52:00 +01:00
client-api-changes.rst Release 0.31.0 2019-12-28 12:07:07 +01:00
compatibility.rst DOCS/compatibility.rst: add this file 2019-10-05 02:11:55 +02:00
compile-windows.md DOCS: mention that mpv doesn't build with MSVC 2019-12-14 16:05:54 +01:00
contribute.md DOCS/contribute.md: fix a typo 2019-12-15 16:33:58 +01:00
edl-mpv.rst ytdl_hook, edl: add fps, samplerate codec parameters 2020-02-21 14:48:23 +01:00
encoding.rst DOCS/encoding.rst: remove deprecated usage of multiple items with *-add 2020-01-07 18:13:12 +01:00
interface-changes.rst DOCS/interface-changes.rst: mention it's for incompatible changes 2020-02-08 14:44:53 +01:00
mplayer-changes.rst mac: remove Apple Remote support 2019-12-15 20:07:31 +01:00
release-policy.md DOCS/release-policy.md: clarify a few details 2019-10-27 14:06:16 +01:00
tech-overview.txt DOCS/tech-overview.txt: some more blabla 2019-12-28 10:09:28 +01:00
waf-buildsystem.rst