summaryrefslogtreecommitdiffstats
path: root/DOCS
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2018-05-09 22:38:21 +0200
committerwm4 <wm4@nowhere>2018-05-24 19:56:34 +0200
commita4321cf6877f47a381ff40bea73ca2934635ea58 (patch)
tree781a87047b16653f92f234b4f61786f6c369411e /DOCS
parent059e7fdb3aaace0c6259728547da1896249818e4 (diff)
downloadmpv-a4321cf6877f47a381ff40bea73ca2934635ea58.tar.bz2
mpv-a4321cf6877f47a381ff40bea73ca2934635ea58.tar.xz
screenshot: change async behavior to be in line with new semantics
Basically reimplement the async behavior on top of the async command code. With this, all screenshot commands are async, and the "async" prefix basically does nothing. The prefix now behaves exactly like with other commands that use spawn_thread. This also means using the prefix in the preset input.conf is pointless (without effect) and misleading, so remove that. The each_frame mode was actually particularly painful in making this change, since the player wants to block for it when writing a screenshot, and generally doesn't fit into the new infrastructure. It was still relatively easy to reimplement by copying the original command and then repeating it on each frame. The waiting is reentrant now, so move the call in video.c to a "safer" spot. One way to observe how the new semantics interact with everything is using the mpv repl script and sending a screenshot command through it. Without async flag, the script will freeze while writing the screenshot (while playback continues), while with async flag it continues.
Diffstat (limited to 'DOCS')
-rw-r--r--DOCS/man/input.rst20
1 files changed, 8 insertions, 12 deletions
diff --git a/DOCS/man/input.rst b/DOCS/man/input.rst
index 94e1ea0b1f..6aa566294f 100644
--- a/DOCS/man/input.rst
+++ b/DOCS/man/input.rst
@@ -186,11 +186,10 @@ List of Input Commands
second argument (and did not have flags). This syntax is still understood,
but deprecated and might be removed in the future.
- Setting the ``async`` flag will make encoding and writing the actual image
- file asynchronous in most cases. (``each-frame`` mode ignores this flag
- currently.) Requesting async screenshots too early or too often could lead
- to the same filenames being chosen, and overwriting each others in undefined
- order.
+ If you combine this command with another one using ``;``, you can use the
+ ``async`` flag to make encoding/writing the image file asynchronous. For
+ normal standalone commands, this is always asynchronous, and the flag has
+ no effect. (This behavior changed with mpv 0.29.0.)
``screenshot-to-file "<filename>" [subtitles|video|window]``
Take a screenshot and save it to a given file. The format of the file will
@@ -204,9 +203,6 @@ List of Input Commands
Like all input command parameters, the filename is subject to property
expansion as described in `Property Expansion`_.
- The ``async`` flag has an effect on this command (see ``screenshot``
- command).
-
``playlist-next [weak|force]``
Go to the next entry on the playlist.
@@ -905,13 +901,13 @@ command behaves by itself. There are the following cases:
have an asynchronous implementation. The async libmpv API still never blocks
the caller in these cases.
-The only exception is the current legacy behavior with screenshot commands,
-which will be fixed later. Using the ``async`` prefix makes them run the file
-saving code in a detached manner.
+Before mpv 0.29.0, the ``async`` prefix was only used by screenshot commands,
+and made them run the file saving code in a detached manner. This is the
+default now, and ``async`` changes behavior only in the ways mentioned above.
Currently the following commands have different waiting characteristics with
sync vs. async: sub-add, audio-add, sub-reload, audio-reload,
-rescan-external-files.
+rescan-external-files, screenshot, screenshot-to-file.
Input Sections
--------------