Update SRT.

i18n/en-us/docusaurus-plugin-content-docs/current/doc/srt.md

@@ -39,7 +39,9 @@ ffmpeg -re -i ./doc/source.flv -c copy -pes_payload_size 0 -f mpegts \
 
 Open the following page to play the stream (if SRS is not on your local machine, replace localhost with the server IP):
 
+* RTMP(VLC/ffplay): `rtmp://localhost/live/livestream`
 * HLS by SRS player: [http://localhost:8080/live/livestream.flv](http://localhost:8080/players/srs_player.html)
+* SRT(VLC/ffplay): `srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=request`
 
 SRS supports converting SRT to other protocols, which will be described in detail below.
 
@@ -195,6 +197,42 @@ srt_server {
 }
 ```
 
+This section describes how to reduce the latency of SRT, which is relevant to each link. The summary is as follows:
+
+* Pay attention to the client's Ping and CPU, which are easily overlooked but can affect latency.
+* Please use SRS Stack as the server, as it has been adjusted and will not cause additional latency.
+* An increase in RTT will affect latency. Generally, with an RTT of below 60ms, it can be stable at the expected latency.
+* With an RTT of 100ms, latency is approximately 300ms, and with an RTT of 150ms, latency increases to around 430ms.
+* Packet loss will affect quality. With a packet loss rate of over 10%, there will be screen flickering and dropped frames, but it does not affect latency significantly, particularly for audio.
+* Currently, the lowest latency can be achieved by using vmix or Xinxiang to stream SRT and playing it with ffplay, resulting in a latency of around 200ms.
+* When streaming SRT with OBS and playing it with ffplay, the latency is around 350ms.
+
+> Special Note: Based on current tests, the latency ceiling for SRT is 300ms. Although vmix can be set to a 1ms latency, it does not work and the actual latency will only be worse, not better. However, if the network is well maintained, a latency of 300ms is 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 |
+| ---           | ----      |  ---         | ---           |
+| vMix Push | 200ms | 300ms | - |
+| OBS Push | 300ms | - | - |
+| Xinxiang Push (http://www.sinsam.com/) | 230ms | - | 400ms |
+
+Latency involves each link, below are the detailed configurations for each link. The directory is as follows:
+
+* [CPU](https://github.com/ossrs/srs/issues/3464#lagging-cpu) Client CPU can cause latency.
+* [Ping](https://github.com/ossrs/srs/issues/3464#lagging-ping) Client network RTT affects latency.
+* [Encoder](https://github.com/ossrs/srs/issues/3464#lagging-encoder) Configuring encoder for low latency mode.
+* [Server](https://github.com/ossrs/srs/issues/3464#lagging-server) Configuring the server for low latency.
+* [SRT](https://github.com/ossrs/srs/issues/3464#lagging-srt) Special configuration for SRT servers.
+* [Player](https://github.com/ossrs/srs/issues/3464#lagging-player) Configuring the player for low latency.
+* [Benchmark](https://github.com/ossrs/srs/issues/3464#lagging-benchmark) Accurately measuring latency.
+* [Bitrate](https://github.com/ossrs/srs/issues/3464#lagging-bitrate) Impact of different bitrates (0.5 to 6Mbps) on latency.
+* [Network Jitter](https://github.com/ossrs/srs/issues/3464#lagging-jitter) Impact of packet loss and different RTT on latency.
+* [Report](https://github.com/ossrs/srs/issues/3464#lagging-report) Test report.
+
 ## High Quality Mode
 
 If you want the highest quality and can't tolerate even a small chance of screen glitches, but can accept increased latency, consider this configuration.
@@ -295,6 +333,57 @@ In other words, the following two addresses are equivalent:
 * `srt://127.0.0.1:10080`
 * `srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=publish`
 
+## Authentication
+
+For the definition of SRT URLs, please refer to [SRT URL Schema](#srt-url).
+
+Here is a special note on how to include authentication information, see [SRS URL: Token](./rtmp-url-vhost.md#parameters-in-url). 
+If you need to include authentication information such as the secret parameter, you can specify it in the streamid, for example:
+
+```
+streamid=#!::r=live/livestream,secret=xxx
+```
+
+Here is a specific example:
+
+```
+ffmpeg -re -i doc/source.flv -c copy -f mpegts \
+    'srt://127.0.0.1:10080?streamid=#!::r=live/livestream,secret=xxx,m=publish'
+```
+
+The address for forwarding to SRS would be like this:
+
+```
+rtmp://127.0.0.1:1935/live/livestream?secret=xxx
+```
+
+## SRT Encoder
+
+SRT Encoder is an encoder based on the SRT adaptive bitrate. It predicts low-latency outbound bandwidth based on information such as RTT, maxBw, and inflight in the SRT protocol, dynamically adjusting the encoding bitrate to be based on the network outbound bandwidth.
+
+GitHub address: [runner365/srt_encoder](https://github.com/runner365/srt_encoder)
+
+Based on the basic congestion control algorithm of BBR, the encoder predicts the state machine of the encoding bitrate (keep, increase, decrease) based on the minRTT, maxBw, and current inflight within one cycle (1~2 seconds).
+
+Note:
+1) This example is just a basic BBR algorithm example, and users can implement the interfaces in the CongestionCtrlI class to improve the BBR algorithm.
+2) SRT is still an evolving protocol, and the accuracy of its congestion control and external parameter updates is also improving.
+
+Easy to use, after compiling, you can directly use the ffmpeg command line.
+
+## Coroutine Native SRT
+
+How does SRS implement SRT? Based on coroutine-based SRT architecture, we need to adapt it to ST as SRT has its own IO scheduling, so that we can achieve the best maintainability.
+
+* For the specific code submission, please refer to [#3010](https://github.com/ossrs/srs/pull/3010) or [1af30dea](https://github.com/ossrs/srs/commit/1af30dea324d0f1729aabd22536ea62e03497d7d)
+
+> Note: Please note that the SRT in SRS 4.0 is a non-ST architecture, and it is implemented by launching a separate thread, which may not have the same level of maintainability as the native ST coroutine architecture.
+
+## Q&A
+
+1. Does SRS support forwarding SRT streams to Nginx?
+
+> Yes, it is supported. You can use OBS/FFmpeg to push SRT streams to SRS, and SRS will convert the SRT stream into the RTMP protocol. Then, you can convert RTMP to HLS, FLV, WebRTC, and also forward the RTMP stream to Nginx.
 
 ![](https://ossrs.net/gif/v1/sls.gif?site=ossrs.net&path=/lts/doc/en/v6/srt)
 

i18n/zh-cn/docusaurus-plugin-content-docs/current/doc/srt.md

@@ -40,7 +40,9 @@ ffmpeg -re -i ./doc/source.flv -c copy -pes_payload_size 0 -f mpegts \
 
 打开下面的页面播放流（若SRS不在本机，请将localhost更换成服务器IP）:
 
+* RTMP(VLC/ffplay): `rtmp://localhost/live/livestream`
 * HLS by SRS player: [http://localhost:8080/live/livestream.flv](http://localhost:8080/players/srs_player.html)
+* SRT(VLC/ffplay): `srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=request`
 
 SRS支持将SRT转换成其他协议，下面会详细描述。
 
@@ -197,6 +199,42 @@ srt_server {
 }
 ```
 
+本节介绍如何降低SRT的延迟，与每个环节都有关。总结如下：
+
+* 注意客户端的Ping和CPU，这些容易被忽视，但会影响延迟。
+* 请使用LightHouse SRS作为服务器，因为它已经调整过，不会造成额外的延迟。
+* RTT的增加会影响延迟。通常，RTT低于60ms时，可以稳定在预期延迟。
+* RTT为100ms时，延迟约为300ms；RTT为150ms时，延迟增加到约430ms。
+* 丢包会影响画质。丢包率超过10%时，会出现画面闪烁和丢帧，但对延迟影响不大，尤其是音频。
+* 目前，使用vmix或芯象推送SRT并用ffplay播放，可实现最低约200ms的延迟。
+* 使用OBS推送SRT并用ffplay播放时，延迟约为350ms。
+
+特别提示：根据目前的测试，SRT的延迟上限为300ms。虽然vmix可以设置为1ms延迟，但实际上并不起作用，实际延迟只会更糟，而不是更好。但是，如果网络维护得好，300ms的延迟是足够的。
+
+超高清、超低延迟SRT直播推荐方案：
+
+* 推流：芯象（230ms）、vMix（200ms）、OBS（300ms）。
+* 播放：ffplay（200ms）、vMix（230ms）、芯象（400ms）。
+
+| - | ffplay | vMix播放 | 芯象播放 |
+| ---           | ----      |  ---         | ---           |
+| vMix推送 | 200ms | 300ms | - |
+| OBS推送 | 300ms | - | - |
+| 芯象推送(http://www.sinsam.com/) | 230ms - | 400ms |
+
+延迟涉及每个环节，以下是每个环节的详细配置。目录如下：
+
+* [CPU](https://github.com/ossrs/srs/issues/3464#lagging-cpu) 客户端CPU会导致延迟。
+* [Ping](https://github.com/ossrs/srs/issues/3464#lagging-ping) 客户端网络RTT影响延迟。
+* [编码器](https://github.com/ossrs/srs/issues/3464#lagging-encoder) 配置编码器低延迟模式。
+* [服务器](https://github.com/ossrs/srs/issues/3464#lagging-server) 配置服务器低延迟。
+* [SRT](https://github.com/ossrs/srs/issues/3464#lagging-srt) SRT服务器特殊配置。
+* [播放器](https://github.com/ossrs/srs/issues/3464#lagging-player) 配置播放器低延迟。
+* [基准测试](https://github.com/ossrs/srs/issues/3464#lagging-benchmark) 准确测量延迟。
+* [码率](https://github.com/ossrs/srs/issues/3464#lagging-bitrate) 不同码率（0.5至6Mbps）对延迟的影响。
+* [网络抖动](https://github.com/ossrs/srs/issues/3464#lagging-jitter) 丢包和不同RTT对延迟的影响。
+* [报告](https://github.com/ossrs/srs/issues/3464#lagging-report) 测试报告。
+
 ## High Quality Mode
 
 若你希望最高质量，极小概率花屏也不能容忍，可以容忍延迟变大，则可以考虑这个配置。
@@ -302,5 +340,57 @@ streamid默认为`#!::r=live/livestream,m=publish`。
 * `srt://127.0.0.1:10080`
 * `srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=publish`
 
+## Authentication
+
+关于SRT URL的定义，请参考[SRT URL Schema](#srt-url)。
+
+这里有一个特别说明，如何包含认证信息，参考[SRS URL: Token](./rtmp-url-vhost.md#parameters-in-url)。
+如果您需要包含诸如密钥参数的认证信息，您可以在streamid中指定，例如：
+
+```
+streamid=#!::r=live/livestream,secret=xxx
+```
+
+这是一个具体的例子：
+
+```
+ffmpeg -re -i doc/source.flv -c copy -f mpegts \
+    'srt://127.0.0.1:10080?streamid=#!::r=live/livestream,secret=xxx,m=publish'
+```
+
+对应的RTMP的地址将如下所示：
+
+```
+rtmp://127.0.0.1:1935/live/livestream?secret=xxx
+```
+
+## SRT Encoder
+
+SRT编码器是基于SRT自适应比特率的编码器。它根据SRT协议中的RTT、maxBw和inflight等信息预测低延迟的出站带宽，动态调整编码比特率以便适配网络出口带宽。
+
+GitHub地址：[runner365/srt_encoder](https://github.com/runner365/srt_encoder)
+
+基于BBR的基本拥塞控制算法，编码器根据一个周期（1~2秒）内的minRTT、maxBw和当前inflight预测编码比特率的状态机（保持、增加、减少）。
+
+注意：
+1) 这个例子只是一个基本的BBR算法示例，用户可以实现CongestionCtrlI类中的接口来改进BBR算法。
+2) SRT仍然是一个不断发展的协议，其拥塞控制和外部参数更新的准确性也在不断提高。
+
+使用简单，编译后，您可以直接使用ffmpeg命令行。
+
+## Coroutine Native SRT
+
+SRS如何实现SRT？基于协程的SRT架构，我们需要将其适配到ST，因为SRT有自己的IO调度，这样我们才能实现最佳的可维护性。
+
+* 关于具体的代码提交，请参考[#3010](https://github.com/ossrs/srs/pull/3010)或[1af30dea](https://github.com/ossrs/srs/commit/1af30dea324d0f1729aabd22536ea62e03497d7d)
+
+> 注意：请注意，SRS 4.0中的SRT是非ST架构，它是通过启动一个单独的线程来实现的，可能没有原生ST协程架构的可维护性。
+
+## Q&A
+
+1. SRS是否支持将SRT流转发到Nginx？
+
+> 是的，支持。您可以使用OBS/FFmpeg将SRT流推送到SRS，SRS将SRT流转换为RTMP协议。然后，您可以将RTMP转换为HLS、FLV、WebRTC，并将RTMP流转发到Nginx。
+
 ![](https://ossrs.net/gif/v1/sls.gif?site=ossrs.net&path=/lts/doc/zh/v6/srt)
 

i18n/zh-cn/docusaurus-plugin-content-docs/version-5.0/doc/srt.md

@@ -40,7 +40,9 @@ ffmpeg -re -i ./doc/source.flv -c copy -pes_payload_size 0 -f mpegts \
 
 打开下面的页面播放流（若SRS不在本机，请将localhost更换成服务器IP）:
 
+* RTMP(VLC/ffplay): `rtmp://localhost/live/livestream`
 * HLS by SRS player: [http://localhost:8080/live/livestream.flv](http://localhost:8080/players/srs_player.html)
+* SRT(VLC/ffplay): `srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=request`
 
 SRS支持将SRT转换成其他协议，下面会详细描述。
 
@@ -197,6 +199,42 @@ srt_server {
 }
 ```
 
+本节介绍如何降低SRT的延迟，与每个环节都有关。总结如下：
+
+* 注意客户端的Ping和CPU，这些容易被忽视，但会影响延迟。
+* 请使用LightHouse SRS作为服务器，因为它已经调整过，不会造成额外的延迟。
+* RTT的增加会影响延迟。通常，RTT低于60ms时，可以稳定在预期延迟。
+* RTT为100ms时，延迟约为300ms；RTT为150ms时，延迟增加到约430ms。
+* 丢包会影响画质。丢包率超过10%时，会出现画面闪烁和丢帧，但对延迟影响不大，尤其是音频。
+* 目前，使用vmix或芯象推送SRT并用ffplay播放，可实现最低约200ms的延迟。
+* 使用OBS推送SRT并用ffplay播放时，延迟约为350ms。
+
+特别提示：根据目前的测试，SRT的延迟上限为300ms。虽然vmix可以设置为1ms延迟，但实际上并不起作用，实际延迟只会更糟，而不是更好。但是，如果网络维护得好，300ms的延迟是足够的。
+
+超高清、超低延迟SRT直播推荐方案：
+
+* 推流：芯象（230ms）、vMix（200ms）、OBS（300ms）。
+* 播放：ffplay（200ms）、vMix（230ms）、芯象（400ms）。
+
+| - | ffplay | vMix播放 | 芯象播放 |
+| ---           | ----      |  ---         | ---           |
+| vMix推送 | 200ms | 300ms | - |
+| OBS推送 | 300ms | - | - |
+| 芯象推送(http://www.sinsam.com/) | 230ms - | 400ms |
+
+延迟涉及每个环节，以下是每个环节的详细配置。目录如下：
+
+* [CPU](https://github.com/ossrs/srs/issues/3464#lagging-cpu) 客户端CPU会导致延迟。
+* [Ping](https://github.com/ossrs/srs/issues/3464#lagging-ping) 客户端网络RTT影响延迟。
+* [编码器](https://github.com/ossrs/srs/issues/3464#lagging-encoder) 配置编码器低延迟模式。
+* [服务器](https://github.com/ossrs/srs/issues/3464#lagging-server) 配置服务器低延迟。
+* [SRT](https://github.com/ossrs/srs/issues/3464#lagging-srt) SRT服务器特殊配置。
+* [播放器](https://github.com/ossrs/srs/issues/3464#lagging-player) 配置播放器低延迟。
+* [基准测试](https://github.com/ossrs/srs/issues/3464#lagging-benchmark) 准确测量延迟。
+* [码率](https://github.com/ossrs/srs/issues/3464#lagging-bitrate) 不同码率（0.5至6Mbps）对延迟的影响。
+* [网络抖动](https://github.com/ossrs/srs/issues/3464#lagging-jitter) 丢包和不同RTT对延迟的影响。
+* [报告](https://github.com/ossrs/srs/issues/3464#lagging-report) 测试报告。
+
 ## High Quality Mode
 
 若你希望最高质量，极小概率花屏也不能容忍，可以容忍延迟变大，则可以考虑这个配置。
@@ -302,5 +340,57 @@ streamid默认为`#!::r=live/livestream,m=publish`。
 * `srt://127.0.0.1:10080`
 * `srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=publish`
 
+## Authentication
+
+关于SRT URL的定义，请参考[SRT URL Schema](#srt-url)。
+
+这里有一个特别说明，如何包含认证信息，参考[SRS URL: Token](./rtmp-url-vhost.md#parameters-in-url)。
+如果您需要包含诸如密钥参数的认证信息，您可以在streamid中指定，例如：
+
+```
+streamid=#!::r=live/livestream,secret=xxx
+```
+
+这是一个具体的例子：
+
+```
+ffmpeg -re -i doc/source.flv -c copy -f mpegts \
+    'srt://127.0.0.1:10080?streamid=#!::r=live/livestream,secret=xxx,m=publish'
+```
+
+对应的RTMP的地址将如下所示：
+
+```
+rtmp://127.0.0.1:1935/live/livestream?secret=xxx
+```
+
+## SRT Encoder
+
+SRT编码器是基于SRT自适应比特率的编码器。它根据SRT协议中的RTT、maxBw和inflight等信息预测低延迟的出站带宽，动态调整编码比特率以便适配网络出口带宽。
+
+GitHub地址：[runner365/srt_encoder](https://github.com/runner365/srt_encoder)
+
+基于BBR的基本拥塞控制算法，编码器根据一个周期（1~2秒）内的minRTT、maxBw和当前inflight预测编码比特率的状态机（保持、增加、减少）。
+
+注意：
+1) 这个例子只是一个基本的BBR算法示例，用户可以实现CongestionCtrlI类中的接口来改进BBR算法。
+2) SRT仍然是一个不断发展的协议，其拥塞控制和外部参数更新的准确性也在不断提高。
+
+使用简单，编译后，您可以直接使用ffmpeg命令行。
+
+## Coroutine Native SRT
+
+SRS如何实现SRT？基于协程的SRT架构，我们需要将其适配到ST，因为SRT有自己的IO调度，这样我们才能实现最佳的可维护性。
+
+* 关于具体的代码提交，请参考[#3010](https://github.com/ossrs/srs/pull/3010)或[1af30dea](https://github.com/ossrs/srs/commit/1af30dea324d0f1729aabd22536ea62e03497d7d)
+
+> 注意：请注意，SRS 4.0中的SRT是非ST架构，它是通过启动一个单独的线程来实现的，可能没有原生ST协程架构的可维护性。
+
+## Q&A
+
+1. SRS是否支持将SRT流转发到Nginx？
+
+> 是的，支持。您可以使用OBS/FFmpeg将SRT流推送到SRS，SRS将SRT流转换为RTMP协议。然后，您可以将RTMP转换为HLS、FLV、WebRTC，并将RTMP流转发到Nginx。
+
 ![](https://ossrs.net/gif/v1/sls.gif?site=ossrs.net&path=/lts/doc/zh/v5/srt)