Фингерпринтинг частоты кадров: экран и видео

Статья о частоте кадров экрана, которую страница измеряет по интервалам requestAnimationFrame, и о темпе воспроизведения видео. BotBrowser задаёт тайминг через --bot-fps и --bot-video-fps, но не поднимает частоту выше возможностей хоста и не заменяет реальный монитор.

Краткое резюме

--bot-fps управляет таймингом экрана (profile, real или число, ENT Tier2), а --bot-video-fps отдельно задаёт реальный и сообщаемый темп видео. Измеряйте около шестидесяти интервалов на видимой вкладке и сравнивайте среднюю частоту с заданной.

Содержание руководства

• Как requestAnimationFrame раскрывает частоту обновления
• Почему частота обновления относится к аппаратным сигналам
• Почему обертки и расширения оставляют пробелы
• Настройка частоты кадров экрана
• Темп воспроизведения видео и нагрузка на CPU
• Выбор значений и проверка результата

Как requestAnimationFrame раскрывает частоту обновления

Когда страница вызывает requestAnimationFrame(callback), браузер запускает функцию перед следующей перерисовкой и передает ей DOMHighResTimeStamp, отмечающий начало кадра. Справочник MDN описывает этот контракт и отмечает, что обратные вызовы обычно совпадают с частотой обновления экрана. Вычитая соседние отметки времени, получают интервал между кадрами, а разделив секунду на этот интервал, получают частоту.

Для надежной оценки хватает короткой выборки. Если собрать несколько десятков последовательных отметок времени и усреднить интервалы, отдельные медленные кадры сглаживаются, а все измерение укладывается в долю секунды, и посетитель ничего не замечает. Выполнять его нужно на видимой вкладке, потому что браузеры обычно приостанавливают или замедляют requestAnimationFrame на фоновых страницах.

Реальные измерения шумные. Загруженная страница время от времени пропускает кадр, и это выглядит как один длинный интервал среди множества обычных, а единичная выборка может попасть именно на это выбросное значение. Медиана или среднее по более длинной серии дают устойчивую цифру, которая обычно оказывается рядом с привычным значением вроде 60, 90, 120 или 144 Гц. Именно эта устойчивость делает число полезным для сайта, который хочет узнавать вернувшееся устройство.

CSS-анимации и переходы продвигаются по тому же циклу экрана. Анимация @keyframes длиной в секунду дает примерно один кадр на обновление, поэтому на экране 144 Гц она движется более мелкими шагами, чем на экране 60 Гц. Спецификация CSS не обещает точности кадр в кадр, но темп, с которым анимация продвигается, все равно следует за экраном. Это важно ниже, потому что страница может прочитать частоту и из requestAnimationFrame, и из анимации и ожидать, что оба показания совпадут.

Переменная частота обновления добавляет еще одно измерение. Экраны с G-Sync, FreeSync или ProMotion могут менять частоту в зависимости от содержимого, например снижаться до меньшей частоты, когда на экране почти ничего не движется. Страница, наблюдающая достаточно долго, видит не только базовую частоту, но и то, как она меняется, а такая картина отличается от ровного темпа панели с фиксированной частотой.

Конфигурации с несколькими мониторами добавляют последнюю деталь. Когда окно переходит с монитора 60 Гц на монитор 144 Гц, интервалы между вызовами меняются в этот момент. Страница, которая следит за интервалами в течение сеанса, может заметить переход, а это говорит кое-что о расположении оборудования за окном браузера.

Почему частота обновления относится к аппаратным сигналам

Частота обновления принадлежит физическому экрану и компоновщику, который им управляет. Она не меняется, когда вы очищаете cookie, открываете приватное окно или переключаете сеть. Посетитель на той же машине может сообщать похожий темп, но нагрузка, переменная частота и смена экрана могут менять наблюдаемые интервалы между сеансами.

