Mirror your PC to a Chromecast or Google TV. No Chrome.

Windows

Install the app from the Windows release, or build it. Building needs MSYS2 (UCRT64) with GCC, CMake, Ninja, protobuf, OpenSSL, Opus, FFmpeg, nlohmann-json and libx264, plus the .NET 8 SDK for the WinUI app. The full package list is in docs/building.md.

Copybuild-all.bat        :: native core + WinUI app
package.ps1          :: self-contained publish, licence and package checks
scripts\run_ubsan.ps1   :: test suite under UBSan (needs clang)
scripts\soak_windows.ps1 -Minutes 10   :: memory and handle soak

Windows needs 10 version 2004 or later, 64-bit. Control traffic uses TCP 8009 and media uses UDP, so the installer adds Firewall rules for private and domain networks; scripts\setup_firewall.ps1 does the same for the portable zip.

Linux

Install the Linux release packages, or build from source. You need a C++20 compiler (GCC 11+ or Clang 14+), CMake 3.20+, Ninja, and developer libraries for GTK 4, Libadwaita, FFmpeg, and PulseAudio.

Prerequisites (Debian / Ubuntu)

Copysudo apt update
sudo apt install -y build-essential cmake ninja-build pkg-config protobuf-compiler libprotobuf-dev     libssl-dev libopus-dev libpulse-dev libx11-dev libxext-dev libxrandr-dev libxfixes-dev     libxcomposite-dev libxdamage-dev     libva-dev libdrm-dev libavcodec-dev libswscale-dev libavutil-dev nlohmann-json3-dev libgtest-dev     libgtk-4-dev libadwaita-1-dev

Configure and build

Copycmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Release
cmake --build build -j"12"

Build artifacts

Running the GUI and CLI

Copy# Launch the GTK 4 desktop app
./build/app/castmirror-gui

# Cast a full monitor via CLI
./build/app/castmirror --device 192.168.0.164 --display 0 --preset High

# List available application windows, then mirror one
./build/app/castmirror --list-windows
./build/app/castmirror --device 192.168.0.164 --window 0x2400004

# Cast display without mirroring system audio
./build/app/castmirror --device 192.168.0.164 --no-audio

Environment variables

• CASTMIRROR_FORCE_SOFTWARE_ENCODE=1: Force FFmpeg libx264 software encoding even when VAAPI GPU acceleration is available.
• CASTMIRROR_FORCE_X11=1: Force X11 display capture instead of the PipeWire portal when running under a Wayland compositor via XWayland.

Network and firewall (Linux)

Control traffic uses TCP 8009 (TLS) to the receiver. Media streams use UDP to the ephemeral port returned in the ANSWER. Both devices must be on the same local subnet. Helper script: scripts/setup_firewall.sh.

CastMirror is a C++20 engine (castcore) with a C API (ABI version 3) and three front ends: the WinUI 3 app (app/winui, .NET 8) on Windows, and a GTK 4 + Libadwaita app (app/gui) and CLI (app/cli) on Linux. The Windows app calls the engine through P/Invoke and checks the ABI version at start-up.

Performance & Latency Contract

• Connect to First Frame: ≤ 8 seconds typical (including TLS, app launch, and OFFER/ANSWER negotiation).
• Glass-to-Glass Latency: ~200 ms typical on a clean 5 GHz LAN at the default targetDelay: 200. The value stays in a 150–400 ms band (Game starts at 150 ms, Cinema at 400 ms) and the adaptive controller steps it 150→200→300→400 ms under loss/jitter and back down when clean. Chrome's own default is 400 ms.
• Teardown Budget: Clean Stop within ≤ 500 ms (guaranteed halt of capture, encoders, and UDP sockets).
• Idle Safety: Capture and encoders never run in the background when disconnected.

Media Pipeline

• Video path (Windows): DXGI Desktop Duplication for a display, or Windows.Graphics.Capture for a window → conversion to BGRA (HDR and 10-bit surfaces tone-mapped to SDR) → frame pacer (steady 30 or 60 fps) → BT.709 limited-range conversion → Media Foundation H.264 (asynchronous hardware transforms supported, x264 fallback) → FrameCrypto → RtpPacketizer → paced UDP.
• Video path (Linux): X11 XRandR / PipeWire portal → BGRA frame → GpuProcessor (letterbox scaling, direct YUV420P/NV12 plane write) → Hardware VAAPI / libx264 encoder (0 B-frames, zerolatency) → Annex-B NALUs → FrameCrypto (AES-128-CTR) → RtpPacketizer (Cast RTP) → Paced UDP socket.
• Audio path (Windows): WASAPI loopback of the default speakers, or of one app through process loopback (Windows 10 2004+) → folded to 48 kHz stereo → Opus → FrameCrypto → RtpPacketizer → UDP. Capture follows the default device when it changes.
• Audio path (Linux): PulseAudio / PipeWire default sink monitor → PCM 48 kHz stereo (10 ms chunks) → Opus encoder (192 kbps) → FrameCrypto → RtpPacketizer → UDP. Host audio sink is muted during streaming and restored on Stop.

