Flussonic Media Server Documentation

Video Ingest in a Cluster

This feature solves the following problem: say, there are a few servers (up to 20), united in a group, and there are a bunch of streams that need to be ingested, not more than once on each server.

If one server fails, it is necessary to ingest streams on another server automatically.

This feature works as follows: configuration file defines all servers involved in ingesting, cluster authorization should be enabled:

cluster_key MYSECRET;

peer s01.myhosting.com;
peer s02.myhosting.com;
peer s03.myhosting.com;

Next you need to define your streams and use cluster_ingest directive:

stream cam01 {
  url ...;

stream cam02 {
  url ...;

stream cam03 {
  url ...;
  cluster_ingest capture_at=s01.myhosting.com;

You can specify an explicit option to bind to a single server. This is not a hard binding, because if the server is turned off, the stream will be started on others.

For a sufficiently large number of streams they will be evenly distributed between the servers.

If the server is shut down, the streams will be automatically started on other servers. If it turns on, this streams will be restarted on the this server again.

If we request a stream from any server in the cluster which does not have this stream, it will redirect you to a different server using a special code.

So you can actually go to any server in this cluster, and you can be sure that you will be redirected to the currently active server.

Currently this feature can be used to capture video from a camera or in a situation where it is necessary to use a narrow channel for a large number of TV channels and distribute them among repeaters in the datacenter.

We plan to implement the following related features:

  • automatic replication of an archive from a backup server to a primary server and then erasing this data on a replica
  • alternative configuration for the transcoder, which is used in case of emergency channel switching from a nearby server


You can play with timeouts in this configuration, but you need to be very careful. Setting too small timeouts will make system unuseable.

Remember very important fact: in the network it is impossible to distinguish between connection loss and very long delay.

peer s01.myhosting.com {
  fetch_timeout 1;
  stale_timeout 3;

This will tell Flussonic Media Server to fetch streams from peer once per 1 second. It is VERY often, do not use it in production, but you should play with it. fetch_timeout is responsible for it.

stale_timeout 3; will tell Flussonic Media Server to make streams from that peer as dead after 3 seconds of non-response from that peer.

So if that peer is overloaded and cannot respond in 3 seconds, he is considered dead and cluster ingest mechanism will start his streams on local host.