WebRTC Metrics

A comprehensive overview of WebRTC statistics, derived calculations, extracted features, and observable signals, to better understand call quality, connectivity, and user experience in rtcStats

Back
trackvideoencoderdecodercpu

Encoder and decoder (feature)

Track-level features recording the encoder and decoder implementations, their power efficiency, and the average per-frame encode cost.

Description

Track-level features, extracted per video track into features_track.

These features tell you which codec implementation ran and what it cost:

  • encoderImplementation - name of the encoder used, and an indicator of whether it was hardware or software (outbound tracks).
  • powerEfficientEncoder - boolean, whether the encoder was considered power efficient (typically hardware accelerated).
  • decoderImplementation - name of the decoder used (inbound tracks).
  • powerEfficientDecoder - boolean, whether the decoder was considered power efficient.
  • averageEncodeTime - mean per-frame encode time, computed as totalEncodeTime / framesEncoded (outbound only).

Extracted by the open-source rtcstats-features package.

Why it matters

Hardware and software codec paths behave very differently. A hardware encoder is cheap on CPU and battery but limited in which profiles and resolutions it supports, and it can silently fall back to software when the client hits an unsupported configuration. encoderImplementation and decoderImplementation name the actual path taken, so you can spot fallbacks that quietly raise CPU cost.

powerEfficientEncoder and powerEfficientDecoder summarize the same thing as a boolean, handy for slicing a population into hardware versus software cohorts. averageEncodeTime puts a number on the cost: rising per-frame encode time is an early sign the sender is CPU bound, which precedes resolution drops and quality-limitation events. Split these by client version and you can catch a regression where a browser update flipped a cohort from hardware to software encoding.

Typical values

  • Hardware path: powerEfficientEncoder = true, low and stable averageEncodeTime.
  • Software path: powerEfficientEncoder = false, higher averageEncodeTime that climbs at higher resolutions.
  • Implementation names are browser specific (for example ExternalEncoder, libvpx, OpenH264).

SQL example

Compare encode cost between power-efficient and software encoders for outbound video:

SELECT
  track.power_efficient_encoder,
  COUNT(*)                       AS tracks,
  AVG(track.average_encode_time) AS avg_encode_time
FROM "rtcstats-server" AS server
JOIN features_metadata   AS metadata   ON metadata.dump_id    = server.id
JOIN features_connection AS connection ON connection.dump_id  = metadata.id
JOIN features_track      AS track      ON track.connection_id = connection.id
WHERE connection.connected         -- only connections that reached 'connected'
  AND track.kind = 'video'         -- 'audio' or 'video'
  AND track.direction = 'outbound' -- 'inbound' or 'outbound'
GROUP BY track.power_efficient_encoder;

Related features

  • Quality limitation - whether CPU pressure forced the encoder to back off.
  • Codec - the negotiated codec these implementations ran.

See also