OVERVIEW
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.
PROBLEM
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.
CONSTRAINTS
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.
MY RESPONSIBILITY
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.
ARCHITECTURE
System model
ENGINEERING CHALLENGES
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.
APPROACH
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.
RELIABILITY
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.
OUTCOME
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.
TECHNICAL CONTEXT
Technologies and systems
Machine-specific configuration, network addresses, credentials, and private deployment data are omitted.