Skip to content

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 abcd;
peer flussonic1:8080;
peer streamer:8081;

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

stream cam01 {
  url file://vod/bunny.mp4;
stream cam02 {
  url file://vod/bunny.mp4;
stream cam03 {
  url fake://fake;
  cluster_ingest capture_at=streamer;

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

Flussonic cluster ingest

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 that 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.

cluster_key abcd;
peer flussonic1:8080;
peer streamer:8081 {
  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.