feat: stream Android emulators on Windows and Linux with OpenH264 - #85
feat: stream Android emulators on Windows and Linux with OpenH264#85NathanWalker wants to merge 1 commit into
Conversation
Non-macOS builds link native_stubs.c instead of the macOS native bridge, so
neither iOS simulator nor Android emulator H.264 streaming can work there.
The browser previously showed the raw JSON stub error in the stream area and
kept retrying WebRTC offers that could never succeed.
Server:
- Add platform.rs as the single source of truth for the live-video
capability, its user-facing reason, and the CLI note.
- Report `hostOs` and a `liveVideo` block from /api/health and
/api/stream-quality.
- Reject WebRTC offers early with 501 and the platform explanation via a new
AppError::Unsupported variant.
- Print a "Live video:" note after the service URLs on non-macOS hosts.
- Share one clear message across the H.264 encoder stubs; drop the unused
WIP helper and the duplicated #[test] attribute.
Client:
- Parse `{"error": ...}` bodies from failed offer and stream-config posts.
- Read `liveVideo` from the stream-quality response, pause the live stream,
and show the reason in the viewport instead of the reconnect loop.
- Disable the stream transport, encoder, frame rate, and resolution controls
with a "Requires macOS" note when the server cannot stream.
Docs: platform support table, health/REST field docs, video guide, and a
troubleshooting entry for the message.
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
I'm going to address this differently - this handles part of the messaging. |
Summary
Android emulator live streaming now works on Windows and Linux. Those builds link
native_stubs.cinstead of the macOS simulator bridge, so the Android WebRTC source had no H.264 encoder and every stream failed with the stub error (rendered as raw JSON in the browser). Frame capture (emulator gRPC screenshots) and the WebRTC transport were already cross-platform Rust; only the encoder was missing.Encoder (non-macOS)
packages/server/src/transport/software_h264.rs: Cisco OpenH264 via theopenh264crate, compiled from source (BSD, no system deps, supported onx86_64-pc-windows-gnu/msvcand Linux). Emits Annex B baseline H.264, which the existing packetizer and browsers already accept.androidEncoders[].encoder.native.cfg-gated: macOS keeps the native VideoToolbox/x264 path behind the C ABI; other targets use the software encoder. Frame publishing is shared.Capability reporting and messaging
platform.rsnow describes iOS simulator support rather than "live video".liveVideoin/api/healthand/api/stream-qualityreportssupported: true,encoder(nativeoropenh264),androidEmulator: true,iosSimulator(macOS only) andiosSimulatorReasonelsewhere.501with that reason (newAppError::Unsupported). Android offers proceed.Live video:note on Windows/Linux; the browser unwraps JSONerrorbodies instead of showing raw JSON, and still pauses with a reason if a server ever reportssupported: false.CI and docs
rust-non-macosjob runscargo clippy -D warningsandcargo teston Ubuntu and Windows, since the macOS job compiles out both the OpenH264 module and the native stubs.Test plan
npm run --prefix packages/client typecheckandnpm run --prefix packages/client test(104 tests)rust(macOS fmt/clippy/test), newrust-non-macos(Ubuntu + Windows clippy/test incl. the OpenH264 encoder tests),integration-androidbuilds the CLI with OpenH264 on both — the Rust side was not compiled locally (no Rust or C++ toolchain on the authoring machine), so these are the real gate.simdeckprints theLive video:note,/api/healthreportsliveVideo.encoder: "openh264", boot an Android emulator and confirm the browser shows live video with touch input;/api/metricsshowsandroidEncoders[].encoder.native.outputFramesincreasing.liveVideo.encoder: "native".Cargo.lockgains theopenh264entries on first build; commit that follow-up (not generated here).Follow-up worth considering: install
nasmon the release runners for OpenH264's assembly paths (up to ~3x faster encoding); left out to keep the release build unchanged.🤖 Generated with Claude Code
https://claude.ai/code/session_013K2GgwpF2vLSgz4otg8tmT