Cluster Restreaming

Flussonic Media Server (the restreamer) can connect to another Flussonic Media Server (the source), take the list of running streams and streams available on-demand, and restream them locally. Also, Flussonic allows you to transparently access DVR on the source.

You can configure several sources on Flussonic and build a robust highly available cluster configuration.

Difference from HTTP proxy

Many CDNs offer the solution to the problem of video delivery that means using a cluster of conventional HTTP proxy servers that cache the segments of an HLS stream and deliver them to a user.

Compared to a simple HTTP proxy, Flussonic Media Server installed on all servers in a network provides the following advantages:

• you can use not only HLS, but DASH, RTMP, RTSP, HTTP MPEG-TS, and UDP MPEG-TS;
• single user authentication on all available protocols;
• centralized aggregation of sessions and collection of statistics.

So the main difference between using a plain HTTP proxy and restreaming via Flussonic Media Server is that you can transfer video between servers only once and get all Flussonic Media Server functionality on the restreaming server.

This is not achievable by using a plain HTTP proxy, because it does not work with video on lower level.

Configuration

To enable Flussonic Media Server cluster restreaming, use the following directives:

• source — specifies the server from which you want to restream video.
• cluster_key — specifies the key for authorization for inter-Flussonic connections.

The source directive has the following syntax and options:

cluster_key abcd;
source streamer:8081 {
}

You need to have the same cluster_key for the source and restreamer. It is important to keep the cluster key in secret because it can be used for configuring the remote server. It is not transferred as plaintext, only as hash.

The source directive enables automatic fetching of the list of remote streams from the source server. You can divide streams into several lists:

• white list — these streams will be available as static on the restreamer.
• gray list — these streams will be available as ondemand on the restreamer.
• black list — these streams will not be visible on the restreamer.

By default, all running (static) streams from the source server are in the white list on the restreamer, all ondemand streams on the source are in the gray list on the restreamer.

When you specify the except option, it moves streams to the blacklist (this option has a higher priority over only).

source streamer:8081 {
  cluster_key abcd;
  except stream1 football;
}

When you specify the only option, you assign available streams (except those in the black list) to white and gray lists: only is for the white list, other streams will become ondemand (not static) and will be awaiting for requests to run.

If there is a local configured or published stream that has the same name as some stream from the source, then the stream from source will be ignored and only the local configuration will be used.

cluster_key abcd;
source streamer:8081 {
  only cbc football stream2;
}

You can use the stream name wildcard pattern with the only and except options. This feature simplifies configuration when live locations are used on a remote server, and the stream names are not known in advance. For example, this configuration allows you to capture all streams from origin, whose names begin with mylive/:

cluster_key abcd;
source streamer:8081 {
  only mylive/*;
}

Extra configuration

You can enable mass configuration for all streams launched via the source:

cluster_key abcd;
source streamer:8081 {
  on_play http://IP-ADDRESS:PORT/php-auth-script.php;
  backup vod/bunny.mp4;
  dvr /storage 2d 97%;
}

source test2:8082 {
  on_play http://IP-ADDRESS:PORT/php-auth-script.php;
  backup vod/bunny.mp4;
  dvr /storage 2d 97%;
}

Such configuration is automatically applied to all streams launched on the restreamer.

If you have a configured backup option on the main server, you should upload backup file to the restreamer and specify it in source:

source origin {
  backup vod/bunny.mp4;
}

Multiple sources

It is possible to configure many sources on restreamer. If several sources has the same stream name, it will mean that one stream will be configured with multiple URLs.

This means that if first source goes down or loses stream, restreamer will switch to second source.

When there are several sources with cluster ingest configured, you can make really highly available cluster configuration.

The M4F protocol

For restreaming, Flussonic Media Server by default uses its internal segment-based protocol M4F.

This protocol guarantees the following features:

• it keeps streams on the source and restreamer highly synchronized;
• the same frame timestamps;
• the same body;
• it doesn't have short timestamp counter as in MPEGTS or RTMP: all timestamps are in UTC;
• keeps the same structure of segments when creatring a byte-to-byte copy of the origin stream for all protocols on the restreamer comparing to the source;
• maintains the same segment number on the source and restreamer;
• it has the same byte structure as the on-disk DVR format;
• it allows sending push notifications to the client from the server about new data;
• it maintains on the restreamer information about the source DVR .

So M4F provides high accuracy in time and data sent to the restreamer. It also supports all codecs that Flussonic works with.

This special protocol M4F has some advantages comparing to HLS or RTMP:

• RTMP has only millisecond timestamp precision and it breaks timestamps;
• RTMP has only 24 (or 32 bits) for millisecond timer, MPEG-TS gives 33 bits for 90 Khz based timer. It means that it is hard to synchronize time between source and restreamer;
• RTMP and MPEG-TS don't have ways to synchronize stream timing with wallclock time;
• RTSP has mechanism to synchronize stream and wallclock time, but it has problems with delivering b-frames and some codecs;
• M4F has enough space to keep wallclock time in 90 khz base, giving high precision absolute timing of each frame.