FAQ

Answers to the questions that arise most often in operation: SRT compatibility with third-party software and multicast reception at high bitrates.

SRT: login and password authorization in third-party software

Between two Perfect Streamer nodes SRT authorization is configured natively, by the input and output fields (SRT). Interoperability with other software is not guaranteed: the stream ID parameter is not standardized and is implemented differently in different software.

The compatibility mechanism is the same in every case: the receiving side takes the stream ID of the connecting client and uses it to look up an account in the list of local logins (User: add and edit). It is the “Login” field that must match — in full — the stream ID value. For example, with the URL

srt://Stream_IP:port?streamid=!#::u=1234567890,password=1234567890

the “Login” field is filled with

!#::u=1234567890,password=1234567890

The stream ID syntax is of no significance to Perfect Streamer: the string is not parsed into parts but compared as a whole. There are three exceptions — characters that the node interprets itself:

  • | — a separator: the part of the string before the first such character is taken as the login, the rest as the account password;

  • * — no stream ID is set; the client is authorized by address, that is, by an account with the “IP address account” flag;

  • @ at the start of the string is reserved for the service authorization between the nodes of a Meshwork domain.

Perfect Streamer does not limit the stream ID length — the limit comes from the SRT library and is 512 bytes including the terminating null. Values longer than roughly 500 characters should not be transmitted: an over-long string either drops the connection or is sent empty without any error message.

Different software builds the stream ID in its own way, so if reception by the URL does not work, enable the “Trace” advanced setting on the SRT output. The log of the stream that accepts the connection will then show the client address, the received stream ID and the reason for the refusal — this line reveals what the other side actually sent. The stream ID can then be corrected: for example, extraneous characters at the start of the string that prevent the value from being passed can be removed.

Recommendations for working with UDP multicast

Objective. Receive UDP multicast with an aggregate bitrate of several hundred Mbps (1 Gbps and above) on a single server without interruptions.

Problem. When reception is performed on network cards with an RJ-45 interface, growing loss of multicast packets sets in as the traffic rises above several hundred megabits. Fine-tuning the card does not help — current operating system versions already use the optimal values. Cards built on better chips do not remove the problem either, especially past 500 Mbps. Bonding two cards does not help as well: a single multicast group always arrives on one physical link and on one receive queue, so it is the total bandwidth that is aggregated, not the headroom of an individual stream.

Solution. Operational experience shows that 10-gigabit network cards with an SFP+ interface should be used for receiving and transmitting UDP multicast. A budget card of the Intel X520-DA1/2 class (Intel 82599ES) is sufficient — in our tests it eliminates packet loss at multicast traffic above 1 Gbps. The CPU load also drops noticeably: handling interrupts and receive queues on such cards is cheaper.

Keep in mind when troubleshooting: the recv-err receive-error counter in the input statistics counts only socket read errors and loss of synchronization on the TS-packet boundary. Losses caused by an overflow of the kernel receive buffer never reach the application and do not appear in this counter — they are visible with the netstat -su command (the RcvbufErrors line) and through continuity errors in the stream analyzer (Analyzer).

Recommendations for network tuning for multicast

The section applies to the UDP / RTP and Pro-MPEG network inputs. These parameters do not affect SRT reception: the SRT library sets the buffer size itself, while the latency and the retransmission headroom are configured on the input itself (SRT).

The socket receive buffer size is set by the input’s “Socket buffer (bytes)” advanced setting. By default it is zero — the node requests nothing and the socket gets the buffer size set system-wide by the net.core.rmem_default parameter. As soon as a value is set explicitly, the net.core.rmem_max ceiling comes into effect: the kernel silently trims the request down to that limit and reports the truncation neither to the log nor to the statistics. The ceiling is therefore raised before the buffer size is set on the input.

The parameters are set in a separate file in /etc/sysctl.d/:

cat > /etc/sysctl.d/99-pss-net.conf <<EOF
net.core.rmem_default=8388608
net.core.rmem_max=16777216
EOF

Apply:

sudo sysctl --system

The rmem_max value is only a ceiling; no memory is reserved for it. The rmem_default value applies to every UDP socket in the system; if such a global size is undesirable, leave it unchanged and set “Socket buffer (bytes)” only on the inputs that really need it. For the calculation, use the stream bitrate multiplied by the acceptable pause in servicing the socket: 8 MB covers about 64 ms at 1 Gbps.

Flussonic and SRT

An example of an SRT URL for reception by the Flussonic software:

srt://Stream_IP:port?streamid=flussonic

Here streamid is the client login in the Flussonic software, which is set in the “Configuration — Peers setup” section.

When a new client is added it is enough to specify only the login; the test URL uses “flussonic”. When working with SRT, the Flussonic software generates streamID automatically, and if the streamID login is not specified in the URL on the receiving side, the stream will not be received and Perfect Streamer will not be able to deliver it.

In the same way streamID can be set in the login-and-password format: create an account in Perfect Streamer whose “Login” field equals !#::u=1234567890,password=1234567890 and enter the following URL in Flussonic:

srt://Stream_IP:port?streamid=!#::u=1234567890,password=1234567890

streamID can also be specified in the IP address format in Perfect Streamer — to do so, enable the “IP address account” flag on the account and fill the address field with:

  • 192.168.1.1 — a single IP;

  • 192.168.1.1-192.168.1.254 — an IP range.

In both cases the URL for reception by IP in Flussonic looks as follows: srt://Stream_IP:port?streamid=*

The stream is bound to the client IP address: reception via this URL is possible only from the specified IP address (or from the specified range).