WebRTC encodingInfo Says Supported: Why Is Send Resolution Lower?
Your camera captures large frames and encodingInfo says the codec is supported, yet Firefox sends smaller ones. What is scaling them down, and where do you see it during the call?
- Firefox 158 can scale H.264 and AV1 output to the negotiated codec level.
- A true encodingInfo support result does not promise unchanged send dimensions.
- Use about:webrtc or outbound-rtp statistics to inspect encoded output during the call.
A supported configuration can still be scaled down
Firefox 158 can lower outgoing H.264 and AV1 resolution and frame rate to remain within the codec level negotiated with the peer. Consequently, Mozilla’s release notes say that encodingInfo() can report a WebRTC configuration as supported even when its dimensions and frame rate exceed the level in its content type.
The relevant parameters are H.264’s profile-level-id and AV1’s level-idx. A successful capability query therefore cannot serve as the call’s measured send resolution.
The implementation record also documents constraining both encoders to the negotiated level. This is one specific behavior to consider, not a diagnosis of every low-quality call.
Capability booleans are not live call statistics
encodingInfo evaluates a proposed media configuration. For a WebRTC send configuration, the type is "webrtc", with video properties including content type, dimensions, bitrate and frame rate.
| Result | What it describes |
|---|---|
supported | Whether the media can be encoded. |
smooth | Whether smooth processing is expected. |
powerEfficient | Whether power-efficient processing is expected. |
These answers help choose a configuration. They do not measure the dimensions or frame rate currently leaving an established call.
Read encoded output while the call is active
In Firefox, open about:webrtc in another tab during the call. Mozilla’s debugging guide describes negotiation details, RTP statistics, bandwidth information and output-frame statistics under RTCPeerConnection Statistics. Expand the relevant connection to inspect them together.
In application code, inspect outbound-rtp reports. Here, pc is the application’s existing RTCPeerConnection:
const stats = await pc.getStats();
for (const report of stats.values()) {
if (report.type === "outbound-rtp" && report.kind === "video") {
console.log({
id: report.id,
width: report.frameWidth,
height: report.frameHeight,
fps: report.framesPerSecond
});
}
}The width and height describe the last encoded frame. The frame-rate field reports encoded frames sent during the last second. Detailed field availability can vary; preserve missing values rather than converting them into zero measurements. Sender output also differs from what the remote display ultimately renders.
Keep capture settings separate from send statistics
For the input track, getSettings() returns current settings. It differs from getConstraints(), which reports the requested constraints.
If captured frames are larger than encoded frames, increasing a capture request alone does not explain the difference. Compare current input settings, negotiated codec limits and measured output. Use the capability query to select candidates and live statistics to report the call’s send resolution.