5G-MAG Reference Tools – Seamless switching between broadcast and broadband delivery

In one of our previous blog posts we looked into playback of a multicast DASH stream in dash.js using the 5G-MAG Reference Tools. In this article, we go even a step further: Based on the availability we dynamically and seamlessly switch between broadcast and broadband delivery.

A dynamic switch between broadcast and broadband delivery offers many possibilities and advantages. Most importantly:

• As a service provider, we can enable/disable broadcast delivery based on consumption metrics while guaranteeing a smooth playback experience for the end user.
• In cases in which users are out of broadcast coverage the service continues to operate by falling back to broadband.
• It enables personalized ad-insertion by receiving the main content via broadcast and the ad content via broadband.

Seamless switching – The basic architecture

An illustration of the basic architecture for seamless broadcast-broadband switching is depicted below. It is worth mentioning that the diagram below reflects a simplified version of the local setup. For a detailed version including 5G components check out our Github. For available live demonstrations check out the IBC section at the end of this article. In the following we are also omitting details like how to configure the Service Announcement files to signal the availability of the broadcast and broadband content to the MBMS Middleware. For details on Service Announcements, please refer to TS 26.346.

Step 1: Configuring an HLS livestream

First thing we need to setup for our local demo is an HLS livestream. The generated manifest and segment files are written to a (watch) folder that is used by two different components:

• The rt-flute-ffmpeg implementation that monitors the folder for changes to multicast the files to our MBMS Middleware
• A simple node.js Express server that hosts the files. In our setup this Express server takes the role of a CDN. The media segment and the manifest files are then accessible via localhost.

A ffmpeg command to generate a HLS live stream from a VoD file looks the following:

#!/bin/bash

ffmpeg -re -stream_loop -1 -i content/01_llama_drama_1080p.mp4 \
-filter_complex "drawbox=x=1460:y=0:width=460:height=100:color=black@0.5:t=fill,\
split=2[v1][v2];\
[v1]drawtext=text='720p-2.0M':x=1480:y=20:\
fontfile=/usr/share/fonts/truetype/freefont/FreeSans.ttf:fontsize=80:fontcolor=white,\
scale=1280x720[v1out];\
[v2]drawtext=text='540p-1.0M':x=1480:y=20:\
fontfile=/usr/share/fonts/truetype/freefont/FreeSans.ttf:fontsize=80:fontcolor=white,\
scale=960x540[v2out]" \
-map [v1out] -c:v:0 libx264 -x264-params "nal-hrd=cbr:force-cfr=1" -b:v:0 2M -maxrate:v:0 2M -minrate:v:0 2M -bufsize:v:0 4M -preset veryfast -g 60 -sc_threshold 0 -keyint_min 60 \
-map [v2out] -c:v:1 libx264 -x264-params "nal-hrd=cbr:force-cfr=1" -b:v:1 1M -maxrate:v:1 1M -minrate:v:1 1M -bufsize:v:1 2M -preset veryfast -g 60 -sc_threshold 0 -keyint_min 60 \
-map a:0 -c:a:0 aac -b:a:0 96k -ac 2 \
-map a:0 -c:a:1 aac -b:a:1 96k -ac 2 \
-f hls \
-hls_time 2 \
-hls_list_size 5 \
-hls_delete_threshold 1 \
-hls_flags independent_segments+delete_segments+temp_file \
-hls_segment_type mpegts \
-hls_segment_filename /home/dsi/5G-MAG/simple-express-server/public/watchfolder/hls/stream_%v_data%02d.ts \
-master_pl_name manifest.m3u8 \
-var_stream_map "v:0,a:0 v:1,a:1" /home/dsi/5G-MAG/simple-express-server/public/watchfolder/hls/stream_%v.m3u8

Step 2: FLUTE encoding and multicasting the HLS files

Now that our livestream is up and running we can monitor the watchfolder for changes. Once new files are added (media segments) or existing files are modified (media playlists) we use the FLUTE transmitter to multicast them to the MBMS Middleware.

Step 3: Receiving the multicast and preparing the files

At the MBMS Middleware we constantly receive manifest files and media segments via multicast. We use the FLUTE library to decode the files and save them on a file server.

In addition to the media playlists received via multicast, the MBMS Middleware periodically requests media playlists from CDN. From these two sources, the content of the playlists that are created and presented to the media player is determined: for multicast playlists, we assume that the latest contained file should be available via multicast, and hence can be presented as such to the player; whereas for CDN playlists, a configurable number of segments is stripped out of the playlist to account for the expected delay. For the media player itself it is not visible whether the manifests and segments originated from multicast delivery or from the CDN.

Step 4: Playback in hls.js

For now, let’s assume that our multicast chain is up and running. We can now play the stream in our favorite media player. In our example we use hls.js for browser-based playback. For the media player itself it is not visible that the files originated from multicast. However, we are including a response header in each media segment request that holds the information whether a segment originated from multicast delivery or was fetched from the CDN. This information is depicted on the top left of the video as an overlay. In this case, it is labeled “5G-BC” (coming from the fact that in a real-world scenario we would receive a 5G broadcast).

Step 5: Seamless switch to broadband reception

To demonstrate the seamless transition between multicast and broadband reception we simply turn off our Flute Transmitter.

A request from the player for a segment that has not yet been received via broadcast triggers a cache miss in the MBMS Middleware, causing this segment to be immediately fetched from the CDN. In the current implementation, a 404 status is returned to the player’s request, mimicking a request too close to the live edge and causing the player to retry with progressive intervals. Once the missing segment has been fetched from the CDN it is available to the player. We are now in “CDN playback mode”:

And that was it! For the viewer the transition between broadcast and broadband is not visible. Playback is not interrupted, although the media content is not delivered via broadcast anymore.

5G Broadcast-Broadband Seamless Switching

If you are interested in the seamless switching mechanism with a real 5G broadcast checkout the video below:

Next steps

The basic architecture and the demo explained in this blog post serve as a proof of concept. Future works includes support for DASH-based streaming and the focus on a more client-centric switching approach. For instance, the content steering mechanism described in our previous blog post together with the @proxyServerURL attribute can be reused to trigger a switch between a local server (hosting the files received via multicast/broadcast) and the CDN.

If you want to set this demo up yourself or contribute to the development of the 5G-MAG Reference Tools and shape the future of 5G Media Streaming and 5G broadcast checkout the 5G-MAG website and 5G-MAG on Github.

Acknowledgements

The author would like to acknowledge the work of Klaus Kuehnhammer in the context of the seamless switching implementation described in this blog post. The local demo setup described here is put on top of Klaus’s implementation.

The 5G-MAG Reference Tools @ IBC 2022

If you are attending IBC 2022, there are multiple options to learn more about the 5G-MAG Reference Tools and see them in action:

• IBC Conference Presentation: “5G-MAG Reference Tools: Dynamic Content Delivery Switching between 5G broadcast and OTT streaming” by Daniel Silhavy on 09 Sep 2022 13:30 – 14:15. More details can be found here.
• Fraunhofer FOKUS – Seamless switching between broadcast & OTT with 5G-MAG Reference Tools: Find us in Hall 8 at Booth 8.B80. More information can be found here.
• Nakolos – Unlimited CDN Capacity at a Fixed Price: First integration of 5G Broadcast-on-Demand into a commercial OTT app using the 5G-MAG Reference Tool transmitter prototype. Check it out at Stand 7.P04. More information can be found here.
• 5G-MAG – Bridging OTT and broadcasting with 5G-MAG Reference Tools: Talk to 5G-MAG and joins us for coffee and croissants at Stand 10.D21. More information can be found here.