Сигнал также несет больше информации, чем раньше. Не так давно почти все потребительские мониторы работали на 60 Гц, и число почти ничего не говорило сайту. Сегодня панели выпускаются на 60, 75, 90, 120, 144, 165, 240 и 360 Гц, а телефоны и ноутбуки с адаптивной частотой вроде ProMotion добавляют разнообразия. Посетитель с монитором на 165 Гц входит в гораздо меньшую группу, чем посетитель с 60 Гц, поэтому значение помогает сузить круг устройств, с которых мог прийти визит. Мобильные браузеры ведут себя так же: существуют экраны на 60, 90 и 120 Гц, и многие современные телефоны переключают частоту во время работы.

Частота обновления является одним из аппаратных сигналов среди нескольких сигналов экрана и сама по себе не доказывает идентичность. Ее вес складывается из сочетания. Вместе с размером экрана, глубиной цвета, плотностью пикселей устройства и выводом GPU она участвует в описании оборудования, которое гораздо конкретнее любого отдельного значения. Руководство по фингерпринтингу экрана и окна рассматривает соседние сигналы экрана.

Несколько функций браузера раскрывают связанные сигналы экрана. Интервалы requestAnimationFrame и ход CSS-анимаций следуют таймингу экрана, а сообщаемые свойства описывают состояние окна и дисплея. Мера приватности, меняющая лишь один сигнал, может оставить остальные указывающими на другой аппаратный контекст.

Тот же принцип важен для команд, которые запускают браузеры на разном оборудовании. У хостов без интерфейса нет физического экрана, а виртуальные машины и контейнеры часто сообщают тайминг, определяемый нагрузкой хоста, а не каким-либо реальным монитором. Профиль описывает устройство с определенной частотой обновления, и видимый странице тайминг, который не совпадает с профилем, является расхождением между заявленным устройством и его наблюдаемым поведением. Примером служит профиль телефона на 120 Гц, у которого обратные вызовы приходят в темпе 60 Гц.

Почему обертки и расширения оставляют пробелы

Частота кадров является локальным свойством оборудования, которое браузер измеряет внутри собственного цикла экрана, поэтому инструменты, действующие в другом месте, до нее не дотягиваются. VPN или любой другой сетевой инструмент меняет маршрут запросов и не влияет на интервалы между вызовами. Приватный режим меняет место хранения данных, а не способ обновления экрана, поэтому измерение в приватном окне совпадает с измерением в обычном.

Расширения и скрипты страницы, изменяющие requestAnimationFrame, имеют больше возможностей, но упираются в ограничения. Распространены три подхода, и каждый оставляет заметный пробел.

• Ограничение обратного вызова. Скрипт может обернуть API и вызывать исходную функцию с меньшей целевой частотой. Тогда обычные анимации начинают подтормаживать, а CSS-анимации продолжают идти с реальной частотой экрана, поэтому два источника времени противоречат друг другу.
• Переписывание отметок времени. Изменение DOMHighResTimeStamp, передаваемого в функции, может имитировать другую частоту, но performance.now(), Date.now() и тайминг CSS-переходов продолжают сообщать исходный темп.
• Блокировка API. Отключение requestAnimationFrame ломает множество веб-приложений, которые используют его для отрисовки.

Общая причина в том, что эти инструменты находятся на уровне JavaScript, тогда как частота экрана проявляется в нескольких местах. Изменение одного места без остальных создает несогласованность, а несогласованность противоречит устройству, которое описывает профиль.

Параметры разработчика в некоторых браузерах позволяют ограничить частоту кадров. Ограничение сдерживает скорость отрисовки, но это потолок, а не выбранная цель. Нельзя запросить конкретную частоту для отдельного сеанса, ограничение не может поднять частоту выше той, что дает экран хоста, а сам механизм может проявляться заметными артефактами. Профиль с объявленными 120 Гц таким способом не воспроизвести с хоста на 60 Гц.

Настройка частоты кадров экрана

BotBrowser поддерживает настройку частоты кадров экрана через --bot-fps, который принимает profile, real или число. Это элемент управления ENT Tier2, поэтому ему нужен профиль с включением ENT Tier2. Когда параметр задан, тайминг requestAnimationFrame следует выбранной частоте, а не той, с которой случайно работает экран хоста.

Режим профиля

