Going live

This page is for the people at the venue or in the studio: the DJ's crew, the church's media team, the league's production staff. It tells you what to set in the encoder, what to check before the doors open and what to expect if the internet drops.

Your developer gives you three things for each venue: an ingest URL, a stream key and, if you plan for trouble, a backup ingest URL. They come from the live stream in the API. See live streams and ingest. The same stream works for every show at that venue, so the settings below only need to be set once.

Encoder settings

Setting	Value
Video codec	H.264
Audio codec	AAC, 128 kbps, 48 kHz stereo
Resolution	1280 x 720 (720p)
Frame rate	30 frames a second
Video bitrate	About 2 to 6 Mbps for 720p. Start at 3 or 4 Mbps.
Bitrate mode	Constant (CBR)
Keyframe interval	2 seconds
Profile	Main or High

The keyframe interval matters most. Players start and switch quality on a keyframe, so a long gap makes viewers wait. Set it to 2 seconds in the encoder, not "auto".

Your upload speed should be at least twice the video bitrate. For 4 Mbps video, plan for 8 Mbps up that is truly yours on the night. Test it at the venue at the time of day of the show, because mobile data and shared Wi-Fi slow down when crowds arrive.

For an audio-only show, such as a radio set or a service where the picture adds little, ask your developer for an audio-only stream. It uses far less data for viewers.

Send from OBS

1. Open Settings, then Stream.
2. Service: Custom.
3. Server: the ingest URL. It starts with rtmps:// or rtmp://.
4. Stream key: the stream key.
5. Open Output. Set the encoder to x264, rate control to CBR, bitrate to 3000 to 4000 Kbps and keyframe interval to 2 s.
6. Open Audio and set the audio bitrate to 128.
7. Press Start Streaming.

Send from a phone

Any app that sends RTMP or SRT works. Larix Broadcaster is a common choice on Android and iPhone. Add a connection, paste the ingest URL and the stream key, set video to H.264 at 720p, 30 frames a second and about 3000 kbps, set the keyframe interval to 2 seconds and start. Use a tripod and keep the phone plugged in. A live stream drains a battery quickly.

SRT copes better than RTMP with a poor network. If your developer gave you an SRT address, use it.

Checklist before showtime

Do this the day before, with the same gear and the same internet, then repeat the short version an hour before the doors open.

1. Send for ten minutes and ask your developer to open the viewer page on a phone on mobile data. Picture and sound should both be there.
2. Check the stream shows as live in your app. Behind the scenes its status moves from idle to connecting to active within about 30 seconds.
3. Use a wired connection for the encoder. Wi-Fi is the second choice.
4. Keep a second way out: a phone hotspot, or a second internet line, ready to switch to.
5. Have the backup ingest URL saved on the encoder computer.
6. Set the encoder to reconnect by itself. In OBS this is under Advanced: automatically reconnect.
7. Plug in power for every device, and turn off sleep and updates.
8. Keep the stream key private. If it leaks, your developer can reset it and the old key stops working at once.
9. Watch the stream yourself on a phone, from the audience's side, while you send. Check the sound levels there, not only in the encoder.

What happens if the connection drops

Every live stream has a reconnect window, 60 seconds unless your developer set another value (it can be up to 30 minutes). Here is what happens:

1. The encoder drops. The stream's status becomes disconnected and your app gets a streams.live_stream.disconnected event.
2. For the length of the reconnect window the broadcast is still considered live. Viewers' players wait, and they may see a spinner.
3. If your encoder reconnects with the same stream key inside the window, the broadcast carries on. Viewers do not need to reload, and they keep the same playback link.
4. If the window passes with no video, the broadcast is over. The status goes to idle and a streams.live_stream.idle event follows. Start again, and viewers whose players stopped may need to reload the page.

A shorter window frees the stream sooner. A longer one gives a flaky connection more time to recover. For a show with a paid audience, keep it at 60 seconds or longer, and make your page show a friendly "we will be right back" message when your app sees disconnected.

If your developer ends a show on purpose, they call complete on the stream, which closes it at once instead of waiting for the window.

Automatic switching to a second video network is on What's coming. Until then, the fastest recovery is a second internet line and an encoder that reconnects by itself.

For your developer

• The stream and its ingest details: live streams and ingest.
• Events to listen for: stream events.
• Stop a stream from taking video, and let it start again: POST /v1/streams/live_streams/{id}/disable and /enable.
• Forward the broadcast to other platforms at the same time with simulcast targets.