Ingest multicast¶

Flussonic Media Server can ingest multicast over UDP MPEG-TS, including RTP encapsulation.

In computer networks, multicast sent from a source stops at the first switch, and doesn't proceed further until a client in the network explicitly requests to join the multicast group to receive the data. To receive multicast OS kernel sends an IGMP request to the switch. While the software is running, the kernel resends IGMP requests to the switch, extending the validity of the data request to join the multicast group. Without IGMP requests to the switch, the client will stop receiving multicast in a few seconds.

Contents:

Requirements¶

A server with Flussonic Media Server installed. A virtual server might not suit due to the specific multicast operation and high complexity of network configuration.
A source of unencrypted multicast. You should know its multicast group address and port. You can start with SPTS source, that's one channel—one group. Then you can move on to MPTS and T2-MI encapsulation.

Ingesting SPTS from a source using a server with a single interface¶

If your server has a single network interface, follow these steps:

Create a stream with some name.
Specify the source like so: udp://239.0.0.1:1234.

stream example {
    input udp://239.0.0.1:1234;
}

SPTS ingest

When playing video and audio in a browser, you may encounter the following issues:

If you have H.264 (AVC) or H.265 (HEVC) video, the browser will play it but not on all Apple smartphones. If you have an MPEG-2 video, you'll need specialized software, like VLC to play the video.
Multicast transmits MPEG-2 or AC-3 audio. Browser can't play either of them.

It's enough to verify the following:

The stream is active.
Stream's uptime grows without any interruptions,
The input bitrate matches the expected bitrate, varying from 1 to 10 Mbits:

SPTS stream bitrate

Selecting a network interface¶

A server receiving multicast usually has more than one network interface. It may have one network card connected to LAN and used to receive video, and the other one connected to the Internet (WAN) and used to serve clients via HLS or HTTP MPEGTS and download updates.

The default route uses WAN interface, so the OS kernel sends IGMP requests to the WAN interface. It means that Flussonic Media Server won't receive the video.

To explicitly specify which interface to use to request and receive multicast, specify the name of the interface, for example, eth2 in the source IP address right before the multicast group address:

stream example {
  input udp://eth2@239.0.0.1:1234;
}

If it's more convenient for you to specify the IP address of the interface to which to send the IGMP request, then specify it in the source address right after the address of the multicast group. For example, if the eth2 interface has the 10.100.200.3 IP address, then the configuration will look as follows:

stream example {
  input udp://239.0.0.1:1234/10.100.200.3;
}

MPTS ingest¶

To ingest a multiprogram transport stream (MPTS), use the protocol-specific options instead of udp://. Learn more

Operating system tuning¶

Linux default settings do not allow ingesting video via UDP without loss, so you have to significantly increase the size of network buffers.

See detailed instructions on tuning the Linux network subsystem in Performance.

Note that to ingest HD video the recommended buffers size is about 16MB.

Multicast ingest issues¶

If you have any problems with the quality of ingested video, you should try to find what the problem is.

First of all, remove all iptables rules: iptables -F.

The rp_filter should also be disabled to avoid routing problems. Flussonic disables it automatically only on the network interface where you enable multicast ingest to reduce server sensitivity to network attacks. If, for some reason, rp_filter was not disabled by Flussonic, disable it manually:

sysctl -w 'net.ipv4.conf.eth0.rp_filter=0'

and

sysctl -w 'net.ipv4.conf.all.rp_filter=0'

Change eth0 to real interface if it differs.

Second, note that when you watch video with Flussonic, many factors affect its quality: the signal quality, ingest quality, the server preformance, and the performance of your network. So the problem probably is not caused by Flussonic Media Server. Now let's try to find the source of problems.

If you run:

/opt/flussonic/contrib/multicast_capture.erl udp://239.0.0.1:1234/10.100.200.3 output.ts

and record 30 seconds of video, copy it to your computer and watch that video in VLC, then you will get an actual quality of multicast received by the server. This script does not extract the MPEG-TS but writes raw multicast to disk.

If at this stage you got a nice smooth video, you can go ahead and run this command on the server itself:

curl -o output.ts http://127.0.0.1:80/example/mpegts

You will receive the video that was ingested by Flussonic, unpacked and packed back in MPEG-TS. Download this file to your computer and watch it locally to make sure that the quality of your network connection does not affect the experiments.

If at this stage the video is also good, but when viewing from Flussonic it freezes, the problem most likely is that your network connection bandwidth is not enough to transfer video smoothly from Flussonic to you.

Issues with switches¶

Sometimes the settings of a network switch can cause issues. For example, one client had a problem with the limit on the number of received channels. It turned out that there was a limit on the number of subscriptions on one port. You can check this limit with the command:

#debug igmp snooping all

If you see this message:

%Jun 25 15:12:18 2015 SrcIP is 192.168.121.2, DstIP is 226.2.1.16
%Jun 25 15:12:18 2015 Groups joined have reached the limit, failed to add more groups

You can fix the problem by raising the limit:

#ip igmp snooping vlan XX limit group <1-65535>

Issues with multicast addresses¶

In certain cases, headends have issues with multicast group addresses between 224.0.0.0.0 and 239.1.1.1.1. We recommend using multicast group addresses from 239.1.1.1.1 and higher. Lower values may not work.