How It Was Built Part 4

Part of How ShadePlay was built

Part 4: sound, saving and the app

Chapter 3: every sound, counted once

Every clip has up to five audio tracks: Mix (what players play), Desktop (everything on the device you listen on), Game, Discord and Mic. The hard part is the Mix: every sound in it exactly once.

Discord on any device

September 24

Problem. The voice call must be recorded whichever device Discord plays on, and nothing else with it.

What we found.

• Windows 10 (version 2004) and later can record one program and its child processes, whatever device they play on ("process loopback").
• Discord's call audio comes from a child process, not from the main one, and its interface sounds from another. Recording the main process's whole tree covers both.
• The opposite mode, "everything except one program", looked tempting for a "game without Discord" track. But it records every output device, including the bass shaker. An inaudible test tone proved it.
• Process loopback has quirks. Windows won't say which format it prefers, the buffer is always 10 ms, packets keep coming even from a silent program, and a program that reads too late loses audio without any warning: 845 ms vanished in a 4-second stall test.

Fix. Only the "include this program's tree" mode, never "exclude". Each Discord client (the normal one, PTB and Canary) is found and followed, and after a Discord update or restart it is hooked again within about 2 seconds. A dedicated high-priority audio thread empties every stream on every wake-up and never waits for anything.

A stereo request that came back 13.5 dB low

September 24

Problem. Discord's audio was recorded far too quietly.

What we found. The headset is an 8-channel (virtual 7.1) device. Asking Windows for stereo from a stream that plays on it made Windows mix it down itself, and the result was 13.5 dB too quiet. Asking for all eight channels returned the sound at exactly the right level.

Fix. ShadePlay asks for 7.1 and mixes it down to stereo itself. The Game track works the same way.

Hours of silence from one wrong unit

September 24

