SRT: Support publish by SRT for live streaming, new generation protocol for broadcasting.

[andryan]

About the support of SRS for the SRT protocol.

See English or Chinese

[winlinvip]

Build From Source

SRT requires the use of Havision's library: https://github.com/Haivision/srt
The license is MPL, similar to LGPL, and the library can only be linked as a shared object (so).
SRS will automatically compile and link this library when the --srt=on switch is enabled.

Compile SRS and start it.

./configure --srt=on && make && ./objs/srs -c conf/srt.conf

Stream SRT, use ffmpeg to convert the file to SRT stream.

ffmpeg -re -i doc/source.200kbps.768x320.flv -c copy \
    -f mpegts 'srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=publish'

Note that FFMPEG needs to be enabled with --enable-libsrt. Refer to the compilation script in srs-docker/dev for guidance.

Note that when statically linking libsrt with FFMPEG, you need to compile openssl and set the compilation parameter for FFMPEG as --pkg-config-flags='--static'.

Play RTMP stream: http://ossrs.net/srs.release/trunk/research/players/srs_player.html?app=live&stream=livestream&server=127.0.0.1&port=1935&autostart=true&vhost=127.0.0.1

TRANS_BY_GPT3

[winlinvip]

Moved to #1147 (comment)

[runner365]

Moved to #1147 (comment)

[winlinvip]

Build From Docker

srs-docker has already supported the compilation environment for SRT. This image includes openssl, libsrt, and ffmpeg, which can be used as a base to compile SRS with SRT support.

• ossrs/srs:dev is the official image.
• registry.cn-hangzhou.aliyuncs.com/ossrs/srs:dev is the official image on Alibaba Cloud.

It is recommended to use the official image on Alibaba Cloud for faster download speed within China.

Compile and start SRS:

cd ~/git/srs/trunk && docker run --rm -it -v `pwd`:/srs -w /srs \
    -p 1935:1935 -p 1985:1985 -p 8080:8080 -p 8085:8085 -p 10080:10080/udp \
    registry.cn-hangzhou.aliyuncs.com/ossrs/srs:dev \
    bash -c "./configure --srt=on && make && ./objs/srs -c conf/srt.conf"

Push SRT stream, convert file to SRT stream using ffmpeg:

docker run --rm --network=host registry.cn-hangzhou.aliyuncs.com/ossrs/srs:encoder \
  ffmpeg -re -i ./doc/source.flv -c copy -f mpegts 'srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=publish'

Note that when FFMPEG supports SRT, you need to specify special parameters. Refer to the compilation script in srs-docker/dev for more information.

Play RTMP stream: http://ossrs.net/srs.release/trunk/research/players/srs_player.html?app=live&stream=livestream&server=127.0.0.1&port=1935&autostart=true&vhost=127.0.0.1

TRANS_BY_GPT3

[winlinvip]

Wiki:

https://github.com/ossrs/srs/wiki/v4_EN_SampleSRT

https://github.com/ossrs/srs/wiki/v4_CN_SampleSRT

[runner365]

Moved to #1147 (comment)

[runner365]

SRT in SRS4.0 has recently been tested and has made good progress:

1. VMIX encoder successfully pushes SRT streams to SRS, with compatibility testing passing. Streaming at 10mbps, the playback is smooth. SRS is deployed on Alibaba Cloud nodes.
2. The latest version of OBS has added support for SRT, and compatibility testing has passed. Pushing a 5mbps stream to SRS4.0 Alibaba Cloud nodes, the playback is smooth. OBS version: https://obsproject.com/forum/threads/obs-studio-25-0-release-candidate.116067/
3. The US node encoder (adaptive bitrate encoder) pushes SRT streams to the Hangzhou node through the internet (RTT fluctuates between 260-560ms). Configured at 1000kbps, the playback is smooth without stuttering. Adaptive bitrate version of ffmpeg: https://github.com/runner365/srt_encoder

Welcome everyone to assist in testing the last-mile SRT streaming to SRS4.0 in various environments:

1. Compatibility
2. Adaptive bitrate encoding
3. Network adaptability

TRANS_BY_GPT3

[winlinvip]

Happy New Year.

Low Latency SRT

This article describes how to reduce the delay of SRT, which is related to each link. The summary is as follows:

• Pay attention to the Ping and CPU of the client, which are easily overlooked but can affect the delay.
• Please use LightHouse SRS as the server, it has been adjusted and will not cause additional delay.
• Increasing RTT will affect the delay. Generally, an RTT below 60ms can maintain stable expected delay.
• With an RTT of 100ms, the delay is approximately 300ms. With an RTT of 150ms, the delay increases to around 430ms.
• Packet loss will affect the quality. Packet loss above 10% may result in screen flickering and dropped frames, but does not affect the delay significantly. The impact on audio is minor.
• Currently, the lowest delay is achieved by using vmix or core elephant to push SRT and playing it with ffplay, with a delay of around 200ms.
• Pushing SRT with OBS and playing it with ffplay results in a delay of approximately 350ms.

