GB28181: 5.0-a0 version TCP transmission has a delay of 3 seconds more than srs-gb28181 UDP transmission.

[abigailcg]

1. SRS Version: 5.0-a0

2. SRS Log: None, can transmit normally, just the delay is too long.

3. SRS Config:
   gb28181.conf
   System environment: CentOS 7

4. Operation Steps
   a. Use the dev version of srs-gb28181, with the configuration file push.gb28181.conf. Then configure the access to the Hikvision camera on the 28181 platform, using UDP as the transmission protocol and GB/T28181-2016 as the protocol version. When playing the RTC video stream, a delay of approximately 1 second is observed between the video stream and the camera.
   b. Recently, it was discovered that SRS has released version 5.0, which supports 28181. Therefore, the latest version 5.0-a0 was downloaded and compiled. The gb28181.conf file was configured, and the same camera on the 28181 platform was accessed. TCP was used as the transmission protocol, with the same protocol version. TCP acceleration was enabled, and the camera was restarted for safety. When playing the RTC video stream, a delay of 4 seconds is observed between the video stream and the camera, which is 3 seconds more than the UDP method.
   c. Following the instructions in the gb28181.conf configuration file, according to https://ossrs.net/lts/zh-cn/docs/v5/doc/low-latency, low-latency configuration was added. SRS was restarted, but there was no improvement in the delay.
   d. HLS was disabled, and SRS was restarted, but the delay remained unchanged.
   e. The original push.gb28181.conf configuration was used directly, and SRS was restarted, but the delay remained unchanged.
   f. If the camera platform cannot register successfully using UDP as the transmission protocol, and if version 5.0-a0 does not support UDP transmission, how can the delay of TCP transmission be reduced?

5. Expected Result
   Reduce the delay when accessing the gb28181 platform using TCP.

TRANS_BY_GPT3

[winlinvip]

5.0-a0 supports GB streaming and WebRTC viewing. The latency will be relatively low, you can test how many seconds it is.

PS: On the public network, UDP transmission of srs-gb28181 is unreliable (no packet retransmission or FEC), so it cannot be used online, even if the latency is lower.

TRANS_BY_GPT3

[abigailcg]

5.0-a0 supports GB streaming and WebRTC viewing. The latency for WebRTC is relatively low, you can test how many seconds it is.
For WebRTC viewing, the TCP delay is 4 seconds, while the original version's UDP delay is 1 second.

TRANS_BY_GPT3

[winlinvip]

I tested the latency and it is 300ms, refer to #3176 (comment)

Using the default configuration as follows:

• Stream type: Substream
• Video type: Composite stream
• Resolution: 640x480
• Bitrate type: Variable bitrate
• Image quality: Medium
• Video frame rate: 25fps
• Bitrate limit: 1024Kbps
• Video encoding: H.264
• Encoding complexity: Medium
• I-frame interval: 50
• SVC: Disabled
• Platform access protocol: GB/T28181-2016
• Platform transmission protocol: TCP, which means pushing the stream to SRS via GB/TCP
• Viewing: WebRTC(UDP)
• SRS version: v5.0.100
• Camera and server: Local network
• Delay: 358ms

It is not necessarily the case that using TCP for GB results in high latency. You can investigate in detail to find out the cause.

1. First, you switch to the internal network, where GB and SRS are on the same network, and observe the latency.
2. Reduce the bitrate and resolution, collect data from the server, and check if the bandwidth and packet loss are normal.
3. Reduce the frame rate, encoding complexity, and GOP, and observe the latency.

Latency is a comprehensive capability, and it is not necessarily high for TCP and low for UDP.

TRANS_BY_GPT3

[abigailcg]

After changing to the sub-stream with a resolution of 704x576, the delay is indeed 300ms.

TRANS_BY_GPT3