Can you run a live presentation on a DIY green screen and record it at the same time?
Yes to the presenting and the recording, no to the keying while it happens: this tool reads a file, not a camera, and it renders in bounded batches, so a 45-minute talk at 1080p is 216 separate exports rather than one stream. What decides whether the job is possible at all is which file you recorded. Point the recorder at the camera and the screen keys out to 476 pixels of 724,004; point it at the composited picture your audience saw and 100% of the background survives, because clearing it would need a similarity of 261 on a control that stops at 100.
The live half is not this tool's job
There are two jobs inside that question and only one of them happens here. Presenting and recording happen in real time, in whatever app you are running the talk from. Keying happens afterwards, in a tool that reads a file: this one takes input from a file picker and a drop zone, decodes video through a video element, and has no camera path anywhere in it. Nothing in its source asks for a microphone, a webcam or a media stream. So the live key has to come from the app you are presenting in, and the only thing the two of them ever share is the recording.
That makes the recording the whole lever. Get it right and everything downstream stays available to you — a clean key, a transparent export, a second pass with different settings. Get it wrong and no amount of slider work afterwards brings it back, because the information the keyer needs is simply no longer in the file. Everything below is about getting that one decision right.
What you have to press record on
I built a 1280x720 presentation frame — a presenter taking up 21.4% of the picture, a green screen filling the other 78.5% — and recorded it twice, the way a screen recorder writes H.264 at 4:2:0. One recording is the camera feed, green screen and all. The other is what your audience sees: the same frame after a live key at this tool's own defaults has dropped a map behind the presenter. Then I ran each of those two recordings back through the same keyer.
The camera feed keys cleanly. Of the 724,004 pixels that belong to the screen, 476 keep any opacity at all, the hair comes through without a single pixel lost, and the rim's alpha sits 0.38 away from the true coverage — the ordinary loss of a semi-transparent edge, not a failure. The composited recording keys to nothing at all: every one of those 724,004 pixels survives, untouched, at the default settings.
Why the composited recording cannot be fixed afterwards
The reason is dull and absolute: there is no green left in the file. A slide, a map or a set of charts is not one colour the keyer can be pointed at, and in this test the furthest pixel in that map sits 1.254 away from the screen colour in normalized RGB. Deleting a pixel that far away needs a similarity of 261, and the control stops at 100. At 42 and again at 70, exactly none of the slide moves.
Push similarity to its maximum and you do not get a cut-out, you get a wrecked frame. 14.85% of the map is punched out — the parks and the forest, the parts that happen to land near the key — while 85.15% of it, the water, the built-up areas and the title bar, stays exactly where it was. The presenter's hair and shirt are untouched throughout, which is the point: the keyer is working perfectly on a file that has nothing left to key.
What a talk-length recording costs here
Even with the right file, this tool will not swallow a whole talk in one go, and the reason is in its own arithmetic rather than in anything you did. It holds 96 MiB of frames per batch, which works out to 8 frames at 1080p, 20 at 720p and 45 at 480p. A 45-minute recording at 30 fps is therefore 10,125 batches at 1080p, 4,050 at 720p and 1,800 at 480p, each one decoded, keyed, written out and handed to the encoder.
On top of that it refuses to begin if the estimated output passes 1.6 GiB, and it says so before it starts rather than dying halfway. That caps a single render at 12.5 seconds of 1080p MOV, 28.2 seconds at 720p and 63.5 seconds at 480p — 216, 96 or 43 separate exports for a 45-minute talk, depending on how small you are willing to go. The output itself would come to roughly 344 GB of 1080p MOV for the full talk, or 153 GB at 720p. Read that ceiling as information, not as an obstacle: it is telling you that a transparent copy of an entire talk is the wrong deliverable. Key the chapters you actually need.
Every chapter is its own render
Because each chapter comes out as its own export, the only thing holding them together is your settings — and this tool does not remember them for you. There is no account and nothing is written to browser storage, so reloading the page puts every slider back at 42, 14, 35 and 10. Write the four numbers down before you start the second chapter, because the tool will not.
Slider drift, at least, turns out not to be what makes a visible seam. Two chapters keyed one notch apart differ on the rim by 0.0073 on average and 0.0765 at the worst pixel, with nothing moving more than 0.10; a key colour that is off by two levels moves the rim by 0.0076. Both are far below anything you would notice. What actually shows at a chapter boundary is the picture itself changing — a lamp switched on, a blind pulled, daylight coming round — and no setting can paper over that.
What the DIY screen has to give you first
A homemade screen is a bedsheet or a painted wall lit by whatever the room has, which means it is rarely flat, and you cannot stop a live talk to re-light it. So the setting you pick beforehand has to cover the whole surface. I ran a gradient across the screen and typed its average colour in as the key: flat within one stop leaves 0.00% of the screen behind, 1.5 stops leaves 0.12%, two stops 1.83% and two and a half stops 6.65%. Since the screen is 78.5% of the frame, even the small numbers are a lot of pixels.
How you pick that colour matters more than most people expect. The eyedropper reads exactly one pixel — a single getImageData call, one pixel, no averaging — so clicking the brightest corner of a one-stop screen leaves 8.43% of it behind, 19.75% at 1.5 stops and 27.42% at two stops. The colour box beside it accepts any hex value, so take thirty seconds, work out the average of the screen area in any image editor, and type it in: #02E254 for that one-stop screen, against a residual of 0.00%.
The version that actually works
Record the camera on its own. If your presentation app will only write the composited picture — and plenty of them will only write what was on screen — then run a second recorder against the camera device itself, because otherwise you will finish the talk with a file whose green is already gone and nothing left to key. Present from the composite; keep the raw feed as the master.
Then cut the master into chapters that fit inside the ceiling — 28 seconds at a time at 720p, or a minute at 480p — and export transparent versions of only the chapters that need one. Sample the key once per chapter from the average of the screen rather than from a single pixel, and keep the four slider numbers in a text file next to the exports, because nothing in the tool is holding them between renders.
Related questions
Can this tool key my webcam while I am presenting?
No. It has no camera path: the input is a file picker and a drop zone, and video is decoded from a file into a video element. Nothing in the source requests a camera or a media stream, so the real-time key has to come from the app you are presenting in. What this tool does is take the recording afterwards and key it, in batches.
How long a recording can it handle in one render?
It refuses to start above an estimated 1.6 GiB of output, which works out to 12.5 seconds of 1080p MOV, 28.2 seconds at 720p and 63.5 seconds at 480p — so a 45-minute talk is 216, 96 or 43 separate exports. It also holds only 96 MiB of frames per batch, which is 8 frames at 1080p and 20 at 720p.
I only have the composited recording. Is there anything I can do?
Not with a keyer. In my test every one of the 724,004 background pixels survived at the defaults, and at maximum similarity 14.85% was punched out — the green areas of the slide — while 85.15% stayed put; clearing it completely would need a similarity of 261 on a control that stops at 100. The only real fix is the original camera file. Make your recorder write it.
Should I click the eyedropper on the green?
Only if your screen is genuinely flat. It reads a single pixel, and on a homemade screen with a one-stop gradient, clicking the brightest corner left 8.43% of the screen behind, rising to 27.42% at two stops. Work out the average colour of the screen area instead and type that hex into the colour box — 0.00% residual for the same one-stop screen. Re-sample it once per chapter.