Change default degradation preference by video source - #991
Change default degradation preference by video source#991xianshijing-lk wants to merge 2 commits into
Conversation
🦋 Changeset detectedLatest commit: b3cf152 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
xianshijing-lk
left a comment
There was a problem hiding this comment.
@adrian-niculescu @davidliu , I broke down default degradation preference changes from #973 to keep the discussion more focused.
Please review this PR.
|
Diffuse output: AARJAR |
adrian-niculescu
left a comment
There was a problem hiding this comment.
The backup codec sender never gets the preference.
publishAdditionalCodecForTrack creates a second transceiver over the same rtcTrack and never touches sender.parameters, so that sender keeps resolving implicitly from the native source's is_screencast. Consequences:
- Camera and screen share stay media-equivalent across the two encoders as long as
options.sourceagrees withtrack.options.isScreencast. A screencast-backed track published withsource = CAMERAnow diverges: primary MAINTAIN_FRAMERATE, backup MAINTAIN_RESOLUTION. - An application-supplied
degradationPreferencereaches the primary encoder only. - The new BALANCED fallback reaches the primary encoder only.
The explicit-override half predates this PR and JS has the same gap, but this PR is what makes a resolved preference a value worth carrying, so applying it to the backup sender belongs here.
| return when (source) { | ||
| Track.Source.CAMERA -> RtpParameters.DegradationPreference.MAINTAIN_FRAMERATE | ||
| Track.Source.SCREEN_SHARE -> RtpParameters.DegradationPreference.MAINTAIN_RESOLUTION | ||
| else -> RtpParameters.DegradationPreference.BALANCED |
There was a problem hiding this comment.
A custom feed published with VideoTrackPublishOptions(source = Track.Source.UNKNOWN) lands here, and this overwrites what libwebrtc would have derived from the native source: a screencast-backed track goes MAINTAIN_RESOLUTION to BALANCED, a camera-like one MAINTAIN_FRAMERATE to BALANCED. track.options.isScreencast already carries that information. BALANCED is also the mode libwebrtc keeps behind the WebRTC-Video-BalancedDegradation field trial, with the in-tree note that it "needs to be tuned first".
Proposal:
private fun getDefaultDegradationPreference(source: Track.Source): RtpParameters.DegradationPreference? {
return when (source) {
Track.Source.CAMERA -> RtpParameters.DegradationPreference.MAINTAIN_FRAMERATE
Track.Source.SCREEN_SHARE -> RtpParameters.DegradationPreference.MAINTAIN_RESOLUTION
else -> null
}
}The KDoc bullet above changes with it. Not a blocker: JS made the same BALANCED choice deliberately, so if this is cross-SDK alignment it stands, but the argument applies there too.
Summary
degradationPreferenceis not explicitly set.MAINTAIN_FRAMERATE.MAINTAIN_RESOLUTION.BALANCED.degradationPreferenceoverrides.Testing
git diff --checkAGENT_ERROR,PUBLISH_DATA_TRACK_RESPONSE,clientProtocol, etc.).