В режиме profile, который используется по умолчанию, BotBrowser читает частоту обновления, сохраненную в загруженном профиле, и подгоняет под нее тайминг requestAnimationFrame.

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --bot-fps=profile

Профиль описывает целевое устройство. Профиль, снятый с оборудования на 60 Гц, сообщает темп 60 Гц, а профиль, снятый с устройства на 120 или 144 Гц, сообщает более быстрый темп, какой бы частотой ни работал экран хоста. В большинстве случаев это правильный выбор, потому что частота обновления остается связанной с остальным описанием устройства и не требует решения при каждом запуске.

Фиксированное значение

Число задает точную частоту, и тайминг кадров и интервалы отрисовки следуют ей на любом оборудовании хоста.

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --bot-fps=60

Используйте его, когда в парке машин смешаны мониторы с высокой частотой и хосты без интерфейса с неровным собственным таймингом, а вам нужен один и тот же темп везде. Выбирайте значения, которые существуют у реальных экранов, например 60, 75, 90, 120, 144, 165 или 240. Значение вроде 73 или 137 не соответствует ни одному монитору, который вероятно есть у посетителя, поэтому противоречило бы экрану, который описывает профиль.

Реальный режим

Значение real использует собственную частоту экрана хоста.

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --bot-fps=real

Оно подходит, когда оборудование хоста уже соответствует цели профиля. Это еще и удобная диагностика. Запуск одной и той же страницы с real и с profile показывает, откуда берется нестабильность: от нагрузки отрисовки на хосте или от настроек профиля.

Параметр --bot-fps управляет только таймингом экрана и выполнения. У воспроизведения видео есть собственный элемент управления, он описан дальше, поэтому страница может сохранить темп экрана 60 Гц, пока ее элементы видео обновляются реже.

Темп воспроизведения видео и нагрузка на CPU

Элементы видео продолжают декодировать и отрисовывать кадры, даже когда рабочий процесс читает только текст, сетевые ответы, состояние DOM или время от времени делает снимок экрана. На странице мониторинга, панели очередей или каталоге с большим количеством медиа это декодирование может быть самой большой отдельной статьей затрат на вкладку, и она растет вместе с числом вкладок.

Для этого случая BotBrowser поддерживает --bot-video-fps=<actual>[:<reported>]. Это элемент управления ENT Tier2, который работает на профилях с включенным Video FPS Control. Профили без него параметр игнорируют.

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --bot-video-fps=1:30

Параметр принимает три формы.

• --bot-video-fps=1 декодирует и отрисовывает видео около 1 FPS и сообщает 1 FPS.
• --bot-video-fps=1:30 отрисовывает видео около 1 FPS, а медиа сообщает 30 FPS.
• --bot-video-fps=1:real отрисовывает видео около 1 FPS и сообщает темп, который заявляет само медиа, если он доступен.

Первое значение это фактический визуальный темп, он определяет, как часто обновляются кадры видео. Второе значение задает политику сообщаемого медиа темпа, а если его опустить, сообщается фактическое значение. Настройка real выравнивает сообщаемые значения по темпу, который заявляет медиа, а не по сниженному фактическому темпу.

Пиксельный вывод следует фактическому темпу, и это единственное ограничение, которое нужно учитывать. Рабочий процесс, который покадрово сэмплирует пиксели видео или делает снимки экрана, где должно быть свежее видео, увидит сниженный темп. Для таких процессов выбирайте более высокое фактическое значение, например 5:30 или 10:30, либо не используйте параметр. Снимок экрана, где видео показано в более низком темпе, соответствует заданному поведению, а не является сбоем.

То же рассуждение относится к любой проверке, оценивающей качество воспроизведения. Тест, который считает потерянные кадры, проверяет плавность воспроизведения или сравнивает соседние кадры видео, измеряет фактический темп, поэтому ему нужна полная частота, и запускать его следует без --bot-video-fps. Параметр подходит для обратного случая, когда видео служит фоновым материалом, а работа идет в DOM, в сети или в тексте страницы.

