Architecture Overview

Architecture Overview

Flashback is built so that the part that touches your GPU and the part you click on never share a fate. This page shows the big pieces, how they talk, and who owns what. The pages linked at the end go deeper into each stage.

The short version: one signed Flashback.exe runs as two processes. The app (window, tray, hotkeys, library, updates, Cloud) stays mostly idle; a headless capture worker does the per-frame work on the GPU. They talk over a private, authenticated local channel, and a failing worker can be replaced without taking the app or your confirmed replay with it. For the performance story, start with Why Flashback Is Light.

Three layers in the code

Flashback is split into three projects so that media technology can change without rewriting product behavior or the interface.

Layer	What it owns	Depends on Windows?
Core	Settings, models and policy: replay lengths, presets, naming rules, profile matching, storage rules	No
Infrastructure	Windows capture, encoding, export, game detection, files, settings storage and cleanup	Yes
App	The WPF interface, tray, global hotkeys, voice commands, editor, updates and composition	Yes

Keeping policy in a layer with no Windows dependency means the rules that decide what to record and what to keep are tested on their own, apart from the code that talks to drivers.

Two processes from one executable

When the replay buffer runs, there are two Flashback processes:

• The desktop host is the app you see: window, tray icon, hotkeys, settings, game detection, the library, the editor, exports and updates.
• The capture worker is a private, headless mode of the same signed Flashback.exe. It owns the display capture, Direct3D, the Media Foundation hardware encoder, active audio capture and writing each output file.

Reusing one executable means Flashback doesn't ship a second copy of the .NET runtime for the worker, and both processes carry the same signature.

desktop host                          capture worker
------------                          --------------
settings + game context   -- IPC -->  one continuous capture session
confirmed segment index   <-- IPC --  frame-boundary output rotation
save / export policy                  hardware encoder + active MP4 sink
        |                                       |
        +----------- finalized MP4s <-----------+
                           |
                  bounded local buffer
                           |
                 stream-copy clip export
                           |
                      clip library

Who owns what

Responsibility	Desktop host	Capture worker
Settings and the settings file	Yes	No
Game detection and per-game profiles	Yes	No
Confirmed replay history (which segments are good)	Yes	No
Saving clips, trims, exports, Discord copies	Yes	No
Library, thumbnails, editor	Yes	No
Hotkeys, tray, notifications, voice	Yes	No
Updates, network, Cloud	Yes	No
Display capture (Desktop Duplication, Windows Graphics Capture)	No	Yes
Hardware video encoding (Media Foundation)	No	Yes
Audio capture (WASAPI) while recording	No	Yes
Writing and finalizing segment files	No	Yes

The worker has no updater, no network client, no Cloud session, no tray and no settings-store role. It does one job.

How the two processes talk

Host and worker use a named pipe with a versioned, size-bounded protocol:

• The pipe is restricted to the current Windows user.
• A random secret created for each launch, plus checks on the process at the other end, binds the pipe to the exact child the host started.
• Every command is correlated with its reply and bounded in time. An accepted output rotation completes as a transaction even if whoever asked for it gives up.
• While recording, the worker sends low-rate status, frame-count and resource snapshots. Nothing per frame crosses the pipe.

The recording path, end to end

 Hotkey / tray / voice          Desktop host                     Capture worker
 ---------------------          ------------                     --------------
                                game detection ----------------> capture settings
                                                                 |
                                                                 v
                                                  Desktop Duplication (preferred)
                                                  or Windows Graphics Capture
                                                                 |
                                                                 v
                                                  GPU scale + one copy into a
                                                  pooled encoder surface
                                                                 |
                                                                 v
                                                  hardware H.264 / HEVC encoder
                                                                 |
                                                                 v
                                <------- finalized ----- rolling MP4 segments
                                confirmed history                on disk
  "save" ---------------------> stream-copy assembly (FFmpeg, no re-encode)
                                         |
                                         v
                                game-aware library folder

1. Capture. The worker captures the selected display, not the game process. See Capture pipeline.
2. Encode. Frames go straight to the GPU's hardware encoder through Media Foundation. See Hardware encoding.
3. Buffer. Output rotates into short, independently finished MP4 segments on disk, without stopping capture. See Replay buffer and segment rotation.
4. Save. The host copies the newest needed segments into one MP4 with FFmpeg stream copy. No video re-encode.
5. File. The clip lands in a folder named after the game that was in front on the recorded display.

Things that stay out of the hot path

Anything you don't need while you play is off until you use it:

• The full window and the editor aren't loaded when Flashback starts hidden in the tray.
• The editor's decoder, storyboard and preview start only when you open a clip, and close when you leave the Editor or hide the window.
• Thumbnails are held in memory; nothing is written beside your clips.
• Capture health checks and storage review run only when you ask.
• Cloud sign-in, upload and preparation code doesn't load until you open the Cloud tab or upload. A small upload queue starts with the app but makes no network requests while it's empty.
• Voice recognition, input-overlay observation, compression, health analysis and Cloud preparation run below normal priority, so the game wins any contest for the CPU.

Failure containment in one paragraph

If a driver, encoder or native callback misbehaves, the damage stops at the worker. The host keeps your window, hotkeys, library and every confirmed segment, then starts a fresh worker. A worker that is slowly growing in memory is replaced at a clean segment boundary before it becomes a problem. See Isolated capture worker and Resource guards and recovery.

Other safeguards

• Settings and clip metadata are written to a temporary file first and then swapped in, so a crash can't leave a half-written file.
• Automatic deletion only ever touches paths verified to sit inside a folder you configured.
• Deleting clips freezes each file's identity before you confirm, so a file that was replaced or moved in the meantime isn't deleted by mistake.
• The rolling buffer lives outside your clip library and can be cleaned without touching saved clips.
• FFmpeg exports, trims, probes and previews all have cancellation and safety deadlines; partial files are removed.

Building blocks

Component	Role
A Flashback fork of ScreenRecorderLib 6.6.0 (MIT)	Display capture, Media Foundation encoding and WASAPI audio, confined to the worker
Flashback's own FFmpeg 8.1.2 build (LGPL)	Stream-copy saves, trims, exports, previews, probing. See FFmpeg build
.NET 10 and WPF	The app itself. See Built on .NET 10
Velopack	Installer and update flow, behind Flashback's own signature checks. See Update security chain
sherpa-onnx and a small GigaSpeech keyword model	Optional offline voice commands

---

Related pages: Capture pipeline · Isolated capture worker · Why Flashback is light · Glossary