WebRTC: przewodnik po migracji starszej wersji getStats()

Henrik Boström

Starszy interfejs getStats() WebRTC API zostanie usunięty w Chrome 117, dlatego korzystające z niego aplikacje będą musiały przejść na standardowy interfejs API. Z tego artykułu dowiesz się, jak przenieść kod i co zrobić, jeśli potrzebujesz więcej czasu na wprowadzenie tej zmiany.

W przeszłości istniały 2 rywalizujące wersje interfejsu API WebRTC getStats(). Starsza wersja interfejsu API getStats(), która jest znana przed procesem standaryzacji i przyjmuje argument wywołania zwrotnego, oraz standardowy i powszechnie obsługiwany interfejs API, który zwraca obietnicę.

Standardowy interfejs API ma więcej funkcji i ma dobrze zdefiniowane dane publicznie udokumentowane w identyfikatorze interfejsu API WebRTC specyfikacji W3C. Specyfikacja zawiera opisy wszystkich wskaźników wymienionych w tym przewodniku i wiele innych.

Od wersji Chrome 117 starsza wersja interfejsu API getStats() będzie zgłaszać wyjątek w kanale wersji stabilnej (zrzucanie wyjątków będzie wdrażane stopniowo). Ten przewodnik ułatwi Ci przejście na standardowy interfejs API.

Starsze i standardowe typy statystyk

Pełną listę standardowych typów statystyk można znaleźć na wyliczeniu RTCStatsType w specyfikacji. Obejmuje to definicja słownika statystyk opisująca dane zbierane dla poszczególnych typów.

Wszystkie obiekty statystyczne mają atrybut id, który jednoznacznie identyfikuje bazowy obiekt w wielu wywołaniach getStats(). Przy każdym wywołaniu metody ten sam obiekt będzie miał ten sam identyfikator. Przydaje się to do obliczania częstotliwości zmian danych (przykład znajdziesz w następnej sekcji). Identyfikatory tworzą także relacje między odwołaniami. Na przykład obiekt statystyk outbound-rtp odwołuje się do powiązanego obiektu statystyk media-source za pomocą atrybutu outbound-rtp.mediaSourceId. Jeśli narysujesz wszystkie relacje typu ...Id, otrzymasz wykres.

Starszy interfejs API ma następujące typy statystyk odpowiadające typom standardowym:

Mapowanie danych ze starszej wersji na standardowe

Mapowanie ma pomóc deweloperom w znalezieniu, które starsze dane odpowiadają określonym standardowym danym. Pamiętaj jednak, że odpowiednie dane mogą mieć inne jednostki lub być wyrażone jako licznik sumy, a nie wartość błyskawiczna. Definicje danych znajdziesz w specyfikacji.
Standardowy interfejs API preferuje ujawnianie sumy liczników zamiast współczynników. Oznacza to, że aby uzyskać odpowiednią szybkość (np. szybkość transmisji bitów) jak w starszym interfejsie API, aplikacja musi obliczyć średnią szybkość, uwzględniają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;

Konieczność samodzielnego obliczania współczynników i średnich może wydawać się uciążliwa, jednak w takiej sytuacji umożliwia uzyskanie średnich wartości w dowolnym przedziale czasu. Wywołując standardowy interfejs API rzadziej niż w przypadku starszego interfejsu API ma to pewne zalety w zakresie wydajności.

Standardowy interfejs API jest wykorzystujący funkcję simulcast

Jeśli używasz narzędzia simulcast, możesz zauważyć, że starsza wersja interfejsu API zgłasza tylko jeden kod SSRC, nawet jeśli używasz tej metody do wysyłania (np.) 3 strumieni RTP za pomocą 3 osobnych kodów SSRC.

Standardowy interfejs API nie ma tego ograniczenia i zwraca 3 obiekty statystyk outbound-rtp, po jednym dla każdego kodu SSRC. Oznacza to, że możesz analizować każdy strumień RTP oddzielnie, ale oznacza to również, że aby uzyskać łączną szybkość transmisji bitów wszystkich strumieni RTP, musisz je zagregować samodzielnie.

Strumienie SVC lub RTP z wieloma warstwami przestrzennymi skonfigurowanymi za pomocą interfejsu API scalabilityMode z drugiej strony nadal wyświetlają się jako pojedynczy element outbound-rtp, ponieważ są one wysyłane przez pojedynczy kod SSRC.

Jeśli potrzebujesz więcej czasu na migrację

Po usunięciu starszej wersji interfejsu API w Chrome 117 użycie go spowoduje wygenerowanie wyjątku. Jeśli nie możesz przeprowadzić migracji kodu na czas, okres próbny źródła dla interfejsu API getStats() opartego na wywołaniach zwrotnych RTCPeerConnection daje zarejestrowanych witrynom więcej czasu na migrację. W przypadku tokena próbnego origin starszy interfejs API getStats() może być nadal używany do wersji Chrome 121.