Windows Screen Streaming System

A Windows background system for configurable multi-monitor capture and reliable RTSP streaming.

Windows systems · StreamingSystem architecture & implementationAnonymized production system

Context

A Windows background application was required to capture configured displays, encode each as a separate stream, and make those streams available to remote consumers without depending on an interactive foreground interface.

What had to be solved

Running FFmpeg was only one part of the problem. The application had to translate monitor configuration into the correct capture workers, supervise those workers and the media server, preserve settings, recover from capture or child-process failure, and resume predictable operation after Windows restarts.

System boundaries

  • The application needed silent/background operation, automatic startup, LAN access, and installer-friendly deployment.
  • Each configured monitor required its own bounds, offsets, stream identity, and coordinated capture process.

System architecture & implementation

  • Designed and implemented the .NET 8 background application, its persistent configuration model, and the control flow from monitor settings to active streams.
  • Built lifecycle supervision and recovery for FFmpeg capture workers and MediaMTX, including prevention of duplicate workers for the same stream.
  • Implemented configurable per-monitor capture and streaming-including resolution, FPS, and RTSP ports-and handled automatic startup, MSI packaging, and Windows firewall/LAN requirements.

System model

Streaming architectureThe .NET application translates configured monitors into separately supervised FFmpeg workers. Each worker publishes its own stream through MediaMTX for RTSP consumers.
Windows host
.NET background application
Capture / process management
FFmpeg
Monitor 01 streamMonitor 02 stream
MediaMTX / RTSP
Remote viewer / consumer

Where the complexity lived

  • Using FFmpeg ddagrab as the primary DXGI/Desktop Duplication-style capture path while retaining gdigrab as an alternative capture path.
  • Recovering from capture loss without repeatedly switching or restarting capture in ways that caused cursor or mouse flicker.
  • Computing monitor bounds and offsets correctly, then maintaining exactly one worker for each configured stream.
  • Coordinating FFmpeg workers and MediaMTX so a failure could be handled without duplicating or unnecessarily restarting unaffected stream processes.

How the solution was structured

  • Centralized process ownership in the .NET application and reconciled the expected configured streams with the FFmpeg and MediaMTX processes actually running.
  • Persisted monitor selection, capture settings, stream ports, and startup configuration so the application could restore intended behavior after restart.
  • Packaged the application for Windows installation and accounted for the firewall and network access required for LAN or external RTSP consumption.

Production behavior

  • Child-process crash detection, targeted restart of the affected process path, and duplicate-worker prevention.
  • Controlled capture retries for transient display or capture-path loss, avoiding aggressive fallback loops.

What the work established

  • A working Windows background streaming system with configurable per-monitor RTSP streams, supervised FFmpeg and MediaMTX processes, persistent settings, and explicit recovery behavior.

Technologies and systems

C#.NET 8FFmpegMediaMTXRTSPddagrabgdigrabMSI

Machine-specific configuration, network addresses, credentials, and private deployment data are omitted.