Skip to content

Setting up CDN

When one server for distribution of video is no longer enough, one has to set up a content delivery network (CDN).

Flussonic has a number of features to simplify this task. Surely, this article cannot claim to be a detailed instruction about organizing an income-generating CDN, but we can provide some pieces of advice about how Flussonic may be useful.

In this article, we will consider a small network of 3-10 servers broadcasting live shows.

Regional distribution

Let's review a situation when a video is captured from a satellite in Asia and transmitted to Europe/America for re-broadcasting.

The videos will have to be transmitted to long distances via public Internet, therefore it will be impossible to guarantee the quality of the channel.

The network structure will be as follows:

  • In the capture region, there will be at least two redundant servers.
  • In the region of broadcasting, the servers will ingress video from one of the two sources.
  • Each channel will be transmitted between the regions only once, to keep the intercontinental traffic to minimum.
  • Some channels that are rarely used will be transmitted only upon user request.
  • In the capture region, video will be recorded in order to prevent losses in case of channel outage.
  • In the broadcasting region, video will also be recorded for archive distribution.

Using this scheme, we will show Flussonic's capabilities.

Capturing

Various configurations may be made for capturing streams in the network, and their configuration depends on whether the video may be taken from the source several times, or not.

Duplicate capturing from source

In the easiest case, if you have a video coming in a multicast via UDP, you can just configure capturing the same video from different servers (further named as grabber1.example.com and grabber2.example.com):


cluster_key mysecretkey;
stream tvchannel {
 input udp://239.0.0.1:1234;
 dvr /storage 3d;
}

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

All the servers should have the same cluster key. In our example it is mysecretkey, but it could have any value.

In this scenario, the ingest servers run independently, the archive is written on both servers, and both servers are constantly available. However, this scheme requires multiple capturing from the IP source, and this is not always convenient or possible. For example, in case when a package of channels that is being received via HTTP sums up to 500 to 800 Mbit/s, the double capturing may require serious extension of the input channel above one Gbit/s.

Capturing from a source with an expensive/slow channel

If you do not wish to capture the video from the source several times, you can configure cluster capturing.

The same config is added to capturing servers with the following stream:


cluster_key mysecretkey;
stream tvchannel {
 input tshttp://EXAMPLE-IP/origin/mpegts;
 cluster_ingest capture_at=grabber1.example.com;
 dvr /storage 3d;
}

You can also enable this option through Flussonic UI:

  1. Head to Media -> Streams section, choose the necessary stream and click on its name.
  2. Then go to Input tab and put a tick in a Cluster ingest checkbox and specify the source in the Capture at field:

Cluster ingest and capture at in UI

With such a config on both capturing servers, all videos will be captured by a single server and the second one will just run in hot standby mode. The capture_at option tells the servers that grabber1 is the high priority for capturing. If it is not specified, the stream will be uniformly distributed between the servers, which can also be a good idea, but it will not be a cluster capturing.

If grabber1.example.com fails, grabber2.example.com will react to it, and will automatically add the streams.

In this configuration, the second server is idle, its archive is not being written, and it will start only if the first server is down.

If the archive should be completely backed up, a different configuration is required.

Capturing with archive backup

If you wish to keep a single point of video capturing, but you wish to have a redundant archive, the second server should constantly pick up and write streams. To do so, different configs should be created at different servers.

At grabber1.example.com, the configuration will be as follows:


cluster_key mysecretkey;
stream tvchannel {
 input tshttp://EXAMPLE-IP/origin/mpegts;
 dvr /storage 3d;
}

Video is captured from the source and written to the hard disk.

At grabber2.example.com, the configuration will be another:


cluster_key mysecretkey;
stream tvchannel {
 input m4f://grabber1.example.com/tvchannel;
 input tshttp://EXAMPLE-IP/origin/mpegts;
 dvr /storage 3d;
}

grabber2 will try to capture the video from the first server, but if failed to do so, it will access the source directly.

Transit from capturing to streaming

From the point of view of the servers located in the distribution region, the capturing servers are the source that usually cannot be captured more than once, so you can use the advice about distribution.

However, there is no need to configure all channels manually and keep an eye on them. You can use Flussonic capabilities instead.

At the streamer1.example.com server, which is receiving the captured video, it is sufficient to write the following into the configuration file:


cluster_key mysecretkey;
source grabber1.example.com {
  dvr /storage 7d replicate;
}
source grabber2.example.com {
  dvr /storage 7d replicate;
}

With this configuration, Flussonic will pick up the channels from one or another server, write them locally to the archive and, if necessary, spool the data available remotely, but absent locally.

If some channels are not needed for continuous operation, they may be labeled as channels on request:


cluster_key mysecretkey;
source grabber1.example.com {
  except tvchannel 2x2;
  dvr /storage 7d replicate;
}
source grabber2.example.com {
  except tvchannel 2x2;
  dvr /storage 7d replicate;
}

Distribution

In case of distributing a large amount of video content, there is a need to solve the problem of load distribution.

It is optimal where Middleware is engaged in distribution. This is the most reliable scheme from the point of view of the clients (not all of them support redirects), but you can use other options, as well.

It makes sense to organize the streamers same as the transit, but the content should be picked from the local servers:


cluster_key abcd;
source streamer1.example.com {
 cache /cache 2d;
}

In this case, we have engaged a segment cache, rather than DVR. Flussonic will put the segments into the cache and, if necessary, distribute them from there. Sure, it makes no sense to place the cache on spindle drives, only SSD should be used.

Live broadcasts are still served from the memory and take 10 gigabits without problems, but cache from a single SATA SSD is limited by 6 Gigabit SATA bus. This may be solved by making a RAID 0 of several SSDs.

The important point here is that the segments captured by the grabber will reach the last streamer in the chain without changes and with the same names, and will remain in the same form for both live broadcasting and the archive. This behavior significantly differs from that of other video streaming servers.