Mirror Bridge
Windows 11 desktop to Apple TV via Miracast-to-WebRTC bridge with H.264+Opus transcoding.
A Windows-to-Apple-TV screen mirroring bridge that intercepts Miracast, demuxes MPEG-TS, transcodes AAC audio to Opus, and streams H.264 video + Opus audio over WebRTC to a tvOS receiver app. Tested live at 2560×1440 @ 60 fps with sub-150ms latency.
- C++17 (Windows bridge)
- Swift 5.9 (tvOS app)
- WebRTC (libdatachannel + WebRTC SDK)
- FFmpeg (MPEG-TS demux, AAC→Opus transcode)
- VideoToolbox (H.264 hardware decode)
- AVSampleBufferDisplayLayer (video render)
- AVAudioEngine (audio routing)
- WASAPI (Windows system audio capture)
- Windows Graphics Capture (desktop capture)
- Boost (ASIO, Beast, JSON)
- CMake + vcpkg (C++ build)
- XcodeGen (tvOS project generation)
The bridge fills a gap in Apple's ecosystem: no native way to mirror a Windows 11 PC to an Apple TV. The Windows side poses as a Miracast wireless display receiver, intercepts the inbound MPEG-TS stream from the host's Win+K mirror command, demuxes video and audio, transcodes the AAC payload to Opus (sub-5ms latency target), and packages both tracks into WebRTC SDP offer/answer signaling over a local WebSocket on port 8443. The tvOS app connects, exchanges ICE candidates, receives the WebRTC media stream, decodes H.264 via VideoToolbox, and renders to an AVSampleBufferDisplayLayer with full telemetry logging.
The architecture enforces a strict source abstraction: whether the bridge ingests from a loopback file, live desktop capture via DXGI + Windows Graphics Capture (WGC), or Miracast RTSP, the downstream WebRTC pipeline sees an identical PROTOCOL.md wire contract. I verified this design at three scales: M2 (file loopback), M4 (live desktop capture at 2560×1440 60fps), and in-progress M5/M6/M7 (Miracast RTSP). The tvOS side needed zero code changes between file and live sources, proving the abstraction works.
Development coordinated via a dual-session git-as-IPC framework, with both sessions (Windows C++ bridge, tvOS Swift receiver) owning separate directories and synchronizing through message files in `orchestrator/messages/`. Each session runs a 15-minute heartbeat loop, committing milestone completion records and cross-session handshakes. Milestones M1–M7 on tvOS are complete (signaling, WebRTC peer, VideoToolbox decode, AVSampleBufferDisplayLayer render, Opus audio, live screen capture validation); Windows M1–M4 are complete, M8 is in polish phase (tray icon, stats logging, auto-reconnect), and M5–M7 (Miracast RTSP) are deferred pending scope prioritization.
- WebRTC dual-layer architecture: Windows C++ bridge (libdatachannel + FFmpeg) sends H.264 + Opus via WebRTC; tvOS Swift receiver (WebRTC SDK + VideoToolbox) decodes and renders without custom codec bindings
- PROTOCOL.md enforces strict wire contract: H.264 Constrained Baseline @ 25 Mbps 1080p60 or 60 Mbps 4K60, Opus @ 128 kbps 48 kHz stereo, RTP timestamp alignment for <1 frame jitter buffer, DTLS-SRTP transport
- Live capture pipeline: Windows Graphics Capture (WGC) source with DPI awareness + frame pool, AAC→Opus transcode via libsamplerate, WASAPI loopback for system audio, verified stable at 2560×1440 @ 61 fps, sub-150ms ICE → render latency
- Dual-session coordination via git message queue: COORDINATION.md defines ownership rules (each session writes only its own directory), handshake protocol for shared-file proposals (PROTOCOL.md versioning), and heartbeat intervals for cross-session sync
- Receiver telemetry overlay (4 lanes: NETWORK / DECODE / RENDER / SOURCE) + CSV log at 1Hz; verified 38s sample showed ±1 frame decode/render delta, 5–12 ms HW VideoToolbox latency, 0 packets lost, 24.38 Mb/s bitrate