Redundant transcoder configuration with cluster ingest¶

The cluster ingest mechanism may be used not only for ingesting video from a source, but also for other scenarios such as transcoding, recording a DVR archive, or pushing video to other servers (e.g., Youtube). In any of those cases each stream will work on one of the peers, and if one of the peers fails, the streams on it will be completely disabled, and the other peers will recapture the streams and perform necessary actions. In particular, the cluster ingest configuration may be very useful for transcoding.

Example scenario¶

For example, let us consider a scenario when 2 Flussonic severs (grabbers) are used for capturing satellite video with 200 channels from an IPTV DVB-Headend. The captured video should then be deinterlaced by 4 other Flussonic servers (transcoders) connected into a cluster, and finally distributed via the Internet. We will use the cluster_ingest option to ensure reliable transcoding of all channels in case of failure and determine which cluster peer will perform the transcoding.

Configuring grabbers¶

Let us configure grabbers so that each of them ingests a half of TV channels. Each of the grabbers will contain 100 streams in its configuration, each stream for ingesting a TV channel:

• grabber1: streams 1-100
• grabber2: streams 101-200

A stream configuration will look like this:

stream dvb01 {
    input mpts-dvb://a1?program=1000;
}

Configuring transcoders¶

The transcoding servers will recapture the streams from the grabbers so that every transcoder will receive 50 streams on input:

• transcoder1: streams 1-50
• transcoder2: streams 51-100
• transcoder3: streams 101-150
• transcoder4: streams 151-200

The transcoders will be connected into a cluster by adding cluster_key directive in each transcoding server’s configuration:

cluster_key abcd;
peer transcoder1;
peer transcoder2;
peer transcoder3;
peer transcoder4;

Here and further on, we agree that the servers have correct hostnames and can be resolved.

Then we add 50 streams into each transcoder’s configuration. All streams' settings will be the same (except for the name of the recaptured stream from a grabber):

stream dvb01 {
  input m4f://grabber1/dvb01;
  transcoder vb=1k deinterlace=true ab=128k;
  cluster_ingest;
}

If we don’t use cluster_ingest in such configuration, all transcoders will recapture streams and process them simultaneously. However, if one transcoder fails, its streams will not be transcoded at all and the TV viewers will not be able to watch some programs.

The cluster_ingest option ensures that if one transcoder fails, its streams will be recaptured by other transcoders that will continue transcoding. Each stream will be processed by only one transcoder. If another transcoder fails, the streams will be redistributed between other peers again.

Please note that if the streams from the nonworking transcoder are redistributed, other transcoders will work under higher loads. For example, if all 4 transcoder peers work simultaneously, each of them may be loaded at 60-70%, but if one of them fails, the load on 3 other peers will rise to 90%. This should be considered when choosing transcoding servers’ capacity.