How It Was Built Part 1

Part of How ShadePlay was built

Part 1: why ShadePlay exists

The setup

ShadePlay was built and tested on one gaming PC, the one in the README's Tested table:

• Graphics: an NVIDIA GeForce RTX 5080 (driver 610.62). Next to its 3D engine it has two separate video-encoding engines.
• Processor and memory: an AMD Ryzen 7 9800X3D with 32 GB. The processor also has a small integrated Radeon GPU, which later became our only AMD test card.
• Monitor: an Alienware AW2725DF, 2560 x 1440 at 360 Hz, with HDR on.
• Windows 11 25H2 (build 26200).
• Sound: a wireless USB gaming headset for the game, voice chat and the microphone, and a USB DAC as the Windows default output. A third output drives a bass shaker. It carries vibration from a haptics app, not sound, and it must never end up in a clip.
• Voice chat: the Discord desktop app. Games: Overwatch 2 and WARDOGS.
• Also present: virtual monitors from VR streaming apps, which Windows lists like real ones.

That mix matters. A recorder that assumes everything you hear plays on the Windows default output gets this PC wrong: here the game played on the headset.

Instant Replay kept switching itself off

September 24

Problem. The maintainer's first message: "ShadowPlay is unreliable, sometimes it doesn't turn on when the computer boots." You only find out after the moment you wanted to keep is gone.

What we found. Nobody outside NVIDIA can look inside its software, so we looked at what is publicly known (checked in September 2026):

• Community tools exist whose only job is to switch Instant Replay back on, and forum fixes range from restarting NVIDIA's background services to toggling the feature off and on. Many people see the same thing.
• Community reports say Instant Replay switches itself off while a window that hides itself from screen capture is open (some password managers and overlays do that), or while copy-protected video plays, and that it stays off without a loud warning.
• Which of these, if any, hit the maintainer's PC was never proven. We treated it as a lesson, not as a diagnosis.

Fix. Three rules for ShadePlay, set before any code was written:

1. Never stop recording because of what is on screen. Windows' own screen capture simply hides or blacks out protected content, and the recording goes on.
2. Every failure is temporary. A missing monitor, a driver reset, a busy encoder or a missing audio device is retried forever, with a growing pause between tries.
3. No "off" state survives a restart. Later the maintainer went further and removed the pause entirely (Always recording).

Game, voice chat and mic in one clip

September 24

Problem. A few minutes after the first message came the second complaint: "One problem is ShadowPlay sucks at capturing the game and my mic and Discord call." Clips came out without the call, or without the game sound.

What we found. Two things on this PC trip up a recorder that doesn't expect them, and both surfaced over the next days:

• The game played on the headset, not on the Windows default output. A track that records "the desktop" from the default output misses it (The game plays on the headset).
• Windows turns other sounds down by 80 % during calls, and that lowered volume is what any recorder hears (Windows turns the game down during calls). This probably explains some of the quiet game audio in the old clips, but it was never measured.

Fix. Separate tracks for the game, the voice chat, the microphone and everything else you hear, each recorded whatever device it plays on, plus one mix in which every sound is counted once. That is most of Chapter 3.

The bitrate cap

September 27

Problem. When the README was written, the maintainer added a third complaint: "add that the NVIDIA App capped my bitrate too." In the README's words: "Fast motion turned into mush, and I couldn't turn the quality up."

What we found. This is the maintainer's own experience, and we kept it that way. The docs make no claim about NVIDIA's product beyond it.

Fix. ShadePlay's quality is one slider with four stops. Even the default stop allows up to 250 Mb/s for SDR and 300 Mb/s for HDR at 1440p and 240 fps, and the top stop allows 750 Mb/s for HDR (Quality you can turn up).

What the maintainer asked for

September 24

The first message was a short list, and it stayed the brief for everything after it:

• "I want the resolution to be native", with an adjustable bitrate, and "as detailed as possible".
• A frame rate of "120 or higher". Asked to pick a default, the maintainer chose 240 fps, over 120 and over the monitor's native 360.
• "I only care about 1 minute of footage."
• "A light app, similar weight and overhead as ShadowPlay". Storage didn't matter: "I'm not concerned about storage usage."
• Uploading to YouTube: "not required right now but keep it in mind".

Two more messages followed within minutes: "HDR recording as well would be amazing", and the audio complaint above. Later the same day: "The save doesn't need to be instant, most times I clip and keep playing. I want the better audio and AV1."

Reliability after booting was the first complaint, so "reliability first" went into every plan that followed.

Build our own?

September 24

Problem. Work around the old setup, or replace it? The first message already leaned one way: "Can we make our own version of ShadowPlay using the NVENC encoders or AV1?"

What we found.

• The failures sat inside a closed product. When replay switches itself off, and how it handles audio devices, are not settings anyone outside can change.
• The PC already had everything a recorder needs: Windows hands each new screen image to a program on the graphics card, the card has dedicated video encoders, and Windows can record one program's sound wherever it plays.
• Claude checked what was installed: no compiler, no build tools and no Visual Studio.

Fix. Our own app, owning every step: screen capture, colour conversion, encoding, audio and saving.

• Written in C++20. The picture never leaves the graphics card, which is how it stays light.
• FFmpeg 8.1 as shared libraries (DLLs), to drive the hardware encoders, encode the audio and write MP4 files.
• The toolchain: llvm-mingw (the Clang compiler for Windows), CMake and Ninja. Claude offered two routes: four zip files of about 326 MB that need no administrator rights, or Visual Studio's build tools (more than 5 GB, installed as administrator). The maintainer approved the zips. At the time the fourth zip was a ready-made FFmpeg build. Today BUILDING.md lists the three toolchain zips with their checksums, and FFmpeg is built from source (Licences, and a GPL surprise).
• One early warning came from the research: the ready-made FFmpeg DLLs were about 117 MB, mostly codecs ShadePlay never uses, and a trimmed build of our own would be far smaller. That idea came back later, for a more serious reason (Licences, and a GPL surprise).

---

---

<- How it was built | Contents | Part 2: how we worked ->