WebRTC: руководство по миграции устаревшего метода getStats()

Henrik Boström

Устаревший API getStats() WebRTC будет удален в Chrome 117, поэтому приложениям, использующим его, необходимо будет перейти на стандартный API. В этой статье объясняется, как перенести код и что делать, если вам нужно больше времени для внесения этого изменения.

Исторически существовало две конкурирующие версии API WebRTC getStats() . Устаревший API getStats(), который предшествует процессу стандартизации и принимает аргумент обратного вызова, а также стандартизированный и широко поддерживаемый API, который возвращает обещание.

Стандартный API более функционален и имеет четко определенные метрики, публично задокументированные в спецификации W3C «Идентификаторы для API статистики WebRTC» . Спецификация включает описания каждой метрики, перечисленной в этом руководстве, и многих других.

Начиная с Chrome 117, устаревший API getStats() будет генерировать исключение в канале стабильной версии (выдача исключений будет постепенно внедряться). Следуйте этому руководству, чтобы облегчить переход на стандартный API.

Устаревшие и стандартные типы статистики

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

Все объекты статистики имеют атрибут id, который однозначно идентифицирует базовый объект при нескольких вызовах getStats() . Один и тот же объект будет иметь один и тот же идентификатор каждый раз при вызове метода. Это полезно для расчета скорости изменения метрик (пример есть в следующем разделе). Идентификаторы также образуют отношения ссылок. Например, объект статистики outbound-rtp ссылается на связанный объект статистики media-source через атрибут outbound-rtp.mediaSourceId . Если вы нарисуете все отношения ...Id вы получите график.

Устаревший API имеет следующие типы статистики, соответствующие стандартным типам:

Сопоставление устаревших и стандартных метрик

Это сопоставление призвано помочь разработчикам определить, какая устаревшая метрика соответствует какой стандартной метрике, но учтите, что соответствующая метрика может использовать другие единицы измерения или выражаться в виде общего счетчика, а не мгновенного значения. Определения метрик см. в спецификации.
Стандартный API предпочитает отображать общие счетчики, а не ставки. Это означает, что для получения соответствующей скорости (например, битрейта), как в устаревшем API, приложение должно вычислить среднюю скорость, взяв разницу между двумя вызовами getStats() . Например:

// Periodically (e.g. every second or every 10 seconds)...
const currReport = await pc.getStats();
// Calculate bitrate since the last getStats() call.
// Handling of undefined is omitted for clarity.
const currOutboundRtp = currReport.values().find(s => s.type == 'outbound-rtp');
const prevOutboundRtp = prevReport.get(currOutboundRtp.id);
const deltaBits = (currOutboundRtp.bytesSent - prevOutboundRtp.bytesSent) * 8;
const deltaSeconds = (currOutboundRtp.timestamp - prevOutboundRtp.timestamp) / 1000;
logBitrateMeasurement(deltaBits / deltaSeconds);
// Remember the report for next time.
prevReport = currReport;

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

Стандартный API поддерживает одновременную передачу

Если вы используете одновременную рассылку, вы, возможно, заметили, что устаревший API сообщает только об одном SSRC, даже если вы используете одновременную рассылку для отправки (например) трех потоков RTP по трем отдельным SSRC.

Стандартный API не разделяет это ограничение и возвращает три объекта статистики outbound-rtp , по одному для каждого из SSRC. Это означает, что вы можете анализировать каждый поток RTP индивидуально, но это также означает, что для получения общего битрейта всех потоков отправки RTP вам нужно будет агрегировать их самостоятельно.

С другой стороны, потоки SVC или потоки RTP с несколькими пространственными уровнями, настроенными через API scalabilityMode , по-прежнему отображаются как один outbound-rtp , поскольку они отправляются через один SSRC.

Если вам нужно больше времени для миграции

Когда устаревший API будет удален в Chrome 117, его использование приведет к возникновению исключения. Если вы не можете перенести свой код вовремя, пробная версия API getStats() на основе обратного вызова RTCPeerConnection дает зарегистрированным веб-сайтам больше времени для миграции. С пробным токеном происхождения устаревший API getStats() можно продолжать использовать до Chrome 121.