State Machine

All subsystems coordinate strictly through an explicit thread-safe state machine:

Idle → Discovering → Ready → Connecting → Negotiating → Streaming ↔ Reconnecting → Stopping → Idle
(Failed state transitions gracefully back to Idle or Reconnecting)

Module Boundaries

CastMirror classifies receivers by model name: CapabilityModel::Evaluate lowercases the mDNS md value and substring-matches it. The mDNS ca capability bitmask is parsed into CastDevice::capabilities but no classifier consumes it.

Receiver Compatibility Matrix

8-Rung Dynamic Adaptation Ladder

Defined once in AdaptiveController::BuildLadder() (core/src/adaptive_controller.cc) — each rung is only a resolution, a framerate and a target bitrate; there is no per-rung min/max bitrate and no RTT-threshold table.

Google Cast screen mirroring uses a specialized real-time media protocol (not WebRTC ICE/DTLS and not HLS media playback).

1. Control Plane (Cast V2 TLS :8009)

• Connection: OpenSSL TLS connection to device port 8009.
• Protobuf Frame: 4-byte big-endian length prefix followed by serialized CastMessage.
• Namespaces:
  • urn:x-cast:com.google.cast.tp.connection — Virtual sender/receiver session bindings.
  • urn:x-cast:com.google.cast.tp.heartbeat — PING / PONG keepalive packets (5-second cadence).
  • urn:x-cast:com.google.cast.receiver — LAUNCH, STOP, and GET_STATUS requests.
  • urn:x-cast:com.google.cast.webrtc — JSON OFFER / ANSWER session negotiation.
• Firmware Mirroring App ID: 0F5096E8 (audio + video display mirroring) or 85CDB22F (audio-only).

2. Media Plane (Cast RTP / RTCP over UDP)

• RTP Profile: rtpProfile: "cast" with a custom 7-byte Cast RTP header extension:

  Byte 0:    Flags (Keyframe marker, Reference frame present)
  Bytes 1-2: Frame ID (monotonically increasing 16-bit integer)
  Bytes 3-4: Packet ID (packet index within frame)
  Bytes 5-6: Max Packet ID (total packet count - 1)

• AES-128-CTR Crypto: Fresh random 16-byte key and 16-byte IV mask per session. Per-frame IV mixes frame_id with the IV mask.
• Compound RTCP: Sender Reports (SR) paired with receiver CAST feedback packets containing:
  • Checkpoint Frame IDs acknowledging complete display rendering.
  • Loss bitmasks (NACK / CST2) detailing dropped UDP packets for immediate retransmit.
  • Picture Loss Indicators (PLI) signaling decoder desync and requesting an immediate IDR keyframe.

The suite covers unit tests, integration tests, network impairments and a simulated receiver that speaks TLS and Cast RTP over loopback. CI runs it on Windows and on Ubuntu (Release, ASan and UBSan, TSan) and Fedora.

Test Suite Status (230 cases; generated by scripts/count_tests.py)

Budgets the tests check

These are simulated-receiver and single-machine results. They are not measurements on real TVs; see the device matrix.

Firmware, resolution and frame-rate ceilings, codecs and playout delay per receiver generation live in the source document. Its rows predate 1.0.0 and were not re-measured for it, so treat them as unverified: docs/DEVICE_MATRIX.md.

Playout delay bounds

• Minimum target playout delay the sender will request: 150 ms.
• Default target delay: 200 ms (Auto / High / Balanced / Smooth).
• Maximum: 400 ms — the Cinema preset starts there and Game starts at 150 ms; the controller clamps every value to the 150–400 ms range.
• The delay is adapted at runtime: AdaptiveController::StepUpPlayoutDelay walks 150→200→300→400 ms when jitter exceeds 30 ms or loss exceeds 3%, and StepDownPlayoutDelay walks back after 15 consecutive clean intervals.

Keyframe cadence & crypto

• 2000 ms periodic intra-refresh, or an IDR on packet-loss bursts.
• OpenSSL AES-128-CTR, hardware-accelerated via AES-NI / ARMv8 Crypto Extensions.