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
SendableMetatype added a commit to EduGeyser/webrtc-java that referenced this pull request Oct 10, 2026
Brings in upstream 0.19.0 and the work after it: the FFmpeg-based
webrtc-java-media module with its native extension API (devopvoid#291, devopvoid#292,
devopvoid#299, devopvoid#300), encoded frame transforms (devopvoid#300), the remaining sender
encoding parameters and RTCConfiguration fields (devopvoid#316, devopvoid#317), custom
and hardware video codec factories (devopvoid#303, devopvoid#310 to devopvoid#315, devopvoid#318 to devopvoid#330),
the log sink and 32-bit ARM stats fixes, and upstream's CI rework
(devopvoid#294 to devopvoid#309).

Fork-side adaptations:
- The media module builds with Gradle, and only in the full variant:
  it needs audio and video. On Linux it links like the JNI library,
  since the Chromium sysroots no longer ship the static libgcc_eh.a.
  The sysroots carry stubs of glibc that no executable links against,
  so FFmpeg's configure links with lld and allows undefined symbols in
  shared libraries.
- The data channels variant leaves out the new media sources, the codec
  factory setup and the hardware codec headers, and skips the new tests
  that need audio or video.
- The module tests run on the module path with the test resources
  patched in, and the core tests open the internal package that
  NativeApi and NativeLoader are tested in.
- The WebRTC checkout keeps this fork's sync, with upstream's
  checkout_instrumented_libraries setting.
- CI builds all platforms from one reusable workflow, as upstream now
  does. The full variant also builds FFmpeg and tests the media module.
  The WebRTC and FFmpeg caches are saved as soon as their builds finish,
  and a release is prepared locally and pushed in one atomic push.
- The Maven poms and upstream's Dependabot setup stay out, and the
  README is the fork's own; the rename script now leaves it alone.
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