Multistreaming / restreaming
Multistreaming, also called restreaming, is sending one live video feed to several streaming platforms at once, such as YouTube, Twitch, Facebook Live and your own website. In the usual setup the encoder sends a single stream to a cloud service, which duplicates it and pushes a copy to each platform's ingest URL with that platform's stream key. Compared with pushing a separate output from the encoder for every platform, this keeps upload bandwidth and encoder load at the level of one stream.
How does multistreaming work?
A restreaming service sits between the encoder and the platforms. The encoder pushes one stream to it over RTMPS or SRT. The service holds a list of destinations, each defined by an ingest URL and a stream key, and opens an outbound RTMP or RTMPS connection to each one when the stream starts.
Most restreaming passes the encoded video through unchanged, so there is no second encode and no extra quality loss. Each platform then does its own transcoding into a ladder and delivers to its own viewers. Because the outbound connections are independent, a destination that rejects the stream or drops out leaves the others running. When the encoder stops, the service closes every outbound connection, and each platform ends its broadcast and may keep its own recording.
Multistreaming from the encoder vs. restreaming in the cloud
Pushing several outputs straight from the encoder needs upload bandwidth for every copy. Three outputs at 6 Mbps each need about 18 Mbps of steady upload, plus headroom for spikes, and the encoder spends CPU on every connection. On a shared office line, a school hall or a mobile bonding unit, that is often more than the link can carry reliably.
Restreaming in the cloud sends one stream from the venue and does the copying in a data centre. The uplink stays at one feed, destinations can be added or removed without touching the encoder, and a slow destination cannot starve the others of bandwidth. The cost is one dependency: every copy relies on the single ingest. Backup ingest from a second encoder, or a second network path, covers that. Pushing from the encoder still suits a strong wired line and two outputs.
What encoder settings does a multistream need?
Because most restreaming passes the stream through without re-encoding, one set of encoder settings has to satisfy every destination. That pushes you toward the settings all platforms accept.
Use H.264 video with AAC audio, the codecs every major platform takes for RTMP ingest. Keep a fixed keyframe interval of about 2 seconds, which is what YouTube recommends and close to what other platforms ask for. Use constant bitrate, so the platforms' transcoders get a steady feed. Stay within the lowest bitrate and resolution cap among your destinations, since a stream above one platform's limit may be rejected or degraded there. A 1080p stream at a moderate bitrate is usually the common ground. If one destination needs very different settings, it needs its own output or a service that transcodes for it.
What are the trade-offs of multistreaming?
Multistreaming widens reach for the cost of one stream, but it splits everything that happens after delivery. Each platform runs its own chat, so a host either watches several chat windows or uses a tool that merges them. Analytics are spread across dashboards with different definitions of a view. Latency differs per platform, so a question asked on one service may arrive before or after the moment it refers to on another.
There are also rules to check. Some platforms or rights agreements restrict streaming the same content elsewhere at the same time. And a restream to a free social platform puts your broadcast next to that platform's recommendations and ads. Many teams treat the platforms as reach and keep the primary audience on their own player, where access, playback and viewer data stay under their control.
How does FastPix handle multistreaming?
FastPix restreams in the cloud. One contribution feed comes in over RTMP, RTMPS or SRT, from a desktop encoder, a hardware box or a phone using the iOS and Android live SDKs, and the Simulcast API pushes copies to RTMP destinations such as YouTube, Twitch and Facebook Live. Adding a destination adds an outbound copy in the data centre, not load at the venue.
The same ingest also feeds your own player: the FastPix Player has native SDKs for web, Android (Media3-based, including Android TV), iOS (AVPlayer-based, including tvOS and visionOS) and Flutter. That copy goes out as LL-HLS, 4 to 7 seconds behind the camera, from 300+ points of presence, with signed playback URLs, DVR and an automatic recording when the stream ends. Backup ingest gives a second path into FastPix. Real-time bitrate and dropped-frame health and webhooks on connect, disconnect and error show whether the source is stable, and Video Data reports startup, rebuffering and live latency for every viewer on your own player, broken down by country, CDN and device.
For 24/7 channels, Cloud Playout can restream each channel to YouTube Live, Facebook Live, Twitch or any RTMP(S) endpoint, with status per destination.
Ingest costs $0.0324 per live minute, flat at any resolution up to 1080p. Restreaming is billed per minute, and viewing on your own player per viewer-minute. Thirty free live minutes, no card, are enough to check that every destination accepts your encoder settings.
