Flussonic Media Server documentation

Cluster restreaming

Flussonic (restreamer) can connect to another Flussonic (source), take list of running and available ondemand streams and restream then locally. Also it is possible to transparently access DVR on source.

You can configure several sources on Flussonic and make really highly available cluster configuration.

Difference from HTTP proxy Anchor Anchor x2

Many CDN offer solution to the problem of video delivery clustering via conventional HTTP proxy servers which caches segments of a HLS stream and deliver them to a user.

Unlike simple HTTP proxy, Flussonic that is installed on all servers in a network provides the following features:

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

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

It is not achievable by plain HTTP proxy because it is not working with video on lower level.

Configuration Anchor Anchor x2

To enable Flussonic cluster restreaming you need to use following directives:

  • source — to tell that you want to restream video from other server
  • cluster_key — to authorize inter-Flussonic connection

source directive has following syntax and options:

cluster_key samekeyforall;

source origin1.tv {

source origin2.tv {
  only cbc football;

source origin3.tv {
  cluster_key anotherkey;
  except comedy;

You need to have the same cluster_key for source and restreamer. Cluster key is important secret, because it can be used for configuration of remote server. It is not transferred as plaintext, only a hash.

Source directive enables automatic fetching of list of remote streams from source stream, this list is divided into several sublists:

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

By default all running streams from sources are marked as white list, all ondemand streams on source are available on restreamer in gray list.

When you specify except option, it moves streams to blacklist (it is of highest priority).

When you specify only option, you split available streams (out of black list) to white and gray list: only is for white list, other streams are not static and are waiting for request to launch.

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

Extra configuration Anchor Anchor x2

You can enable massive configuration for all streams launched via source:

source origin1 origin2 {
  segments 10;
  auth http://backend/auth.php;
  dvr /storage 2d 95%;

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

Multiple sources Anchor Anchor x2

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.

Protocol Anchor Anchor x2

Flussonic will use by internal default protocol m4f.

This protocol gives following features and guarantees:

  • it keeps streams on source and restreamer highly synchronized:
  • the same frame timestamps
  • the same body
  • doesn't have short timestamp counter as in MPEGTS or RTMP: all timestamps are in UTC
  • keeps the same structure of segments giving byte-to-byte copy of all protocols on restreamer comparing to source
  • maintains the same segment number on source and restreamer
  • has the same byte structure as on-disk DVR format
  • has push notification of client from server
  • maintain information about source DVR on restreamer

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