PUSH RTSP is removed, does not support RTSP streaming

winlinvip commented 3 years ago

Push RTSP to SRS is removed by https://github.com/ossrs/srs/commit/2fa5a0bee8c950f669ff3c6b22496eb40becc412

Regarding RTSP, let's start with the conclusion: SRS does not directly support RTSP. The existing feature of pushing RTSP to SRS will be marked as deprecated and eventually removed. SRS can use Ingester (FFmpeg) to pull RTSP streams and convert them to RTMP before pushing them to SRS. However, this functionality is actually supported by FFmpeg.

Wikis: v2_EN_Streamer, v2_CN_Streamer, v3_EN_Streamer, v3_CN_Streamer, v4_EN_Streamer, v4_CN_Streamer

Discussion: From the perspective of media transmission, why do IPCs (Internet Protocol Cameras) support different methods for GB (Great Britain) and RTSP? One method is to pull the stream from the IPC using RTSP, while the other is for the IPC to push the stream out using GB28181.

Mino: It seems to be for network penetration. The advantage of the national standard is network penetration and cascading.
Yang Jie: Pulling the RTSP stream directly from the IPC doesn't work over the internet.
Xiaochun San Yue: GB can actively push the stream out, it has an active connection. RTSP connection is passive, and that's the main difference.
Jiang Linchun: I also think the core difference is between passive and active. RTSP can only passively accept requests, while 28181 solves the controlled active connection, penetration, and cascading issues through signaling control and RTP mode. At the same time, the extension capabilities defined by GB28181 fully consider various industries (public security, transportation, security, etc.) and scenarios, including details like variable-speed playback, voice broadcasting, etc. The video stream negotiation control of 28181 is just one feature; otherwise, wouldn't ONVIF be enough?
Chen Haibo: Yes, 1. The server cannot actively connect to the IPC, 2. The IPC itself doesn't know where to push the stream. Using the GB protocol, the IPC actively registers with the server and maintains a long connection with it. This allows the server to control the IPC at any time and tell it where to push the stream, solving the network issues of RTSP.
Zhang Peng: The introduction of 28181 is for the industry and the national unified network platform. The national standard platform uses the three levels of province, city, and county, and there may also be industry management platforms and government agencies (ZF, GA, etc.) calling it. Furthermore, the introduction of 28181 also provides a way for small and medium-sized manufacturers; otherwise, they would be completely monopolized by large companies with proprietary protocols, as was the case with the early intercommunication platforms.
Lao Chen: SIP has a complete device discovery and registration mechanism, which is more suitable for security scenarios. In addition, the registration mechanism of SIP is equivalent to establishing a connection tunnel with the device, making it more suitable than RTSP in NAT scenarios.
Anfang 1664: In the field of the Internet, compared to other protocols, GB28181 has the advantage of actively pushing the stream to the cloud.

Note: SRS 5.0 has already merged some of the capabilities of GB. For details, please refer to https://github.com/ossrs/srs/issues/3176.

RTSP

For the RTSP part, many friends have discussed it for a long time, and we will maintain the current approach of SRS.

Clients push streams to SRS via RTSP, and SRS converts them to RTMP. Generally, GB28181 is used for pushing streams, and RTSP pushing is rarely used. Currently, SRS supports RTSP pushing, but there have been sporadic issues reported.
SRS pulls streams via RTSP and converts them to RTMP. SRS achieves this through FFmpeg implementation. SRS does not have plans to directly support it because this belongs to the client-side mode, which is best suited for FFmpeg. If there is a need for optimization, it will be done based on FFmpeg.

The flowchart for RTSP stream processing should be as follows:

+-----------+               +----------------------+                +--------+  
| IP Camera +--->--RTSP-->--+ SRS Ingester(FFmpeg) +--->--RTMP-->---+  SRS   +
+-----------+               +----------------------+                +--------+

Note: IPC (IP Camera) and SRS Ingester (FFmpeg) are usually in the internal network, and FFmpeg pushes the stream to the internal or public network SRS.

GB28181: Reverse Gateway

According to reports, there is a scenario where the RTSP stream of a camera from the public network is pulled and pushed to an internal network server for viewing by internal network users. Due to the fact that it is a one-way gateway from the public network to the internal network (only allowing connections initiated from the public network to the internal network, and not vice versa), it is said that the GB protocol is needed to push the stream to the internal network server (all using UDP), as shown in the following diagram:

                          |
+-----------+             |     +---------------+  
| IP Camera +-->--GB28181-+->---+  SRS Server   +
+-----------+      (UDP)  |     +---------------+ 
                          |

Public Network Reverse Gateway Internal Network

> Note: The main limitation of this situation is that the reverse gateway can only open UDP ports to the outside. The GB28181 protocol uses UDP ports for signaling and media, which means that two UDP ports need to be opened for the camera to stream to the SRS shown above.

> Note: In this scenario, it is also not possible to use RTSP to stream to SRS because RTSP signaling uses the TCP protocol, while only the GB28181 protocol is fully UDP-based.

OBS

Supplementing the next scenario, OBS can also support pulling streams from IPC via RTSP, and after mixing with desktop or other streams (optional), it can be pushed to SRS via RTMP.

For example, in a teaching scenario, OBS can be used to pull streams from an IPC facing the teacher, another IPC facing the students, capture the desktop (displaying PPT), the sound from the local sound card, and even play files. After setting up the layout, OBS encodes and pushes the stream to SRS.

NVR

In addition, there is the scenario of NVR, which involves recording and playback in surveillance monitoring.

NVR can use the RTSP protocol to pull streams from IPC, then record them, or convert them to RTMP and push them to SRS.

Technically, it is as described above. For example, an NVR system can be built based on FFmpeg to pull streams and transcode them.

NVR supports multiple protocols and can also pull streams from cameras using the SDK provided by the manufacturer.

Plan

Future plan: Remove the built-in SIP signaling in SRS and use external signaling to avoid users using the SIP signaling used in SRS internal demos.

Reason: Signaling is a very important aspect of business attributes, and users must maintain it themselves. Open source projects are not suitable for this purpose.

TRANS_BY_GPT3

winlinvip commented 3 years ago

https://github.com/ossrs/srs/issues/2304#issue-865962340

winlinvip commented 3 years ago

https://github.com/ossrs/srs/issues/2304#issue-865962340

winlinvip commented 3 years ago

https://github.com/ossrs/srs/issues/2304#issue-865962340

ossrs / srs