feat(ios): live AVC bitrate control and keyframe requests - #358
Open
gmegidish wants to merge 1 commit into
Open
Conversation
…ream conn SetAvcBitrate/RequestAvcKeyFrame previously rejected iOS devices (a leftover from the MJPEG days), leaving the REMB feedback loop dead: the device's H.264 encoder ran uncapped for the whole session (observed 22-38 Mbps for a 602x1310 stream). Both platforms now accept the same JSON-RPC payload (screencapture.setBitrate with 'bps'); only the transport differs — Android over the localabstract control socket, iOS as length-prefixed JSON written on the live H.264 stream connection. It must be that exact conn: the broadcast extension's TCPServer redirects video output to its newest client, so a separate control connection would steal the stream. Requires devicekit-ios-h264 PR #5 (Android-compatible payload) on the device side.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
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
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.
Summary
SetAvcBitrate/RequestAvcKeyFramepreviously rejected iOS devices (a leftover from the MJPEG days), leaving the adaptive-bitrate feedback loop dead on iOS: the device encoder ran uncapped for the entire session — observed 22–38 Mbps for a 602×1310 stream, saturating the path (RTT 180–480ms with spikes past 1.4s).screencapture.setBitratewithbps,screencapture.requestKeyFrame); only the transport differs — Android over the localabstract control socket, iOS as length-prefixed JSON written on the live H.264 stream connection.TCPServerredirects video output to its newest client, so a separate control connection would steal the stream. The conn is stashed onIOSDevicewhen the AVC capture dials in and cleared when the stream ends.Stacked on #357 (pointer receivers) — the conn stash requires
*IOSDeviceinstances in the device cache. Device side: mobile-next/devicekit-ios-h264#5.