Flussonic Media Server documentation

Multicast Receiving

Flussonic can ingest video sent as multicast over UDP MPEG-TS and UDP RTP.

To ingest multicast, Flussonic has to send an IGMP request to join the multicast group at the right network interface.

In the simplest case you'll need to create a stream, give it a name and add the source: udp://239.0.0.1:1234

stream ort {
    url udp://239.0.0.1:1234;
}

Contents:

Selecting a network interface Anchor Anchor x2

A server receiving multicast usually has more than one network interface. For example, it may have one network card connected to LAN and used to receive video, and the other one connected to the Internet and used to serve clients via HLS or HTTP MPEGTS.

The WAN interface often goes first and Flussonic by default will send its IGMP requests to this interface and therefore will not get video.

To explicitly specify which interface must be used to receive multicast, you need to add the server's IP address of this interface. For example, if eth2 has the address 10.100.200.3, then the URL will look like this:

stream ort {
    url udp://239.0.0.1:1234/10.100.200.3;
}

MPTS ingest Anchor Anchor x2

To ingest a multiprogram transport stream (MPTS), create streams and add a multicast group as the source and specify program IDs:

stream 1 {
  url udp://239.0.0.1:1234 program=2001;
}

stream 2 {
  url udp://239.0.0.1:1234 program=2002;
}

stream 3 {
  url udp://239.0.0.1:1234 program=2003;
}

Operating system tuning Anchor Anchor x2

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.

Mulicast ingest issues Anchor Anchor x2

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.

Disable the rp filter:

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:8080/ort/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 Anchor Anchor x2

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:

%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

the problem can be fixed by rising up the limit:

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

Headend problems Anchor Anchor x2

We have met issues with group addresses on some headends (without names, sorry =)

We recommend using group addresses from 239.1.1.1 and higher. Lower addresses might not work sometimes.