Skip to content

Commit 9facffd

Browse files
duiniuluantanqinduiniuluantanqin
authored
DOC: rtsp (#83)
* DOC: rtsp * update * update * update faq * update SDP * update * big update * init english version * update
1 parent a643dda commit 9facffd

File tree

4 files changed

+262
-2
lines changed

4 files changed

+262
-2
lines changed

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

Lines changed: 134 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,134 @@
1+
---
2+
title: RTSP
3+
sidebar_label: RTSP
4+
hide_title: false
5+
hide_table_of_contents: false
6+
---
7+
8+
# RTSP
9+
10+
RTSP is a well-established protocol with nearly 30 years of history. In the security surveillance industry, many companies have implemented their own RTSP servers, but they rarely open-source them and often add proprietary extensions. While RTMP servers are readily available, finding a good RTSP server is much more challenging.
11+
12+
SRS initially supported the RTSP protocol in version 2.0, but only for publishing streams (ANNOUNCE → SETUP → RECORD) without playback capabilities (DESCRIBE → SETUP → PLAY). In practice, many traditional client/server applications, decoders, embedded devices, and even the latest AI vision detection systems still prefer RTSP as their primary playback protocol.
13+
14+
This version reuses some protocol parsing code from version 2.0, removes the publishing functionality, adds playback support, and only works with TCP transport.
15+
16+
## Usage
17+
18+
First, compile and start SRS (ensure you're using version `7.0.47+`):
19+
20+
```bash
21+
cd srs/trunk && ./configure --rtsp=on && make
22+
./objs/srs -c conf/rtsp.conf
23+
```
24+
> You must enable RTSP with `--rtsp=on` during compilation (disabled by default).
25+
26+
Then, publish a stream using RTMP:
27+
28+
```bash
29+
ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://localhost/live/livestream
30+
```
31+
32+
Finally, play the stream using RTSP (note: only TCP transport is supported):
33+
34+
```bash
35+
ffplay -rtsp_transport tcp -i rtsp://localhost:8554/live/livestream
36+
```
37+
38+
## Config
39+
40+
Reference `conf/rtsp.conf`:
41+
42+
```bash
43+
rtsp_server {
44+
enabled on;
45+
listen 8554;
46+
}
47+
48+
vhost __defaultVhost__ {
49+
rtsp {
50+
enabled on;
51+
rtmp_to_rtsp on;
52+
}
53+
}
54+
```
55+
56+
## Port
57+
58+
The RTSP protocol consists of two parts: signaling (DESCRIBE/SETUP/PLAY, etc.) and media transport (RTP/RTCP packets).
59+
60+
Signaling must use TCP protocol. The default port is `554`, but some systems require `root` privileges to listen on this port, so we've changed it to `8554`.
61+
62+
After successful signaling, media transport begins. There are two methods: TCP or UDP. TCP reuses the socket connection established during signaling. UDP transport is not supported because it requires port allocation. If you try to use UDP as transport, it will fail:
63+
64+
```bash
65+
ffplay -rtsp_transport udp -i rtsp://localhost:8554/live/livestream
66+
67+
[rtsp @ 0x7fbc99a14880] method SETUP failed: 461 Unsupported Transport
68+
rtsp://localhost:8554/live/livestream: Protocol not supported
69+
70+
[2025-07-05 21:30:52.738][WARN][14916][7d7gf623][35] RTSP: setup failed: code=2057
71+
(RtspTransportNotSupported) : UDP transport not supported, only TCP/interleaved mode is supported
72+
```
73+
74+
There are currently no plans to support UDP transport. In practice, UDP is rarely used; the vast majority of RTSP traffic uses TCP.
75+
76+
## RTP
77+
78+
When using TCP transport, each RTP/RTCP packet has an additional 4-byte header. The first byte is fixed at `0x24`, followed by a 1-byte channel identifier, followed by a 2-byte RTP packet length. See section 10.12 `Embedded (Interleaved) Binary Data` in `RFC2326`.
79+
80+
## Play Before Publish
81+
82+
RTSP supports audio with AAC and OPUS codecs, which is significantly different from RTMP or WebRTC.
83+
84+
RTSP uses commands to exchange SDP and specify the audio track to play, unlike WHEP or HTTP-FLV, which use the query string of the URL. RTSP depends on the player’s behavior, making it very difficult to use and describe.
85+
86+
Considering the feature that allows playing the stream before publishing it, it requires generating some default parameters in the SDP. For OPUS, the sample rate is 48 kHz with 2 channels, while AAC is more complex, especially regarding the sample rate, which may be 44.1 kHz, 32 kHz, or 48 kHz.
87+
88+
Therefore, for RTSP, we cannot support play-then-publish. Instead, there must already be a stream when playing it, so that the audio codec is determined.
89+
90+
## Opus Codec
91+
92+
No Opus codec support for RTSP, because for RTC2RTSP, it always converts RTC to RTMP frames, then converts them to RTSP packets. Therefore, the audio codec is always AAC after converting RTC to RTMP.
93+
94+
This means the bridge architecture needs some changes. We need a new bridge that binds to the target protocol. For example, RTC2RTMP converts the audio codec, but RTC2RTSP keeps the original audio codec.
95+
96+
Furthermore, the RTC2RTMP bridge should also support bypassing the Opus codec if we use enhanced-RTMP, which supports the Opus audio codec. I think it should be configurable to either transcode or bypass the audio codec. However, this is not relevant to RTSP.
97+
98+
## Architecture
99+
100+
For the RTSP protocol parsing, we copied code from version 3.0, removed SDP, RTP, and publishing-related code, keeping only the essential `SrsRtspRequest` and `SrsRtspResponse` for handling requests and responses. We only process five methods: `OPTIONS`, `DESCRIBE`, `SETUP`, `PLAY`, and `TEARDOWN`. This is sufficient for RTSP playback.
101+
102+
For the business logic, `SrsRtspConnection` handles client connections and protocol interactions, `SrsRtspPlayStream` consumes data from `SrsRtspSource`, `SrsRtspSource` manages multiple `SrsRtspConsumer` instances and distributes RTP packets, and finally `SrsRtspSendTrack` sends audio and video data to clients.
103+
104+
## Testing
105+
106+
### Unit Test
107+
108+
```bash
109+
./configure --utest=on & make utest
110+
./objs/srs_utest
111+
```
112+
113+
### Regression Test
114+
115+
```bash
116+
cd srs/trunk/3rdparty/srs-bench
117+
go test ./srs -mod=vendor -v -count=1 -run=TestRtmpPublish_RtspPlay
118+
```
119+
> Note: You need to start SRS before running regression tests.
120+
121+
### BlackBox Test
122+
123+
```bash
124+
cd srs/trunk/3rdparty/srs-bench
125+
go test ./blackbox -mod=vendor -v -count=1 -run=TestFast_RtmpPublish_RtspPlay_Basic
126+
```
127+
128+
## TODO
129+
130+
The current version implements only basic functionality. Additional features like authentication, redirection, and RTCP will be planned according to actual needs, possibly in the near future.
131+
132+
## References
133+
134+
- [rfc2326-1998-rtsp.pdf](https://ossrs.net/lts/zh-cn/assets/files/rfc2326-1998-rtsp-12b5cccfcac4f911bfab96c8f57b0bf9.pdf)

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

Lines changed: 125 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,125 @@
1+
---
2+
title: RTSP
3+
sidebar_label: RTSP
4+
hide_title: false
5+
hide_table_of_contents: false
6+
---
7+
8+
# RTSP
9+
10+
RTSP是很古老的协议，已经有接近30年的历史。在安防行业，几乎每家公司都自己实现了一个RTSP服务器，但他们都不喜欢开源，还喜欢加很多私有的东西在里面。在市面上，你随便就能找到一个RTMP服务器，却很难找到一个RTSP服务器。
11+
12+
SRS最早在2.0版本就已经支持RTSP协议，但只有推流（ANNOUNCE → SETUP → RECORD），而没有拉流（DESCRIBE → SETUP → PLAY）。实际上，很多传统的C/S架构的客户端、解码器、嵌入式设备，以及最新的AI视觉检测等，首选播放协议仍然RTSP。
13+
14+
这个版本，复用了2.0的协议解析的部分代码，删除推流，新增拉流，仅支持TCP方式。
15+
16+
## Usage
17+
18+
首先，编译和启动SRS，请确认版本为`7.0.47+`：
19+
20+
```bash
21+
cd srs/trunk && ./configure --rtsp=on && make
22+
./objs/srs -c conf/rtsp.conf
23+
```
24+
> 编译时必须开启`--rtsp=on`（默认关闭）。
25+
26+
然后，使用RTMP协议推流
27+
28+
```bash
29+
ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://localhost/live/livestream
30+
```
31+
32+
最后，使用RTSP协议拉流，注意：仅支持TCP方式
33+
34+
```bash
35+
ffplay -rtsp_transport tcp -i rtsp://localhost:8554/live/livestream
36+
```
37+
38+
## Config
39+
40+
参考`conf/rtsp.conf`
41+
42+
```bash
43+
rtsp_server {
44+
enabled on;
45+
listen 8554;
46+
}
47+
48+
vhost __defaultVhost__ {
49+
rtsp {
50+
enabled on;
51+
rtmp_to_rtsp on;
52+
}
53+
}
54+
```
55+
56+
## Port
57+
58+
RTSP协议分为2个部分，1个是信令交互，即DESCRIBE/SETUP/PLAY等；1个是媒体传输，即RTP/RTCP包发送。
59+
60+
信令交互必须是TCP协议，默认端口是`554`，某些系统需要`root`权限才能监听，所以这里改成了`8554`。
61+
62+
交互成功后开始媒体传输，有2种方式：TCP或UDP，TCP方式直接复用交互时建立的Socket链接。由于UDP需要分配端口，所以不支持通过UDP传输媒体流。如果您尝试使用UDP作为传输，则会失败：
63+
64+
```bash
65+
ffplay -rtsp_transport udp -i rtsp://localhost:8554/live/livestream
66+
67+
[rtsp @ 0x7fbc99a14880] method SETUP failed: 461 Unsupported Transport
68+
rtsp://localhost:8554/live/livestream: Protocol not supported
69+
70+
[2025-07-05 21:30:52.738][WARN][14916][7d7gf623][35] RTSP: setup failed: code=2057
71+
(RtspTransportNotSupported) : UDP transport not supported, only TCP/interleaved mode is supported
72+
```
73+
74+
目前没有计划支持 UDP传输。在实际应用中，UDP很少使用；绝大多数RTSP流量都使用TCP。
75+
76+
## Rtp
77+
78+
TCP传输时，每个RTP/RTCP包前面有额外的4个字节，第1个字节是固定的`0x24`，后跟1个字节通道标识符，后跟2个字节的RTP包长度，参考`RFC2326`中的第10.12小节`Embedded (Interleaved) Binary Data`。
79+
80+
## Play Before Publish
81+
82+
RTSP协议在处理音频编码方面与RTMP和WebRTC有明显区别。由于RTSP需要通过SDP交换来确定音频轨道参数，而不同编码格式（如OPUS和AAC）的参数差异较大，因此无法支持先播放后推流的功能。播放RTSP流时，必须已经有流存在，这样才能确定正确的音频编码参数。
83+
84+
## Opus Codec
85+
86+
当前RTSP不支持Opus编码，主要是因为在RTC转RTSP的过程中，音频会先转为RTMP格式（只支持AAC）。要支持Opus，需要调整桥接架构，让RTC2RTSP能够保留原始音频编码，而不是经过RTMP转换。虽然enhanced-RTMP已支持Opus，但这需要额外的适配工作。
87+
88+
## Architecture
89+
90+
RTSP协议解析部分，拷贝了原来3.0的代码，删除了SDP和RTP以及推流相关的一些代码，只保留关键的`SrsRtspRequest`和`SrsRtspResponse`用于处理请求和相应，并且只处理`OPTIONS`、`DESCRIBE`、`SETUP`、`PLAY`、`TEARDOWN`这5个方法。对于RTSP播放，这足够了。
91+
92+
业务部分，`SrsRtspConnection`负责处理客户端连接和协议交互，通过`SrsRtspPlayStream`从`SrsRtspSource`消费数据，`SrsRtspSource`管理多个`SrsRtspConsumer`并分发RTP包，最终通过`SrsRtspSendTrack`将音视频数据发送给客户端。
93+
94+
## Test
95+
96+
### Unit Test
97+
98+
```bash
99+
./configure --utest=on & make utest
100+
./objs/srs_utest
101+
```
102+
103+
### Regression Test
104+
105+
```bash
106+
cd srs/trunk/3rdparty/srs-bench
107+
go test ./srs -mod=vendor -v -count=1 -run=TestRtmpPublish_RtspPlay
108+
```
109+
> 注意：回归测试需要先启动SRS
110+
111+
### BlackBox Test
112+
113+
```bash
114+
cd srs/trunk/3rdparty/srs-bench
115+
go test ./blackbox -mod=vendor -v -count=1 -run=TestFast_RtmpPublish_RtspPlay_Basic
116+
```
117+
118+
## TODO
119+
120+
目前的版本，只是实现了一个基本功能，其他比如鉴权、重定向、RTCP等，根据实际需要再做计划，或许就在不久的将来。
121+
122+
123+
## Refer
124+
125+
- [rfc2326-1998-rtsp.pdf](https://ossrs.net/lts/zh-cn/assets/files/rfc2326-1998-rtsp-12b5cccfcac4f911bfab96c8f57b0bf9.pdf)

‎i18n/zh-cn/docusaurus-plugin-content-pages/faq.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -194,7 +194,7 @@
194194
### [RTSP](#rtsp)
195195
* `RTSP`：RTSP推流，RTSP服务器，RTSP播放等
196196
> 1. SRS支持用Ingest拉RTSP，不支持推RTSP流到SRS，这不是正确的用法，详细原因请参考 [#2304](https://github.com/ossrs/srs/issues/2304) 。
197-
> 1. 当然RTSP服务器，RTSP播放，更加不会支持，参考 [#476](https://github.com/ossrs/srs/issues/476)
197+
> 1. ~~当然RTSP服务器，RTSP播放，更加不会支持，参考 [#476](https://github.com/ossrs/srs/issues/476)~~ 已经支持RTSP播放，参考 [#4333](https://github.com/ossrs/srs/pull/4333)
198198
> 1. 如果你需要非常多比如1万路摄像头接入，那么用FFmpeg可能会比较费劲，这么大规模的业务，比较推荐的方案是自己用ST+SRS的代码，实现一个拉RTSP转发的服务器。
199199
* `Browser RTSP`: 如何使用浏览器播放RTSP等
200200
> 1. H5如何播放RTSP流，FFmpeg拉RTSP流，如何降低延迟，参考[链接](https://stackoverflow.com/a/70400665/17679565)

‎sidebars.json

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -40,7 +40,8 @@
4040
"doc/webrtc",
4141
"doc/flv",
4242
"doc/srt",
43-
"doc/gb28181"
43+
"doc/gb28181",
44+
"doc/rtsp"
4445
]
4546
},
4647
{

0 commit comments

Comments
 (0)