My split-screen fix passed every test. It fixed half the bug.

Created: October 12, 2026 · Updated: October 12, 2026

Katto turns long videos into vertical clips. I build it solo, in public. On 10 October I fixed a split-screen geometry bug, tested it, shipped it and wrote "fixed" in the changelog. That evening I found the same bug still happening. And fixing it twice still did not make the split screen good.

What a split screen is for

A podcast or an interview is usually filmed wide: two people at a table, one on each side of a 16:9 frame. A vertical short is 9:16. Crop the centre and you get the table and nobody's face. Follow whoever is talking and the other person disappears every time they reply. (The general problem of turning horizontal video vertical has its own guide.)

When two people sit far enough apart, Katto does something else: it cuts one window around each person and stacks them, one on top of the other. Two half-height panels, both faces visible, all the time. It is the standard answer to the two-speaker shot, and it is what the reframe page describes.

What was going wrong

Each panel has a width, and the code capped that width so the two windows would not overlap. The cap was derived from the distance between the two people. That sounds reasonable and it measures the wrong thing.

Here is a real case. A 1920 pixel wide source, the two people 1300 pixels apart. The cap came out at 1235, the panel width at 1214, so the cap did not engage. Then each window was centred on its person and pushed back inside the picture where it ran off the edge. The left window moved 358 pixels right, the right window 236 pixels left. Towards each other.

Two windows of 1214 pixels need 2428 pixels to sit side by side. The picture has 1920. Whatever you do with them, at least 508 pixels end up in both panels at once.

On screen that is a strip of the same image at the bottom of the top panel and the top of the bottom panel: a shoulder twice, half a face twice, sometimes the whole person twice.

The rule I should have started from fits in one line: two windows of width W fit side by side only if 2W is at most the width of the picture. The distance between the people has nothing to do with it.

How often it happened

I went back over the split clips Katto had already delivered and read the overlap straight from their stored geometry: the right edge of the first window minus the left edge of the second.

31 percent of them overlapped. Among those:

Overlap	Share	What you see
300 px or more	18%	a person or a torso duplicated
150 to 299 px	15%	a piece of body at the inner edge
60 to 149 px	36%	a strip of background
under 60 px	30%	nothing you would notice

Percentages are rounded, so they add up to 99. Roughly a third invisible, a third subtle, a third plainly broken. The worst case was the 508 pixels above.

My first count said 23 percent, not 31. I had computed the overlap through a field that is missing on some older clips, and those rows were skipped without a word. The number looked plausible, so I nearly kept it.

The fix, and the tests it passed

The new cap is the one-line rule: each panel at most half the picture, and the two windows placed so they cannot cross. It only engages when the original placement actually overlaps. An earlier version recomputed the geometry in every case and nudged a handful of healthy clips by a pixel or two. A fix that touches clips that were fine is a second bug.

Then the checks. I replayed a batch of stored clips with the fix off and on: everything that did not overlap came out identical, and the only clips that changed were exactly the ones that overlapped. Then a fresh job on a real video: 12 split clips, the cap engaged on 3, none overlapping.

I shipped it, and I wrote it up in the changelog as fixed.

The same evening

One more test video. One clip came out with a 44 pixel overlap, with the fix switched on.

There were two functions. One handles the classic case, two people facing each other at a table, and gives each a close-up. The other is the general fallback, used when the first one declines: it takes the leftmost and rightmost faces in each frame and splits on those. Both produce a split-screen clip with their own pair of window positions. Both had the same defect, almost word for word. I had fixed the first one and never opened the second.

The annoying part is how convincing the evidence looked. My measurement and my test batch mixed both code paths, and I had no idea. The first fix cleaned up enough of the sample for the result to read as complete. A measurement taken on stored results counts symptoms. It does not tell you how many places produce them.

The second fix is the same rule in the second function. Replayed on the same batch: four more clips corrected, overlaps of 56, 124, 230 and 340 pixels all down to zero, nothing else moved. The 56 pixel one had come through the morning fix untouched. That is the leak, caught in the act.

Checking for a third one

Before writing "fixed" a second time, I searched the code for everything that sets a window position. Four places, not one. Two are the functions above, now both corrected. The third builds panels from a dividing line it has already found and caps each panel at the space on its own side of that line, so its two windows cannot cross by construction. The fourth only passes the third one's numbers along.

So the claim this time is narrower: no split screen rendered since 10 October puts the same part of the picture in both panels. Clips rendered before that keep the geometry they were made with.

What is still not right

No duplicated picture is a floor, not a good split screen. Three things I can see on real videos today:

The panels are too wide for the people in them. Each panel is sized from the picture, not from the person. On a wide studio shot, someone can fill a third of their panel with the rest given to the set behind them. Two half-empty panels can look worse than one well-framed shot, and it is the reason I have not yet opened the split to more kinds of shots. Tightening each panel around its person is the next piece of work.

A short exchange inside a longer clip does not get split. The decision is made for the whole clip. If one person talks for forty seconds and the second person cuts in for five, the clip stays on a single framing and the reply happens off screen.

Some two-person shots are never recognised as such. The trigger counts faces. In profile, at a distance or in poor light, the face detector can miss a person that the body detector sees in every frame, and the clip falls back to a single framing.

None of these duplicates anything. They are the difference between a split screen that is not broken and one that is actually good, and I would rather say so than let "fixed" stand for both.

What I am keeping from this

When a fix works, look for the other places that produce the same output. Not only the place where you found the bug: every place that can emit the same kind of result. Here it was one search for one field name, and I ran it after shipping instead of before.

An aggregate number cannot tell you a fix is complete. It went down a lot, and a big drop is exactly what makes you stop looking.

A metric that quietly skips rows is worse than one that fails. A missing field turned 31 percent into 23 without a single warning.

Start from the constraint, not from a proxy. The cap was built from the distance between two people because that number was at hand. The real limit was the width of the picture, which was also at hand.

The changelog entry said "fixed" on 10 October, a few hours too early. It now says what happened.