--- title: FAQ url: https://doc2.pstreamer.tv/en/manual/faq/index.html lang: en product: Perfect Streamer version: 2.0.2.362 --- # 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](../planning/index.md#planning-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](../webui/configure.md#webui-user-editor)). 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](../streamer/analyzer.md#streamer-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](../planning/index.md#planning-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. How much buffer was actually granted the node shows for a running input in two places: the stream statistics, in the “Input connection” block, has the “Socket buffer (granted)” line ([Stream statistics](../webui/streams.md#webui-stream-stats)), and in the input editor ([Input and output editor](../webui/streams.md#webui-stream-io)) 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: below the field — in bytes, so that it can be compared with it directly, in the statistics — rounded. 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, the stream window is closed and opened again — or one looks at the statistics, where the value is live. The parameters are set in a separate file in `/etc/sysctl.d/`: ```bash cat > /etc/sysctl.d/99-pss-net.conf <