A 4K60 game view recording on the user's machine had 517 of 827
frames. The rest were skipped without a word: when the editor's tick
came late, FrameGate let the due slots pass, and only frames lost to a
busy encoder or read back counted as dropped. The file kept its time
but stuttered, and nothing said so.
- FrameGate counts the frames it took and the slots the recording's
time has room for. The difference is skipped, next to dropped in
__gm.recording().
- FramePace judges the missed frames over spans of 2 s. The first
time more than 10 % are missed, the log warns once with the frames
a second the recording really got.
- At the end, when more than 5 % are missed, a warning gives the
frames of the whole file and what helps (30 fps or a smaller
resolution). It comes after the upload's notice, which would cover
it at once in the editor.
- The first second counts for neither warning. Without that, a short
e2e recording warned about 3 frames lost while starting.
- A recording that starts logs an info line with its size, fps, codec
and sound. TakeHost.log takes a level for it. The editor recording
keeps the line to the console, its notice would be in the video.
- consoleLine is the one place with an eslint exception for
console.info, so the console panel shows the line plain.
Found along the way: headless Chrome in WSL records the editor with
real stutter in e2e 67 (1280x800@60 27 %, 2304x1440@30 12-14 %). That
is the software encoder there, and only now shown.
Tests:
- Gate on melektaus-atx: green, 309 files, 4810 tests.
- Unit recording.test.ts: 36 green, 6 new for FrameGate.skipped and
FramePace. With skipped stuck at 0 the test turns red.
- e2e 67 on melektaus-atx: ALL PASSED, 15 checks, run twice. The new
67b-ii slows the editor to about 20 fps: a 640x360@60 recording
says "about 19 of 60 fps" and saves with 95 of 192 frames.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
adminandClaude Opus 5.5
77365f17d3