Bilingual subtitles in OBS with chroma key, end to end

OBS has no built-in live captioning. The standard cross-border approach treats captions as a video source: the translation tool draws a caption window on a pure green background, OBS captures that window, and a chroma key filter turns the green transparent.

What makes this worth doing is the decoupling — any program that can draw text becomes a caption source, and OBS never needs to know where the text came from. The price is that you inherit every quirk of window capture.

#00B140 and #00FF00: separate the two claims

#00B140 genuinely is the film industry’s green screen standard — but it standardises fabric and paint, so that a physical backdrop still reads evenly once it has been lit and shot. A caption window is drawn directly by software: no creases, no uneven lighting, no sensor noise. None of the reasoning survives the move.

What does bite you is elsewhere. OBS’s Key Color Type preset “Green” is 0x00FF00 in the source code — see the key_type branch in chroma-key-filter.c. Set your caption background to #00B140, leave OBS on the Green preset, and OBS is keying a colour you never used. The symptom is having to push Similarity extremely high before the background clears, at which point the text edges start eroding — which reads as “I picked a bad green” when the real problem is that the two ends never matched.

So the section reduces to two rules and a footnote:

1. Both ends must be the same colour. Use Custom and type the hex value, or eyedrop the window background directly;
2. The background hue must sit as far as possible from the text colour. White text with a black outline over green is safe; if the captions themselves contain green, key against magenta or blue instead.

Whether that colour is #00FF00 or #00B140 barely matters for a software-rendered window. Both key cleanly. The only advantage of the former is that it matches the OBS preset.

Two capture methods, plus automatic

The Capture Method dropdown on a Windows Window Capture source has exactly three entries, spelled out in OBS’s own interface strings:

• Automatic lets OBS choose;
• BitBlt (Windows 7 and up) is the legacy path. Low overhead, but blind to GPU-accelerated content, so Electron and Chrome-based windows often capture as solid black;
• Windows 10 (1903 and up) is Windows Graphics Capture. Best compatibility, and it handles hardware-accelerated windows.

The widely repeated claim that Windows Graphics Capture is a third, separate method comes from treating the API’s technical name and its interface label as two different things.

About that yellow border. Capturing with Windows 10 (1903 and up) draws a bright outline around the captured window. Windows draws it, not OBS: the OBS knowledge base explains it comes from Microsoft’s capture API as a security indicator. Two things follow. It exists only on your own screen and never enters the recording or the stream, and on Windows versions that expose a way to switch it off, OBS requests exactly that with no user action required — see the IsBorderRequired handling in OBS’s WinRT capture code. Seeing the border is not a fault to chase.

If your caption window captures black, change the capture method first. Do not start debugging the caption program.

DPI scaling is the silent time sink

This is the trap that costs people half an hour: Windows display scaling at 125% or 150% makes the pixel dimensions that window capture receives differ from what you see on screen. The symptom is captions that look blurry in OBS, or a capture that only contains the top-left corner of the window.

The dependable fix is setting the display that hosts the caption window to 100% scaling, so logical and physical dimensions agree. Windows also offers “Override high DPI scaling behaviour” in the compatibility settings, which is worth trying, but its effect depends on how the individual program declares DPI awareness and it does not always help. Do not reach for it first.

The step people skip: render the caption window at the pixel size you intend to display in OBS, rather than rendering large and letting OBS scale it down. Text loses definition on any resampling pass, and the sharpness you keep here is worth more than anything you can recover with a filter afterwards.

Readability matters more than the plumbing

Once it technically works, typography decides whether it helps:

• Two lines maximum. Bilingual captions are inherently twice as long, and anything beyond two lines changes before viewers finish reading.
• Source language on top, translation below, with the translation optionally a size larger. Overseas viewers are reading the translation; the source is corroboration.
• Dwell time cannot be a pure function of character count. A short but dense line — a price, a size chart — needs to stay longer.
• Respect the safe area. Platform UI covers the bottom of the frame with comments and buttons. No platform publishes how much, and it changes between app releases, so the only reliable method is to go live once, open your own room on a phone as a viewer, screenshot it, and measure the obstructed band. Then lock the position with Transform → Edit Transform.

The synchronisation illusion

A recurring report: viewers say the captions lag the audio. Do not immediately start adjusting the translation tool.

Captions and audio travel completely independent paths inside OBS. Sync Offset, in Advanced Audio Properties, is a per-audio-source setting; video sources, including your caption window capture, have no equivalent. The two directions therefore need different treatment:

• If captions arrive before the speech, the fix is on the video side. OBS ships a Render Delay filter, described in the filters guide as delaying the rendering of a source to help with audio/video sync. Add it to the caption source and push it back in milliseconds.
• If captions arrive after the speech, Render Delay cannot help — it only pushes later, never earlier. Look at how fast the caption program itself emits text. And note that a Window Capture source has no frame rate setting; refresh comes from the FPS value under Settings → Video, so hunting for a capture frame rate in the source properties is time wasted.

Record locally and step through frames before adjusting anything. Judging which of two streams is ahead by eye, live, is not reliable.