Dawn Stream cloud streaming

Dawn Engine Dawn Stream pushes the locally rendered viewport to a browser over WebRTC and injects remote browser input back into the engine. The full application runs on a GPU host; end users only need a browser for try-before-you-buy, review, or demos—no client install.

Maturity: MVP delivered (core pipeline works). Shipped as the DawnStream Gem; off by default. Enable and start streaming explicitly. The recommended demo tier is 720p / 30 fps. With a real WebRTC stack and hardware encode, 1080p is a viable production-oriented tier. Higher concurrency and full cloud orchestration continue on the roadmap.

It does not replace the Multiplayer Gem: Dawn Stream carries encoded video and remote input, not authoritative game-state replication.

What problem this solves

Cloud rendering, digital-twin kiosks, remote review, and web demos often require shipping a full client or hand-rolling capture, encode, playback, and input return. Dawn Stream provides an end-to-end path:

• Dawn Engine renders on a GPU host;
• the Gem captures the Atom viewport, encodes, and sends over WebRTC;
• the browser plays low-latency video and returns input on a DataChannel;
• a signaling service handles discovery, auth, and SDP/ICE exchange.

With the Gem disabled or streaming stopped, local input, rendering, and networking behave as before. You do not need to add level components for everyday streaming—the system component activates with the Gem.

How it works

Browser Viewer ──HTTPS/WSS signaling──► Signaling Server
 │ │
 ├── WebRTC media (video / optional audio) ► DawnStream Runtime (in-engine)
 └── DataChannel input / control ──────────► RemoteInputDevice → AzFramework
 ▲
 Frame Capture ← Atom Viewport
 ▼
 Encoder → WebRTC

1. The Streamer (Dawn Engine app) connects to signaling and registers capabilities.
2. The Viewer (browser) authenticates, joins, and completes SDP/ICE.
3. The engine captures viewport frames → color convert / encode → WebRTC RTP.
4. Browser input arrives on the DataChannel into RemoteInputDevice; gameplay treats it like a local device.
5. A bitrate loop reacts to loss / REMB; keyframes are on-demand via PLI/FIR (recommended default).

Layout under Gems/DawnStream/:

Quick start (summary)

1. Start signaling: cd Gems/DawnStream/Signaling → node src/main.ts --port 8090 → check /healthz.
2. Enable the Gem; set DAWNSTREAM_AUTH_TOKEN / PS_* env vars; launch with --dawnstream-enabled --dawnstream-mode AlwaysStreaming.
3. Build and open the reference player with ?signaling=.&token=..

Without libwebrtc / native CMake gates the engine uses a stub adapter (signaling and input work; no real video). Full steps and acceptance checks: Getting started.

Handbook chapters

Glossary

Limits and related capabilities

You can rely on:

• Optional gem; single-streamer / single-viewer end-to-end video and mouse/keyboard input when media gates are on;
• setreg + CLI + diagnostic console commands; standalone or embedded signaling; STUN/TURN config entry points;
• Route A software encode for demos; Route B hardware encode and GPU color convert when built correctly;
• Bitrate feedback, on-demand keyframes, input ownership and disconnect release.

Do not assume:

• Real video without CMake media gates (stub has no media);
• Streaming on by default (needs Enabled plus mode / CLI);
• Zero-copy is safe for long-lived reconnect loops (off by default for a reason);
• Dawn Stream replaces multiplayer state sync or every need for a local client;
• Multi-viewer arbitration, full cloud orchestration, SFU, HDR/XR, and similar are default deliverables (mostly extensions or experimental flags).

Next steps

• Getting started — shortest path to a working local loop.
• Introduction — Dawn Engine capabilities and how it differs from O3DE.
• World Streaming / Double-precision rendering — large-world scenes often pair with cloud tryouts.