Highlights
🐛 Screen mirroring no longer smears during motion
serve-web and serve-vnc replayed the feature string from Apple's captured Xcode offer, FLS;VRAE:0;SW:1;, in the codec bank the device negotiates. VRAE is AVConference's video-resolution-adaptation switch. With it forced off, the device encoder's only rate-control lever at the fixed 6 Mbps cap is dropping input frames, and each dropped frame turns the next P-frame into a large residual that gets encoded as the blocky mosaic seen during swipes and scrolling. The offer now declares FLS;SW:1; (Apple's own literal in AVConference) and the encoder keeps every frame.
Measured on iPhone18,4 / iOS 27.0 with the device's own VCPEnc telemetry over identical 20 s home-screen swipe sequences: the old string dropped 207-219 frames per run at ~42 fps out of the encoder; the new one drops none at ~53 fps. In Chrome the old string produced repeated multi-frame mosaic episodes, the new default none. The bitstream was valid all along (zero RTP loss, zero decoder errors), which is why every decoder-side theory failed.
Credit to @jkcoxson: the idevice screen-stream offer was the first known configuration without the smear. The device intersects the offered tokens with the ones it knows (VRAE, SW) and drops the rest, so that richer string negotiates to plain FLS and works for the same reason: it no longer says VRAE:0.
DisplayService.start_video_stream() also gains hevc_features / avc_features overrides for experimenting with the feature strings from scripts, and the full investigation is recorded in pymobiledevice3/remote/core_device/MOTION_TEAR_FINDINGS.md.
pymobiledevice3 developer core-device display serve-webWhat's Changed
- 09b315e core_device: Align the VRAE findings table for markdownlint and credit jkcoxson (#1954) (@doronz88)
- f9aa3da core_device: Drop VRAE:0 from the screen-mirror offer to stop encoder frame drops (#1953) (@doronz88)
Full Changelog: v11.13.0...v11.13.1