Skip to content

feat(ios): live AVC bitrate control and keyframe requests - #358

Open
gmegidish wants to merge 1 commit into
fix/ios-device-copylocksfrom
feat/ios-avc-live-bitrate-control
Open

feat(ios): live AVC bitrate control and keyframe requests#358
gmegidish wants to merge 1 commit into
fix/ios-device-copylocksfrom
feat/ios-avc-live-bitrate-control

Conversation

@gmegidish

Copy link
Copy Markdown
Member

Summary

  • SetAvcBitrate/RequestAvcKeyFrame previously 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).
  • Both platforms now accept the same JSON-RPC payload (screencapture.setBitrate with bps, 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.
  • The control write must ride that exact conn: the broadcast extension's TCPServer redirects video output to its newest client, so a separate control connection would steal the stream. The conn is stashed on IOSDevice when the AVC capture dials in and cleared when the stream ends.
  • Adds tests covering the wire framing (4-byte big-endian length + JSON), the Android-compatible payload, and the no-active-stream error.

Stacked on #357 (pointer receivers) — the conn stash requires *IOSDevice instances in the device cache. Device side: mobile-next/devicekit-ios-h264#5.

…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.
@coderabbitai

coderabbitai Bot commented Aug 24, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: bba656ab-daa1-40aa-b70e-0da3b200f44b

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Comment @coderabbitai help to get the list of available commands.

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