Публичный тест BotBrowser измеряет эффект на рабочей нагрузке с большим количеством видео. В тесте использовалась официальная сборка Linux x64 в режиме без интерфейса, локальное видео AVC размером 640 на 360 пикселей и 30 FPS в каждом элементе, 10 секунд прогрева, окно выборки 30 секунд и 3 повтора для каждой настройки. Базовая политика 30:30 сравнивалась с 1:30.

Одновременных видео	Базовая средняя нагрузка CPU	Средняя нагрузка CPU с 1:30	Снижение
8	33,96 %	9,70 %	71,43 %
16	61,20 %	12,10 %	80,24 %
24	76,49 %	13,81 %	81,95 %

Эти цифры описывают одну нагрузку на одной платформе. Использование CPU зависит от хоста, драйвера, кодека и содержимого страницы, поэтому воспринимайте диапазон от 71 до 82 % как ориентир из теста с большим количеством видео, где допускался более низкий визуальный темп, а не как экономию, которую можно ожидать везде. Полная конфигурация приведена в тесте Video FPS Control.

Когда оба элемента управления используются вместе, среда отображения сохраняет темп 60 Гц, а элементы видео обновляются реже.

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --bot-fps=60 \
  --bot-video-fps=1:30

Выбор значений и проверка результата

Рассматривайте FPS экрана и FPS видео как два решения с разными владельцами. FPS экрана входит в описание устройства, поэтому он должен совпадать с загруженным профилем, если только вы намеренно не проверяете другой класс экрана. Профиль офисного ноутбука на 60 Гц, мобильный профиль на 120 Гц и профиль настольного компьютера с высокой частотой не стоит смешивать небрежно, потому что тайминг кадров соседствует с размером экрана, плотностью пикселей устройства, выводом GPU и таймингом анимаций. Руководство по управлению профилями рассматривает, как профили хранятся и ротируются.

FPS видео это эксплуатационный выбор. Начните с осторожного значения: 1:30, когда достаточно редких визуальных обновлений, и более высокого фактического темпа, когда снимкам экрана нужны более свежие кадры. Покадровое сравнение пикселей видео это случай, который исключает очень низкие значения.

Для парков машин записывайте политику по каждой нагрузке. Держите одну политику для страниц, которым нужно полное визуальное воспроизведение, другую для фоновых страниц с медиа и третью для процессов со снимками экрана. Записанная политика облегчает последующий разбор изменений производительности и отделяет настройку нагрузки от решений о согласованности профиля.

Чтобы проверить результат, измеряйте на видимой вкладке. Соберите отметки времени примерно шестидесяти последовательных вызовов requestAnimationFrame, усредните интервалы и сравните полученную частоту с заданной. Затем сравните ее с показанием, снятым с CSS-анимации. Для видео сравните загрузку CPU и видимый темп с --bot-video-fps и без него. Запуски без интерфейса и с интерфейсом могут различаться под нагрузкой, поэтому проверьте оба с одним и тем же профилем и параметрами. Руководство по согласованности режимов без интерфейса и с интерфейсом рассматривает эти различия.

Превращение выборки таймингов в проверку отказа

Этот сборщик записывает 120 интервалов последовательных вызовов анимации. Запустите его в консоли DevTools страницы, пока вкладка остается видимой; медиана оценивает обычный темп, а 95-й процентиль показывает хвост задержанных кадров, который может скрыть среднее значение.

const intervals = [];
let previous;
let valid = document.visibilityState === 'visible';
if (!valid) console.log('sample invalid: open the page in a visible tab');
document.addEventListener('visibilitychange', () => {
  if (document.visibilityState !== 'visible') {
    valid = false;
    console.log('sample invalid: tab became hidden');
  }
});
function sample(timestamp) {
  if (!valid) return;
  if (previous !== undefined) intervals.push(timestamp - previous);
  previous = timestamp;
  if (intervals.length < 120) {
    requestAnimationFrame(sample);
    return;
  }
  const sorted = [...intervals].sort((a, b) => a - b);
  const middle = sorted.length / 2;
  const medianIntervalMs = (sorted[middle - 1] + sorted[middle]) / 2;
  const p95IntervalMs = sorted[Math.ceil(sorted.length * 0.95) - 1];
  console.log(
    JSON.stringify({
      visible: valid && document.visibilityState === 'visible',
      intervalCount: intervals.length,
      medianIntervalMs: Number(medianIntervalMs.toFixed(2)),
      p95IntervalMs: Number(p95IntervalMs.toFixed(2)),
      estimatedHz: Number((1000 / medianIntervalMs).toFixed(1)),
    })
  );
}
if (valid) requestAnimationFrame(sample);

