Your first live show on Open Live
This guide takes you from an empty account to a production on air. It covers which plan you actually need and why, the four things Open Live models (sources, templates, productions, flows), how to get a camera feed in, what the mixer and the multiviewer give you, and a rehearsal checklist. It assumes no prior Open Live knowledge. For provisioning detail and troubleshooting an instance that will not start, the service documentation is the reference; this guide is about running a show.
Pick the right plan first, because it decides your topology
Open Live splits along one axis that matters more than price: where the media pipeline runs. That pipeline is Strom, the engine that does the actual video work. There are three answers, not two, and the middle one is not for live production.
| Option | What it means | Fit |
|---|---|---|
| Bring your own Strom | You run the pipeline engine yourself and point Open Live at it. No GPU rented from us, and no plan requirement. Personal at 15 EUR/month is the usual plan alongside it. | Live production, if you are willing to operate the GPU host. |
| Shared GPU in Frankfurt, 69 EUR/month | We run the pipeline on GPU capacity shared between everyone on this plan. Requires Professional or above. | Demo and evaluation only. See the warning below. |
| Hosted GPU add-on, from 750 EUR/month | A dedicated GPU-backed Strom instance, hosted and managed for your environment, sold as an add-on rather than a plan. Our pricing section describes it as guaranteed capacity with no shared load. Confirm the terms with sales before budgeting on it: the platform pricing page lists no GPU add-on, and no SLA is published behind the phrase. | Live production with nothing to run yourself. |
Do not plan a real show on the shared GPU. The Frankfurt GPU is shared between all users on that plan, capacity is not guaranteed, and performance varies with load, which is why the pricing page marks it demo and evaluation only. It is the right choice for learning the tool and proving a workflow. It is the wrong choice for anything with an audience and a start time. For a managed path with guaranteed capacity, the Hosted GPU add-on is what that exists for; otherwise bring your own Strom.
If you are on the free plan, the bring-your-own path is metered against your one-time token allowance rather than gated by plan. Budget for that if you are testing rather than running a real event.
The four things Open Live models
Most of the confusion in a first production comes from not knowing which of these you are editing. They are separate objects with separate lifetimes.
| Object | What it is | Lifetime |
|---|---|---|
| Source |
One video or audio feed, with a stream type of
srt or whip and an address.
|
Reused across shows. Create your cameras once. |
| Template | A reusable pipeline blueprint: the flow plus named input slots that sources get patched into. | Reused. This is your show format. |
| Production | One event. Holds a template plus the specific source assignments for that event. | Per show. |
| Flow | The running pipeline, created in Strom when you activate and deleted when you deactivate. | Only while you are on air. This is what costs you. |
The practical consequence: build your sources and your template once, then create a production per event and activate it only for the window you are actually producing. Start for an event, tear down after.
Getting feeds in
A source has a stream type and an address. Two types are supported, and they suit different origins.
- SRT for contribution from a venue or an encoder. This is the normal choice for a camera feed arriving over the public internet, because SRT is built to survive a lossy path.
- WHIP for anything that already speaks WebRTC, including a browser and most modern software encoders. Lower latency to establish, and no listener port to open.
A production takes up to 16 sources. That is the ceiling to design around: if your show needs more inputs than that, the answer is upstream sub-mixing, not more source slots.
On SRT passphrases. The passphrase is part of the source address, and Open Live encrypts it at rest before storing it. You do not need to do anything for that to happen. You do need a plan for rotating it, and the project publishes an operator runbook for exactly that case, including a suspected compromise. Read it before an event rather than during one.
What you get in the browser
The production controller is a browser application. There is no client to install and no per-seat licence to count.
- Vision mixing: cuts, auto transitions, downstream key layers, picture-in-picture, graphics overlays, and fade to black.
- Audio mixer: per-channel faders with EBU R128 loudness metering. The meters give you momentary, short-term and integrated loudness plus loudness range and true peak, which is what a delivery spec will actually ask you for.
- Multiviewer: browser-based monitoring over WebRTC, targeting sub-500ms glass to glass.
- Stream Deck control for hands-free operation of the things you do not want to mouse to mid-show.
On the rendering side, video mixing runs in real time at 4K on a commodity GPU using NVENC, with decode, composite and encode in one GPU pass where CUDA-GL interop is available on the host. If interop fails, only the colour-conversion step falls back to the CPU rather than the whole pipeline, which is why a host without perfect interop degrades rather than collapses.
Going on air, and coming off it
Activation is one call and it does three things in order:
- Clones the template's flow.
- Patches each assigned source address into its matching block in that flow.
- Creates the flow in Strom and starts it.
Deactivation stops and deletes the flow. Deactivate when you come off air. An activated production is a running pipeline whether or not anyone is watching it, and on the shared-GPU path that is the part you are paying for.
Rehearsal checklist
Run this once, in full, before the first real event. It is twenty minutes and it is the difference between finding a problem in rehearsal and finding it on air.
- Every source shows a picture in the multiviewer, from the actual encoder and the actual network path it will use on the day.
- If you are on bring-your-own Strom, the URL is publicly reachable, tested from outside your own network.
- Source count is at or under 16, and you know which feed you would drop if one more appeared.
- Audio levels checked against your delivery spec using the integrated loudness reading, not by ear.
- Cut, transition, DSK and fade to black each tried once, by the person who will operate them.
- Deliberately kill one source mid-rehearsal. Confirm the mix keeps running and the operator can see which feed went.
- Deactivate, then reactivate, and confirm the production comes back with its assignments intact.
- Agree who deactivates at the end of the show, and when.
Ready to build your first production?
Start a 14-day trial, create your sources once, and run the rehearsal checklist before you put it in front of an audience.