I’m building LiveFaceSwap, a web studio that takes a webcam feed and a reference image, then shows the transformed video next to the original. You can see the result in the browser as you move. Open the camera menu in another app, though, and you’ll see your physical webcam. The transformed video is still sitting inside the browser.
That gap turned into a separate engineering problem. The model had already done its job. I still needed to get the right frames to the software people use to record, stream, or join a call.
For recording or streaming, OBS can capture a window. Point it at the browser studio, crop the scene to the processed output, and select your microphone in OBS. That gives someone a way to use the result without installing a separate LiveFaceSwap desktop app. If they need the composed scene in a call, OBS Virtual Camera can expose that scene as a camera source. I kept that route because it uses the studio that’s already running. It also gives people control over the rest of their scene. The tradeoff is that you’re capturing part of a window. Change the layout or resize the window and you may need to adjust the crop. If you want the output to show up as a named camera that another app can pick directly, you need an operating system integration.
I kept the web studio inside an Electron shell. It uses the same live processing and account as the website. The extra piece is a small bridge that only exists inside the desktop app. During a live session, that bridge reads frames from the processed output and passes them to a native helper. A Windows Media Foundation camera source can then present those frames to another app as LiveFaceSwap Camera.
The split is useful for debugging. The studio decides what the video looks like. The bridge moves those pixels. The Windows camera source makes them available as a device. If the preview looks fine but OBS can’t find the camera, I can start with registration and device selection instead of changing the model or its prompts.
There’s a simple way to catch one common setup mistake. Put an obviously different effect on the processed feed, then compare the two panes in the studio with the OBS preview. If OBS matches the raw pane, check which camera source you selected before spending time on AI settings. The microphone stays a separate input, so you can check it independently.
The current bridge targets 1280 × 720 at 30 frames per second. At four bytes per pixel, that’s roughly 111 MB per second of raw pixel data at the target cadence, before copies or other overhead. That’s the nominal size of the local handoff, not an internet speed requirement or a measured frame rate.
That calculation shaped a choice in the implementation. The renderer allows one frame submission at a time. If a submission is still outstanding when the next tick comes around, it skips that tick. The native pipe also tells the sender when to wait for it to drain. In live video, an old frame loses value quickly. A queue that faithfully delivers every frame can make a camera feel further and further behind.
There’s also a difference between a helper process starting and the helper being ready to accept frames. The controller waits for an explicit ready message before sending video. I can test that handshake and the binary frame format with a fake child process. Those tests catch errors at the boundary between JavaScript and native code. They don’t tell me whether a particular Windows machine will list the camera in OBS.
I think about the check in three steps now:
Each step narrows down where to look. A black browser preview can point to permissions or a busy webcam. A moving original preview with no processed video sends me to the live session. A healthy processed preview with no camera in the receiving app sends me to the capture or device path.
The browser capture route is documented, and the native route is available as an unsigned preview for Windows 11 22H2 or later on x64. I’m treating device discovery and live output in each receiving app as separate compatibility checks. That’s one of the more useful lessons from this build: I can make the demo work without having tested the place someone actually wants to use it.
OBS documents both the [window capture source](https://obsproject.com/kb/window-capture-sources) and [OBS Virtual Camera](https://obsproject.com/kb/virtual-camera-guide).
If you’ve shipped a virtual camera, what check caught the most real-world bugs for you: clean-install device discovery, repeated start/stop, or letting the video run long enough to see whether it falls behind?
Disclosure: This article was drafted by an AI agent from the project's source code and development notes. The project owner reviewed the draft and approved publication.