Skip to content

Configuring a cluster for real-time restreaming

Contents

M4F and M4S protocols

M4F and M4S are proprietary Flussonic protocols that are always recommended to use for Flussonic-to-Flussonic connectivity. Let's consider in more detail for what purposes they are used.

M4F is a segmented protocol, but at the same time it is able to send video segments as soon as they appear on the source (which distinguishes it favorably from, for example, HLS protocol).

Note

In pull protocols (such as HLS and MPEG-DASH), the receiver periodically connects to the source, checks for recent segments and gets (pulls) them if they are new, then closes the connection and disconnects from the source. The receiver repeats this whole procedure to get updated about new segments, therefore, you may experience a small time delay in pull protocols.

In push protocols (M4F, RTSP), the receiver opens a connection to the source and keeps it constantly active. The source will send (push) all new segments to the receiver using that always-on connection. The difference is that in push protocols, you get new segments instantly.

M4F is also used to access the archive (DVR), with segments being the same for both live and archive. More details here.

M4F is codec-agnostic, which means it can use content encoded with any coding format and is suitable for most tasks. However, as mentioned above, M4F is segment-based, and that is why it (like any segmented protocol) causes latency (accumulation of 3 video segments at the source before starting playback). There are certain situations in which this latency is undesirable (for example, when transmitting video from an IP camera, or broadcasting a sporting event).

For such situations, M4S — real-time data transfer protocol, is suitable. It, unlike M4F, transmits video frame by frame, and there is practically no delay between the real-time event and the broadcast.

DVR Archive (Digital Video Recording)

Flussonic Media Server has ample opportunities for recording streams to an archive and subsequent work with them, more details here.

It is important to understand that there is no sense to access the archive via M4S. There are several reasons for that:

  1. In the case of viewing the archive, such a thing as latency is actually absent and does not play any role for the user.
  2. With frame-by-frame archive access, the frame transition rate from the source to the receiver is determined by the source, while with the segment access, the receiver regulates the download speed of the segments. Downloading segments from the source is more efficient in terms of practice (server load, traffic consumption) than frame-by-frame transmission to the receiver. That is why it is a more modern and correct approach.

Archive (DVR) access via M4S

What to do in a situation when you need M4S, but you also need an access to the archive?

When using internal protocols, a signaling mechanism is implemented in Flussonic Media Server, due to which several Flussonic servers (Cluster) identify each other. When adding an M4S source, Flussonic will automatically check for the existence of an archive, and, if necessary, add a source for the archive and access it by M4F.

Thus, you get a very low latency configuration for live streaming, and at the same time, cluster access to the archive.

Configuration example

This configuration can be used in situations when Flussonic server is located in a remote location (cottage, oil platform) where, due to limited network bandwidth, it is impossible to send streams from all cameras simultaneously. In addition, you need to both output a live broadcast and record an archive, but play it on request from another Flussonic server.

M4F causes latency from source to player during live broadcasting about 20-30 seconds (similar to MPEG-DASH, HLS) due to segmentation. This is acceptable for TV, but not suitable for IP cameras. M4S gives a source-player delay up to 1-2 seconds on average, so it is good for broadcasting from a camera. However, it did not support an archive access before, but this is no longer a problem.

Source:


http 8888;
cluster_key 123;
stream main {
  input fake://fake;
  dvr /storage;
}

Receiver:


http 9999;
cluster_key 123;
source m4s://FLUSSONIC-IP:8888;