A tester saw 2 cameras, and the editor was innocent

Somebody testing Cilevi dragged the camera inset in a project, exported it, and reported 2 cameras stuck on screen at once. One at the bottom left, where they had put it, and one at the bottom right that they had never put anywhere.

That looks exactly like a rendering bug, and it cost most of a day before it turned out not to be one. The useful part is not the fix. It is the order the suspects were eliminated in, because the same order will save you a day on your own tools.

What the compositor was accused of

There were 4 plausible ways for a second camera to get drawn, and each was checked against the real project file rather than reasoned about:

The camera drag has a mechanism that restores the background under the bubble as it moves, which would leave a ghost if it ever got the dirty rectangle wrong. It was read line by line, and then ruled out by a fact about the report: the bug appears on a fresh load of a project nobody has dragged in that session, in frame zero.

A cross dissolve between 2 recordings draws both of their cameras for the length of the transition, which would genuinely put 2 faces on screen. That project has exactly 1 video clip. With no join, the code that looks for one can never return true, and a log line put in immediately before the check confirmed it at every frame.

A camera region clip can enlarge or hide the camera, so 2 of them overlapping might explain it. The project's camera track has no clips at all.

That left the painter itself drawing twice. A log line inside it printed the destination box and the source texture on every call across the whole export: 1 call per frame, the same box at 265,640 and 259 by 259 pixels, the same texture, for all 6.8 seconds.

The answer was already in frame zero

Pulling a frame straight out of the raw screen recording, with none of our own compositing anywhere near it, showed the second camera sitting there in the corner of the desktop.

It was the floating camera preview window. The small live bubble the recorder shows you before and during a take, so you can see your own framing. On this machine that window is excluded from capture and never lands in a recording. On theirs it did, and once it is in the raw file it is as much a part of the video as their taskbar. The editor then correctly added 1 camera inset of its own, which is how a single correct render reads as 2 cameras to somebody who does not know the preview window exists.

The lesson generalises. Before suspecting the layer that composites a picture, look at the layer the picture comes from. A frame dump of the raw asset, taken separately from the export, is what actually split "our code drew this" from "the source already had it".

The flag that was supposed to prevent it

Windows has a call that marks a window as excluded from screen capture, and the preview window makes it immediately after it is created. The same call is used by the toolbar, the countdown and the region overlay, and on a current Windows it works.

It needs Windows 10 version 2004, build 19041, or newer. On anything older the call either does nothing or blacks the window out instead, and either way the content can end up in the capture depending on how the capture is being taken.

Their exact build was never checked, because there was no access to their machine. That makes the build number the leading explanation and not a confirmed one, and it is worth saying plainly rather than filing the bug as solved.

The toolbar was doing the same thing, and that is worse

The recording that proved the camera leak also has the recorder's own toolbar baked into it, along the bottom centre. Same call, same failure.

That one is worse than the camera preview, because the preview only affects people who record with a camera on, and the toolbar is on screen for every take. On a system where the exclusion silently fails, every recording anybody makes has our own controls sitting in the middle of it.

Hiding the window was the wrong fix

The first fix hid both windows for the length of a take on any system where the exclusion could not be trusted. Trust is now decided by 2 things that have to agree: the real build number read out of the registry, which survives an application manifest making the ordinary version call lie, and the return value of the exclusion call itself.

Hiding works, and the owner of this project asked the right question about it: can an old Windows really not show a user their own camera while recording? It can. Every capture this recorder takes is a rectangle. One monitor, or one window, or a region you dragged. Anything outside that rectangle is not in the video, so the preview window does not need to disappear, it needs to move somewhere the capture is not looking: beside the captured area first, which on 2 monitors means the other screen, then below it, then above it.

Hiding survives only for the case with nowhere left over, which is one whole screen being recorded on a machine with one screen.

When there is nowhere to park

A user whose toolbar has just vanished has no obvious way to stop recording, so in that one case a window comes up before the countdown, warning that the controls will be hidden and naming the ways back: F9, or clicking the tray icon to bring the toolbar back, or right clicking the tray icon for Stop Recording. Cancel means no recording starts at all.

There is a real trade here and it is not free. On an older single screen Windows you record without seeing your own camera preview, and you stop with a keyboard shortcut or the tray. The alternative is your own face in the corner of every video you publish.

Nothing changes on a current Windows

This was the condition the whole fix had to meet. On a machine reporting build 26200, with the exclusion working, there is no notice, no warning, and no movement: the toolbar and the preview were measured at identical coordinates before a take and during it. Every branch above sits behind the check, so it costs nothing where the flag does its job.

Check your own raw file, not your export

If something impossible shows up in a video you made with any tool, find the raw capture before you open the editor, and look at the first frame. Half of what looks like an editing bug was already in the file.

If you are on Windows 10, winver tells you the build. Below 19041, the exclusion call cannot be trusted by anything that uses it, which is worth knowing beyond this program. Recordings that survive worse than this are covered in how a recording survives a crash, and a report of something impossible in your own recording belongs on the feedback board, with the raw file if you still have it.