Skip to content

Multicast and MPTS ingest

A transport stream over UDP is the headend's main input. The signal arrives either as a single service on a group (SPTS), or as a multiplex where the program you need is one out of a dozen (MPTS). Mcaster takes both, and in the second case it takes the trunk in once for all its programs, however many streams you assemble out of it.

Attach the group

Create a stream and press + Add source on the Sources tab. The protocol is UDP MPEGTS:

  • Host — the multicast group address, for example 239.255.1.77, or 0.0.0.0 for unicast on a port;
  • Port — the group's port;
  • Incoming interface — the network interface name or its local IPv4 address; an empty field lets the system choose.
  • Peer timeout (ms) — how much silence to tolerate before restarting the ingest; an empty field means the default.

Press Save. If the Host field holds a multicast group, the station subscribes to it itself (IGMP for IPv4, MLD for IPv6). Unicast differs only in the address: 0.0.0.0 means "listen on the port on every interface".

Selecting the incoming interface

When multicast arrives through a separate network card, set Incoming interface for the MPEG-TS/UDP input on the Sources tab. For example, set Host to 239.255.1.77, Port to 5500 and Incoming interface to eno2. You can use the card’s IPv4 address instead of its name, for example 192.168.20.10. The group subscription is created on that interface even when the default route uses eno1.

The field applies to IPv4 multicast, including source-specific multicast (SSM). Leave it empty for IPv6: explicit interface selection for IPv6 is not supported. For unicast, this field does not select the receiving interface. Clear the field and save to restore selection through the OS routing table. Changing the interface recreates the subscription and briefly interrupts ingest.

The name or address must belong to the streamer receiving the feed. If the interface cannot be found or has no IPv4 address, the source will not start; its input status shows the reason. In a cluster, check the setting on every streamer where this stream may be placed.

For a source configured by URL, use udp://239.255.1.77:5500?interface=eno2. The format udp://eno2@239.255.1.77:5500 is also supported; when the interface parameter is present as well, it takes precedence.

The interface for sending multicast is configured separately for each push.

A program out of an MPTS trunk

A multiplex from a satellite or from a partner carries several services in one group. The one you need is picked by the Program (PNR) field of the same source: create one stream per service, all with the same group and port and different program numbers.

An empty field means "the first one with content" — that is what the form says under it.

What matters here in practice:

  • The trunk is received once. Two streams with the same group, port, interface and SSM source share the socket and the demultiplexer: the network sees one subscription, the machine does one transport parse. Ten programs out of one trunk do not cost ten ingests.
  • With no number given, the first program that actually carries media is taken. Not the first by PSI: tables in trunks are often stale and announce services whose PIDs were dropped long ago.
  • An unparsable number is refused by the form rather than understood as "the whole trunk": otherwise the stream would end up as a mash of every program in the multiplex.
  • Counters are attributed per subscriber, while errors of the trunk as a whole are duplicated to all of them: per stream you see both its own PIDs and the trouble that happened to the entire transport.

Ingest from a specific sender (SSM)

When several sources broadcast into a group and only one of them is wanted, put its address into the Source (SSM) field.

The kernel subscribes to the group naming the sender (IP_ADD_SOURCE_MEMBERSHIP, IGMPv3) and drops foreign traffic before it reaches the station. Supported for IPv4.

HTTP ingest

The same transport stream served over HTTP is the usual way to take a signal from a partner when multicast does not run between you. The source protocol is HTTP MPEGTS, with a URL and, if needed, a Peer timeout (ms).

Chunked transfer is supported. A broken connection and a silent but live connection are told apart and show up differently in the input status — these are two different diagnoses: "we were disconnected" and "they stopped sending".

An HTTP input has the smoothing buffer on by default (30 seconds): such a source almost always arrives in bursts, and without the buffer the bursts would travel to the output.

What is parsed out of the stream

Video H264, HEVC, MPEG-2; audio AAC, AC3, EAC3, MPEG-2 audio; DVB teletext and DVB subtitles with their descriptors, CEA-608/708 captions, KLV metadata, SCTE-35 markers, track language descriptors from the PMT.

SCTE-35 markers are received, pass through the stream to every output and are assembled into ad breaks, see Ad marks.

What must be true in the network

  • Multicast does not travel over the internet. The station must sit in the same segment as the group's source, or the network between them must route multicast.
  • The station is what subscribes. The IGMP request leaves from it, and switches with IGMP snooping deliver the stream only to subscribers. There is nothing to configure on the station for that — what matters is that the network passes the subscription.
  • Check from the station's machine. tcpdump -i <iface> host 239.255.1.77 run there answers the question "do the packets arrive", and no check from a neighbouring machine replaces it.

Applying changes

Changing the group, the port, the interface, the program number or the URL restarts the source. Changing a timeout alone is applied on the fly, without interrupting the ingest.

What next