Fact-checking every course
ffmpeg -h muxer=whip on the local FFmpeg 7.1.1 binary returns Unknown format 'whip'. The WebRTC course taught -f whip as a command that already worked on FFmpeg 7.1.
On 23 September, every claim in every course, quiz, lab and reference tool got checked against a primary source: the FFmpeg 7.1.1 binary itself, the relevant RFC, Apple's HLS Authoring Specification, dash.js 5.2.1, or a vendor pricing page, whichever the section actually claimed to be citing. 617 teaching claims in the FFMPEG course alone, 98 of them wrong, outdated or imprecise enough to fix. Another 347 across the six lab modules, 54 corrections.
What "checked" meant
An FFmpeg claim meant running it: ffmpeg -h encoder=, -h filter=, -h muxer=, or the actual command against a synthetic input, not trusting what the lesson said the flag did. A spec claim meant the primary spec page, cited by section number. An external link meant curling it for a real status code.
The muxer that didn't exist yet
The sharpest finding: the WebRTC course's opening lesson said FFmpeg 7.1 added a whip muxer, so a command line could publish straight into a gateway like MediaMTX or Janus. Locally, ffmpeg -h muxer=whip on 7.1.1 returns Unknown format 'whip', and ffmpeg -muxers doesn't list it at all. The whip muxer landed in upstream commit 167e343bbe, tagged after n7.1.1 and before n8.0. It shipped in FFmpeg 8.0. Fixed across eight lesson files, each one now saying plainly that the local FFmpeg 7.1.1 used everywhere else in the course can't run it.
A second claim in the same course was worse: a debugging lesson told learners to probe a WHEP endpoint with ffprobe, captioned as needing "an FFMPEG build with the whep demuxer." No such build exists, at any version. ffmpeg -h demuxer=whep fails the same way on 7.1.1, and a GitHub commit search across the entire FFmpeg history, current git master included, turns up zero WHEP demuxer commits, ever. The fix swapped in a workaround that actually runs: probe MediaMTX's re-served RTSP stream instead, since that's what sits on the other end of a WHEP gateway.
Three smaller WebRTC corrections, precision fixes rather than outright reversals: a=simulcast send was missing its colon (RFC 8853 requires a=simulcast:send). "Opus is the only audio codec every peer shares" isn't true; RFC 7874 §3 makes G.711 equally mandatory to implement. "H.264 baseline" should read "H.264 Constrained Baseline" in four places, per RFC 7742.
Getting the direction backwards
The FFMPEG course had a cleaner kind of bug: math with the sign flipped.
| Lesson said | Command | Actual result |
|---|---|---|
| "4× slower" | setpts=PTS/4.0 | 4× faster (0.99s from a 4s clip) |
| "2× faster" | setpts=PTS/0.5 | 2× slower (7.92s from a 4s clip) |
| "2× slower" | setpts=PTS/2.0 | 2× faster (1.98s from a 4s clip) |
Six lesson passages, a challenge, and a quiz all built on the same inverted rule: "smaller divisor equals faster." It's backwards, in both directions, confirmed against FFmpeg's own documented setpts=2.0*PTS idiom for slowing down 2×. The quiz's marked-correct answer was the wrong option. The fix rewrote the module to the multiplier form, setpts=0.5*PTS, setpts=2.0*PTS, instead of division, and re-verified every rewritten command's output duration against what the prose now claimed.
Other FFMPEG fixes: smartblur thresholds that sat outside the filter's valid range and would fail if a learner actually ran them, and a "5-10x faster" hardware-encoding figure repeated five times with no source behind it, softened to "often several times faster (typically 2-10x, depending on GPU, preset and resolution)."
The labs had their own kind of wrong
347 claims, 54 corrections. A -var_stream_map command in both the GCP and AWS Cloud Video Lab packages reused one -map 0:a across three HLS variants. The command fails to run. AWS MediaConvert and MediaLive pricing ranges understated the real ceilings by 3-7x. Three citations, including an HBO Max incident attribution with no traceable source, got replaced or dropped outright rather than left standing on nothing.
The review ledger
docs/content/fact-check/REVIEW-DECISIONS.md is the adjudication pass: accept a correction, correct it further, or defer it. 117 rows went to QUESTIONS.md instead: rules of thumb with no source and simplifications nobody could sign off on as fact ("VP9 is about 30% better than VP8" is one). The first round of fixes needed a second one. The labs PR's own follow-up commit, after code review, fixed the real CBR figure in the AWS command, reworded a Twitch FPGA claim, corrected a Zoom recording citation, and fixed an egress-tier comment, all missed the first time through.
Two of those 117 rows are design questions, decisions I haven't made yet. One: the Cloud Video and Media Networks labs' pricing figures are dated 23 September 2026, and cloud vendors change prices. I haven't decided whether that means a review cadence, an "as of" label in the UI, or something else.