Skip to content

Alternatives to multicast UDP for MBR streams

Background of the industry standard

Today, many vendors in the IPTV/OTT industry recommend using UDP multicast to send video from transcoding servers to packagers. In this model, each quality profile of the multibitrate video stream is sent in a separate multicast group, and the packagers receive all of the multicast streams to create a single multibitrate video and convert it into a unicast streaming protocol. This approach originated in the IPTV world, where IP multicast networks are used to deliver MPEG-TS video to TVs and set-top boxes. The vendors of transcoding equipment for linear TV applications added multibitrate functionality to their transcoders, which involves transcoding a source stream into 3-5 different profiles with different resolutions and bitrates. These legacy transcoders already had the capability to push video to a multicast network, so it was easy for vendors to send each profile as a separate multicast stream.

Vendors of packaging software had no choice but to adapt to this model. They did, however, push for a standard called Adaptive Transport Stream, in which each profile stream should have special EBP markers embedded to indicate the beginning of the segment. Some packagers require these markers to synchronize the streams.

Weaknesses of the industry standard

We at Flussonic believe that this approach has several problems. In order for the packager to create a valid playlist and .ts or .mp4 chunks, all profiles coming from transcoders must be perfectly synchronized by I-frames and timestamps. Additionally, all video frames for all profiles must be delivered from transcoder to packager in real time without drops or delays.

Imagine a situation where the transcoder is connected to the packager via separate multicast stream for each profile. There are 4 profiles: 1080p, 720p, 576p, 360p. If one of the multicast streams, let's say the 576p stream, fails, the packaging software must decide how to handle the problem. It can choose to drop the profile from the manifest altogether, substitute the missing data with a placeholder (keeping in mind that it must have the same code, resolution, and GOP structure as the original to prevent the players from freezing), or produce .ts chunks with zeros, which would result in freezes, visual artifacts, or even a closed playout session.

From the perspective of broadcaster, only those who are viewing the 576p quality at the moment will be affected. However, the problem goes beyond just the immediate impact on these viewers. When the packager writes the video to the archive for nDVR or catchup TV purposes, it first initializes the archive for a certain type of MBR stream with a definite number of profiles, audio tracks, and video tracks. If one of the profiles becomes temporarily missing, the integrity of the entire stream, including all other profiles, is also compromised, and there is no point in writing the remaining profiles to disk. This can also cause issues with backhauling the MBR video to other systems.

Flussonic's solution

It is clear that the current industry standard of using UDP multicast to transmit separate streams for each quality profile can lead to significant problems, especially in cases where one of the streams fails. While this approach may be suitable for some applications, in OTT/IPTV a different approach may be more appropriate.

Because of this, we at Flussonic have made the decision not to support the ingest of multiple independent UDP streams from third-party transcoders. Instead, we believe that it is better to use a single TCP stream that includes all quality profiles, subtitles, SCTE-35 ad markers and other metadata.

There are several alternative solutions that can be used to avoid the problems associated with the current industry standard of using UDP multicast to transmit separate streams for each quality profile:

  • Use Flussonic Media Server as a transcoder. This way, you won't even need to set separate roles for transcoder and packager, and if you need to backhaul video between Flussonic systems, you can use the robust and reliable Flussonic Cluster protocols m4f and m4s.

  • Ingest MBR video from a third-party transcoder using TCP-based protocols, such as MPEG-TS over HTTP. In this case, the third party transcoder can multiplex multiple streams into a single MPTS, where each profile is a separate program. Flussonic will ingest this MPEG-TS stream and treat it as a multibitrate video.

  • Alternatively, you can use other, more reliable protocols such as SRT to deliver multibitrate video between the transcoder and packager. It is important to carefully evaluate the trade-offs and consider the strengths and limitations of different approaches to ensure that you choose the one that best meets your needs.

Conclusion

In conclusion, transferring multibitrate video over UDP is a legacy practice that has significant problems. While it may seem easy and work well initially, it is prone to issues such as loss of transmitted data, difficulty synchronizing profiles, and problems with archiving and backhauling. At Flussonic, we do not support this approach because it ultimately leads to customer frustration when problems arise that are not within our control. Instead, we offer alternative solutions such as using Flussonic Media Server as a transcoder, ingesting MBR video from a third-party transcoder using TCP-based protocols, or using more reliable protocols such as SRT.

If you are interested in integrating Flussonic with your existing transcoding solutions or replacing them entirely with Flussonic Transcoder, please contact our technical support and sales team at support@flussonic.com. We will be happy to guide you and provide you with the best advice on how to achieve your goals.