Cinematic dorito fix web reaction

Hah — well, fair play to your local Claude for actually doing the bisect. I'll take the L on the TAA call.
Reading through your report, a few things to sit with:

The chroma-subsampling diagnosis is cleaner than mine in a way that makes me a bit annoyed I didn't land on it. Mag mean of 11–14.6 across any H.264 yuv420p quality versus 7.26 for yuv444p is a really decisive signal — that's not a quality-knob problem, that's a structural one. Bumping bitrate or CRF inside 4:2:0 doesn't help because you're not losing precision in the encode, you're losing it in the colorspace conversion before the encoder ever sees the pixels. The 2×2 chroma averaging is deterministic; no amount of bits saves a highlight that's already been averaged with its neighbors. That's why the smear had that locked-in, "this is what the pixel just is now" quality rather than the temporally-jittery look real TAA ghosting has. In hindsight, the static shape across the smear was a clue I should have weighted more.

The reason my diagnosis was tempting and wrong: chroma-subsampling artifacts and specular-temporal-ghosting artifacts can produce visually similar smears on bright highlights against darker backgrounds, because both involve "color information from one place ending up at another place." But the mechanisms are completely different — TAA is temporal (across frames), 4:2:0 is spatial (within one frame). Asking "does it appear on a still frame straight from the engine" would have separated them in one step, and I didn't push hard enough on that.

The three-mode setup is the right shape for this. Default 4:2:0 for anything that's going through a social re-encoder anyway (since you're right — Reddit/YouTube will crush it back to 4:2:0 regardless, so paying the file-size cost of 4:4:4 for a deliverable is wasted), 4:4:4 for "I want to actually look at this on my own machine and see what the engine is doing," and FFV1 as the archival truth. Clean separation of concerns.

One small thing worth flagging for your future self: the FFV1 mag mean of 5.57–6.36 vs. 7.26 for H.264 4:4:4 — that gap (~1 unit) is probably the H.264 DCT quantization on the chroma planes specifically, not a subsampling issue. If you ever care enough to close that gap without the 1.5 GB cost, H.264 lossless mode (-qp 0) or HEVC -x265-params lossless=1 would land you at FFV1 levels at roughly half the size. Probably not worth it for a deliverable pipeline, but good to know exists.

*AFTER READING THE BISECT REPORT*

Read it. A few things stand out beyond the summary you'd already given me.

TAA was off the entire time. That makes my original diagnosis worse than "plausible but wrong" — it's confident-sounding pattern matching on a mechanism that wasn't even running in the scene. The shape of the artifact triggered a "this looks like specular TAA ghosting" reflex, and I committed to that read without asking the one question that would have falsified it in one turn ("is TAA on?"). Worth filing under lessons.

The -bf 0 -g 30 cq=16 row is the cleanest falsification in the table and it's a falsification of the followup theory I floated, not the original one. After you'd told me about WGC+NVENC, I shifted to "NVENC motion-compensated residuals on a bright highlight, exacerbated by 4:2:0." The 4:2:0 part survived; the motion-compensation part did not. With B-frames disabled and a 30-frame GOP, every artifact-bearing frame is either an I-frame or a P-frame predicted from a recent I-frame, and the magnitude barely moved (14.58 → 11.32). If motion compensation were doing real work in producing the smear, killing B-frames and shortening the GOP should have changed the texture of it. It didn't. The smear is intra-frame.

The p7 cq=1 row is the other really decisive one. That's about as much quality as NVENC can deliver under yuv420p — high-quality preset, near-lossless quantizer, no B-frames — and it lands at 11.31, basically indistinguishable from the default-quality run at 11.40, while yuv444p at the same preset drops to 7.26. There is no rate-control or quality knob inside 4:2:0 that recovers the chroma, because the chroma is already gone before the encoder gets the buffer. That's a textbook demonstration and worth keeping in your back pocket the next time someone says "just bump the bitrate."

The 0.8-unit env contribution is interesting on its own. Baseline 5.57 vs. full-env-ffv1 6.36 is the noise floor of the rendering itself — SDFGI and the rest of the stack producing slightly different float outputs frame-to-frame even with a locked camera. That's not an artifact, that's just what a stochastic-ish renderer does. It's useful to know that floor exists because it tells you how close to "pixel-identical to engine" you can ever realistically get through any encode. The 7.26 yuv444p result is roughly 0.9 above that floor, which is about as good as H.264 will ever do here without going lossless.

The "social re-encoders WILL re-transcode to yuv420p" line in the report is the one practical insight I underweighted in my reply. I framed the 4:4:4 build as a viable delivery option for some platforms; really it's a verification tool. Reddit, YouTube, Twitter, Discord — they all re-transcode, and they all re-transcode to yuv420p. So the 4:4:4 build's actual job is to let you watch your own footage cleanly and confirm the engine is producing what you think it's producing; the 4:2:0 build is the only thing that ever leaves your machine for a deliverable, and the smear is just a fact of life on social platforms regardless of what container you upload.