Special Note: Based on current testing results, the maximum delay for SRT is 200ms. Although vmix can be set to a 1ms delay, it does not work effectively and the actual delay will only be worse, not better. However, if the network is well maintained, a 200ms delay is already sufficient.

Recommended solution for ultra-high definition, ultra-low latency SRT live streaming:

• Streaming: Xinxiang (230ms), vmix (200ms), OBS (300ms).
• Playback: ffplay (200ms), vmix (230ms), Xinxiang (400ms).

-	ffplay	vmix playback	Xinxiang playback
Streaming with Xinxiang	230ms (recommended)	-	400ms
Streaming with vmix	200ms	300ms	-
Streaming with OBS	300ms	-	-

Delay involves every link, below are the detailed configurations for each link. The directory is as follows:

• CPU Client CPU can cause delay.
• Ping Client network RTT affects delay.
• Encoder How to set the encoder to low latency mode.
• Server How to configure the server for low latency.
• SRT Special configuration for SRT servers.
• Player How to configure the player for low latency.
• Benchmark How to accurately measure delay.
• Bitrate The impact of different bitrates (0.5 to 6Mbps) on delay.
• Network Jitter The impact of packet loss and different RTTs on delay.
• Report Testing report.

CPU

For streaming and playback, it is important to monitor the CPU usage. On Windows, you can open the Task Manager. CPU usage can have an impact on delay.

Note: It was found that there was a delay of up to 2 seconds, despite having a good network. Eventually, it was discovered that the delay was due to the CPU running at 100%, likely because the laptop is not powerful enough.

Sometimes, it's not the encoder or player causing high CPU usage. It's possible that other programs or network activities are causing the CPU to spike.

Ping

Ping can display the network conditions, and the network is constantly changing. If the RTT is 100ms, then the latency is at least 100ms, considering the worst-case scenario.

Suggestions for optimization: '.

• Pull dedicated lines to avoid interference in transmission, and directly connect them to the BGP machine room for forwarding.
• Decrease the bit rate to prevent increased RTT due to insufficient bandwidth.
• Connect with Ethernet cables to prevent unstable WiFi.

As shown in the following figure, if the maximum is 112ms, then the latency may be even greater than this:

And the network in the following figure is very stable, it is the WiFi at home to the BGP server, basically around 10ms, at worst it is also 20ms, such a network is very stable:

If the ping shows high latency, you can use the WiFi Explorer tool to check the signal and noise of the WiFi.

Based on actual testing, even if the Huawei WiFi has a strong signal and low noise, the RTT occasionally becomes large, reaching 100ms or even 200ms. It seems that the 5G channel is slightly better than the 2G channel. In conclusion, it is necessary to rely on ping data. If the RTT exceeds 60ms, it may cause latency.

Encoder

The encoder has a significant impact on latency. It is important to choose the Baseline profile and select CBR (Constant Bit Rate). If there are options for fine-tuning (TUNE), you can choose zerolatency.

Optimization suggestions:

• Baseline: disable B-frames and complex encoding, as they cause latency.
• CBR: disable bitrate fluctuation to prevent network congestion caused by sudden bandwidth increase.
• TUNE: zerolatency is another encoding tweak, you can enable it if needed.

Using Sinsam Live, configure as shown in the following diagram:

Using vMix for live streaming, configure as follows:

OBS configuration is shown in the following figure:

Server

Special configuration must also be done on the server, as SRT is a UDP protocol and the default UDP buffer is very small. It needs optimization. You can refer to SRS Optimization for reference and adjust the following parameters:

# Modify the buffer length to 16MB
sysctl net.core.rmem_max=16777216
sysctl net.core.rmem_default=16777216
sysctl net.core.wmem_max=16777216
sysctl net.core.wmem_default=16777216

You can check if the server is dropping packets, which often indicates network congestion or the inability to handle them in time. Pay particular attention to the errors metric below:

[root@VM-24-2-centos ~]# netstat -suna
Udp:
    0 packet receive errors
    0 receive buffer errors
    0 send buffer errors

During high bitrate, due to the high number of UDP packets, you can check for congestion. The Recv-Q is the receiving queue, and if it is relatively large, it indicates that the server is unable to handle them in time.

[root@VM-24-2-centos ~]# netstat -lpun |grep 10080
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
udp6       0      0 :::10080                :::*

In addition, the CPU indicator of the server must also be monitored. For SRS, if the CPU exceeds 80%, it indicates a problem, regardless of the number of CPU cores. To prevent high latency caused by the CPU running at a high percentage, you can use the top command to check.

[root@VM-24-2-centos ~]# top
top - 09:42:49 up 1 day, 58 min,  1 user,  load average: 0.03, 0.04, 0.05
Tasks: 104 total,   1 running, 103 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.7 us,  0.5 sy,  0.0 ni, 98.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  1881844 total,   196064 free,   301496 used,  1384284 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  1383460 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                
13517 root      20   0  346628  15988   5868 S   0.7  0.8   9:59.24 ./objs/srs -c conf/lighthouse.conf

It is also necessary to monitor the server's bandwidth to prevent it from running over. You can use the dstat -N eth0 command to check. Install it if it is not available by running yum install -y dstat.

[root@VM-24-2-centos ~]# dstat -N eth0
You did not select any stats, using -cdngy by default.
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 
  1   1  98   0   0   0|  11k   33k|   0     0 |   0     0 |2158  4082 

SRT

The configuration of SRS and SRT also needs to be adjusted in order to obtain lower latency.

srt_server {
    enabled on;
    listen 10080; # UDP port
    maxbw 1000000000;
    connect_timeout 4000;
    latency 20;
    peerlatency 20;
    recvlatency 20;
}

• peerlatency default is 300, it can be changed to 20 milliseconds.
• recvlatency default is 300, it can be changed to 20 milliseconds.

Player

SRT streaming address, Xinxiang Live, OBS, vmix, streaming address:

srt://127.0.0.1:10080?streamid=#!::h=live/livestream,m=publish

You can directly play SRT streams using ffplay.

ffplay -fflags nobuffer -flags low_delay \
  -i 'srt://127.0.0.1:10080?streamid=#!::h=live/livestream,m=request&latency=20'

Note: If using OBS, fill in the server address directly, do not enter the stream key.

You can also directly play the SRT source on the production platform, or use the production platform to pull the SRT and then transmit it to other display devices through NDI, and so on.

Configuration of xinxiang live preview stream:

Configuration of vmix preview stream:

Note: The delay setting of vmix is separate, do not specify the delay in the play URL, the Stream ID should be #!::h=live/livestream,m=request

Benchmark

Delay measurement can be done using a stopwatch. We recommend using stopwatch online stopwatch. You can open it directly using OBS's Window Capture or Browser. Refer to #2742 for more information.

Bitrate

We conducted separate tests for delay with different bitrates, and found that it had minimal impact. Here are the results:

• 500Kbps, delay of 260ms.
• 2Mbps, delay of 250ms.
• 4.5Mbps, delay of 230ms.
• 6Mbps, delay of 260ms.
• 8Mbps, delay of 230ms.

Note: There may be some fluctuations in the delay, but overall it is not closely related to the bitrate.

Note: The network is very good, it is LightHouse's BGP bandwidth, with an RTT of generally less than 25ms.

Network Jitter

When there is network jitter, it can impact the latency. We recommend using the tool clumsy, whose interface is shown below:

• Lag: Simulates network delay, which means increasing the Round-Trip Time (RTT). For example, 10ms is considered good, 30ms is average, 60ms is not good, 100ms is considered bad, and 200ms is similar to a transnational connection.
• Drop: Simulates network packet loss. For example, 10% is poor network quality, 30% is very poor, and 50% is extremely rare.

Drop: Testing data is as follows, testing at a rate of 6Mbps, as the maximum bandwidth is 8Mbps, some retransmission bandwidth needs to be reserved:

• With a 10% packet loss, occasional localized screen glitches may occur, but the video remains smooth and does not affect latency.
• With a packet loss of over 20%, there will be noticeable frame skipping or severe screen glitches, which will impact the viewing experience but not latency.
• With a packet loss of over 30%, the connection is completely lost.

RTT latency, the test data is as follows, testing with a bitrate of 6Mbps because the maximum bandwidth is 8Mbps, and some bandwidth needs to be reserved for retransmissions:

• At a latency of 200ms, there is no impact on quality, but the latency increases, resulting in a total latency of 530ms.
• At a latency of 150ms, there is no impact on quality, but the latency increases, resulting in a total latency of 430ms.
• At a latency of 100ms, there is no impact on quality, but the latency increases, resulting in a total latency of 400ms.
• At a latency of 60ms, there is no impact on quality, but the latency increases, resulting in a total latency of 340ms.
• At a latency of 30ms, there is no impact on quality, and the latency remains stable, resulting in a total latency of 230ms.

As can be seen, at a bitrate of 6Mbps and a 10% packet loss, with an RTT of 60ms, the SRT push-pull stream can maintain a stable latency of 230ms without compromising the quality.

Report

Public network LightHouse SRS server, Xinxiong live streaming pushes SRT stream, vmix pulls SRT stream, with a latency of 260ms.

Xinxiong streaming, ffplay playback, with a latency of 190ms.

vMix streaming, ffplay playback, with a latency of 200ms.

Local device cores like live streaming and pulling SRT streams, with a 300ms latency.

Local device diagram of pushing and pulling SRT streams using Vmix, with a 300ms latency.

Local device diagram of pushing and pulling streams using OBS, with a latency of around 300ms.

Local device core like pushing and pulling streams, playing with ffplay, minimum latency of 230ms.

Local VMix pushing and pulling streams, playing with ffplay, minimum latency of 200ms.

TRANS_BY_GPT3