Skip to content

Cluster restreaming

A Flussonic Media Server restreamer can connect to the Flussonic Media Server source or origin, take the list of running streams and streams available on-demand, and restream them locally. Also, Flussonic provides transparent access to the DVR on the source server.

You can configure several sources on Flussonic and build a high-availability cluster configuration.

On this page:

Difference from HTTP proxy

Many CDN providers offer to use a cluster of HTTP proxy servers that cache the segments of an HLS stream and deliver them to users.

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

  • Just-in-time packaging on the restreamer. Receiving a stream over a single protocol, the restreamer can repackage that stream into available output protocols, such as HLS, DASH, RTMP, RTSP, HTTP MPEG-TS or UDP MPEG-TS.
  • Single user authentication for all available streaming protocols.
  • Centralized aggregation of sessions and collection of statistics.

The main difference between using an HTTP proxy and restreaming via Flussonic Media Server is that you can transfer video between servers once and get all the Flussonic Media Server features on the restreaming server. An HTTP proxy can't offer you that, because it doesn't operate with video on lower levels.

Enabling cluster restreaming

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

  • source—specifies the server to pull the stream from and then restream it.
  • cluster_key—specifies the authorization key for Flussonic-to-Flussonic connections.

The source directive has the following syntax and options:


cluster_key abcd;
source streamer:8081 {
}

The cluster_key on the source and restreamer have to be the same. Keep the cluster key in secret because it can be used to configure a remote server. The cluster key is hashed and then transferred.

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

  • whitelist—these streams are available as static on the restreamer.
  • greylist—these streams are available as ondemand on the restreamer.
  • blacklist—these streams aren't visible on the restreamer.

By default, all the running static streams from the source server are on the whitelist on the restreamer. All the ondemand streams from the source are in the greylist on the restreamer.

Streams specified in the except option move to the blacklist. This option has a higher precedence than only.


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

Flussonic cluster restreaming

Streams specified in the only option move to the whitelist. All the remaining streams (except those on the blacklist) move to the grеylist.

Flussonic cluster restreaming

If the source server has a stream with the same name as the one configured locally on the restreamer or published to the restreamer, the locally configured stream takes precedence. The stream from the source is ignored.


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

You can use the stream name wildcard pattern with the only and except options. A wildcard makes the configuration of live locations on a remote server when stream names aren't known in advance simpler. For example, to capture all the streams from the source server whose names begin with mylive/, use the configuration below:


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

Extra settings

You can apply the settings to all streams started with source at once like so:


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%;
}

The preceding configuration applies to all the streams started on the restreamer.

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


source origin {
  backup vod/bunny.mp4;
}

If you need to restrict playback via specific streaming protocols, use the protocols option in the source:


source origin {
  protocols -dash -hls -rtmp;
}

The preceding example shows how you can disable DASH, HLS, and RTMP streaming, so that a viewer won't be able to play the streams via these streaming protocols.

For more information about the options and settings available for the source, refer to the Flussonic API Reference.

Enabling several sources

Flussonic allows to configure several sources on a restreamer. It works as follows:

  • If several sources have the same stream name, the stream with that name will have several URLs.
  • If the first source goes offline, the restreamer switches to the second source.

To create a highly available source cluster configuration, enable cluster ingest feature for every source.

M4F protocol overview

By default Flussonic Media Server uses its own segment-based M4F protocol for restreaming.

M4F has the following advantages:

  • Synchronization of streams on the source and on the restreamer.
  • The same frame timestamps in the streams from the source and from the restreamer.
  • The same payload when requesting a stream segment from both the source and the restreamer. The payload is the same on all servers. All servers return a compatible response.
  • Timestamps in UTC.
  • The same stream segment structure due to a byte-to-byte copy of the source stream for all the protocols on the restreamer.
  • The same order of segments at the source and the restreamer.
  • A single byte-structure for transferring streams between servers and storing them to the archive. It ensures that the data transmitted between servers over M4F and the data recorded to the archive are the same.
  • Notifying the restreamer about new segments via push notifications. The restreamer receives a notification about the availability of a new segment and downloads it through a separate channel.
  • Providing information about the source DVR to the restreamer.

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

Other protocols have the following disadvantages compared to M4F:

  • RTMP breaks timestamps.
  • RTMP and MPEG-TS by design make timestamp synchronization of streams transferred between the servers complicated.
  • RTMP and MPEG-TS don't have mechanisms to synchronize stream timestamps with absolute time.
  • RTSP has a mechanism to synchronize stream timestamps and absolute time, but it has problems delivering B-frames and some codecs.

M4F gives the absolute time of each frame with high precision.