How does the In-Stream Switching work?

In-Stream switching is the process of dynamically switching content delivery networks (CDNs) while a video stream is being delivered to the end-user. First, it digests real-time CDN quality data and video event data (obtained from the Stream Monitoring), then it will utilize these data to intelligently route video delivery in real-time to the best-performing CDN (through HTTP) and/or existing peers (through Web RTC) for a given end-user (at a specific location and time). 

In this article, we will describe how In-Stream Switching works. Below is the schematic diagram illustrating how it works.

Note: Stream delivers video streams using HTTP Live Streaming (HTS) protocol, hence video streams are delivered in segments (.ts files) which are downloaded individually through a playlist (.m3u8 file).

Preliminary step

Let’s begin the process with the CDN configuration. Here, you can specify the type and number of CDNs, and/or enable P2P (peer-to-peer) for routing. It also defines the routing priorities between CDNs (through CDN business scores), and which domains are allowed to deliver the video (through domain allowlist). 

Using the above illustration as an example:

  • CDN A score: 80
  • CDN B score: 80
  • P2P delivery: enabled
  • Allowlist: www.youtube.com

In-Stream Switching

When an end-user visit your website and played one of your videos on their browser, this will initiate the execution of SDK, and then their browser will download the playlist file (.m3u8) from any of the CDNs. The CDN score will be the deciding factor on how each video segment will be downloaded and delivered.

The CDNs with higher scores will download the first few video segments (.ts file). Using the above example, CDN A and CDN B have an equal likelihood to be used to deliver the first few video segments.

Once a CDN finished the delivery of a video segment, this CDN will be assigned to deliver the next video segment. Also, in case the delivery of a video segment using a CDN fails, then the next available CDN will also attempt to deliver this video segment.

This is the core process of In-Stream switching.

While the CDNs are delivering the video segments, the Stream Monitoring service will gather CDN quality data. Moreover, while the video segment is playing, the Stream Monitoring service will gather video event data.

CDN quality data includes CDN bandwidth and CDN availability as metrics. While video event data includes several metrics (please check this link to know each metric measured on video event data).

The collected CDN quality data and video event data will be sent to the collector.

These collected data will be used to recalculate/update the CDN scores. Recalculation will be based on how well a CDN performs and how well the video is delivered such that well-performing CDNs will improve its score, while poor-performing CDN will degrade its score.

In case the user modified the CDN business scores on the platform, these changes will also be used to update the CDN scores as well.

After the new CDN score has been calculated, this score will be used to decide which CDN will be preferred to download the succeeding video segments. In other words, the new score will be the basis of the new routing priority.

For example, during the initial streaming stage, CDN A performs better than CDN B, this means CDN A has higher CDN quality data, and hence will improve its current score. During the mid-streaming stage, CDN A will now get a higher routing priority than CDN B. Hence the current scores can be updated to:

  • Updated CDN A score: 90
  • Updated CDN B score: 60

With this updated scores, CDN A will now get a higher routing priority than CDN B. 

Note: The updating of scores is done at a specific frequency.

Video Delivery

As described above, video content can be delivered through Multi CDN and P2P. Multi CDN obtains the video segments through the stream source (origin server) and delivers video content to the end-user using the HTTP protocol. While P2P obtains the video segments from other end-users (“peers”) who are watching the same video and delivers the video content to other end-users using the Web RTC protocol.

When the P2P video delivery feature is enabled, then this will allow P2P video delivery for the video stream.

The routing ratio between CDNs and P2P is based on the location of the video segment relative to the player’s playback position. The best CDN will most likely deliver the video segment closer to the playback position, while the less-performing CDN and P2P will most likely deliver the video segments farther to the playback position, with the P2P:CDN ratio increasing as the video segment gets farther from the playback position. 

Since P2P delivery uses Web RTC, this will improve the privacy protection of the stream source. In addition, since P2P delivery uses existing peers to deliver video segments, this will reduce the use of CDN infrastructures, and consequently reduce the cost of content delivery as well.