Build a Live Treatment-Demo Feed With Preview and Program Kept Separate
Build a Live Treatment-Demo Feed With Preview and Program Kept Separate
There is a moment in a remote treatment meeting when you need to stop talking about the page and start showing the thing — the animation, the sample, the little application that proves the idea works — and then get back to your own face without the client watching you rummage. A fixed screen share can't do that. It has one window and one state, and every reach for the next thing is visible.
OBS Studio can do it, and the mechanism fits in a sentence: Studio Mode gives you a preparation pane called Preview and an outgoing pane called Program, and a transition moves one into the other. The client should be watching Program. You should be fiddling in Preview.
That sentence is where most people stop, and it isn't enough. A preview pane is private by convention, the way a rehearsal room is private — nobody outside the room is watching. Unlike a rehearsal room, there is a switch down the hall that puts it on air. The Virtual Camera has its own output selection, and one of the choices is Preview.
So the job is this: build only the scenes the conversation needs, prepare in Preview, transition into Program on purpose, confirm which of those two the virtual camera is actually sending, find out which sources two scenes share, route the audio separately and check it, and rehearse the failure you hope not to have.
Everything below is a rehearsal you run on your own machine with your own harmless material. Where OBS's documentation actually supports a step, it's named. Where it doesn't — and there are three places where it doesn't — the step is a check you perform, not a promise anyone made.
Build four scenes with named sources
Rehearse with material you own. An invented title page, a placeholder speaker name, a sample file that isn't anyone's unreleased work. You are going to break things deliberately in a few minutes, and the breakage should land on throwaway material.
Four scenes cover almost every treatment conversation:
Speaker carries the camera. It's where you return to talk.
Page carries the treatment page the client is arguing about — a specific browser window or reader window showing it, not the whole desktop.
Demo carries the thing that moves: the animation, the media file, the small application that proves the idea works.
Card carries the still and the sentence you cut to when the demo dies: a static frame, a placeholder, words you can narrate over while you fix what broke. Build it now, because the moment you need it is the moment you can't make it.
That's the set, and all of it is built before the call starts. Anything you add mid-call is one more thing to keep track of while you're also talking.
Capture the window, not the display. A display capture includes notifications, other applications, and your own notes — and it includes anything you drag onto that display "just for a second." When you choose the window, choose the one the room would see: if you capture a presentation application's presenter view, the notes panel is inside that window and therefore inside the feed. Pick the audience-facing window instead.
A window capture can also reach the receiver as a black or frozen rectangle. You find that out by looking at the receiver, not at the thumbnail sitting in OBS.
Name scenes for their jobs and sources for their origins — Speaker, Page, Demo, Card for the scenes; Cam — built-in, Window — treatment browser, Media — sample_v3 for the sources. Ten minutes into a call you'll be staring at two panes and a source list, and you need to know instantly which name describes a job and which describes a machine.
Before you trust any of this, write down three things: the OBS version you're running, your operating system version, and the meeting application's version and whether it's the desktop app or a browser tab. Menus move between releases. A set of instructions that doesn't name its versions is a rumor.
Prepare in Preview, send Program on purpose
Studio Mode splits the main window. You arrange the next scene in Preview; the transition control moves what's in Preview into Program. OBS's own overview of the feature describes that sequence directly — prepare in the preview view, then make a deliberate transition to the outgoing composition.
For camera-to-page and page-to-demo, a cut is usually the right choice. A slow dissolve across an information change makes the client wait for something they already asked for. Save the long transition for a moment that earns it.
Now the part that decides the outcome.
Studio Mode controls what OBS is composing. The Virtual Camera controls what leaves your machine. Choose Program there — the guide lists Program, Preview, Scene and Source as the available outputs, and Program is the one that sends the live composition you've been building.
Choosing Preview is the trap, and it isn't subtle once you know it exists: the Virtual Camera guide describes the preview output as sending the preparatory view, including the changes you make to it. Your client watches you assemble the next scene. Scene and Source point the camera at a fixed target rather than at the live Program feed, which means your transitions stop being the thing that decides what goes out. Verify at a receiver before you rely on either.
Both OBS pages are older than the build you're probably running — the overview carries a 2021 date and the virtual camera guide a 2022 date — so read the actual wording on your machine rather than mine. The setting lives near the virtual camera controls; start the camera, then select the virtual camera entry in the meeting app's camera list.
Then the step people skip. Nothing on your screen proves any of this. The word Program printed under a pane is a label on the operator's side. The question — what is the meeting showing? — gets answered somewhere else: a second device signed into the same meeting, camera off, microphone muted, speakers audible, sitting where you can see and hear it while you work. A colleague on the call does the same job. Your own self-view tile is a start, but that's the meeting application rendering your feed back to you, not a second participant decoding it.
A reused source is one source, not two
A scene is not a saved picture. It's an arrangement of live inputs, and the same input can sit in several arrangements at once. When a source appears in both Page and Demo, there is one window being read, one media file being played, one text object placed on two canvases.
The distinction worth testing is between the scene's arrangement of a source and the source itself. Run it with a marker before the call. Put a large text source reading PAGE into the Page scene, then reuse that same text source in Demo. With Page in Program, select Demo in Preview and watch the receiver device while you do two things:
- Move the marker and resize it inside the Demo scene.
- Change the marker's text to NEXT and enlarge the lettering.
You aren't trying to get the correct answer. You're trying to learn which answer your version gives you. Whichever edit reaches the receiver's live image while you're still preparing is the edit you cannot safely make during a pitch — and you learned it with the word NEXT instead of a client's page number.
Then the part that needs no experiment. A window capture is a live view. Scroll the treatment page in that browser while Page is in Program and the client scrolls with you. The page you flick to is the page they see. There is no snapshot and no buffer between the window and the feed — which means if you need to look at something the client shouldn't see, look at it in a different window, a different document, or a different device.
Where your marker test shows a preparation change reaching the live output, you have three honest options: don't edit that source while you're live; add a second, separately configured capture of the same window for the second scene so the two scenes aren't holding the same input; or restructure so the two uses don't overlap. Renaming the scene changes nothing — a name is a label for you, not a boundary around the source.
Which brings us to notes. Notes are a source problem, not a discipline problem. A note is safe exactly when no capture can see it. Not on a display you're capturing. Not in a window you're capturing — including another tab of the same browser window, because the window is the unit being read. Not in the document you're scrolling in the Page scene. A second display that no capture references, a phone, or paper. That's the list.
Sound takes its own route
The Virtual Camera guide is a guide to a picture. It documents which video OBS hands to the camera device. It does not tell you where your microphone goes, and it does not establish that your demonstration's audio travels alongside the pictures. No virtual camera setting decides the meeting's audio path. The meeting application has its own microphone selection sitting a few menus from the camera selection, and it's wrong by default often enough to matter.
So decide the route deliberately and write it down as a device name, not as an intention.
The simple route: your microphone goes into the meeting app and OBS never touches your voice. Then the demonstration audio has to reach the room some other way — usually by playing it out loud so your microphone picks it up, which also delivers your room and plays your sample through a laptop speaker. It works. It sounds like a phone call, and if your headphones are on, your microphone hears nothing at all.
The composed route: microphone and demonstration audio both go into OBS, and OBS's output is presented to the meeting as a separate audio device. This is the route that gives you a mixed, level-matched feed. It also depends on your operating system and your meeting application's device list, and it is precisely the part the documentation does not settle. Check your own machine.
Then check at the receiver with two separate cues:
- Speak. Do they hear you once, at a normal level? If they hear you twice with a short gap, your voice is arriving by two routes at once — direct and through OBS — and it sounds like a bad line rather than a doubled signal.
- Play a demonstration cue. Does it arrive at all, once, at a sane level, and while the Demo scene is on Program? Compare its loudness to your voice; sample audio much louder or much quieter than speech is the most common complaint about this kind of feed.
Listen for what shouldn't be there, too: notification chimes, system sounds, the room, a second copy of the sample.
One thing fools nearly everyone. Don't conclude anything from hearing silence on your own end — your own microphone is not routed back to your own speakers, so your silence proves nothing. The receiver device, or the colleague, is the test. Headphones help as well, but only on the composed route, where the sample already reaches the room through OBS: there they close the acoustic path from your speakers back into your microphone, the usual cause of a doubled sample. On the simple route they do the opposite, shutting off the only path the demonstration audio had to the room.
Rehearse the failure, then rehearse the return
The successful transition is the easy evening. The one that decides how the meeting feels is the one where the demo dies.
Pick a moment in rehearsal: Demo is on Program, the sample is running, and you close the window, or stop the media. Watch the receiver and write down what it actually showed. Last frame held? Black? A placeholder? The rest of the scene with a hole in it? You need to know which, because how the next ten seconds go depends on whether the client is looking at a frozen picture or at nothing.
Then perform the recovery you've planned: transition to the Card scene — a still, words. Say what it is. "That's a still of the frame we were just looking at." A frozen frame you keep narrating as if it were moving is worse than a fallback you named out loud; the client can see that nothing is animating, and pretending costs you standing you'll want later in the conversation.
Rehearse three more moments while you're there.
The return to Speaker, which should take one action and no hunting.
The end of the session. Stop the virtual camera and see what the meeting shows — a black camera, a fallback device, a frozen frame. If the meeting application quietly drops back to your laptop camera, you have just shown the room your ceiling at the worst possible moment. Learn that behavior in rehearsal.
The hard stop. If you can do it safely, quit OBS mid-rehearsal and look at the receiver again. That's the worst case, and it's cheap to watch once.
Record what broke and what fixed it. Not a general claim that the setup is private — you cannot establish that from a rehearsal on your own machine — but a specific record: this version, this action, this is what the receiver displayed.
The route card
Keep one page next to the laptop. Not a manual — a card.
- Versions: OBS, operating system, meeting application and whether it's the desktop app or a browser tab.
- Scenes: Speaker, Page, Demo and Card, with the actual source behind each one, named by origin.
- Output: the virtual camera set to Program, and where that setting lives in this version.
- Audio: the device names on both ends — microphone into what, demonstration audio into what, and which device the meeting app is listening to.
- Checks: the receiver device you watch, and the two cues you run, spoken and sample.
- Fallback: the Card scene, and the sentence you'll say when you use it.
There's no line on the card for confidence, because there isn't one that helps. "It looked private in Preview" is a statement about a pane on your screen. Whether it was private is a fact about the meeting's screen, and the only way to have it is to look there before the client does.
Frequently asked questions
What is Studio Mode for, and what should the client see?
Studio Mode gives you a preparation pane called Preview and an outgoing pane called Program; a transition moves one into the other. The client should be watching Program, while you prepare in Preview. For camera-to-page and page-to-demo, a cut is usually the right choice because a slow dissolve across an information change makes the client wait. Save a long transition for a moment that earns it.
Why is Preview not automatically private?
Studio Mode controls what OBS is composing, but the Virtual Camera has its own output selection and one choice is Preview. The preview output sends the preparatory view, including changes you make to it, so a client can watch you assemble the next scene. Choose Program there, but verify at a receiver because the word Program printed under a pane is a label on the operator's side. Scene and Source point the camera at a fixed target, which can mean your transitions stop deciding what goes out. The OBS pages are older than many current builds, so read the actual wording on your machine.
How can I find out whether a source is shared across scenes?
Run a marker test before the call. Put a large text source reading PAGE into the Page scene, then reuse that same text source in Demo. With Page in Program, select Demo in Preview and watch the receiver device while you move and resize the marker inside Demo and change its text to NEXT. You are learning which answer your version gives you, not seeking a correct answer. Whichever preparation edit reaches the receiver's live image is unsafe during a pitch. A window capture is also a live view: scroll the treatment page while Page is in Program and the client scrolls with you, with no snapshot or buffer.
How should audio be routed and checked?
The Virtual Camera guide covers picture only; the meeting application has its own microphone selection a few menus from the camera selection. In the simple route, your microphone goes into the meeting app and OBS never touches your voice, so demonstration audio usually has to play out loud for the microphone to pick it up. In the composed route, microphone and demonstration audio both go into OBS, and OBS's output is presented to the meeting as a separate audio device; this depends on your operating system and meeting app, so check your machine. At the receiver, speak: once at a normal level is right, while twice with a short gap means your voice is arriving by two routes. Play a demonstration cue: it should arrive once, at a sane level, while Demo is on Program. Do not conclude anything from hearing silence on your own end.
What failures should I rehearse?
Rehearse the demo dying while it is on Program: close the window or stop the media, watch the receiver, and write down whether it shows the last frame, black, a placeholder or a hole in the scene. Then rehearse the recovery to the Card scene and say what it is, such as that it is a still of the frame you were just looking at. Also rehearse the return to Speaker, stopping the virtual camera to see what the meeting shows, and if safe, quitting OBS mid-rehearsal. Record specific facts: this version, this action, this is what the receiver displayed, not a general claim that the setup is private.