Flussonic Media Server documentation

Reducing memory consumption

The launched Flussonic may consume huge amount of memory: up to 30 Gigabytes.

It looks creepy, but if we count how it is used, it will no longer seem so scary. The fact is that in order to run as fast as possible, Flussonic prepares all the data in the memory for some protocols in advance.

So, for the HLS and HDS protocols all segments are stored in memory and are extracted as fast as possible. With that, Flussonic is actually one of the two servers that efficiently use several cores and distribute video from shared memory to clients across the cores.

Most of the servers written in C can't run in the multi-trend mode and require writing HLS segments to the disk. This behavior of the server results in unpredictable speed of video delivery from the disk, and a successful writing to the log may affect live broadcasting. Flussonic does not have such a problem, since the memory is used directly for storing the last seconds of the stream.

Let's see what the main memory consumers in Flussonic are.

HDS Anchor Anchor x2

The easiest way to reduce memory consumption is disabling HDS. One can do without it, but HLS should better be preserved:
stream ort {
  url udp://239.0.0.1;
  hds off;
}

With the default settings, this will save about several dozens of megabytes per stream.

Prepush Anchor Anchor x2

The next way to reduce memory consumption is disabling prepushing. Prepush means the frames in memory that will be sent to fill the buffer at a client that has just connected over the RTMP or HTTP MPEG-TS protocol:
stream ort {
  url udp://239.0.0.1;
  hds off;
  prepush off;
}

Now the frames will not be saved in the stream, but will be accumulated only in the list of HLS segments.