Replay Buffer and Segment Rotation

Replay Buffer and Segment Rotation

The replay buffer is what lets you save something after it happened. This page explains how Flashback keeps a rolling window of video on disk without ever stopping capture, how a save turns that into one clip with no re-encode, and how it stays honest when something interrupts recording.

The short version: one capture session writes a chain of short, finished MP4 files and never stops between them. Saving copies the span you asked for out of those files without re-encoding, so a clip is ready in seconds at exactly the recorded quality, and it costs almost no CPU or GPU.

The idea in one picture

time ------------------------------------------------------------------>

capture   ====================================================  (never stops)

segments  [ seg 41 ][ seg 42 ][ seg 43 ][ seg 44 ][ seg 45 ...
            old, pruned          confirmed            being written

save pressed here ---------------------------------------^
clip  =  newest confirmed segments covering your replay length
         + the current segment, closed early on a clean keyframe
         --> stream copy into one MP4 (no video re-encode)

One session, many files

Flashback runs one continuous capture session while the buffer is on. Its output is a series of short, independently finished MP4 segments, each one a complete file that plays on its own.

Switching from one segment to the next works like this:

1. The worker prepares the next MP4 output away from the capture thread, so frame capture isn't held up.
2. It asks the encoder for a keyframe (an IDR frame, which decodes without any earlier frame).
3. It switches outputs exactly on that clean frame, so the new segment starts decodable.
4. The previous file is finalized in the background while capture carries on into the new one.

Frame acquisition never stops for a rotation. If the background finalizer is still busy, the next rotation simply waits for it rather than blocking the active output.

On compatible NVIDIA hardware H.264, the encoder itself stays alive across rotations; only the file output changes. Other GPUs and codecs create a new encoder per segment, prepared off the capture thread. See Hardware encoding.

How often segments rotate

• In the background, a segment rotates at most once every 120 to 180 seconds. Fewer rotations means less teardown work.
• A segment is never longer than 300 seconds.
• Pressing save requests an immediate boundary, so your clip ends at the moment you pressed it rather than at the next scheduled rotation.

Where the buffer lives

The buffer is kept under %LOCALAPPDATA%\Flashback\Buffer, outside your clip library. It's bounded: Flashback keeps only the segments needed to cover your replay length (or a longer smart-replay length or game-profile length, if you've set one) and prunes the rest automatically. Incomplete or stale buffer files from an earlier session are set aside and cleaned up carefully on a later launch, never mixed into your library.

Long replay lengths work the same way. You can pick any length from 15 seconds to 24 hours, and the buffer still consists of bounded segments rather than one ever-growing file.

If the drive holding the buffer fills up, Flashback tells you which drive to free up instead of restarting capture over and over.

Saving: stream copy, no re-encode

When you press the save shortcut:

1. The worker closes the current segment early on a clean keyframe.
2. The host picks the newest confirmed segments that together cover your replay length.
3. Bundled FFmpeg joins them with stream copy: the already-encoded video is copied into one MP4 without decoding or re-encoding it. The clip starts on the keyframe at or just before the requested moment, and every audio track is cut at that same instant, so the clip plays in sync in every player.
4. The clip is filed under the game that was in front on the recorded display, and a Clip saved notification appears.

Because there's no re-encode, saving uses very little CPU or GPU, the clip is exactly the quality that was recorded, and it's ready within a few seconds. Flashback's own budget is that a clip is available within 3 seconds of the current segment finishing.

A save pressed while the previous one is still saving waits its turn instead of being dropped. If the buffer is paused or still starting, you hear the error sound and get a notice.

Clean joins

Joining segments needs care: a segment's audio and container can run a fraction longer than its video. Flashback declares each segment's actual video duration in the join timeline, so the largest video gap at a join is one frame at 60 FPS (16.667 ms, down from 33.316 ms before this was fixed), and audio timing stays continuous. In 0.7.41 and later, mixed audio stays lined up with the video at every join, and in 0.8.0 each segment's sound is held to its own timestamps, so separate tracks don't drift apart either. If a clip's keyframes can't be read, the save keeps the requested start and cuts the way earlier versions did, rather than adding footage you didn't ask for. See Audio and video sync.

Confirmed history, and why clips never hide a gap

The desktop host, not the worker, owns the list of confirmed segments: files that were finished cleanly and checked. A file existing on disk isn't enough; open or ambiguous outputs are never treated as history.

Each run of uninterrupted recording belongs to a continuity generation:

• A graceful worker replacement (for example a planned recycle) finalizes and confirms the active segment first, so the generation continues and nothing is lost.
• An unexpected worker loss starts a new generation. Segments from before and after the outage are never joined into one clip.

That means a clip never contains a hidden jump where recording was down. The trade-off is honest: a hard-killed encoder can lose the file it had open, and starting a new worker takes a moment, so there can be a brief gap. Avoiding that would require running two encoders at once all the time, which would cost GPU on every frame you record. Flashback deliberately doesn't do that.

When a save meets a recovery (0.8.0)

0.8.0 makes saves smarter when they collide with a worker restart:

• A save pressed while a worker is being stopped for recovery waits for that stop to finish, instead of failing with a timeout.
• A finished segment is salvaged. If the worker died just after completing the segment your save asked for, the host verifies that file and, if it checks out, your save uses it as normal.
• An interrupted save falls back to what's verified. If the moment you pressed can't be reached, Flashback saves from the finalized history that reaches into the window you asked for, marks the clip as recovered, and tells you how far before your press it ends. If nothing usable covers that window, it fails with a plain explanation.
• A save pressed just after a boundary waits for the next one, so it can't quietly export footage that stops before you pressed.

What the buffer costs

The buffer writes compressed video to disk continuously, at roughly your chosen bitrate (15 Mbps for the Balanced preset). It holds only what your replay length needs, plus the segment being written. Settings shows a size estimate for your choices.

---

Related pages: Instant replay · Isolated capture worker · Audio and video sync · Library