SoftwareChromeopen sourcevideodeveloper tools
Paul Irish's chrome-capture records a Chrome tab to AV1 MP4 with one npx command, no FFmpeg, and finishes saving in 17 ms
The Apache-2.0 repo wraps Chrome 153's new startScreenRecording call, and its own benchmark has Playwright's built-in recorder taking 3,800 ms to finish the same clip.
Recording a web page to video is one line in Paul Irish’s chrome-capture: npx chrome-capture https://paulirish.github.io/chrome-capture/ demo.mp4 4s. A URL, a filename and a duration are the whole interface. (No config file. Refreshing.)
The README’s pitch fits in three sentences: “Record a Chrome tab at 60-120fps (up to 2160p) straight to a AV1 .mp4. Tab audio too. No ffmpeg.” The trick lives in the browser. The README’s heading reads “Chrome 153+ has a native MP4 tab recorder!” and credits Alex Rudenko for the new Page.startScreenRecording call.
The old route was Page.startScreencast, which sends JPEG frames over the DevTools protocol so a script can pipe them into FFmpeg. The new one skips the detour. “Frames go straight from the compositor to an out-of-process encoder over shared memory,” the README says, and Chrome writes AV1 into the MP4 as it records, with optional “48kHz stereo Opus tab audio.” No JPEG hop, no pipe, no encoder install.
The numbers come from the author’s own bench: a 6.4-second UI replay at 1280x800 on an M4 Max. Playwright’s recordVideo, which rides the old screencast path, took 3,800 ms to stop and finalize. chrome-capture took 17 ms. The same table has 11 seconds of wall-clock time against 21, 450 KB of WebSocket traffic against 10.5 MB, and a 330 KB file against 480 KB. One machine, one replay, and the author is also the one selling it. Still, 17 milliseconds is shorter than most people’s “save” reflex.
The headline figure comes with fine print. The README lists “2160p @ 120fps” (119.9 fps, 59.8 Mbps AV1 plus stereo Opus on Three.js/WebGL2 scenes), but only on a Mac running headful Chrome on a 120Hz ProMotion screen. The CLI notes say 120 fps “needs a 120Hz display and headful Chrome, e.g. a ProMotion MacBook.” A headless Mac reaches 2160p at 60 fps, and the README warns against turning off vsync on a GPU-accelerated Mac: “Leave native vsync alone; it’s what gets you to 120.” So “4K at 120” is true the way “up to 20 hours of battery” is true.
It also slots into code you already have. startRecording() accepts a Playwright Page, a Puppeteer Page or a raw CDP session and defaults to 60 fps. The README even invites you to “point your agent at src/index.ts” and reuse the implementation, and the license is Apache-2.0. The only 120 fps result the README lists is that one Mac run.
Test frameworks tend to follow whatever the browser ships natively. The likely path: once Chrome 153 is everyone’s baseline, “record video” in Playwright-style runners starts calling Page.startScreenRecording and the FFmpeg plumbing quietly retires. The mechanism is simple: the encoder sits next to the compositor, so the slow part of the pipeline, shipping JPEGs out and back, disappears. That is a guess about other people’s roadmaps, not something the README promises.
Seventeen milliseconds: blink and it’s saved.