Flussonic Media Server documentation

Sending a multicast

When working with IPTV, one often has to deal with videos transmitted as multicasts. In most cases, a multicast contains an MPEG-TS container (7 188-byte packets in each UDP packet). Less frequently, an RTP Protocol in transmitted into the network that contains the same MPEG-TS. RTP is needed to make it possible to track the losses, since the RTP packet contains a 16-bit counter that is used to track sequence numbers.

Brief basics of multicast Anchor Anchor x2

A multicast is a set of UDP packets transmitted from the same source to a group of subscribers. The address to which packets are sent is usually in the range between 224.0.0.0 and 239.255.255.255, however, 224.0.0.0/8 is not recommended due to the large number of special addresses.

In a properly configured network, multicast traffic is sent to the nearest router, and the router itself chooses the client to send the traffic to, based on the requirements of the customers. The requests are transmitted via the IGMP protocol that is used for transmitting messages about the need to include some address into the distribution group, or exclude it from the group.

Therefore, in order to make Flussonic sent multicast to clients, it is necessary to make it send the packets to the proper interface (local operator network), and the router should be configured to work correctly with multicast.

Configuring Flussonic Anchor Anchor x2

To configure a multicast distribution, it is sufficient to indicate the push option in the stream:

stream ort {
 url hls://provider.iptv/ort/index.m3u8;
 push udp://239.0.0.1:1234;
}

In the web interface, a new stream should be created, the source address should be indicated and a new push URL should be added udp://239.0.0.1:1234

You can select what tracks to send:

stream ort {
 url hls://provider.iptv/ort/index.m3u8;
 push udp://239.0.0.1:1234?tracks=v2a4;
}

v2 stands for second video track and a4 for 4-th audio track.

Configuring the server Anchor Anchor x2

All done, chances are that nothing will work, since very often, due to server settings, multicast traffic will be sent to the first interface, which usually looks into the Internet. I.e., the problem is to make Flussonic start sending traffic to the interface that looks into a local network.

route add -net 239.0.0.0/8 dev eth2

Eth2 is the name of the interface with the local network here. After such a configuration, the multicast from Flussonic will be routed to the proper interface, and it may be seen at the router, and at the client, respectively.

A reverse situation with capturing multicast is described in the next article: Capturing multicast