Skip to content

feat: map the remaining sender encoding parameters - #316

Merged
devopvoid merged 1 commit into
mainfrom
feat/encoding-parameters
Sep 30, 2026
Merged

devopvoid merged 1 commit into
mainfrom
feat/encoding-parameters

Conversation

@devopvoid

Copy link
Copy Markdown
Owner

RTCRtpEncodingParameters and RTCRtpSendParameters gain the encoding parameters WebRTC has and the Java API didn't. This makes simulcast, SVC and degradation behavior controllable from Java.

API

On RTCRtpEncodingParameters:

Field What it does
rid RTP stream ID, for simulcast through RTCRtpTransceiverInit.sendEncodings
scaleResolutionDownTo Absolute size cap (new RTCResolutionRestriction); takes precedence over scaleResolutionDownBy
scalabilityMode SVC mode, e.g. L1T3, L3T3_KEY
numTemporalLayers The older way to ask for temporal layers
bitratePriority, networkPriority Sender priorities (share of bitrate, DSCP)
adaptivePtime Longer audio packets at low bitrates
codec A codec of its own for the encoding, e.g. mixed-codec simulcast

On RTCRtpSendParameters: degradationPreference, with the new RTCDegradationPreference enum.

On RTCRtpCodecCapability: getScalabilityModes(), the modes a codec supports, i.e. what scalabilityMode accepts.

Behavior, checked against WebRTC's source

  • Priorities: bitratePriority and networkPriority apply to the whole sender. WebRTC accepts them on the first encoding only (PerSenderRtpEncodingParameterHasValue), and the Javadoc says so.
  • rid: can't be changed after the transceiver is created; setParameters() throws.
  • Scalability modes: an unsupported one makes setParameters() throw (CheckScalabilityModeValues).
  • Degradation default: unset, WebRTC keeps the resolution of screen shares and of detail/text content hints, and the frame rate of other video. BALANCED is only a default behind a field trial.

Testing

RTCRtpEncodingParametersTests (9 tests):

  • simulcast rids, scales and priorities round-trip through addTransceiver
  • a changed rid is rejected
  • priorities on a later encoding are rejected
  • scaleResolutionDownTo and degradationPreference round-trip
  • adaptivePtime round-trips on audio
  • in a live VP8 call, L1T3 is applied and frames keep flowing
  • L3T3 is rejected for VP8, and VP8's capability lists L1T3 but not L3T3
  • a per-encoding codec round-trips

mvn -pl webrtc test: 193 tests pass. -Pjni-check: 193 tests pass, with no FATAL ERROR in native method.

Docs

The media constraints guide (docs/guide/media/constraints.md) has new sections on absolute resolution caps, degradation preference, simulcast, scalability modes and priorities.

RTCRtpEncodingParameters gains the encoding parameters WebRTC has and the
Java API did not: rid for simulcast, scaleResolutionDownTo (with the new
RTCResolutionRestriction), scalabilityMode and numTemporalLayers for SVC,
bitratePriority and networkPriority, adaptivePtime for audio, and codec to
send an encoding with a codec of its own. RTCRtpSendParameters gains
degradationPreference, with the new RTCDegradationPreference.

RTCRtpCodecCapability gains getScalabilityModes(), the modes a codec
supports, which is what scalabilityMode accepts; unsupported modes make
setParameters() fail. The priorities apply to the whole sender, and WebRTC
accepts them on the first encoding only, which the Javadoc says.

The media constraints guide covers the new parameters, with simulcast and
scalability modes.
@devopvoid
devopvoid merged commit 239d6d2 into main Sep 30, 2026
24 checks passed
@devopvoid
devopvoid deleted the feat/encoding-parameters branch September 30, 2026 21:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant