diff --git a/Development.md b/Development.md
index 6e184ac..f58a8df 100644
--- a/Development.md
+++ b/Development.md
@@ -21,7 +21,7 @@ php tests/php/releases.test.php                               # the release stor
 php tests/php/files.test.php                                  # uploaded files in a folder per account (#344), the same way
 php tests/php/videos.test.php                                 # the video store, its queue and the worker (#402), with the
                                                               #   real ffmpeg: the CI image and feuerwerk-video have it
-node tools/seed-e2e.mjs && node tools/e2e.mjs                 # 2077 editor checks, screenshots in /tmp/gm-e2e-*.png
+node tools/seed-e2e.mjs && node tools/e2e.mjs                 # 2080 editor checks, screenshots in /tmp/gm-e2e-*.png
 GM_STEPS=20 node tools/e2e.mjs                                # or 1-12, or 6,20 — a subset while working on one step
 ./e2e.sh start [GM_STEPS]                                     # the same run detached, see below
 ./e2e.sh status                                               # live progress, or the last run's result
diff --git a/Videos.md b/Videos.md
index ec9a011..884d92f 100644
--- a/Videos.md
+++ b/Videos.md
@@ -222,8 +222,20 @@ Two action nodes record what the game view shows, with what the master plays (#4
   and **Import after conversion** do nothing there.
 - **A file of 2 GB**, the most an upload may be, ends the recording and saves it, with a line in
   the log. At 1080p60 that is roughly half an hour.
-- **When the encoder cannot keep up**, a frame is left out rather than everything falling behind;
-  the converted MP4 has a constant frame rate again.
+- **The log says what it records:** an info line when it starts, with its size, fps, codec and
+  whether it has sound, such as `Recording "Trailer" started: 3840x2160 at 60 fps, H.264, with
+  sound`.
+- **When the computer cannot keep up**, a frame is left out rather than everything falling behind:
+  the editor drew too late for it, or the encoder was still busy. The time in the file stays right,
+  but the picture stutters. The recording says so in the log twice, as a warning. Once while it
+  records, the first time it misses more than a tenth of its frames over 2 s, such as
+  `Recording "Trailer" can't keep up: about 38 of 60 fps, so the video will stutter`. And once when
+  it is saved, if it missed more than 5 % in all, such as `Recording "Trailer" has 517 of 827
+  frames: 310 missed (37 %), so it stutters`, with a hint that 30 fps or a smaller resolution
+  helps. Its first second is left out of both: a short stall while it starts is no stutter. The
+  line at the end comes after the run, so in the editor it is in the console panel. 4K at 60 fps
+  is too much for most computers: reading each frame back from the GPU takes longer than a frame.
+  The converted MP4 has a constant frame rate again.
 
 How it is made: H.264 from Chrome's `VideoEncoder` (VP9 where there is no H.264), hardware where
 the computer has it, 10 Mbit/s at 1080p60, a keyframe every 2 s. The file is Matroska, written by
@@ -268,6 +280,8 @@ The recording is always uploaded; **Download** in the video picker saves it as i
   3840x2160 needs a window of that shape: open the editor with `?w=1920&h=1080`.
 - **Cost:** 4K at 60 fps is about 40 Mbit/s, so the 2 GB a file may have last about 7 minutes. The
   encoder is whatever Chrome has; frames it cannot keep up with are dropped. 30 fps halves both.
+  It warns of a stutter as the game view recording does, in the notice line. The line when it
+  starts stays in the console panel: the notice would be in the recording.
 - **The mouse pointer** is drawn in when asked: the system draws it over the page, so it is not in
   the canvas; the recording draws its own in the shape the editor shows (arrow, hand, resize
   arrows, I-beam, crosshair).