Flussonic Media Server documentation

System requirements

Often you need to know what load will be possible with your existing hardware, or what to buy to achieve a certain performance.

Note that all estimates (including those described on this page) are very approximate and may not reflect reality.

For example, you may assume that on average one camera outputs video at the speed of 2 megabits, but keep in mind that some other camera can give 1, or 4, or 8 megabits. You can approximately estimate how much CPU or RAM a single stream will use, but note that some special streams can use much more resources.

The best way to get concrete numbers is to carry out load testing. For example, before creating a cluster of 20 servers, you should test at least of one of them.

Important. Whenever possible, always experimentally check the productivity of your hardware.

Architecture Anchor Anchor x2

Flussonic Media Server supports the following architectures:

  • amd64 (x86_64)
  • armhf 32bit (RaspberryPI, Cubieboard, Parallela, etc.)
  • tilera
  • porting to mips - in progress

Rough estimates of performance Anchor Anchor x2

Number of simultaneous connections 10 100 1 000 5 000+
Processor Any 1 core 4 cores (Xeon / i7) 2 core Xeon E5
RAM 128 M 256 M 1024 M 16 G
HDD 40 M 40 M 40 M 40 M
Network interface 100 Mbit/s 1 Gbit/s 1 Gbit/s for servers 10 Gbit/s Intel
Operating System Debian Linux, Ubuntu Linux

Under normal circumstances, the first "bottleneck" is the network bandwidth. A powerful processor does not help when customers simply don't have enough bandwidth to download video. On average, we can assume that one client (one person looking videos on the network) will spend 2 megabits to view a normal camera or SD-channel, or 10 Mbps for HD-channel.

RAM can be installed on average at the rate of 20-50 megabytes for 1 stream. This amount of memory can significantly increase when using advanced features such as JPEG thumbnails, or reduced by directives such as hds off.

It's necessary to consider that when you transfer multimedia data from files, from HDD, the main load falls on a disk subsystem. Respectively, when planning a configuration of the server, the special attention has to be paid to productivity of the used hard drives. SSD should be used for "a hot zone" and a cache, HDD for all the rest. Read about it in more detail in File broadcasting.

Processor Anchor Anchor x2

As a minimum, you need any modern processor.

i5/i7/Xeon — will sustain relaying about 200 streams/cameras without transcoding, Raspberry — only 64.

One server with multiple processors is better than multiple servers with a single processor.

Transcoding Anchor Anchor x2

Transcoding is necessary for changing video size, its bitrate, to create multibitrate streams, deinterlace, to add logos, to turn an audio track into AAC, etc

Transcoding is a very resource-intensive task. Expect from 5 to 20 channels on one server, depending on the settings. More specifically, for example, Xeon E3 1240 server can transcode about 5-10 channels.

One of reasonable options for transcoding is Xeon E5 with a maximum frequency. It's a server-grade solution.

It's possible to take non-server processors, they are a little more likely to fail, significantly cheaper and usually allow to work at a greater frequency than a server-grade solution. Anyway, you need Sandy Bridge, Ivy Bridge and beyond.

Interaction with other applications and the operating system Anchor Anchor x2

Also resources needed to run the operating system and other services that will operate in parallel with Flussonic Media Server should be taken into account.

It's best to make sure that the server is running only Flussonic Media Server. If you use any other video striming applications — move them to other separate servers.

If you plan to use more than 60 GB of RAM, expect that to reserve about 10 gigabytes for Linux.

You also need to completely disable a swap, as it is not compatible with video streaming. If the server doen't have enough RAM, it cannot be extended by a swap.

Clustering Anchor Anchor x2

If the power of one server isn't enough, you can distribute the load to multiple servers. Learn more in the article about clustering.

High loads Anchor Anchor x2

To prepare for a really high load you need to follow the next hints:

  • refuse from hardware RAID and switch to JBOD with possible software RAID or application level RAID
  • understand size of your "hot" and "warm" content to select properly HDD and SSD
  • select proper hosting. Not all 10Gbit/s hostings are really 10G.