Atlas project production

Rust Streaming Tool (Web Playback)

Provide a low-latency, self-hosted screen/audio streaming tool that plays directly in a browser via WebRTC. Capture a selected monitor and audio source. Encode video (H.264) and audio (Opus) with GStreamer. Serve a minimal web UI and WebRTC signaling endpoint for browser playback.

Playbook available

Operational guidance is available for this system.

Open playbook
Type
System
Lifecycle
Active
Last touched
2025-11-26
Visibility
Public
Why it's showcased

Highlights full-stack WebRTC streaming with a minimal browser playback surface and self-hosted infrastructure.

Purpose

Provide a low-latency, self-hosted screen/audio streaming tool that plays directly in a browser via WebRTC.

Current state

Last touched: 2025-11-26. Functionality and completeness: Core capture/encode/signaling pipeline is documented; production hardening is pending.

Next step

Add baseline automated tests to cover critical flows; Add CI pipeline for build/test/lint; Document deployment/runtime environment (or add Dockerfile); Document interfaces (CLI flags, API endpoints, file formats); Add structured logging and basic health checks.

Interfaces

Inputs
  • screen capture feed, audio source, stream config (resolution, fps, bitrate)
Outputs
  • browser-playable streams, signaling endpoint, session stats (recommended)

Reality to Action trace

Reality Ingestion

Contributes in this stage.

Canonical Storage

Not in scope.

Automation Engines

Contributes in this stage.

Human Interfaces

Contributes in this stage.

Operational Adoption

Contributes in this stage.

Core workflow

  1. Select capture sources (screen and audio).
  2. Start the GStreamer pipeline for encoding.
  3. Launch the signaling server and web UI.
  4. Negotiate WebRTC session with the browser.
  5. Stream frames and audio to connected clients.
  6. Monitor session health and errors.
  7. Tear down sessions and release resources.

Data integrity and contracts

Canonical schema definitions

  • CLI config schema for capture source, resolution, and bitrate.
  • WebRTC signaling payload shapes.
  • Session stats fields (latency, bitrate, client count).

Source of truth rules

  • Live capture is the source of truth; no persistence layer.
  • Streaming configuration is authoritative for each session.

Data quality checks

  • Verify required codecs and plugins are available.
  • Check capture device availability before start.
  • Monitor dropped frames or jitter thresholds.

Safe handling

  • Restrict access to internal networks or authenticated users.
  • Avoid exposing sensitive streams publicly.
  • Keep signaling endpoints protected.

Downstream integration map

  • Operators and viewers.
  • Monitoring and troubleshooting workflows.

Operational notes

Reliability posture

Failure modes and safe behavior: Capture failures or missing plugins abort startup with logs. Idempotency / retries / batching behavior: Not applicable; long-lived streaming sessions.

Observability

  • Logs: tracing logs
  • Metrics/health checks: None documented
  • basic health/status endpoint (recommended)

Security and privacy

Stream access control required; restrict access to internal networks.

Dependencies

Upstream
  • WebRTC clients in browsers
  • capture devices/feeds
  • network
Downstream
  • monitoring
  • viewing workflows

Ownership

Owners

Josh Barton

Users

you, operators/viewers (future), Josh Barton (owner)

aether-streamer

Architecture & Major Components

  • High-level diagram (text):

    • Entry/trigger -> core logic -> outputs (details per docs below)
  • Screen capture via X11 (x11rb) with optional PipeWire path.

  • Audio capture from PulseAudio/PipeWire sources.

  • GStreamer pipeline feeds webrtc-rs and a Warp-based signaling server.

  • Entry points: src/main.rs

  • Top-level folders: src

  • src/ submodules: capture, pipeline

  • Key abstractions: capture pipeline, signaling server, WebRTC session manager

Setup / Build / Run

  • Build system(s): Cargo.
  • Requires GStreamer, X11/PipeWire, and audio dependencies on the host OS.
  • CLI flags control monitor selection, resolution, bitrate, and audio source.