Problem. ShadePlay converts audio from devices that run at other rates (the test PC's USB DAC runs at 384 kHz) to 48 kHz with FFmpeg's resampler. The plan set the resampler's start time in output samples.

What we found. That setting counts input samples. The second research pass tested it with the real DLLs: converting 384 kHz to 48 kHz with a start of 4,800 produced 4,184 samples of silence at the front, where none were expected. After a long uptime, every reset of the resampler would have injected hours of silence.

Fix. The start time is never set, and the resampler starts from its first packet.

The game plays on the headset

September 27

Problem. In every live test of the first day, the Desktop track was digital silence, while Discord and the mic had sound. When work resumed on September 27, Claude's first question was where the game's sound actually plays.

What we found. On the headset. The Desktop track recorded the Windows default output, the USB DAC, and the game wasn't there.

Fix.

• A Game track: process loopback of the detected game's whole process tree, so the game is recorded on any device. A clip has no Game track when no game was captured during it.
• A choice for the Desktop track: it records the device you listen on. Left empty, it follows the Windows default. The simple settings page later called it "What you listen on".
• The check: the inaudible tone played on the headset as a stand-in game. With the Desktop track on the default output, the Game track carried the tone in every 100 ms block, and the Mix contained it exactly once (0.91 to 1.01 times, second by second). With the Desktop track on the headset, the Mix left the Game track out, so the tone was counted once there too. Counted twice, it would have been about 6 dB louder.
• The first hands-on test, later that day, had five tracks with the right content: the game on the Game track from the headset, Discord, the microphone, the Desktop track and the Mix. The maintainer checked Discord with Discord's own microphone test: "I can hear the echo so it's working."

Which app is the game?

September 27

Problem. The Game track and the clip names need to know which program is the game, without touching the game.

What we found. A foreground app can count as the game when it covers the whole recorded monitor (fullscreen or borderless), lives in a game library folder (Steam, Epic, Xbox, Riot, Battle.net or the Roblox player, minus the known tools in them), or is on a list. The review found two ways to get it wrong:

• Discord taken for the game would have been recorded twice: once as Discord and once as the game.
• Overlays pushed the game aside. The Game Bar, the screenshot tool or a video player, briefly in front, replaced the game.

Fix. Discord clients can never be the game. Browsers, launchers, media players, photo viewers, remote-desktop and streaming apps and Windows' own overlays never count. A game stays selected until it exits or another game has been in front for 3 seconds (30 seconds for a windowed app that qualifies only by its folder), and a game that was pushed aside becomes the game again at once when it is back in front within 2 minutes. Detection uses window events and a check once a second, and opens other programs with the most limited rights, so nothing is injected into any game.

Counted once

September 27

Problem. The same sound can reach a clip twice: once through the Desktop track (the device you listen on) and once through the Game or Discord track. Added together it is doubled, and because the two recordings arrive 14-28 ms apart, the doubling also turns into a comb filter that colours the sound.

What we found.

• The first rule looked, once a second, at which devices each program had an open audio stream on. It left a program's track out of the Mix while the program played on the Desktop device and on no other device.
• In real use, the log said the game and Discord "play on the Desktop device and on another output at once", so the Mix kept their tracks: doubled.
• A read-only check found out why. The game and Discord each had a real stream on the headset and an open but completely silent stream on the Windows default output. The rule counted the silent one as "playing". The review of that work had even written this down as a known limit (When the AI got it wrong).
• Before designing a fix, Claude measured Windows' per-stream level meters: a meter shows a 20 ms sound for 109-112 ms, reads a -80 dBFS tone exactly, and a reading waits about 0.1 ms for Windows' audio service.

Fix. Decide by sound, not by open streams.

• Every 80 ms, ShadePlay reads the level meter of every audio stream of the game and of Discord, per output device, and it lists the streams once a second.
• A program counts as audible on a device at -84 dBFS or louder. That is just above the quietest noise of 16-bit audio and far above the exact zeros a silent open stream sends. A threshold of -60 dBFS would have called quiet game passages silent.
• Each second: audible on the device you listen on, and the program's own track stays out of the Mix, because the Desktop track already carries it, even if it is also audible elsewhere. Audible only elsewhere, and its track goes into the Mix. Silent everywhere, and the last decision holds, so the Mix doesn't flap.
• The review added one more rule: when a program is heard on both sides, a faint trace (below -60 dBFS next to a louder side, or 40 dB quieter than it) doesn't count. Without it, an idle stream with a little noise could have dropped a game from the Mix entirely.
• The cost: about 6 to 11 ms of the control thread's time per second, mostly waiting for the audio service. The thread that captures the audio isn't involved.
• The check: the tone on the headset plus a silent stream on the default output. The new rule counted the tone once in every sample. The old rule either doubled it or, where the offset made the two copies cancel, left almost nothing (about -91 dBFS). Restoring the old rule makes 3 tests fail, and removing the "hold" makes 2 fail.
• The fix was built in a private copy of the code while another feature was being built in the real one, merged in one step, and running on the maintainer's PC the same day.

A device that must never be recorded

September 24, hardened on September 27

Problem. The PC's bass shaker is an audio output. Its signal is vibration for a haptics app, and it must never end up in a clip.

What we found.

• The "exclude" recording mode would have recorded it (Discord on any device).
• Process loopback records a program on every device, so a program that also plays something on the shaker brings it into its own track.
• The first never-record list failed open: when Windows couldn't tell a device's name, or when the list had bad entries, the device counted as allowed.
• On September 27 the review found the same flaw on error paths: a failed Windows call left the device allowed.

Fix.

• A never-record list of device names, "Excluded devices" in the advanced settings. A device whose name can't be read counts as excluded while the list has entries: the list fails closed.
• A program's own track is muted for every second in which the program is audible on an excluded device, and for anything the meters can't rule out: an excluded device that can't be listed or metered, or a gap between meter readings.
• The list is empty by default. A list you saved is kept as it is.

Lining the tracks up

September 24

Problem. Five audio sources and the video, each with its own clock, must line up in every clip, even after days of uptime.

What we found.

• Windows stamps audio with the same system-wide clock (QPC) the video uses, in units of 100 ns.
• Device clocks drift. The USB DAC's clock was off by about 28 to 75 parts per million, which adds up to 100-270 ms per hour of uptime if nobody corrects it.
• The two kinds of recording see the same sound at different times. Process loopback came 20.7 to 33.7 ms after device loopback over 11 tries (about 28 ms on average), and about 14 ms after it on the live USB DAC path.

Fix.

• Every audio packet is placed on a 48 kHz timeline by its time stamp, with an exact whole-number formula, instead of by counting samples. That matters because an idle device sends no packets at all: counting samples would squeeze the silence out, and the sound would run ahead of the picture after every quiet moment. Gaps simply stay silent, filled from the clock, without keeping a silent playback stream open.
• Each source is re-anchored all the time: single jumps are rejected, slow drift is followed in 0.5 ms steps, and the resampler stretches the sound by at most 0.1 %, which nobody can hear.
• The per-program tracks (Discord and the game) are shifted by -20 ms. That splits the difference between the measured paths (13 to 34 ms), and the error left over is far below what anyone notices. An automatic calibration was designed but not built (Ideas saved for later).

Windows turns the game down during calls

September 24

Problem. By default, Windows lowers other sounds by 80 % while a "communications" stream is active, such as a Discord call. Discord can lower other apps too.

What we found. The lowering happens before the sound reaches the output, so it is baked into every loopback recording. In a clip, the game gets quieter whenever someone talks, and nothing can undo that afterwards.

Fix. ShadePlay detects the Windows setting and suggests "Do nothing" (Sound control panel, Communications tab) and Discord's attenuation at 0 %, and it offers a shortcut to the right page. It never changes the setting itself. It also opens the microphone in a way meant not to trigger the lowering on its own, but that part is a hypothesis; the advice is the dependable fix.

Our own sounds in our clips

September 24, refined on September 27

Problem. ShadePlay plays short sounds: a tick when you press the hotkey, a chime when a clip is saved, a low tone when something fails. In a fullscreen game, a sound is the only feedback that always gets through. But the sounds play on the default output, which the Desktop track records, so the chime of one clip ended up in the next one.

What we found. The research had said: don't play sounds, they will be recorded. Dropping the feedback seemed worse than solving the problem.

Fix. The tray app tells the recorder exactly when each sound plays, and the recorder mutes those moments (10 ms before to 150 ms after, with soft edges) in the Desktop track before the Mix is built. The live check logged "muting 1 feedback sound span(s)". On September 27 a new bug appeared: with a chosen Desktop device that never plays the chime, the muting cut the headset's own sound instead. Now ShadePlay mutes only while the Desktop track records the Windows default output.

Chapter 4: the replay and the save

The last minute lives in memory

September 24

Problem. Keep the last minute at up to 750 Mb/s, without wearing out the SSD.

What we found. The compressed video of one minute can reach about 2.5 GB in fast action at the default HDR cap, while an idle desktop costs about 40 MB a minute. Nothing needs to touch the disk until you save.

Fix.

• The replay is a ring of compressed video packets plus one 48 kHz ring per audio source, all in memory.
• It keeps the replay length, plus one keyframe interval, plus 7 seconds of margin (including up to 5 seconds to make up for a slow hotkey).
• The first review added a budget: before, the menus offered settings that could need more memory than the PC has. The budget is a quarter of the PC's memory, at least 512 MiB. Beyond it, the oldest keyframe intervals are dropped, and the status says that the replay is shortened to fit. At the maintainer's first start, the budget came to 7.8 GiB.
• Saves waiting in the queue share the same budget.

Saving while you keep playing

September 24

Problem. "The save doesn't need to be instant, most times I clip and keep playing. I want the better audio."

What we found.

• Taking a snapshot of the ring held its lock too long: about 18 ms for a 5-minute replay at 360 fps, enough to stall the video thread.
• FFmpeg's default AAC encoder, the best-sounding one, is slower than the quick options. Encoded in parallel, four 60-second tracks took about 1 second.

Fix.

1. The tray app stamps the hotkey press with the shared clock and picks the file name.
2. The recorder takes references to the packets (no copies) in chunks of 2,048, releasing the lock in between, and copies the audio for exactly the same span.
3. A low-priority save worker builds the Mix, encodes the tracks in parallel (AAC-LC: 320 kb/s for the Mix, 256 kb/s for Desktop, Game and Discord, 160 kb/s mono for the mic) and writes the MP4 file.
4. The tray app writes a small sidecar file next to the clip, plays the chime and shows a notification.

Several saves can queue, and each one's content is fixed at the moment you press the key. In the first hands-on test, a 60.8-second clip with five tracks was saved 3.3 to 3.4 seconds after F10. Opus and FLAC are options in the advanced settings.

Never lose or overwrite a clip

September 24

Problem. The first review found three ways to lose a clip.

What we found.

• If the final rename hit a file lock lasting more than about 1.5 seconds (from antivirus or a sync tool, for example), the finished clip could be deleted.
• A cleanup of half-written files deleted any *.mp4.part file in the clips folder, including other programs' downloads.
• A clip with the same name as an existing file could have replaced it.

Fix.

• Clips are written as <name>.part and renamed when complete, so no other program ever sees half a clip.
• A rename is retried for 30 seconds, then a copy is tried, and as a last resort the finished .part file is kept. A finished clip is never deleted.
• Names are never reused: a taken name gets " (2)", " (3)" and so on.
• Only ShadePlay's own .part files (its exact naming pattern, in its game folders) are ever touched, and a complete one left behind is recovered at the next start by reading its MP4 structure.
• An unreachable clips folder (a network drive, for example) falls back to Videos\ShadePlay with a warning, instead of failing every save.

Naming clips after the game

September 24, refined on September 27

Problem. Clips should land in one folder per game, named after the game.

What we found. Many games leave the name fields of their program file empty, and some fill them with something odd. Overwatch's program calls itself "Overwatch Application", so the first real clips landed in a folder with that name.

Fix. The name comes from the first of these that exists: your own name for that game (in the advanced settings), the name in Steam's manifest, the program's product name, its file description, the window title, and the program's file name. The app that was in front for most of the clip wins, and the desktop is "Desktop". Names are made safe for Windows and macOS, reserved names and trailing dots included. A clip goes to <clips folder>\<Game>\<Game> YYYY-MM-DD HH-MM-SS.mp4, with its sidecar file next to it.

A settings file that can't be lost

September 24

Problem. An empty config.json (after a crash at the wrong moment, say) silently reset every setting, and the next change then overwrote the good backup. Reloading after an edit also rejected UTF-16 files, which Notepad and Windows PowerShell 5.1 write, although start-up accepted them.

Fix. One parser for start-up and reload, which accepts UTF-8 with or without a byte-order mark, and UTF-16. An empty file counts as corrupt. Saving is atomic: write a temporary file, keep the old file as .bak only if it is valid, then swap them. A bad value falls back to its default with a warning in the log.

Chapter 5: an app that just works

A supervisor and a recorder

September 24

Problem. A driver reset, a driver update or a thread stuck inside an encoder call can't be fixed from inside the process. And Windows has no automatic restart for normal apps: its built-in restart needs 60 seconds of uptime and only offers to restart, and Task Scheduler's restart covers only failed launches.

Fix. One program, two processes.

• The supervisor is the tray app: the icon, the hotkey, the settings, start-with-Windows, game detection, clip names, notifications and the watchdog. It loads no graphics, FFmpeg or audio code, so it has little reason to crash.
• It starts itself a second time as the recorder, inside a Windows job object that ends the recorder if the supervisor dies.
• The two talk over the recorder's standard input and output, one JSON message per line. The recorder reports its status twice a second.
• The watchdog restarts the recorder when its output ends, when no status arrives for 10 seconds, or when its video heartbeat stands still for 10 seconds while recording (30 seconds in other states). It waits 1, 2, 4, 8, then 15 seconds between tries, and starts over after a minute of healthy running.
• Before a restart, the old recorder is ended and awaited for up to 5 seconds, because it still holds a capture slot and an encoder session.
• A hidden top-level window hears Windows' broadcasts: display changes, sleep and resume, the taskbar restarting. The usual choice for invisible apps, a "message-only" window, never receives broadcasts, as a test confirmed.
• A crashing recorder writes its own crash dump. On a hang, the supervisor writes the dump from outside, on a worker thread that it abandons after 5 seconds, so the tray never freezes.

The first live test of the watchdog, on a test copy: after a crash the recorder came back after 1 second, then after 2; a hang was detected within 10 seconds and a dump was written; and when the supervisor was ended by force, the job object took the recorder with it.

Hangs that went unnoticed

September 24

Problem. One of the two high findings of the first review: whenever an audio problem put the recorder into its "degraded" state, a hang in the video thread went unnoticed, and recording could stop silently.

Fix. The hang rule applies in every state except shutting down: 10 seconds while video is recording, 30 seconds otherwise. The same review found that the hang dump was written on the tray's own thread, with no time limit. It now runs on a worker thread with a 5-second limit.

Starting with Windows, every time

September 24

Problem. The very first complaint was an Instant Replay that wasn't on after booting. Then the first review found the same kind of flaw in our own code (the other high finding): start-with-Windows was registered only on the very first run and never checked again, while the menu showed it ticked even when nothing was registered.

What we found.

• Programs in the registry's Run key or in the Startup folder start after Explorer's idle wait. Users report 30 seconds to 3 minutes, and Microsoft promises nothing. A Task Scheduler logon task starts at logon.
• Task Scheduler's defaults are hostile to a recorder: below-normal priority, a 72-hour time limit, and stopping on battery (a UPS blip would be enough).

Fix.

• A per-user logon task as the main launcher, with those defaults overridden (normal priority, no time limit, runs on battery, a 3-second delay so that the taskbar exists), plus a Run-key entry as a fallback.
• Both are checked and repaired on every start. The menu shows what is really registered, and a warning appears if both launchers fail.
• Turning ShadePlay off in Windows Settings > Apps > Startup is respected: the start-with-Windows launch then exits quietly.
• A copy running from a temporary folder, a synced folder or a build folder never registers itself, because sync tools can replace a running program and paths differ from PC to PC.

F10, and a check you do once

September 24

Problem. The design's default hotkey was Alt+F10, the same as NVIDIA's. The maintainer asked for something simpler: "maybe just F10 or something".

What we found.

• Claude warned that plain F10 already has a job in Windows and that some games use it. The maintainer kept F10, and later chose it again as the default for everyone, over Claude's Alt+F10.
• The research wanted to detect a clash with NVIDIA's hotkeys from Windows' "hotkey already registered" error. A test showed that NVIDIA's app doesn't register its keys that way: Alt+F10, Alt+Shift+F10, Alt+F9 and Alt+Z were all free while it ran. A clash can't be detected from an error code.
• Polling the keyboard, as some recorders do, fails while an elevated game has the focus. Low-level keyboard hooks are removed by Windows without notice after a timeout, and anti-cheat systems dislike them.

Fix. A standard registered hotkey: F10 by default, any key combination in the settings, and a retry every 30 seconds if another program holds it. On the first start ShadePlay asks you to press it once, and it notices when the keys were pressed but the hotkey never arrived, which means another program swallowed it.

Always recording

September 27

Problem. The first design had a Pause item, a paused setting and switches for the tracks. The maintainer: "I want it to always clip even on the desktop", and "I don't want it to be enabled only when gaming."

What we found. Even the first design had refused to remember a pause across restarts: an "off" state that survives a reboot is exactly the failure being replaced. Two questions were left, and the maintainer chose Claude's recommended answers: remove Pause completely, and keep only the clip names on the Games page.

Fix.

• No Pause, no "only in games" option, no switches for the Desktop and Game tracks, and game detection always on.
• Older settings files are accepted: their pause and switch values are read, ignored and not written back. A compatibility test ran a read-only copy of the maintainer's real settings file, plus seven broken or outdated variants, through the new code: all passed.
• The recorder still stops by itself while the PC sleeps, the screen is locked or no display is available, and the tray says that recording resumes by itself.
• To stop ShadePlay, choose Exit. It starts again at the next sign-in.

A hotkey picker that pressed buttons

September 27

Problem. "A simple tray app that can be opened where the settings can be changed" had been on the list since the first day, and the maintainer chose to have it built before the first hands-on test. It got six pages (General, Video, Audio, Games, Saving and Status), a hotkey picker, a live status strip and a light or dark theme like Windows', and it was checked only on a hidden desktop, never on the maintainer's. The worst finding of the second review was in it: choosing an Alt+letter hotkey in the picker also fired that letter's shortcut on the page. Alt+P ticked Pause, and Alt+A ran Apply.

What we found. Windows had already queued a character message for those keys when the picker took them.

Fix. When the picker finishes, it removes the queued character messages.

"Too complicated"

September 27

Problem. Right after the release work had started, the maintainer looked at the settings. About the audio page: "Just ask to select mic and speaker outputs." About the whole app: "The app is too complicated. I want it to be simple and just work. Make a simple slider for the bitrate and other quality things." About the status line: "I just expect it to record all sound." And about the YouTube helper: "since I have to manually upload to YouTube we can remove that too".

Fix. Claude stopped the release run within about a minute, confirmed that no file had changed yet, and rewrote the plan:

• One simple page: the save hotkey, the replay length (a slider from 15 seconds to 5 minutes), the quality (a slider with four stops, from "Smaller files" to "Best quality", with an estimate such as "Up to about 2.1 GB per minute of clip."), the frame rate, "What you listen on", the microphone, the clips folder and start with Windows.
• Show advanced settings opens everything else, as before. Every new option goes there.
• A minimal tray menu: Save now, Open clips folder, Settings... and Exit (and later Send feedback).
• Plain status: "Recording", with a line such as "your game, voice chat and mic are included". Process counts, codec names and dBFS live in the advanced view and in the logs.
• The YouTube helper moved to the advanced settings, off by default. Settings files from before are updated once (to version 2), so the helper doesn't stay on by accident.
• A new reviewer joined the release run: a "non-technical gamer" who checked the simple mode. The review then found codec names in the simple status, a PC without a microphone showing a permanent warning, and a replay slider promising more than the memory budget allows.

Notifications that wait for your game

September 24

Problem. A pop-up in the middle of a fullscreen game is the last thing anyone wants.

Fix. ShadePlay shows notifications only when Windows says that the user accepts them (not during fullscreen games or presentations), and marks them as "real time", so that Windows drops them rather than showing them late. Sounds give the feedback inside games (Our own sounds in our clips). The tray icon is drawn at run time (starting, recording, warning, error, standby) and comes back when Explorer restarts. ShadePlay never takes the focus, except for its own menu.

Exit while a clip is saving

September 24

Problem. Exit ended the recorder after 10 seconds even while saves were running (the recorder itself allows 60), silently, and left multi-GB .part files behind. Three review findings shared this one cause.

Fix. Exit waits up to 90 seconds for saves in progress, and a save that is lost anyway is reported with a tone and a notification. The installer waits for the same thing when it closes a running ShadePlay.

Chapter 6: YouTube without a Google app

Sign in with Google?

September 27

Problem. "Can we make it have a login with Google button", with defaults such as Unlisted, applied when a clip is set to upload automatically.

What we found (Google's documentation and policies as read on September 27, 2026, with the important claims checked again by a skeptical second pass against the primary sources):

• Videos uploaded through a YouTube API project created after 28 July 2020 that hasn't passed YouTube's compliance audit are locked private, and the lock can't be lifted for those videos. The audit asks for a public homepage and a privacy policy, and reported waiting times range from days to months.
• A sign-in app left in "testing" mode loses its sign-ins after 7 days.
• Open-source code may not ship API credentials, so every user of a public ShadePlay would need their own Google Cloud project and their own audit.
• YouTube Studio's upload defaults, such as Unlisted, don't apply to uploads through the API anyway.
• Since 1 June 2026, uploads have their own quota of 100 a day.

Claude raised the private lock before building anything, and offered three routes: automatic uploads plus applying for the audit (its recommendation), a browser helper, or both. The maintainer asked: "what are other options, can we do no Google app thing?"

Fix. No Google sign-in, and no upload code at all (A browser helper).

A browser helper

September 27

Problem. Make uploading easy without YouTube's programming interface.

Fix. With the helper on, clicking the "clip saved" notification (or a tray item) opens youtube.com/upload in your browser and a File Explorer window with the clip selected, and puts the clip's path on the clipboard. You drag it in, and YouTube Studio's own upload defaults apply. The maintainer chose it from four options.

At first the helper made a special "YouTube copy" (60 fps, the Mix track only, no MP4 edit lists) at low priority: a 60.8-second clip took 13.2 seconds, 4.6 times faster than real time. The review found and fixed several problems:

• the helper's 2-minute hang check could kill a healthy helper during a long rewrite of a multi-GB file; now disk activity counts as a sign of life;
• a clip without a Mix track silently kept only one track; now the helper picks the right one and says so;
• under heavy game load, a 10-second copy took 35 seconds, because the low-priority helper got little processor time. That was accepted: the game comes first.

The HDR scare

September 27

Problem. "I test uploaded one of the clips and it wasn't in HDR once processed."

What we found.

• Claude's first theory was the frame rate: YouTube's documentation lists HDR frame rates only up to 60 fps. It named processing delay and missing brightness information as other possible causes.
• Claude made two 60 fps HDR test copies on the GPU, one in HEVC and one in AV1, both 10-bit with full HDR labels. The maintainer uploaded both: "looks like neither is HDR".
• Claude then explained that YouTube adds HDR in a separate, later pass, and made a third copy without an MP4 edit list, just in case.
• Hours later: "B from earlier is now HDR on YouTube". The AV1 copy had turned HDR about three hours after its upload.

Fix. Nothing was wrong with the clips. YouTube processes the SD and HD versions first and the HDR version later, sometimes hours later. The README says so.

240 fps HDR works as it is

September 27

Problem. "I think it's probably fine if the fps is 240 on the upload, I don't want multiple copies of the same file."

What we found.

• The maintainer wanted to try a 240 fps AV1 HDR upload. Claude made one with the new helper's "remux" mode (no re-encoding: 240 fps, the Mix only, no edit list) in 0.37 seconds.
• "D is HDR on YouTube", about 15 minutes after the upload.
• And the very first raw clip, uploaded earlier that day with all five tracks and edit lists: "it looks great", in HDR and with the right sound.

Fix. "Upload to YouTube" now hands over the original clip: no copy and no duplicate file. The copy stayed as an option, and it keeps the frame rate by default (a quick remux). A live check proved that the original mode starts no extra process (515 process snapshots) and leaves the maintainer's clipboard alone. Later the same day, the whole helper moved to the advanced settings, off by default (Too complicated). The README's advice is simply to upload clips as they are.

A radio button that flipped itself back

September 27

Problem. In the YouTube settings, choosing "original" could flip back to "copy" when the window was activated again.

What we found. When the window got the focus back, the focus returned to the radio button that had it before, now unchecked, and Windows sends a "clicked" message when an unchecked radio button receives the focus. The review's finding was unverified at first; Claude reproduced it on real Windows, in a test harness on a private desktop.

Fix. The focus no longer returns to an unchecked radio button. The harness failed 5 checks before the fix and passed 73 of 73 after it.

Chapter 7: more graphics cards

AMD and Intel encoders

September 27

Problem. The maintainer asked for AMD support, so that friends with AMD cards could use ShadePlay too, and for "an exe or msi that installs everything" and "starts with Windows". Asked which cards, the maintainer chose NVIDIA, AMD and Intel Arc: one more than Claude recommended.

What we found. The FFmpeg DLLs already contained AMD's (AMF) and Intel's (Quick Sync) encoders. There was no AMD or Intel graphics card to test with, but the Ryzen processor has a small integrated Radeon GPU, and the research ran real test programs on it:

• AMD's encoder accepts ShadePlay's own graphics surfaces directly, with zero copies, and sending a frame doesn't block.
• 1440p HEVC at 10 bits ran at about 215 fps in the "speed" and "balanced" modes and 172 fps in "quality" mode, and 1080p HDR at 240 fps ran in real time with the right labels. 10-bit input was exactly as fast as 8-bit.
• The AMD RX 9070 XT has a single video engine, shared with Discord streaming, browser video and AMD's own instant replay.
• Intel's encoder can use the same graphics device, but no Intel graphics was available to test at all.

Fix. The encoder family follows the maker of the graphics card that drives the monitor. NVIDIA is tested. AMD and Intel are labelled experimental in the app and the README until someone runs them on a real card.

AMD's traps

September 27

Problem. In several places AMD's encoder quietly does something other than what was asked.

What we found.

• Its "quality" rate-control modes need a pre-analysis step that fails with 10-bit input. On 8-bit input it switches on silently and runs on the shader cores: 64 fps instead of 214 on the test GPU. One of these modes also blew far past the bitrate cap (1.11 Gb/s against 400 Mb/s).
• 10-bit video without colour labels is labelled HDR.
• Options with the wrong name, or set in the wrong place, are silently ignored: keyframes on request are off by default, and the usual B-frame setting doesn't reach AMD's encoder.
• On newer AMD cards, AV1 at 1080 lines is padded to 1082.
• AMD drivers were reported to hang when encoder sessions open back to back.

Fix. "Peak-constrained" VBR with a minimum quality floor, which behaved like NVIDIA's constant quality with a cap (109 Mb/s on hard content with a 100 Mb/s cap, where a fixed quality produced 331 Mb/s). Every colour label is always set, B-frames are switched off in the right place, and a fallback encoder waits a second before it opens. An AMD driver without 10-bit support records 8-bit SDR instead of failing; the release review caught that such a driver first stopped recording altogether.

No AV1? Use HEVC

September 28

Problem. AV1 encoding needs a recent card: an NVIDIA RTX 40 or 50, or an AMD RX 7000 or newer. On the research's own AMD test GPU, opening the AV1 encoder failed within about 12 ms with "encoder not found".

Fix. If the card refuses AV1, ShadePlay records HEVC by itself. The refusal is remembered for that graphics adapter only once HEVC has actually opened on it, because the same errors can also mean "driver too old". The release review found that "AV1 not supported" was first guessed from ambiguous error codes; now it counts only as a guess until the fallback has worked.

When the encoder can't keep up

September 28

Problem. A weaker card, or one shared with other apps, may not keep up at 240 fps.

Fix. An overload guard for every maker: if, over five seconds, more than 1 % of the frames are dropped and most frame sends are slow, the encoder steps to a faster preset (a new epoch). Late frames with quick sends come from somewhere else, so they don't count. The release review found that the step down lasted for the rest of the session. Now the guard steps back up after 30 healthy seconds, and if the overload returns, the waiting time doubles, up to 10 minutes.

A test anyone can run

September 28

Problem. Nobody at hand had a discrete AMD or Intel card.

Fix. ShadePlay.exe --encoder-test encodes a moving test picture with every codec, records nothing from the screen or the microphone, and writes a short JSON report about the graphics card, its driver and how each format did. Testers attach it to an issue (see the README's Tested section). On the RTX 5080, AV1, HEVC and H.264 all ran in real time at 240 fps with 0 late frames. On September 28 the report's --out desktop option learned to find the Desktop wherever Windows keeps it, because with a cloud backup of the Desktop folder switched on, the Desktop isn't where you'd expect.

---

---

<- Part 3: the picture | Contents | Part 5: making it shareable ->