REMI remote production over SRT

With Open Live, the cameras stay at the venue and the production crew does not have to. Feeds travel to the cloud over SRT, the mixing runs there, and the director, the vision mixer operator and the audio operator work from a web browser wherever they are. There is no outside broadcast truck to send and no control room hardware to ship.

What is REMI remote production?

REMI (the remote integration model) is a way of producing a live show where only the cameras and the people who operate them are on site. The video and audio are sent back to a central point, and the switching, graphics and audio mixing happen there. In Open Live that central point is Strom, the media engine that the Open Live backend drives. The crew controls it from Open Live Studio, a browser application with nothing to install.

How do camera feeds get from the venue to Open Live?

Each venue feed becomes an SRT source in Open Live. SRT is the usual choice for a camera feed that crosses the public internet, because it is built to recover from packet loss on the way. When you add an SRT source in Studio you choose which end of the link dials:

• Listener. Open Live waits for the venue encoder to connect. Where the Open Live instance has reserved a set of SRT ports from its Strom, Open Live assigns the source a free port from that set, so you do not pick one by hand.
• Caller. Open Live dials out to an encoder that is listening at the venue, at the host and port you enter.

Both kinds can carry an SRT passphrase. Open Live encrypts the passphrase before it stores the source and masks it whenever the API returns the source. You can also set the SRT receive latency for each source, and when a feed carries more than one audio stream, Studio can list them so you choose which one the mixer uses. Contribution that uses the EFP framing protocol over SRT is a source type of its own.

Do I have to build the venue side by hand?

No. Open Live Ingest is an open-source contribution gateway that runs on a Linux machine or a Mac at the venue, next to a local Strom. Run it and it asks for the settings it needs, checks each answer, then takes every capture device that Strom can see, such as an SDI capture card or a webcam. For each one it builds a flow that encodes the picture to H.264 (using a hardware encoder when there is one) and sends it as MPEG-TS over SRT to the Strom that Open Live uses. It also registers each feed as a source in Open Live, so the feed shows up in Studio ready to assign to a mixer input.

• One flow per camera, so one camera failing does not disturb the others.
• A test pattern with tone (up --test) to commission the link before the cameras are plugged in.
• Built for SSH. A closed session or a dropped connection to the box does not take the venue off air, and status and down work from a second session.
• One-line install with static release binaries for Linux (x86_64 and aarch64) and macOS (Apple silicon and Intel).

The media goes straight from the venue Strom to the cloud Strom and never passes through the Open Live backend. If Open Live itself is unreachable for a while, the gateway logs it and tries again, and the feeds keep running.

Which end of the SRT link needs an open port?

Whichever end listens needs an inbound UDP port. By default the gateway runs in caller mode: the venue dials out to the cloud, so the venue needs no inbound port at all, which suits venue networks behind NAT. In this mode Open Live chooses the port for each feed from the ports it holds, so several venue gateways can feed the same Open Live without picking ports by hand. If the venue has to be the listening end, listener mode uses a port range you set at the venue instead.

How does the production crew know the venue feeds are healthy?

A venue gateway can be registered in Open Live. It then reports its status to Open Live over one outbound WebSocket, and the Gateways tab in Studio shows whether the venue is reachable, when it was last seen, which inputs are running, and each uplink's bitrate and round trip time. Sources fed by a gateway are marked with it in the source list. The connection only reports status: nothing on it can start or stop a feed. On the venue machine itself, open-live-ingest status shows the same picture.

What does the crew use to run the show remotely?

Everything is in Studio, in the browser. The vision mixer has program and preview, transitions, picture-in-picture, downstream keyers and graphics. A multiview of the sources, program and preview comes to the browser over WebRTC (WHEP) with glass-to-glass latency under 500 ms, and an audio mixer with EBU R128 loudness metering sits next to the vision mixer. Operators who prefer hardware buttons can use a Stream Deck or any other surface through the Open Live module for Bitfocus Companion.

Feeds that arrive with different delays can be lined up: each source can get its own video and audio time offset.

Where does the programme go after the remote production?

A production can send its programme out over SRT (MPEG-TS), EFP over SRT, RTMP to a streaming platform, or WHEP for WebRTC viewing. For an SRT output that listens, the Open Live API reports the address a receiver has to dial. A production can also record the programme to a storage connection you set up, and since release 0.7.0 it can record chosen SRT, EFP or WHIP inputs to their own files beside the programme, so the venue cameras are kept as separate recordings.

Is Open Live remote production free and open source?

Yes. The Open Live backend and Studio are published on GitHub under the MIT licence, and Open Live Ingest under MIT or Apache-2.0, at your option. Self-hosted, you run the backend and its CouchDB database, Studio and Strom yourself; the self-hosting guide covers what that involves. On Open Source Cloud you sign in, pick a monthly plan that includes production hours on shared Strom, and start producing. If you are new to Open Live, your first live show walks through a production from an empty account to on air.