WebRTC: Legacy getStats()-migratiegids

Henrik Boström

De oude getStats() WebRTC API wordt verwijderd in Chrome 117. Daarom moeten apps die hiervan gebruikmaken, migreren naar de standaard API. In dit artikel wordt uitgelegd hoe u uw code kunt migreren en wat u moet doen als u meer tijd nodig heeft om deze wijziging door te voeren.

Historisch gezien zijn er twee concurrerende versies van de WebRTC getStats() API geweest. De oude getStats() API, die dateert van vóór het standaardisatieproces en een callback-argument accepteert, en de gestandaardiseerde en breed ondersteunde API die een belofte teruggeeft.

De standaard API is rijker aan functies en beschikt over goed gedefinieerde statistieken die openbaar zijn gedocumenteerd in de W3C-specificatie Identifiers for WebRTC's Statistics API . De specificatie bevat beschrijvingen van elke statistiek die in deze handleiding wordt vermeld, en nog veel meer.

Vanaf Chrome 117 genereert de oude getStats() API een uitzondering in het stabiele releasekanaal (het genereren van uitzonderingen wordt geleidelijk uitgerold). Volg deze handleiding om uw overstap naar de standaard API te vergemakkelijken.

Legacy versus standaardstatistieken

De volledige lijst met standaardstatistiekentypen kunt u vinden door naar de RTCStatsType- opsomming in de specificatie te kijken. Dit omvat onder meer welke definitie van het statistiekenwoordenboek de voor elk type verzamelde statistieken beschrijft.

De stats-objecten hebben allemaal een id-attribuut dat het onderliggende object op unieke wijze identificeert via meerdere getStats() -aanroepen. Telkens wanneer de methode wordt aangeroepen, heeft hetzelfde object dezelfde ID. Dit is handig voor het berekenen van de mate waarin statistieken veranderen (er staat een voorbeeld in de volgende sectie). De ID's vormen ook referentierelaties. Het outbound-rtp stats-object verwijst bijvoorbeeld naar het bijbehorende media-source stats-object via het outbound-rtp.mediaSourceId attribuut. Als je alle ...Id relaties tekent, krijg je een grafiek.

De oude API heeft de volgende typen statistieken, die als volgt overeenkomen met de standaardtypen:

Verouderd naar standaard metrische gegevenstoewijzing

Deze mapping is bedoeld om ontwikkelaars te helpen bepalen welke oude statistiek overeenkomt met welke standaardstatistiek. Houd er echter rekening mee dat de overeenkomstige statistiek verschillende eenheden kan gebruiken of kan worden uitgedrukt als een totaalteller in plaats van een momentane waarde. Raadpleeg de specificatie voor metrische definities.
De standaard-API geeft er de voorkeur aan totaaltellers weer te geven in plaats van tarieven. Dit betekent dat om de overeenkomstige snelheid (bijvoorbeeld bitrate) te krijgen, zoals in de oude API, de app de gemiddelde snelheid moet berekenen door de delta tussen twee getStats() -aanroepen te nemen. Bijvoorbeeld:

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

Het op deze manier zelf berekenen van tarieven en gemiddelden lijkt misschien een omslachtige extra stap, maar het heeft het voordeel dat u gemiddelden kunt krijgen over elk gewenst tijdsinterval. Het minder vaak aanroepen van de standaard API dan u anders met de oudere API zou hebben gedaan, heeft enkele prestatievoordelen.

De standaard API is simulcast-bewust

Als u simulcast gebruikt, is het u misschien opgevallen dat de oude API slechts één enkele SSRC rapporteert, zelfs als u simulcast gebruikt om (bijvoorbeeld) drie RTP-streams over drie afzonderlijke SSRC's te verzenden.

De standaard-API deelt deze beperking niet en retourneert drie outbound-rtp statistiekobjecten, één voor elk van de SSRC's. Dit betekent dat u elke RTP-stream afzonderlijk kunt analyseren, maar het betekent ook dat u, om de totale bitsnelheid van alle RTP-verzendstreams te verkrijgen, deze zelf moet aggregeren.

SVC-streams of RTP-streams met meerdere ruimtelijke lagen geconfigureerd via de scalabilityMode API verschijnen daarentegen nog steeds als een enkele outbound-rtp omdat deze via een enkele SSRC worden verzonden.

Als u meer tijd nodig heeft voor de migratie

Wanneer de oude API in Chrome 117 wordt verwijderd, genereert het gebruik ervan een uitzondering. Als u uw code niet op tijd kunt migreren, geeft de oorspronkelijke proefversie van de RTCPeerConnection callback-gebaseerde getStats() API geregistreerde websites meer tijd om te migreren. Met een origin-proeftoken kan de oude getStats() API blijven worden gebruikt tot Chrome 121.