Simulcast
Simulcast in live streaming is broadcasting the same live video to several destinations at the same time, for example your own app plus YouTube and Facebook Live. Usually the encoder sends one stream to a cloud service, which copies it to each platform's ingest URL. In WebRTC the word has a second meaning: a sender encodes the same camera at several qualities at once so a server can forward the right one to each participant. Either way, one live source reaches viewers through more than one path.
How does simulcast work?
In the broadcast sense, simulcast starts with one contribution feed. The encoder pushes it to a streaming service over RTMPS or SRT. The service keeps one copy for its own delivery and opens one outgoing push per destination, usually over RTMPS, to that platform's ingest URL with its stream key.
Each destination then treats the copy as an ordinary incoming stream. It transcodes, packages and delivers to its own viewers with its own player, its own latency and its own chat. Because every outbound connection is independent, one platform rejecting the stream or going down does not stop the others or the stream on your own player. The copies are usually passed through without re-encoding, so the settings the encoder uses have to suit every destination at once.
Simulcast vs. multistreaming
In live streaming, simulcast and multistreaming describe the same thing: one feed, several platforms, at the same time. Simulcast is the older broadcast word, from the days when a programme aired on TV and radio together. Multistreaming and restreaming are the words creator tools use.
WebRTC simulcast is different. RFC 8853, published by the IETF in January 2021, defines simulcast as sending several differently encoded streams of the same source at once. A video call client might send 720p, 360p and 180p versions of its camera, and a selective forwarding unit passes each participant the one their connection can take. That is closer to an adaptive bitrate ladder built on the sender than to restreaming. When someone says simulcast, check whether they mean destinations or qualities.
Simulcast from the encoder vs. from the cloud
Many encoders can push several outputs themselves. Each output is a full copy of the stream on the venue's uplink, so the upload has to carry the sum of all of them at once, plus headroom. Every extra destination also adds encoder load and another connection that can fail at the venue.
Cloud simulcast moves the copying off site. The encoder sends one stream, so the uplink carries one feed however many destinations you add, and outbound connections leave from a data centre with ample bandwidth. The trade is that the cloud copy depends on the ingest staying healthy: if the venue feed drops, every destination drops with it. Backup ingest and a second encoder protect against that. Cloud simulcast also lets a crew add or remove a destination without touching the encoder mid-event.
What can go wrong with a simulcast?
Most simulcast problems come from destinations disagreeing. Platforms set their own limits on bitrate, resolution, frame rate and keyframe interval, and a stream that suits one may be rejected or flagged by another. Stream keys can expire or be regenerated, so a destination that worked last week may refuse the connection today. Delay differs too: each platform adds its own latency, so viewers on different services see the same moment at different times.
There are non-technical limits that change the setup. Rights deals sometimes forbid sending the same content to third-party platforms, so a league may simulcast the pre-match show but keep the match on its own player. Chat and analytics split across every destination. And the stream on your own player is the one where you control access, playback and viewer data.
How does FastPix handle simulcast?
On FastPix the encoder sends one stream over RTMP, RTMPS or SRT, and the Simulcast API copies it to third-party RTMP destinations such as YouTube, Twitch and Facebook Live. The venue uplink carries a single feed no matter how many destinations are added, and the stream for your own viewers runs alongside the copies rather than through them.
Your own audience watches on the FastPix Player, with native SDKs for web, Android (Media3-based, including Android TV), iOS (AVPlayer-based, including tvOS and visionOS) and Flutter, or on any HLS player, served from your own custom domain if you want one, delivered as LL-HLS at 4 to 7 seconds glass-to-glass across 300+ points of presence. On that copy you set the rules: signed playback URLs with token expiry, DVR, clipping mid-event, an automatic recording with the same playback ID when the stream ends, and Video Data on every session. Ingest health, with bitrate and dropped frames, and webhooks on connect, disconnect and error show when the source feed itself is in trouble.
Cloud Playout channels can simulcast too: each channel can go to YouTube Live, Facebook Live, Twitch or any RTMP(S) endpoint, with status shown per destination.
Billing follows the stream. Live encoding is a flat $0.0324 a minute ingested at any resolution up to 1080p, simulcasting is billed per minute, and viewing on your own player is billed per viewer-minute. Viewers on YouTube, Twitch or Facebook are served by those platforms. A test simulcast fits in the free plan's 30 live minutes, with no card.
By the numbers
- The IETF defined WebRTC-style simulcast, sending several differently encoded streams of the same source at once, in RFC 8853, published in January 2021. (RFC 8853: Using Simulcast in SDP and RTP Sessions (IETF))
