Put a live close-up above a stage and the audience watches the close-up. Not sometimes — always. A face four metres wide carries more information than a face forty metres away, and attention goes where the information is.
Every other decision in this follows from accepting that rather than fighting it.
Decide what the screen is for
There are only three honest answers, and picking one before you touch a camera will save you a month.
Magnification (IMAG). The screen shows the audience what they cannot see from row R. Standard at concerts and conferences. Artistically inert, operationally easy, and the right answer more often than directors like to admit.
A second vantage point. The screen shows something the audience cannot see from any seat: inside a box, behind a wall, a performer’s hands from above, a face from six inches away. The screen is not competing with the stage because it is not showing the same view.
A different kind of information. The screen shows the same bodies through an instrument that changes what they are — thermal, infrared, long-exposure, slit-scan, depth. Łukasz Twarkowski’s ORACLE runs its live feed through thermal and infrared imaging, so the performers appear on screen as coloured heat fields. A thermal camera cannot show you a face, so the close-up problem evaporates: the screen is not a better view, it is a machine’s view.
The first is a service. The second and third are dramaturgy. Mixing them without a rule is what produces productions where the video looks bolted on, because it is.
Camera positions that actually work
Operators inside the set. Not in the wings, not on a tripod at the back — in the space, moving with the performers, visible to the audience. This is the single most important decision available to you. A visible operator makes the filming part of the event rather than a transparent window, and it solves the blocking problem, because the camera can be where no fixed position could be. ORACLE puts its operators inside a modular set and lets the audience watch them work.
It costs you rehearsal time, because a camera operator is now a performer with choreography, and it costs you a camera that cannot be locked off.
Locked-off frames in impossible places. A camera inside a prop, under a table, at floor level, pointed straight down. Cheap, repeatable, and gives you material no operator could hold.
One wide, always. Keep an unglamorous wide shot of the whole stage available at all times, even if you never cut to it. It is your safety shot when something goes wrong, and it is what the archive recording needs.
The audience, before you start. Point a camera at the house as people come in and put it on the screen. It is the cheapest participatory gesture in theatre and it establishes the screen as a thing that captures before any performer appears. ORACLE does exactly this.
Latency, and the number that matters
Your budget is roughly two frames, about 80 ms, before an audience perceives the screen and the stage as out of step. Lip movement is the giveaway; a mouth on screen that trails the sound by more than that reads as broken rather than stylised.
Where it goes:
- Camera output — 1 frame or less on a decent camera in a clean mode. Turn off every in-camera effect, stabilisation and noise reduction; they all buffer.
- Transport — SDI over coax is essentially free. HDMI over a long run with extenders is not. NDI over Ethernet costs you frames and is network-dependent, which is fine for a monitor feed and a risk for a projected one.
- Switcher or processing — a hardware switcher adds a frame. A laptop running software effects adds whatever the software adds, and it is rarely documented. Measure it.
- Projector — the forgotten one. Many projectors add 2–4 frames of internal processing. Find the low-latency or “game” mode and turn everything else off. This is frequently the largest single contributor and the easiest to miss.
Measure the whole chain once, physically: point the camera at a stopwatch on a phone, project it, photograph the phone and the projection together, read the difference. Do this before you design anything that depends on synchronisation.
Light is the real fight
Stage lighting is designed to put a lot of light on performers. Projection needs darkness to have contrast. These are opposed requirements in the same room.
Practical resolutions, in order of how well they work:
- Separate them in space. Project where the stage light is not — above the action, upstage behind it, onto a surface that the rig is kept off. ORACLE’s horizontal split, screen above and action below, is this solution.
- Separate them in time. The lighting designer and the video designer agree on cues where one yields. This requires the two of them to actually talk, in the same room, early.
- Out-gun it. More lumens. Expensive, loud, generates heat, and reaches its limit fast.
And one that is not optional: camera exposure follows the lighting, not the other way round. Set your cameras during a lighting session with the actual lighting states, lock the exposure manually, and never leave a camera on auto. An auto-exposing camera will visibly hunt on every lighting cue, and the audience will see it even if you do not.
A tech order that works
- Cameras to a monitor only. No projection. Confirm every camera, every cable, every power supply.
- Measure end-to-end latency with the stopwatch method. Record the number.
- Lighting states with cameras live, no performers. Set and lock exposure per camera per state.
- Projection with lighting, no cameras. Find where contrast survives.
- Everything together, no performers. Operators walk the blocking with cameras.
- Add performers. By now nothing technical should be in question.
The temptation is always to run step 6 first because the performers are in the building. Doing so turns the actors into witnesses to your cable problem.
Things that go wrong on the night
A camera drops out. Have the wide shot on a key and a stage manager who knows which one it is.
The operator’s shadow is in the shot. Found in step 5, not step 6.
Wireless camera link glitches. It will. Run cable if the shot permits it; if it does not, accept the glitch as part of the aesthetic rather than as a fault, and tell the director that before opening.
The projection is washed out in one scene only. That scene’s lighting state was set after the video was designed. See step 3 and 4, and the part about the two designers talking.
Where to go next
Build the simplest possible version first: one camera, one operator inside the set, one surface, no effects. Run a scene. Watch where the audience looks. Everything else — multiple feeds, keying, thermal cameras, real-time processing — is an elaboration on whether that one relationship works, and if it does not work with one camera it will not be rescued by four.
Sources
- The Basics of Multi-Cam Live Production — Filmmaker IQ on YouTube
- NDI technical documentation
- SMPTE ST 259 / SDI overview — SMPTE
- łukasz twarkowski turns theater into a live cinematic spectacle — designboom