Fix local track dimensions during device rotation#950
Open
Conversation
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
pblazej
force-pushed
the
blaze/rotation-dimension-freeze
branch
from
841f4c8 to
c5c724d
Compare
Trigger setNeedsLayout() when track dimensions change so performLayout() recomputes the renderer frame. Since WebRTC m137 the Metal renderer no longer does this internally, causing stale/distorted video after rotation. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
pblazej
force-pushed
the
blaze/rotation-dimension-freeze
branch
from
6bf7e10 to
e040846
Compare
Contributor
Author
|
@hiroshihorie the change is totally additive, but I'll wait till it's confirmed to work (multiple moving parts here). |
…tion On certain devices (e.g. iPhone 11), the accelerometer oscillates at landscape orientation boundaries, causing WebRTC's RTCCameraVideoCapturer to alternate frame rotation between portrait and landscape on every frame. This produced continuous dimension toggling (1280x720 ↔ 720x1280) that thrashed encoder parameters, layout, and Metal drawable sizing—freezing the local video preview permanently. - Require 3 consecutive frames with the same dimensions before accepting a change in VideoCapturer.set(dimensions:) (first value and nil still propagate immediately) - VideoView.render() reads capturer.dimensions (stabilized) for local tracks instead of computing from raw frame rotation - Guard rotationOverride setter in performLayout() to avoid transient zero drawableSize on every layout pass Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Resolves #949
My initial speculation was that the orientation (dimensions) is unstable between the capturer/track/publication - so we need more
debounce- during the actual rotation.Probably the reason is simpler, disabling
isDebugModealso disablesfpsTimerthat may resolve the dimensions "automatically" (in non-smooth way).Note: this is only reproducible with UIKit (uikit-minimal example), SwiftUI does the layout thing implicitly.
No exact change that could have caused that (maybe still m137 regression - order of operations?).