WebRTC: przewodnik po migracji starszej wersji getStats()

Henrik Boström

Starsza wersja interfejsu WebRTC API getStats() zostanie usunięta w Chrome 117, dlatego aplikacje korzystające z niego będą musiały zostać przeniesione do standardowego interfejsu API. Z tego artykułu dowiesz się, jak przenieść kod i co zrobić, jeśli potrzebujesz więcej czasu na wprowadzenie tej zmiany.

Wcześniej istniały 2 konkurujące wersje interfejsu WebRTC getStats() API. Starsza wersja interfejsu API getStats(), która jest wcześniejszym procesem standaryzacji i przyjmuje argument wywołania zwrotnego, oraz ustandaryzowany i szeroko obsługiwany interfejs API, który zwraca obietnicę.

Standardowy interfejs API jest bardziej rozbudowany i zawiera dobrze zdefiniowane wskaźniki, które zostały publicznie udokumentowane w specyfikacji W3C w sekcji Identifiers for WebRTC's Statistics API. Specyfikacja zawiera opisy poszczególnych danych wymienionych w tym przewodniku i wielu innych.

Od Chrome 117 starszy interfejs API getStats() zgłosi wyjątek w wersji stabilnej (wyjątki będą wdrażane stopniowo). Z tego przewodnika dowiesz się, jak łatwo przejść na standardowy interfejs API.

Porównanie starszych i standardowych typów statystyk

Pełną listę standardowych typów statystyk znajdziesz w wyliczeniu RTCStatsType w specyfikacji. Obejmuje to definicję słownika statystyk, która opisuje wskaźniki zebrane dla każdego typu.

Wszystkie obiekty statystyk mają atrybut id, który jednoznacznie identyfikuje bazowy obiekt w wielu wywołaniach getStats(). Ten sam obiekt będzie mieć taki sam identyfikator przy każdym wywołaniu metody. Jest to przydatne przy obliczaniu tempa zmian danych (przykład znajdziesz w następnej sekcji). Identyfikatory tworzą również relacje odwołań. Na przykład obiekt statystyk outbound-rtp odwołuje się za pomocą atrybutu outbound-rtp.mediaSourceId do powiązanego obiektu statystyk media-source. Jeśli narysujesz wszystkie relacje typu ...Id, pojawi się wykres.

Starsza wersja interfejsu API zawiera następujące typy statystyk odpowiadające typom standardowym:

Mapowanie danych starszego typu na standardowe

To mapowanie ma pomagać deweloperom w znalezieniu starszych danych odpowiadających poszczególnym standardowym danym. Pamiętaj jednak, że odpowiednie dane mogą używać innych jednostek lub być wyrażone w postaci licznika, a nie natychmiastowej wartości. Definicje danych znajdziesz w specyfikacji.
Standardowy interfejs API preferuje ujawnianie łącznej liczby liczników niż współczynniki. Oznacza to, że aby uzyskać odpowiednią szybkość (np. szybkość transmisji bitów) tak jak w starszym interfejsie API, aplikacja musi obliczyć średnią wartość, wykorzystując różnicę między 2 wywołaniami getStats(). Na przykład:

// 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;

Samodzielne obliczanie stawek i średnich może wydawać się dodatkowym uciążliwym zadaniem, a dodatkowo w końcu pojawia się możliwość uzyskania średnich wartości w dowolnym przedziale czasu. Wywołanie standardowego interfejsu API rzadziej niż w przypadku starszej wersji interfejsu API ma pewną poprawę wydajności.

Standardowy interfejs API obsługuje technologię Simulcast.

Jeśli korzystasz z simulcast, możesz zauważyć, że starszy interfejs API zgłasza tylko 1 SSRC, nawet jeśli używasz tej funkcji do wysyłania (np.) 3 strumieni RTP do 3 osobnych SSRC.

Standardowy interfejs API nie udostępnia tego ograniczenia i zwraca 3 obiekty statystyk outbound-rtp, po jednym dla każdego SSRC. Oznacza to, że każdy strumień RTP możesz analizować z osobna, ale aby uzyskać całkowitą szybkość transmisji bitów wszystkich wysyłanych strumieni RTP, musisz je zagregować samodzielnie.

Strumienie SVC lub strumienie RTP z wieloma warstwami przestrzennymi skonfigurowanymi przez interfejs scalabilityMode API są nadal wyświetlane jako pojedynczy element outbound-rtp, ponieważ są przesyłane przez jeden SSRC.

Jeśli potrzebujesz więcej czasu na migrację

Jeśli starszy interfejs API zostanie usunięty w Chrome 117, użycie go spowoduje wygenerowanie wyjątku. Jeśli nie uda Ci się przenieść kodu na czas, testy origin dla interfejsu API getStats() opartego na wywołaniach zwrotnych RTCPeerConnection zapewnią zarejestrowanym witrynom więcej czasu na migrację. Jeśli korzystasz z tokenu testowego origin, możesz korzystać ze starszej wersji interfejsu API getStats() do wersji Chrome 121.