Resolve default video degradation preference by track source, including the backup codec - #1083
Merged
xianshijing-lk merged 1 commit intoAug 10, 2026
Conversation
`.auto` resolved to `.maintainResolution` for every video track. It now resolves from the track source: camera maintains framerate, screen share maintains resolution, other sources fall back to balanced. Degradation preference is a sender-level property, and a backup codec publishes over its own sender, so it needs the preference applied separately. `publish(additionalVideoCodec:for:)` never set it, leaving the backup encoder to resolve one implicitly and potentially adapt along a different axis than the primary. Apply the resolved preference there too. Extract the sender parameter write into `LKRTCRtpSender.set(degradationPreference:)` so both publish paths share it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
hiroshihorie
approved these changes
Aug 8, 2026
xianshijing-lk
deleted the
sxian/default-degradation-preference-by-source
branch
August 10, 2026 14:58
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Aligns Swift with the behavior landed in client-sdk-android (livekit/client-sdk-android#991). Two related changes.
Source-based defaults
VideoPublishOptions.degradationPreferencealready defaults to.auto, documented as "The SDK will decide which preference is suitable" — but.autocollapsed to.maintainResolutionfor every video track:.autonow resolves from the track source: camera →.maintainFramerate(smoother video for real-time communication), screen share →.maintainResolution(clarity matters for text/UI), other →.balanced.balancedis the preference the WebRTC spec mandates as the default and is the honest choice when the application declined to declare a motion-vs-detail intent.No API change —
.autoalready existed with exactly these semantics. An explicitly set preference still wins; the source default only applies to.auto.Backup codec sender
Degradation preference is a property of the sender, not of the track — a top-level field on
RtpParameters, not per-encoding.publish(additionalVideoCodec:for:)adds a second transceiver and therefore a second sender, which was never configured, so the backup encoder resolved a preference implicitly from the native source and could adapt along a different axis than the primary.Both senders sink from the same video source, so a diverging backup does not just degrade itself — its restriction is merged onto the shared source and affects the primary too.
Both publish paths now resolve the preference the same way and share
LKRTCRtpSender.set(degradationPreference:), extracted from the existing inline parameter write (the "changing params directly doesn't work" dance is preserved).Note simulcast is unaffected — all simulcast encodings live under one sender and already share its preference. Only the backup codec is a separate sender.
Tests
Tests/LiveKitCoreTests/DegradationPreferenceTests.swiftcovers the three source mappings for.auto, explicit preferences winning over the source default, and the.autodefault onVideoPublishOptions.swift buildclean, the 4 new tests pass, and theLiveKitCoreTestsfailure count is unchanged frommain(132 issues on both, all from integration tests that need a local LiveKit server).swiftformat --lintclean on all touched files.Cross-SDK
client-sdk-js gets the backup-sender half in livekit/client-sdk-js#2040 (its source-based defaults already matched); client-sdk-flutter gets both in livekit/client-sdk-flutter#1155. The Rust SDK already resolves the same defaults and has no backup-codec publish path.
🤖 Generated with Claude Code