amadan
native/README: the Optimise for modes, sender tuning and the motion gate
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 file changed,
+25
−2
native/README.md+25 −2
CI passed — run details
diff --git a/native/README.md b/native/README.md| index 6e2ed13..8c39352 100644 |
| --- a/native/README.md |
| +++ b/native/README.md |
| @@ -335,8 +335,31 @@ transceiver in its own stream, exactly as the browser sends one, announced with |
| `share {on:true}`; stopping stops the transceiver and renegotiates, so the far |
| side's track ends rather than freezing, and says `share {on:false}`. The menu |
| bar's stop control and a shared window closing end it the same way as the |
| -button. The source is a screencast, so WebRTC gives up frame rate before |
| -resolution, and frames are capped at 1920 on the long side and 30 a second. |
| +button. Frames are capped at 1920 on the long side and 30 a second. |
| + |
| +**Optimise shared screen for** (in the device panel, remembered, applied live |
| +to a share in progress) decides what gives way when the uplink or the encoder |
| +cannot carry everything: **Balanced** (the default) holds the frame rate and |
| +sends full size while the link allows; **Text and detail** holds resolution |
| +and lets frames fall; **Motion and video** holds the frame rate at 1280 on the |
| +long side at most. They are sender parameters (`ScreenSendPolicy`), so nothing |
| +renegotiates. While a screen goes out it asks for H.264 first (Apple's |
| +hardware encoder), with every other codec still offered, and has high priority; |
| +the camera beside it is capped at 500 kbit/s and 360 lines, and given its |
| +defaults back when the share stops. While sharing, the panel shows one line on |
| +how the screen is actually leaving, e.g. "Screen: 1920×1080 at 8 fps, limited |
| +by bandwidth, 1.2 Mbit/s, direct (H264 hardware)". The Mac capture keeps three |
| +frames in its queue, drops a frame that arrives more than 100 ms late, and |
| +repeats the last frame once a second while the screen is still, so a keyframe |
| +can be made for a receiver that asks for one. The browser offers the same three |
| +choices, as `contentHint`, `degradationPreference` and sender parameters. |
| + |
| +The numbers behind the modes come from `TestNativeMacScreenMotion` (in |
| +`make native-browser`): the app shares a 1080p page scrolling at 30 fps with a |
| +window dragged across it, and Chromium measures what arrives, with the app's |
| +uplink estimate open and capped at 1.5 Mbit/s. Before this, a 1.5 Mbit/s uplink |
| +delivered 2 fps at full size. Balanced and motion must now arrive at 15 fps or |
| +more, and detail must keep 1920×1080. |
| On **iPhone** the whole screen is shared through a ReplayKit broadcast |
| extension, which hands its frames to the app over a socket in an App Group |