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 authorisation in third-party software

Between two Perfect Streamer nodes, SRT authorisation is configured with the standard input and output fields (SRT). Interoperability with other software is not guaranteed: the stream ID parameter is not standardised 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 the stream ID value, and in full. 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. The exceptions are three 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 authorised by address, that is, by an account with the “IP address account” flag;

  • @ at the start of the string is reserved for service authorisation 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, by removing extraneous characters at the start of the string that prevent the value from being passed.

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. On network cards with an RJ-45 interface, loss of multicast packets sets in and keeps growing 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 either: 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 synchronisation 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 analyser (Analyser).

Recommendations for network tuning for multicast

This section applies to the UDP / RTP and Pro-MPEG COP3/RTP+FEC (SMPTE 2022-1/2) 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 (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. The value entered is a request, not an outcome. As soon as it is set explicitly, the net.core.rmem_max ceiling comes into effect, and the kernel trims the request down to that limit while reporting success either way. The ceiling is therefore raised before the buffer size is set on the input.

The node shows how much buffer a running input was actually granted in two places: the stream statistics have the “Socket buffer (granted)” line in the “Input connection” block (Stream statistics), and in the input editor (Input and output editor) the granted size is printed below the field itself, with a warning next to it if the request did not fit under the ceiling. Both places show the useful volume that went to the socket, not what was typed into the field: in bytes below the field, so that the two can be compared directly, and rounded in the statistics. The absence of the line means that there is no socket: the input is stopped. It never means a zero buffer.

The value in the statistics is refreshed together with the other indicators, whereas below the field it is read once, when the stream window is opened. That is why the line below the field disappears after a new size is saved: saving reopens the socket, and the former number no longer applies to it. To see what the new socket was granted, close the stream window and open it again, or look at the statistics, where the value is live.

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. Zero and an explicitly set number are not equivalent even at the same magnitude: the kernel doubles a requested size but takes the default size as it is, while in both cases half of what is granted goes to the bookkeeping overhead of the packets. Therefore, on a system with the same rmem_default, an input with an explicitly stated number gets twice as much useful room as an input left at zero.

For the calculation, use the stream bitrate multiplied by the acceptable pause in servicing the socket. For example, 8 MB covers about 64 ms at 1 Gbps. The guideline sets the useful volume, that is, the number in the input’s field; the net.core.rmem_max ceiling must then be twice the largest such number. The recommended pair of values above satisfies this condition.

SRT: reception in third-party software with its own stream ID

An example of an SRT URL for reception in third-party software that passes its own stream ID when working with SRT:

srt://Stream_IP:port?streamid=client1

Here client1 is the login of an account on the “Local logins” tab (User: add and edit). When the account is added, specifying the login alone is enough. If such software passes its own stream ID and the URL gives no login, the stream is not received: Perfect Streamer finds no account and does not deliver the stream.

The stream ID can be set in the login-and-password format in the same way: the account’s “Login” field equals !#::u=1234567890,password=1234567890, and the third-party software is given the URL:

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

The stream ID can also be set in the IP address format. To do so, enable the “IP address account” flag on the account and enter in the address field:

  • 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 the third-party software looks like this: 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).