Just-in-time packaging in the context of Live Mass Broadcasts: The Case of the St. Petersburg TV channel

August 27, 2021

This past spring there was a live military parade in Russia in honor of the 76th anniversary of the Victory. The broadcast, entirely in UHD (Ultra High Definition), was on the St. Petersburg television channel and was also broadcast on the channel’s website. Peak streaming loads were 10 Gigabits per second and Flussonic Media Server was used as the platform for streaming.

Broadcasts are collected from different sources and streamed to the Flussonic Media Server. Flussonic packages videos before sending them to providers and streaming them back to the CDN.

During the parade, broadcasts were collected from different sources and streamed to the Flussonic Media Server. Flussonic was used to package videos before sending them to providers and streaming them back to the CDN. The video feed was then transmitted to the television channel’s website: topspb.tv. A second Flussonic was used for full packet redundancy.

Since that May 9 parade, the St. Petersburg TV channel now also uses Flussonic Media Server to receive RTMP and HLS broadcasts from the Internet and convert them to UDP and then deliver them to cable OTT operators. Therefore, Flussonic also provides interaction between the Internet and cable networks.

Why is it convenient to use the Flussonic Media Server for live streaming?

  • Flussonic repackages the inflow into the outflow. It receives the stream 1 time and, in real time (on the fly), decompresses it into segments, corrects errors at the protocol transfer level and the packet level. Packet losses/errors can occur, for example, due to a poor internet connection. If you provide a technically faulty stream, the player will “hang.” At the other end of the screen, the viewer will have to reload the page, the decoder, or the television. If we talk about CDN, some of them will also require reconnection. Flussonic “removes” the containers from the packages, restores the entire structure, making the flow technically correct. And then you repackage it in the desired protocol. Consequently, the player will not crash and the video will continue to play.
  • You can build a CDN based on Flussonic. Such CDNs will have a great advantage: the price of traffic will not increase when more protocols are requested. A CDN without Flussonic simply delivers the video from point A to point B. The video is delivered to the final viewer in the same form that it comes from the source. And if the video is requested, for example, both through DASH and HLS, you will have to send the same transmission to the CDN 2 times. If there is a Flussonic within the CDN, then the video, upon receipt, is repackaged “on the fly” in the necessary protocols that users request. Therefore, the traffic does not multiply. It is enough to have the source stream in any convenient protocol once, and then Flussonic will independently repackage it into the necessary protocols for the end subscribers.
  • Flussonic is easy to reconfigure. For example, to change the quality of the output stream from HD to SD (if there are both tracks in the stream coming from the source), just click some buttons on the web admin panel. Flussonic, in general, is convenient in terms of flow management. You can always see on the same page what streams are coming and delivered, what is the bit rate, on which card the stream is transcoded, whether DVR system, authorization, DRM are enabled or not.
Streams management is convenient in the Flussonic user interface
Alexandra Gorelova