Новый API сохраняет видео в AV1 MP4 со звуком вкладки по выбору без ffmpeg. Для 120 FPS нужен экран с частотой 120 Гц.
В Chrome 153 и новее доступна встроенная запись вкладок в MP4 с кодеком AV1 и опциональным звуком вкладки — без ffmpeg. API Page.startScreenRecording, добавленный в сентябре 2026 года, позволяет записывать видео вплоть до 2160p при 120 FPS. Автор инструмента chrome-capture показал, как использовать эту возможность, и опубликовал результаты тестов. Максимальная частота доступна не на любой системе.
Источник: Shazoo
Кадры поступают напрямую из композитора Chrome в отдельный процесс кодирования через общую память. Браузер кодирует видео во время записи и сразу пишет его в MP4. Можно захватывать звук вкладки в стереоформате Opus с частотой 48 кГц, а запись запускать и останавливать в нужный момент — например, после входа в аккаунт и подготовки страницы.
Раньше Playwright с recordVideo и Puppeteer с page.screencast() опирались на Page.startScreencast. Этот API появился примерно в 2013 году для показа в DevTools изображения с подключённого по USB Android-устройства. Chrome сжимает каждый кадр в JPEG, передаёт его через Chrome DevTools Protocol в виде base64 внутри JSON и ждёт подтверждения получения. Затем библиотека отправляет кадры в ffmpeg.
Новый подход прежде всего сокращает ожидание после остановки: видео уже закодировано, поэтому долгая финальная обработка не нужна.
Что показали тесты
Автор сравнил оба способа на M4 Max: один и тот же сценарий продолжительностью 6,4 секунды включал ввод текста, клики, перетаскивание и прокрутку. Разрешение составляло 1280 × 800, а chrome-capture работал с частотой по умолчанию — 60 FPS.
Частота готового видео: 25 FPS у recordVideo против 60 FPS у chrome-capture.
Общее время выполнения: 21 секунда против 11 секунд.
Остановка и завершение файла: 3800 мс против 17 мс.
Трафик WebSocket: 10,5 МБ против 450 КБ.
Размер файла: 480 КБ против 330 КБ.
PSNR относительно снимка без потерь: 32 дБ против 34 дБ.
Звук: отсутствовал у старого способа, у нового доступен по выбору.
Для 2160p разница во времени завершения оказалась ещё больше: 91 мс у нового API против 20,5 секунды у прежней связки. Это результаты конкретных тестов автора, а не обещание одинаковой скорости на любом компьютере.
Где доступны 4K и 120 FPS
Чтобы проверить реальную частоту, автор выводил двоичный счётчик на каждом вызове requestAnimationFrame, а затем считывал его из готового MP4. Такой тест считает уникальные кадры, а не полагается на частоту, указанную в файле.
macOS, Chrome без видимого окна: 1080p, 1440p и 2160p держали 60 FPS. Ускорение Metal работает, но requestAnimationFrame в этом режиме использует синтетический таймер на 60 Гц.
macOS, Chrome с видимым окном на экране ProMotion 120 Гц: доступны 1080p и 2160p при 120 FPS. На сценах Three.js/WebGL2 автор получил 119,9 FPS с AV1, битрейтом 59,8 Мбит/с и стереозвуком Opus.
Linux без GPU, включая CI: около 60,4 уникального кадра в секунду при 1080p и около 58 при 1440p. После отключения ограничений частоты и вертикальной синхронизации результат при 1080p достигал 75–83 FPS.
Windows и Linux с дискретной видеокартой: результатов в источнике нет.
На Mac с GPU-ускорением автор предупреждает против флагов --disable-frame-rate-limit и --disable-gpu-vsync. С ними requestAnimationFrame разгоняется до 1600–9800 вызовов в секунду, перегружает очередь Metal и мешает захвату. В тесте запись 2160p при 60 FPS падала до 0,3 FPS. Для 120 FPS на такой системе нужна штатная вертикальная синхронизация.
Как использовать chrome-capture
Пакет доступен через npm. Команда npx chrome-capture https://paulirish.github.io/chrome-capture/ demo.mp4 4s записывает четыре секунды демонстрационной страницы в 720p при 60 FPS со звуком вкладки. Параметры --fps=120 --width=1920 --height=1080 --headful задают 1080p при 120 FPS — для этого нужен экран на 120 Гц и Chrome с видимым окном. Флаг --with-devtools позволяет записывать страницу с открытыми рядом DevTools.
При частоте до 60 FPS включительно утилита по умолчанию запускает Chrome без видимого окна через --headless=new. На macOS при запросе выше 60 FPS она автоматически переключается на видимое окно, чтобы браузер мог синхронизироваться с экраном ProMotion.
Библиотечная функция startRecording() принимает страницу Playwright, страницу Puppeteer или сессию CDP. По умолчанию она использует 60 FPS и пределы 1280 × 720. Можно выбрать захват области страницы или окна браузера, включить звук, сохранить MP4 по указанному пути либо получить Buffer после остановки. Конструкция await using завершает запись при выходе из блока.
Для Playwright Test есть отдельная фикстура: она записывает каждый тест и прикрепляет MP4 к отчёту. Автоматический запуск можно отключить, чтобы начинать захват в середине теста. Для демонстрации действий Playwright умеет добавлять в DOM курсор, подсветку элементов и отметки кликов — новый API захватывает их вместе со страницей.
В Puppeteer 25.10 и новее новый механизм доступен через экспериментальный page.record(), который заменяет устаревающий page.screencast(). По обновлению от 10 ноября, для Playwright открыт pull request №43999 с поддержкой Page.startScreenRecording в Chromium. Это ещё не означает, что изменение принято.
Ограничения качества
«Настройки битрейта/CRF пока нет», — пишет автор chrome-capture. Chrome использует libaom AV1 с однопроходным кодированием в реальном времени и переменным битрейтом. Целевой битрейт растёт пропорционально числу пикселей в секунду: 2 Мбит/с для 720p30, 9 Мбит/с для 1080p60, 18 Мбит/с для 1080p120 и 72 Мбит/с для 2160p120.
По оценке автора, 1080p60 и более высокие режимы дают удачное сочетание разрешения и битрейта. Если же нужна передача мелкого текста без потерь и достаточно примерно 10–15 FPS, он оставляет место прежнему способу: захвату PNG через Page.startScreencast с последующей обработкой в ffmpeg.
