Capture Pipeline

Capture Pipeline

How a frame gets from your monitor into the replay buffer: which Windows capture API Flashback uses, how it stays on the right screen, and why it does so little work per frame.

The short version: Flashback reads the monitor, not the game, so nothing runs inside your game. It captures only as many frames as you record (on a 480 Hz display at 1080p60, that cut the recorder's 3D-engine load from 5.6% to 1.8%), and each frame is copied once on the GPU straight into the encoder (about 12% less GPU share than the old three-copy path). What you'll notice: nothing, which is the point.

Display capture, not game injection

Flashback records the display, not the game process. It never loads a DLL into a game, never draws an in-game overlay and never hooks the game's rendering. That has two big effects:

• One path for everything. DirectX, Vulkan, OpenGL and Java games (including shader-heavy Minecraft), borderless windows, exclusive fullscreen and the plain desktop all go through the same capture code.
• Nothing inside the game. The game's own frame loop isn't touched, so Flashback stays away from anti-cheat-sensitive hooks. Save and screenshot shortcuts use the Windows RegisterHotKey service rather than keyboard hooks.

Two Windows capture methods

Windows offers two ways to read a monitor's image, and Flashback can use both.

	Desktop Duplication (DDA)	Windows Graphics Capture (WGC)
What it is	The DXGI Desktop Duplication API: Windows hands over each new desktop image plus a list of what changed	The newer Windows capture API built on the compositor
Capture border	No	Windows can show a capture border or indicator
Role in Flashback	Preferred in Automatic	Automatic fallback, or pick it yourself

How Automatic decides

The Capture method setting has two choices:

• Automatic (recommended) asks for Desktop Duplication first. If that session never receives a real desktop frame, or the display is driven by a different graphics adapter (common on laptops with two GPUs), the session switches to Windows Graphics Capture. The decision is made per session and logged.
• Windows Graphics Capture uses WGC directly.

Because the fallback can happen, Flashback doesn't promise a border-free session. If you see a capture border, that session is running on WGC.

Staying on the right monitor

The Display setting can follow the active game or stay on one monitor.

• Automatic · follow active game records the monitor your game is on.
• A specific monitor stays put. It never silently switches to another screen.

Under the hood, capture is bound to the selected monitor's physical identity for the whole replay run, not to a position or a number that Windows can reassign. The host keeps checking that binding, and WGC also pins the display path, desktop bounds and rotation. If the monitor disconnects or Windows remaps it, capture fails closed: it stops rather than recording a different screen or repeating a stale frame. When the same monitor comes back (after sleep, a cable reconnect or a driver reset), recording resumes on its own.

A quiet but unchanged display is re-validated at a bounded rate, without restarting capture.

Pacing: capture only what you'll keep

A display can refresh at 144, 240 or 480 Hz, but a 60 FPS clip only needs 60 frames a second. Older builds fetched and resized frames close to the refresh rate and threw the extras away.

Flashback paces acquisition to the output frame rate instead:

• Desktop Duplication is paced to 105% of the configured frame rate.
• Windows Graphics Capture keeps a 120% margin, the level it was qualified at.
• Waits use high-resolution, sleep-based timing rather than rounding each wait up to a whole millisecond.

The effect, measured on a 480 Hz display at 1080p60 when pacing first arrived: recorder CPU went from 1.676% to 0.900%, recorder 3D-engine load from 5.634% to 1.805%, and copy-engine load from 0.673% to 0.120%. Tightening the DDA margin from 120% to 105% later moved average recorder CPU from 0.85% to 0.69% at 1440p60, with output still exactly 60 FPS. A 1080p240 validation stream held exactly 240 FPS (14,405 frames in 60.021 seconds). These are recorder measurements on one PC, not game FPS; see Benchmarks.

Per-frame work on the GPU

Every frame stays on the GPU from capture to encoder, and Flashback trims the work done to it:

• One copy into the encoder. Each frame is scaled straight into the capture surface and copied once, directly into the encoder. Before 0.7.38 it was scaled into a temporary image and copied three times. On the test PC that change cut Flashback's share of the GPU by about 12% while the cursor is hidden, as it is during most matches.
• Dirty rectangles on the copy engine. When Desktop Duplication reports that only part of the screen changed, and the display isn't rotated, those areas are copied with the GPU's copy engine instead of a 3D draw that would need a new shader resource and vertex buffer every update.
• Reused resize resources. Scaled recording keeps its GPU resize resources rather than creating new ones every frame.
• No compositor pass when it isn't needed. Output scaling is set up before recording starts, and the compositing step is skipped when a resized frame already fills the output.
• A bounded sample pool. Eight Media Foundation samples backed by Direct3D textures are reused in a loop. A sample returns to the pool only after the encoder releases it. If all eight are busy, capture waits briefly; if the encoder still hasn't caught up, that one input frame is dropped rather than stalling capture. Nothing is allocated per frame in steady state.

Correctness details in the capture engine

Flashback's fork of the capture library also fixes the less visible things that make captures trustworthy:

• The shared canvas starts from a complete first frame, and stale Desktop Duplication metadata is cleared on every acquire.
• An acquired frame stays owned until its change lists have been read, and a frame deferred by a timeout is kept for the retry, so a full refresh or a cursor-only update is never written as a partial frame. 0.8.0 tightens this frame ownership further during retries and metadata failures.
• Pacing and the one-time fallback guard are restored whenever a display source is recreated.
• The encoder's color conversion output is managed so queued frames can't exhaust its allocator.

Cursor

Cursor capture is on by default and can be turned off. When the cursor is hidden, as in most games, the GPU path is at its lightest.

Screenshots share the session

While the buffer is running, the screenshot shortcut takes a PNG from the active capture session. Flashback never opens a second Desktop Duplication session for the same display, which keeps fullscreen capture reliable. When the buffer is paused, a short-lived screenshot-only session captures the selected display and then closes.

High frame rates

At 240 FPS, hardware H.264 uses constant bitrate and fixed pacing in low-latency mode, which smooths out encoder and disk-write bursts. When the source has no new image, the current surface is repeated so the timeline stays even. If a profile is too demanding for the hardware, sustained lag is bounded and Flashback shows a performance warning rather than quietly saving uneven clips.

That warning only appears for demanding captures: a high-frame-rate or 4K target in a fullscreen game, several slow samples in a row, and real signs of encoder backlog in the worker. A still desktop or an app that naturally runs at 60 FPS won't set it off.

---

Related pages: Hardware encoding · Replay buffer and segment rotation · System requirements · Anti-cheat and games