Devlog #5

SubBake was released, the web demo went live, and then the review came back: “can’t see no subtitles.” That’s a bug report against a shipped product — the whole point of the app is subtitles, and the review had no way to see them. I couldn’t argue with it: the output carried no visible proof. This devlog is about hunting that bug down and making sure the subtitles can never be invisible again.

The fix two

There was no rendering at all, nothing to prove a subtitle existed. So the fix attacked both sides. Burn mode re-encodes the video with subtitles drawn into the frames, so the text becomes part of the picture — impossible to miss. And the preview gives real playback with a VTT attached to the <video> element, so muxed output shows its subtitles too. The web API grew a mode parameter (mux | burn), the burn path got progress and cancel wired through the existing worker machinery, and the GUI picked up a matching checkbox. Burn mode also rejects SUP input outright — bitmap subtitles can’t be rasterized by libass, and a silent fallback would just recreate the “nothing visible” bug.

The output file was empty, and nobody noticed

While testing burn with a +1s offset, the job failed with a cryptic libass error: Unable to open /tmp/.... The real cause was in the remux step. The remux command — the one that shifts timestamps with itsoffset before burning — was missing -y. The output path already existed because it came from NamedTemporaryFile, and ffmpeg refuses to overwrite without -y. Worse, it exited with returncode 0 while writing nothing, so the “did it succeed?” check passed. A zero-byte file then went into libass.

Two small ordering bugs

• The preview VTT was extracted with a hardcoded "ffmpeg" while the rest of the server resolves a bundled binary via find_ffmpeg(). On a machine without ffmpeg on PATH, preview breaks exactly where the reviewer looks. Switched to the shared resolver.
• The <track> element was appended after video.load(). The track never registered, so even correct VTT extraction showed nothing. Order matters: attach the track, set the source, then load.

Proof

The bug report was about visibility, so the fix had to be verified the same way. I burned two different subtitle files into the same video and compared raw RGB. Everything above the subtitle band matched; rows 174–239 differed by ~14,000 pixels — the only difference between the two outputs was the burned text. Then an offset burn: at t=0.5s the frame matched the original (subtitle hadn’t appeared yet), at t=2.5s the text was present.

Korean needed one more thing in production: the server had no CJK fonts, so Korean subtitles would burn as tofu boxes. Installed noto-fonts-cjk, re-ran the Korean burn — 12,152 pixels of band difference, and the black outline count jumped from 1385 to 1581. Real glyphs, not boxes.