Authors
Much of this explainer synthesizes and consolidates prior discussions and contributions from members of the WebRTC working group.
Game streaming platforms like Xbox Cloud Gaming and Nvidia GeForce Now rely on hardware decoding in browsers to deliver low-latency, power efficient experiences. However, there is currently no reliable way for these applications to detect when decoding silently falls back to software during a stream.
This proposal introduces a runtime event to notify applications when a decoder fallback occurs. The goal is to give developers actionable visibility into runtime behavior without exposing new fingerprinting vectors or hardware details.
End users of game streaming services may experience increased latency, degraded quality, and battery drain when the browser switches from hardware to software decoding. Developers currently lack a way to detect this fallback in real time without prompting users for camera/mic permissions. In the past, developers used to rely on decoderImplementation info, but as of Chromium M110+ it requires getUserMedia() permissions. This is not ideal because the UI prompt is invasive, it’s excessive since it grants access to the camera and mic hardware when apps don’t need it, and it has a high failure rate since users have little reason to grant the permission unless they want to use voice chat. This gap makes it difficult to diagnose performance regressions and provide troubleshooting guidance.
getUserMedia() permissions).MediaCapabilities already provides.Feedback from Xbox Cloud Gaming, Nvidia GeForce Now and similar partners shows:
getUserMedia() to query decoderImplementation has a high failure rate because users often deny permissions that are irrelevant to media playback.MediaCapabilities is insufficient because it only provides a static capability hint and does not reflect what happens at runtime, for example, when hardware decode fails mid-session and the browser silently falls back to software.Introduce an event on RTCRtpReceiver (see slide 30) that fires when a decoder error occurs:
This enables applications to alert users, re-negotiate codecs, and debug issues without requiring getUserMedia() permissions.
const pc = new RTCPeerConnection();
pc.addEventListener('track', (event) => {
const receiver = event.receiver;
// Listen for decoder state changes
receiver.addEventListener('decoderstatechange', (ev) => {
// Adapt application behavior based on power efficiency
if (!ev.powerEfficient) {
// Notify the user
showToast("Playback quality may be reduced");
// Lower resolution or disable heavy post-processing
adjustQuality('low');
// Log telemetry signal with codec and RTP timestamp
logMetric(`Decoder fallback: codec=${ev.codecString}, rtp=${ev.rtpTimestamp}`);
}
});
});
partial interface RTCRtpReceiver {
attribute EventHandler ondecoderstatechange;
};
interface RTCDecoderStateChangeEvent : Event {
constructor(DOMString type, RTCDecoderStateChangeEventInit eventInitDict);
// Media timeline reference
readonly attribute unsigned long rtpTimestamp;
// Codec now in effect after the change.
readonly attribute DOMString codecString;
// Align with MediaCapabilitiesInfo, powerEfficient changes primarily based on hardware/software decoder
// https://www.w3.org/TR/media-capabilities/#media-capabilities-info
readonly attribute boolean powerEfficient;
};
Note: The event fires at the beginning of streaming.
decoderImplementation info via WebRTC Stats API
getUserMedia() permissions, which are invasive and have a high failure rate.MediaCapabilitiesInfo.powerEfficient
decoderFallback field to RTCInboundRtpStreamStats
MediaCapabilitiesInfo.powerEfficient attribute. A “common implementation strategy” is to treat hardware usage as indicative of optimal power draw.Last discussed in the 2025-09-16 WebRTC WG Call: Slides 17-21 & minutes
Many thanks for valuable feedback and advice from:
Links to past working group meetings where this has been discussed: