ossrs/srs

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

andryan opened this issue ยท 47 comments

About the support of SRS for the SRT protocol.

See English or Chinese

Need more discuse and vote in SRS4.

SRT is widely used in broadcasting streaming media, and it is worth discussing the support of this protocol.

TRANS_BY_GPT3

Shiva (runner365) master, based on SRS3, has implemented SRT. The branch is runner365/3.0release.srt.dev. You can see the main modifications here compare.

I will join runner365 to see how to merge it into SRS4. Let's give runner365 a thumbs up and cheer them on!

The following modifications have resolved the SRT compilation and environment issues:

What still needs to be done is to improve the thread model. Currently, the main logic of SRT is:

  1. SrsServer::initialize_st, the main process will call this to initialize ST.
  2. SrsServer::listen_srt, it will start a coroutine srt2rtmp::init to retrieve data from the queue, convert it to RTMP, and send it to the local SRS.
  3. SrsServer::listen_srt, it will call srt_server::start to start a thread.

This logic runs without any issues, as ST is running on SRS's thread and the newly created SRT thread does not call ST functions. However, there is a risk of crashing when using ST in multiple threads. If there are any modifications to SRT in the future and ST functions are accidentally called in another thread, it can cause the entire SRS to crash.

So it would be better if this model could be transformed into a hybrid model with multiple processes. Hybrid.

Additionally, the amazing Wu Aimin (Edward-Wu) has independently developed an SRT server. You can find it at https://github.com/Edward-Wu/srt-live-server.

TRANS_BY_GPT3

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

image

TRANS_BY_GPT3

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.

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

image

TRANS_BY_GPT3

Because libsrt uses MPL license, you can configure with --use-shared-srt to use libsrt.so in comercial product, please read https://github.com/ossrs/srs/wiki/LicenseMixing#srt

https://www.bilibili.com/video/av83480771

Testing SRT (Secure Reliable Transport) in various network environments in a hardcore manner.

image

image

image

image

image

image

TRANS_BY_GPT3

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

New Generation Live Streaming Protocol SRT
https://mp.weixin.qq.com/s/P4cbRxJnXlkQOtXNkdDL4w

We verify the effectiveness through a test instance: streaming data from an SRT encoder in the United States to a node in Hangzhou via the Internet, establishing SRS4.0. The test open source address is shown in the figure, using FFmpeg to configure the encoding bitrate as 1000kbps. The encoding bitrate is dynamically adjusted during the transmission process according to the actual export bandwidth. From the line 1 on the right side of the figure, we can see that the adaptive bitrate can reach up to 1400kbps, demonstrating good adaptive performance. In terms of actual test experience, the video playback is smooth without significant buffering, and even occasional bandwidth fluctuations can be quickly recovered.

image

TRANS_BY_GPT3

@runner365

Testing server: China Unicom 1, China Unicom 2 rtt: 30ms
Software version: ffmpeg_4.2.2_srt_1.4.1 srs_4.0.10_srt_1.4.1

Test case 1: rtmp push
China Unicom 1: ffmpeg -stream_loop -1 -re -i frozen.mp4 -c copy -f flv 'rtmp://China Unicom 2/live/frozen'
Test result: ffplay rtmp://China Unicom 2/live/frozen is normal.

Test case 2: ffmpeg-srt push + receive
China Unicom 1: ffmpeg -stream_loop -1 -re -i frozen.mp4 -c copy -f mpegts 'srt://China Unicom 2:1940?pkt_size=1316&mode=caller'
China Unicom 2: ffmpeg -i 'srt://0.0.0.0:1940?pkt_size=1316&mode=listener' -c:v copy -c:a copy -f flv 'rtmp://127.0.0.1/live/frozen'
Test result: ffplay rtmp://China Unicom 2/live/frozen is normal.

Test case 3: ffmpeg-srt push, srs-srt receive
China Unicom 1: ffmpeg -stream_loop -1 -re -i frozen.mp4 -c copy -f mpegts 'srt://China Unicom 2:10080?streamid=#!::h=live/frozen,m=publish'
Test result: ffplay rtmp://China Unicom 2/live/frozen has severe buffering issues.

ffplay has a large number of the following error logs.
[h264 @ 0x7f81950d8800] missing picture in access unit with size 12
[h264 @ 0x7f81950d8800] no frame!
[h264 @ 0x7f81950d8800] missing picture in access unit with size 12

TRANS_BY_GPT3

@runner365

Test server: Unicom1, Unicom2 ttl: 30ms
Software version: ffmpeg_4.2.2_srt_1.4.1 srs_4.0.10_srt_1.4.1

Test case 1: rtmp push
Unicom1: ffmpeg -stream_loop -1 -re -i frozen.mp4 -c copy -f flv 'rtmp://Unicom2/live/frozen'
Test result: ffplay rtmp://Unicom2/live/frozen normal

Test case 2: ffmpeg-srt push + receive
Unicom1: ffmpeg -stream_loop -1 -re -i frozen.mp4 -c copy -f mpegts 'srt://Unicom2:1940?pkt_size=1316&mode=caller'
Unicom2: ffmpeg -i 'srt://0.0.0.0:1940?pkt_size=1316&mode=listener' -c:v copy -c:a copy -f flv 'rtmp://127.0.0.1/live/frozen'
Test result: ffplay rtmp://Unicom2/live/frozen normal

Test case 3: ffmpeg-srt push, srs-srt receive
Unicom1: ffmpeg -stream_loop -1 -re -i frozen.mp4 -c copy -f mpegts 'srt://Unicom2:10080?streamid=#!::h=live/frozen,m=publish'
Test result: ffplay rtmp://Unicom2/live/frozen severe lag

ffplay has a large number of the following error logs
[h264 @ 0x7f81950d8800] missing picture in access unit with size 12
[h264 @ 0x7f81950d8800] no frame!
[h264 @ 0x7f81950d8800] missing picture in access unit with size 12

Test case 2:
You can take a look at the wiki: https://github.com/ossrs/srs/wiki/v4_CN_SRTParams
How to configure the SRT address?

Test case 3:
What latency did you configure for SRT in SRS? Is there a high packet loss rate in the network?
The configured latency is generally related to the network's round-trip time (RTT), packet loss rate, and network bandwidth.

TRANS_BY_GPT3

Test case 2:
You can take a look at the wiki: https://github.com/ossrs/srs/wiki/v4_CN_SRTParams
How to configure the SRT address,

Test case 3:
What is the latency you configured for SRT in SRS? Is there a high packet loss rate in the network?
The configured latency is generally related to the network's round-trip time (RTT), packet loss rate, and network bandwidth.

Case 2: SRT transmission is completed using ffmpeg, and the address is assembled according to the ffmpeg address, and it can also run normally.

Case 3: Configuration of SRS:
cat conf/srt.conf
listen 1935;
max_connections 1000;
daemon on;
srs_log_tank ./objs/srs-srt.log;
srt_server {
enabled on;
listen 10080;
peerlatency 300;
recvlatency 300;
}
vhost defaultVhost {
}
The round-trip time (RTT) between the two servers is approximately 30ms, and there is no packet loss. The bandwidth is guaranteed to be 10m, so theoretically there should be no issue. The SRS logs are also normal, so there is suspicion of compatibility issues.

TRANS_BY_GPT3

Test case 2:
You can take a look at the wiki here: https://github.com/ossrs/srs/wiki/v4_CN_SRTParams
How to configure the address of SRT?
Test case 3:
What is the latency configured for SRT in your SRS? Is there a high packet loss rate in the network?
The configured latency is generally related to the network's round-trip time (RTT), packet loss rate, and network bandwidth.

In case 2, SRT transmission is completed using ffmpeg. The address is assembled according to the address format of ffmpeg and it can run normally.

Case 3, SRS configuration:
cat conf/srt.conf
listen 1935;
max_connections 1000;
daemon on;
srs_log_tank ./objs/srs-srt.log;
srt_server {
enabled on;
listen 10080;
peerlatency 300;
recvlatency 300;
}
vhost defaultVhost {
}
The round-trip time (RTT) between the two servers is about 30ms, and there is no packet loss. The bandwidth is guaranteed to be 10Mbps, so there shouldn't be any problem theoretically. The SRS logs are also normal, so we suspect there might be compatibility issues somewhere.

xiaoq_bj@126.com, can you send me the mp4 file you are using so that I can reproduce and locate the issue?

TRANS_BY_GPT3

Can I ask if the current compilation is based on SRS 4.0?
I encountered this issue when using the compilation on my end, may I ask what could be the possible cause for it?
I first performed the compilation of SRT and also set the LD_LIBRARY_PATH to /usr/local/lib64.

./configure --with-srt && make
objs/srt/lib/libsrt.a(cryspr-openssl.c.o): In function crysprOpenSSL_AES_CtrCipher': cryspr-openssl.c:(.text+0x62): undefined reference to AES_ctr128_encrypt'
collect2: error: ld returned 1 exit status.

Thank you.

TRANS_BY_GPT3

Just asking, is the current compilation based on srs 4.0?
I encountered this problem while compiling. Can you please let me know what might be causing it?
I first compiled srt and also set export LD_LIBRARY_PATH=/usr/local/lib64.

./configure --with-srt && make
objs/srt/lib/libsrt.a(cryspr-openssl.c.o): In function crysprOpenSSL_AES_CtrCipher': cryspr-openssl.c:(.text+0x62): undefined reference to AES_ctr128_encrypt'
collect2: error: ld returned 1 exit status.

Thank you.

Just use Docker directly, or copy the compiled SRS from Docker to use: https://github.com/ossrs/srs-docker/tree/srt

If you really want to compile it yourself, refer to the compilation script in Docker: https://github.com/ossrs/srs-docker/blob/srt/Dockerfile

TRANS_BY_GPT3

This is because libsrt cannot find the linked openssl. In the SRS project, openssl 1.1.0e is integrated. By default, when compiling with "./configure --with-srt", the integrated openssl is also compiled. However, during the linking process, the library form of ssl cannot be found. One solution is to compile libsrt using the integrated openssl in SRS, and then compile the SRS project using "./configure --with-srt --use-sys-ssl". Another solution is to copy the last error message and add "-lssl -lcrypto" to compile successfully.

TRANS_BY_GPT3

I originally compiled the openssl that srt static library depends on as version 1.0.2, and successfully compiled ffmpeg with added support for srt.

When using PKG_CONFIG_PATH="/ffmpeg/ext-libs/lib/pkgconfig" ./configure --with-srt to compile srs, it gives the following error.
no libsrt, please use srs-docker or build from source #1147 (comment)

Is this also caused by the mismatch of the two OpenSSL versions as mentioned?

TRANS_BY_GPT3

I originally compiled the openssl library that srt depends on as version 1.0.2, and successfully compiled ffmpeg with support for srt.

Using this PKG_CONFIG_PATH="/ffmpeg/ext-libs/lib/pkgconfig" ./configure --with-srt, compile srs.
It reports this.
no libsrt, please use srs-docker or build from source #1147 (comment)

Is this also caused by the mismatch of the two openssl versions as mentioned before?

Make sure to verify the installation path of libsrt. In the configure, check the path of SRT as /usr/local/lib64/libsrt.a.

TRANS_BY_GPT3

Well, manually copying it can be detected.

TRANS_BY_GPT3

Use OBS to push SRT to SRS and then play with ffplay, eg: srt://IP:10080?streamid=#!::h=live/livestream, m=request
Can hear the sound, but the video always does not appear, [also in the local area network]
[h264 @ 000001FD2C9007C0] non-existing PPS 0 referenced 0B f=0/0
Last message repeated 1 times
[h264 @ 000001FD2C9007C0] decode_slice_header error
[h264 @ 000001FD2C9007C0] no frame!
[h264 @ 000001FD2C9007C0] non-existing PPS 0 referenced 0B f=0/0
Last message repeated 1 times
[h264 @ 000001FD2C9007C0] decode_slice_header error
[h264 @ 000001FD2C9007C0] no frame!
[h264 @ 000001FD2C9007C0] non-existing PPS 0 referenced 0B f=0/0
Last message repeated 1 times
[h264 @ 000001FD2C9007C0] decode_slice_header error
[h264 @ 000001FD2C9007C0] no frame!
[h264 @ 000001FD2C9007C0] non-existing PPS 0 referenced 0B f=0/0
Last message repeated 1 times
[h264 @ 000001FD2C9007C0] decode_slice_header error
[h264 @ 000001FD2C9007C0] no frame!
[h264 @ 000001FD2C9007C0] non-existing PPS 0 referenced 0B f=0/0

Similar errors like this, what needs to be adjusted? It seems like there is audio, is there still a problem with forwarding from SRT to SRT currently?

TRANS_BY_GPT3

May I ask if the current compilation is based on SRS 4.0?
I encountered this problem during compilation. Could you please let me know what might have caused it?
I first did the compilation of SRT. I also set the LD_LIBRARY_PATH to /usr/local/lib64.

./configure --with-srt && make
objs/srt/lib/libsrt.a(cryspr-openssl.c.o): In function crysprOpenSSL_AES_CtrCipher': cryspr-openssl.c:(.text+0x62): undefined reference to AES_ctr128_encrypt'
collect2: error: ld returned 1 exit status.

Thank you.

I have also encountered this problem. Have you found a solution?

TRANS_BY_GPT3

May I ask if the current compilation is based on srs 4.0?
I encountered this problem during the compilation. Could you please let me know what could possibly cause this?
I tried compiling srt first and also set the LD_LIBRARY_PATH to /usr/local/lib64.
./configure --with-srt && make
objs/srt/lib/libsrt.a(cryspr-openssl.c.o): In function crysprOpenSSL_AES_CtrCipher': cryspr-openssl.c:(.text+0x62): undefined reference to AES_ctr128_encrypt'
collect2: error: ld returned 1 exit status.
Thank you.

I also encountered this problem. May I ask if you have solved it?

When configuring, add: ./configure --with-srt --use-sys-ssl
Then proceed with make, it worked for me.

TRANS_BY_GPT3

Just asking, is the current compilation based on srs 4.0?
I encountered this problem while using the compilation. Could you please tell me what might have caused it?
I first compiled srt and also set export LD_LIBRARY_PATH=/usr/local/lib64.
./configure --with-srt && make
objs/srt/lib/libsrt.a(cryspr-openssl.c.o): In function crysprOpenSSL_AES_CtrCipher': cryspr-openssl.c:(.text+0x62): undefined reference to AES_ctr128_encrypt'
collect2: error: ld returned 1 exit status.
Thank you.

I also encountered this problem. Have you resolved it?

When configuring, add: ./configure --with-srt --use-sys-ssl
Then proceed with the make command, it worked for me.
Okay, thank you. I tried it and it works fine now. The complex relationship between several SSL versions was the main issue.

TRANS_BY_GPT3

Just asking, is the current compilation based on srs 4.0?
I encountered this problem during compilation, may I ask what might have caused it?
I initially compiled srt. I also did "export LD_LIBRARY_PATH=/usr/local/lib64".
./configure --with-srt && make
objs/srt/lib/libsrt.a(cryspr-openssl.c.o): In function crysprOpenSSL_AES_CtrCipher': cryspr-openssl.c:(.text+0x62): undefined reference to AES_ctr128_encrypt'
collect2: error: ld returned 1 exit status.
Thank you.

Just use Docker directly, or you can copy the compiled SRS from Docker and use it: https://github.com/ossrs/srs-docker/tree/srt

If you really want to compile it yourself, refer to the compilation script in Docker: https://github.com/ossrs/srs-docker/blob/srt/Dockerfile

There are issues with compiling using the Docker environment:

  1. Missing libsrt.so library.
    image

  2. The command to run in the document requires adding a mapping for port 10080:10080/udp, which is used for testing SRT.
    image

TRANS_BY_GPT3

The path for SRT check in the configuration is /usr/local/lib64/libsrt.a.

TRANS_BY_GPT3

If you are a user of Ubuntu 16.04, after manually installing srt, libsrt will be located in /usr/local/lib. Even if you use LD_LIBRARY_PATH to point to the correct path, it won't work. You can manually do $ sudo ln -s lib lib64 in the /usr/local path, and then the compilation will work.

For Ubuntu 16.04 user, after manual srt installation, the libsrt.a is located at /usr/local/lib/ instead of /usr/local/lib64/ as requested by the program, even with LD_LIBRARY_PATH correctly pointed to /usr/local/lib, the configure seems could not work proprely. One of the dirty trick is to go to /usr/local and make the following command: $ sudo ln -s lib lib64 , after that redo the configure && make, it works for me. Hope this would help someone if you have the same issue.

TRANS_BY_GPT3

Under release v4.0, you can run srt and the client can see the video stream. However, there are constant warnings in the console for ffmpeg pushing frequency. What is the issue? Thank you.

20:10:43.628031/ffmpegE:SRT.d: epoll/update: IPE: update struck EID 1 which is NOT SUBSCRIBED to @39381165
20:10:43.648689/ffmpeg
E:SRT.d: epoll/update: IPE: update struck EID 1 which is NOT SUBSCRIBED to @39381165
20:10:43.648996/ffmpeg*E:SRT.d: epoll/update: IPE: update struck EID 1 which is NOT SUBSCRIBED to @39381165

I successfully run srs with srt option, it works, but I've got constant warning message from console where runs ffmpeg loop as below:

20:10:43.628031/ffmpegE:SRT.d: epoll/update: IPE: update struck EID 1 which is NOT SUBSCRIBED to @39381165
20:10:43.648689/ffmpeg
E:SRT.d: epoll/update: IPE: update struck EID 1 which is NOT SUBSCRIBED to @39381165
20:10:43.648996/ffmpeg*E:SRT.d: epoll/update: IPE: update struck EID 1 which is NOT SUBSCRIBED to @39381165

TRANS_BY_GPT3

Use OBS to push SRT to SRS, and then use ffplay to play, for example: srt://IP:10080?streamid=#!::h=live/livestream,m=request
I can hear the sound, but the video does not appear [the same for LAN].
[h264 @ 000001FD2C9007C0] non-existing PPS 0 referenced 0B f=0/0
Last message repeated 1 times
[h264 @ 000001FD2C9007C0] decode_slice_header error
[h264 @ 000001FD2C9007C0] no frame!
[h264 @ 000001FD2C9007C0] non-existing PPS 0 referenced 0B f=0/0
Last message repeated 1 times
[h264 @ 000001FD2C9007C0] decode_slice_header error
[h264 @ 000001FD2C9007C0] no frame!
[h264 @ 000001FD2C9007C0] non-existing PPS 0 referenced 0B f=0/0
Last message repeated 1 times
[h264 @ 000001FD2C9007C0] decode_slice_header error
[h264 @ 000001FD2C9007C0] no frame!
[h264 @ 000001FD2C9007C0] non-existing PPS 0 referenced 0B f=0/0
Last message repeated 1 times
[h264 @ 000001FD2C9007C0] decode_slice_header error
[h264 @ 000001FD2C9007C0] no frame!
[h264 @ 000001FD2C9007C0] non-existing PPS 0 referenced 0B f=0/0

Similar to this error, what needs to be adjusted? It seems that there is audio, is there still a problem with forwarding from SRT to SRT?

What is the source stream for this? Is the video in the source stream h264? If possible, can you provide the source stream to me so that I can reproduce it and help you solve the issue?

TRANS_BY_GPT3

It is possible to run srt under release v4.0. Clients are able to see the video stream. However, there are constant warning alerts in the console where ffmpeg is pushing the frequency. What could be the issue? Thank you

20:10:43.628031/ffmpeg_E:SRT.d: epoll/update: IPE: update struck EID 1 which is NOT SUBSCRIBED to @39381165
20:10:43.648689/ffmpeg_E:SRT.d: epoll/update: IPE: update struck EID 1 which is NOT SUBSCRIBED to @39381165
20:10:43.648996/ffmpeg*E:SRT.d: epoll/update: IPE: update struck EID 1 which is NOT SUBSCRIBED to @39381165

I successfully run srs with srt option, it works, but I've got constant warning message from console where runs ffmpeg loop as below:

20:10:43.628031/ffmpeg_E:SRT.d: epoll/update: IPE: update struck EID 1 which is NOT SUBSCRIBED to @39381165
20:10:43.648689/ffmpeg_E:SRT.d: epoll/update: IPE: update struck EID 1 which is NOT SUBSCRIBED to @39381165
20:10:43.648996/ffmpeg*E:SRT.d: epoll/update: IPE: update struck EID 1 which is NOT SUBSCRIBED to @39381165

Don't worry about it. This is an unnecessary log from the srt protocol. It incorrectly assumes that the custom epoll interface requires at least one fd event. In reality, the number of events can temporarily be set to 0 without any impact.

TRANS_BY_GPT3

Does SRS Forward support SRT streaming forwarding function now?

TRANS_BY_GPT3

Is SRS Forward currently supporting SRT stream forwarding functionality?

Not supported.

TRANS_BY_GPT3

Has the source code for SRT's functionality not been released yet? Why don't I have that feature in the latest code from git?

TRANS_BY_GPT3

Does the latest release 4.0 of SRS Forward support forwarding SRT streams to Nginx?

TRANS_BY_GPT3

Is there a planned support for the forward function of SRT streaming?

In release v4.0, SRT can be run and the client can see the video stream. However, there have been constant warnings in the console where ffmpeg is pushing the frequency. May I ask what the problem is? Thank you.

20:10:43.628031/ffmpeg_E:SRT.d: epoll/update: IPE: update struck EID 1 which is NOT SUBSCRIBED to @39381165
20:10:43.648689/ffmpeg_E:SRT.d: epoll/update: IPE: update struck EID 1 which is NOT SUBSCRIBED to @39381165
20:10:43.648996/ffmpeg*E:SRT.d: epoll/update: IPE: update struck EID 1 which is NOT SUBSCRIBED to @39381165

I successfully run srs with srt option, it works, but I've got constant warning message from console where runs ffmpeg loop as below:

20:10:43.628031/ffmpeg_E:SRT.d: epoll/update: IPE: update struck EID 1 which is NOT SUBSCRIBED to @39381165
20:10:43.648689/ffmpeg_E:SRT.d: epoll/update: IPE: update struck EID 1 which is NOT SUBSCRIBED to @39381165
20:10:43.648996/ffmpeg*E:SRT.d: epoll/update: IPE: update struck EID 1 which is NOT SUBSCRIBED to @39381165

You don't have to worry about it. This is an extra log from SRT that believes at least one fd event is needed in the custom epoll interface, but in reality, the number of events can temporarily be zero without any impact.

Do you plan to support the forwarding function for SRT streams, sir?

TRANS_BY_GPT3

Dear experts, when will the SRS4.0 plan be released? From which version will H.265 support be available?

TRANS_BY_GPT3

Two questions:

  1. The problem of not finding libsrt.
    Solution:
    First, add the environment variable. Secondly, create a pointer.
    export LD_LIBRARY_PATH=/usr/local/lib
    sudo ln -s /urs/local/lib /usr/local/lib64
  2. Problem with encryption function.
    cryspr-openssl.c:(.text+0x15f): undefined reference to `AES_ctr128_encrypt'
    Solution:
    srt/haicrypt
    vi cryspr-openssl.c
    Solution:
    Change the function name at line 121: replace AES_ctr128_encrypt with CRYPTO_ctr128_encrypt.
    After this modification, the program can be compiled and run successfully on Ubuntu.

TRANS_BY_GPT3

Hello, I installed using Docker. Everything was fine until the compilation, where it prompted "./configure: error: invalid option '--with-srt'. Can someone knowledgeable please guide me on specifying the correct path for this?

TRANS_BY_GPT3

Hello, I am using Docker to install. Everything was fine until the compilation step where it is showing the error: "./configure: error: invalid option --with-srt". Could someone please guide me? Do I need to specify a path somewhere?

Hello, I realized that I installed SRS3 so it might not work. Does that mean only SRS4 supports SRT?

TRANS_BY_GPT3

Hello, I installed with Docker, everything was fine until the compilation step where it is showing ./configure: error: invalid option "--with-srt". Can someone please guide me, do I need to specify a path somewhere?

Hello, I realized that I installed SRS3 and that's why it's not working. Can you please tell me if SRT is only supported in SRS4?

Okay, my mistake. SRT is only supported in SRS4. Now let me share my test results. I found that using VMIX for both SRT pushing and pulling works smoothly, but when pushing SRT and pulling RTMP, I often encounter screen glitches. By the way, could you please confirm if the streamID in VMIX should be filled in this format: #!::h=live/livestream,m=publish?

TRANS_BY_GPT3

image
What is the problem?

TRANS_BY_GPT3

image
What is the problem?

go to /srs/auto
open depends file
line 433
python ....
python2 ....
after python 2, add this line
python3 --version >/dev/null 2>&1 && SYS_PYTHON=python3;

youshould make this change before you configure.

TRANS_BY_GPT3

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 - -

WechatIMG1532

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:

WechatIMG365

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:

WechatIMG364

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

WechatIMG1259

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:

WechatIMG367

Using vMix for live streaming, configure as follows:

WechatIMG375

OBS configuration is shown in the following figure:

151642059-8c1bdd74-1c91-4f1b-99f6-fa49f244cb7e

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:

WechatIMG247

Configuration of vmix preview stream:

WechatIMG376

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.

WechatIMG371

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.

WechatIMG1341

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

WechatIMG10998

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

WechatIMG10993

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

WechatIMG368

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

WechatIMG377

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

WechatIMG1185

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

WechatIMG9677

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

WechatIMG378

TRANS_BY_GPT3