Читайте выборку как проверку ветки, а не как вывод об устройстве:

Наблюдение	Что это устанавливает	Следующая проверка
Вкладка стала скрытой до завершения 120 интервалов	Фоновое ограничение сделало выборку недействительной	Оставьте вкладку видимой и повторите тот же захват
Медиана близка к выбранной частоте, но p95 намного больше	Обычный темп есть, но в хвосте присутствуют задержанные кадры	Повторите на свободном хосте и проверьте нагрузку CPU/GPU до смены профиля
Медиана следует real, но не частоте, заявленной профилем	Тайминг хоста и профиля расходятся	Проверьте активный аргумент --bot-fps и частоту экрана профиля
requestAnimationFrame совпадает, а видео медленно идет при 1:30	Частота экрана и фактический темп видео разделены согласно настройке	Уберите ограничение видео для покадровых пикселей или проверки качества воспроизведения

Существующий список неполадок рассматривает отклонение и медленное видео. Эти строки добавляют воспроизводимый способ отличить недействительную фоновую выборку, хвост дрожания, расхождение хоста и профиля и намеренное ограничение видео до изменения любого из параметров.

Большинство проблем укладывается в несколько схем.

• Измеренная частота расходится с заданной: проверьте, не перегружены ли CPU и GPU хоста, потому что тяжелая нагрузка отрисовки может добавлять дрожание вокруг целевой частоты.
• Профиль говорит о 120 Гц, а измерение показывает около 60: убедитесь, что --bot-fps не зафиксирован на 60, и проверьте параметры запуска работающего процесса.
• Видео сообщает 30 FPS, но выглядит медленным: при --bot-video-fps=1:30 это ожидаемо, потому что сообщаемые FPS и визуальный темп разделены по замыслу.
• Параметр видео не действует: убедитесь, что в профиле включен Video FPS Control, потому что профили без него параметр игнорируют.

Частота кадров это лишь часть тайминга выполнения, который может наблюдать страница. Руководство по таймингам производительности рассматривает соседние сигналы времени.

BotBrowser поддерживает настройку частоты кадров экрана через --bot-fps (profile, real или фиксированное значение) и темпа воспроизведения видео через --bot-video-fps на профилях с включенным Video FPS Control, поэтому тайминг requestAnimationFrame следует выбранному профилю, а страницы с большим количеством видео могут расходовать меньше CPU. Для вас это означает частоту обновления, соответствующую выбранному устройству, и меньшую нагрузку на CPU на страницах, полных видео, при раздельном выборе FPS экрана и FPS видео. BotBrowser не включает эти элементы управления без включения ENT Tier2 в профиле, не применяет --bot-video-fps на профилях без Video FPS Control, не может гарантировать такую же экономию CPU за пределами проверенной нагрузки и не заменяет выбор профиля, у которого сигналы экрана, GPU и времени согласованы.

Что добавлено по сравнению со справочной страницей

Справочная страница описывает управление дисплеем. Добавленное сравнение отдельно записывает интервалы requestAnimationFrame и темп видео в режимах профиля, фиксированном и реальном. Если анимация стабильна, а видео нет, проверьте медиатракт и нагрузку хоста.

Источники

• Reference

• Reference

• Reference

• Reference

Практический итог

Относитесь к FPS экрана и FPS видео как к двум решениям: первый должен совпадать с профилем, второй выбирается по нагрузке на CPU. Если профиль говорит о 120 Гц, а замер показывает около 60, сначала проверьте, не зафиксирован ли --bot-fps на 60, и параметры запуска процесса.