From 3f57ca5966a164128abf0e8b5e7542ff3726ccc0 Mon Sep 17 00:00:00 2001 From: winlin Date: Tue, 19 Aug 2025 22:28:10 -0600 Subject: [PATCH] AI: Update SRS docs for Augment. --- .../srs-docs/doc/getting-started-ai.md | 56 ++++++++ trunk/3rdparty/srs-docs/doc/hls.md | 112 +++++++++++++-- trunk/3rdparty/srs-docs/doc/http-api.md | 4 +- trunk/3rdparty/srs-docs/doc/http-server.md | 2 +- trunk/3rdparty/srs-docs/doc/origin-cluster.md | 5 + trunk/3rdparty/srs-docs/doc/rtmp.md | 85 +++++++++++ trunk/3rdparty/srs-docs/doc/rtsp.md | 136 ++++++++++++++++++ 7 files changed, 387 insertions(+), 13 deletions(-) create mode 100644 trunk/3rdparty/srs-docs/doc/getting-started-ai.md create mode 100644 trunk/3rdparty/srs-docs/doc/rtsp.md diff --git a/trunk/3rdparty/srs-docs/doc/getting-started-ai.md b/trunk/3rdparty/srs-docs/doc/getting-started-ai.md new file mode 100644 index 000000000..9dbc690d0 --- /dev/null +++ b/trunk/3rdparty/srs-docs/doc/getting-started-ai.md @@ -0,0 +1,56 @@ +--- +title: AI Agent +sidebar_label: AI Agent +hide_title: false +hide_table_of_contents: false +--- + +# AI Agent + +AI Agents are powerful tools for maintaining SRS and helping you understand, debug, operate, and develop SRS applications. We use a comprehensive set of AI Agents to maintain the SRS community and have established guidelines for AI to follow, enabling you to use these tools more efficiently. + +## Augment Code + +Augment Code is an exceptionally powerful AI Agent that we highly recommend. We have configured specific settings and guidelines for Augment Code, allowing you to simply open the SRS project with VSCode and immediately leverage the full power of AI assistance. SRS provides comprehensive context for AI to work effectively, including code, documentation, and tests. + +To use Augment Code, first install VSCode, then install the Augment Code extension. Follow the installation guide at [Install Augment for Visual Studio Code](https://docs.augmentcode.com/setup-augment/install-visual-studio-code). + +Next, clone the SRS code and ensure you open the root directory, which contains the `.augment-guidelines` file: + +```bash +git clone https://github.com/ossrs/srs.git +cd srs +code . +``` + +You can verify the Augment Code settings to ensure the `Context` is correctly configured, then test it by asking Augment Code a question like this: + +``` +Will you follow any .augment-guidelines and .augmentignore of this project? +``` + +We've found that Augment Code demonstrates deep familiarity with the SRS codebase, comparable to that of experienced maintainers. For a practical example of using Augment Code to review pull requests and improve code quality, see [AI Agent for SRS](https://medium.com/@winlinam/f9eb12a1ce74). + +## GitHub Copilot + +GitHub Copilot is an effective AI Agent for reading and writing SRS code. We also utilize it for pull request reviews. While it's a valuable AI tool, it doesn't quite match the expertise level of an experienced maintainer. + +## Pull Request + +SRS also uses AI to help review pull requests, making it important to structure your pull requests in a way that AI can effectively understand your changes and code. To ensure optimal AI review, please follow these guidelines: + +* Avoid renaming variables and functions in your pull request, as this can confuse AI analysis. +* Avoid reordering functions or restructuring code, as this makes it difficult for AI to understand the actual changes. +* Avoid moving or renaming files, as these appear as major changes to AI systems. + +If you need to perform such refactoring tasks (renaming variables, functions, or files, or reordering functions), please submit a separate pull request before your main feature pull request. Clearly comment that the refactoring PR contains no logic changes, so we can skip AI review for that specific PR. + +## Comments + +Adding comments is highly beneficial and recommended, especially for complex logic that might confuse both you and AI. Generally, if you need AI assistance to understand or clarify code, you should also ask AI to add comments for that code. + +Comments are always valuable and welcome—think of them as prompts for AI. With accurate and thorough comments, AI can better understand complex code and implicit background knowledge. By maintaining these good practices, AI can continue to help improve project quality and create a better maintenance experience. + +You should also leverage AI to generate brief and clear commit messages and pull request descriptions. There's no need for excessive text—just enough to clarify the special context and knowledge that is implicit in the code. + +![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/getting-started-ai) diff --git a/trunk/3rdparty/srs-docs/doc/hls.md b/trunk/3rdparty/srs-docs/doc/hls.md index eede0f87c..78792543a 100644 --- a/trunk/3rdparty/srs-docs/doc/hls.md +++ b/trunk/3rdparty/srs-docs/doc/hls.md @@ -56,13 +56,19 @@ The config for HLS: ```bash vhost __defaultVhost__ { - hls { - # whether the hls is enabled. + hls { # whether the hls is enabled. # if off, do not write hls(ts and m3u8) when publish. # Overwrite by env SRS_VHOST_HLS_ENABLED for all vhosts. # default: off enabled on; + # whether to use fmp4 as container + # The default value is off, then HLS use ts as container format, + # if on, HLS use fmp4 as container format. + # Overwrite by env SRS_VHOST_HLS_HLS_USE_FMP4 for all vhosts. + # default: off + hls_use_fmp4 on; + # the hls fragment in seconds, the duration of a piece of ts. # Overwrite by env SRS_VHOST_HLS_HLS_FRAGMENT for all vhosts. # default: 10 @@ -78,8 +84,8 @@ vhost __defaultVhost__ { # for example, the hls_fragment is 10s, hls_aof_ratio is 1.2, # the segment will reap to 12s for pure audio. # Overwrite by env SRS_VHOST_HLS_HLS_AOF_RATIO for all vhosts. - # default: 1.2 - hls_aof_ratio 1.2; + # default: 2.1 + hls_aof_ratio 2.1; # the hls window in seconds, the number of ts in m3u8. # Overwrite by env SRS_VHOST_HLS_HLS_WINDOW for all vhosts. # default: 60 @@ -123,11 +129,49 @@ vhost __defaultVhost__ { # [timestamp],replace this const to current UNIX timestamp in ms. # [seq], the sequence number of ts. # [duration], replace this const to current ts duration. - # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/dvr#custom-path - # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/delivery-hls#hls-config + # @see https://ossrs.io/lts/en-us/docs/v7/doc/dvr#custom-path + # @see https://ossrs.io/lts/en-us/docs/v7/doc/hls#config # Overwrite by env SRS_VHOST_HLS_HLS_TS_FILE for all vhosts. # default: [app]/[stream]-[seq].ts hls_ts_file [app]/[stream]-[seq].ts; + # the hls fmp4 file name. + # we supports some variables to generate the filename. + # [vhost], the vhost of stream. + # [app], the app of stream. + # [stream], the stream name of stream. + # [2006], replace this const to current year. + # [01], replace this const to current month. + # [02], replace this const to current date. + # [15], replace this const to current hour. + # [04], replace this const to current minute. + # [05], replace this const to current second.p + # [999], replace this const to current millisecond. + # [timestamp],replace this const to current UNIX timestamp in ms. + # [seq], the sequence number of fmp4. + # [duration], replace this const to current ts duration. + # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/dvr#custom-path + # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/delivery-hls#hls-config + # Overwrite by env SRS_VHOST_HLS_HLS_FMP4_FILE for all vhosts. + # default: [app]/[stream]-[seq].m4s + hls_fmp4_file [app]/[stream]-[seq].m4s; + # the hls init mp4 file name. + # we supports some variables to generate the filename. + # [vhost], the vhost of stream. + # [app], the app of stream. + # [stream], the stream name of stream. + # [2006], replace this const to current year. + # [01], replace this const to current month. + # [02], replace this const to current date. + # [15], replace this const to current hour. + # [04], replace this const to current minute. + # [05], replace this const to current second. + # [999], replace this const to current millisecond. + # [timestamp],replace this const to current UNIX timestamp in ms. + # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/dvr#custom-path + # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/delivery-hls#hls-config + # Overwrite by env SRS_VHOST_HLS_HLS_INIT_FILE for all vhosts. + # default: [app]/[stream]/init.mp4 + hls_init_file [app]/[stream]/init.mp4; # the hls entry prefix, which is base url of ts url. # for example, the prefix is: # http://your-server/ @@ -244,8 +288,7 @@ vhost __defaultVhost__ { # on_hls, never config in here, should config in http_hooks. # for the hls http callback, @see http_hooks.on_hls of vhost hooks.callback.srs.com - # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/delivery-hls#http-callback - # @see https://ossrs.io/lts/en-us/docs/v4/doc/delivery-hls#http-callback + # @see https://ossrs.io/lts/en-us/docs/v7/doc/hls#http-callback # on_hls_notify, never config in here, should config in http_hooks. # we support the variables to generate the notify url: @@ -254,8 +297,7 @@ vhost __defaultVhost__ { # [param], replace with the param. # [ts_url], replace with the ts url. # for the hls http callback, @see http_hooks.on_hls_notify of vhost hooks.callback.srs.com - # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/delivery-hls#on-hls-notify - # @see https://ossrs.io/lts/en-us/docs/v4/doc/delivery-hls#on-hls-notify + # @see https://ossrs.io/lts/en-us/docs/v7/doc/hls#on-hls-notify } } ``` @@ -495,5 +537,55 @@ https://developer.apple.com/library/ios/technotes/tn2288/_index.html SRS3 supports slice encryption, for specific usage, refer to [#1093](https://github.com/ossrs/srs/issues/1093#issuecomment-415971022). +## HLS fMP4 + +SRS (7.0.51+) supports HLS with fMP4 (fragmented MP4) segments instead of traditional MPEG-TS segments. fMP4 is the modern container format for HLS that offers several advantages: + +* **Better codec support**: Required for HEVC/H.265 and essential for Low-Latency HLS (LL-HLS) +* **Lower overhead**: fMP4 has smaller file overhead compared to MPEG-TS segments +* **DVR compatibility**: fMP4 segments can be used for DVR and time-shifting applications +* **Future-proof**: fMP4 is the recommended format for modern HLS implementations + +To enable HLS with fMP4 segments, set `hls_use_fmp4 on` in your configuration: + +```bash +vhost __defaultVhost__ { + hls { + enabled on; + hls_use_fmp4 on; + hls_fragment 10; + hls_window 60; + hls_m3u8_file [app]/[stream].m3u8; + hls_init_file [app]/[stream]-init.mp4; + hls_fmp4_file [app]/[stream]-[seq].m4s; + } +} +``` + +When fMP4 is enabled, SRS generates: +* **Initialization segment**: `init.mp4` file containing codec information +* **Media segments**: `.m4s` files containing the actual media data + +You can customize the file naming using these configuration options: +* `hls_fmp4_file`: Media segment filename pattern (default: `[app]/[stream]-[seq].m4s`) +* `hls_init_file`: Initialization segment filename pattern (default: `[app]/[stream]/init.mp4`) + +For example, start SRS with fMP4 enabled: + +```bash +docker run --rm -it -p 1935:1935 -p 8080:8080 ossrs/srs:7 \ + ./objs/srs -c conf/hls.mp4.conf +``` + +Publish a stream: + +```bash +ffmpeg -re -i ./doc/source.flv -c copy -f flv rtmp://localhost/live/livestream +``` + +The generated m3u8 playlist will reference fMP4 segments instead of TS segments, making it compatible with modern HLS players and Low-Latency HLS requirements. + +Play the stream by SRS player: [http://localhost:8080/live/livestream.m3u8](http://localhost:8080/players/srs_player.html?stream=livestream.m3u8) + ![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/hls) diff --git a/trunk/3rdparty/srs-docs/doc/http-api.md b/trunk/3rdparty/srs-docs/doc/http-api.md index b024e9e18..a046e0c63 100644 --- a/trunk/3rdparty/srs-docs/doc/http-api.md +++ b/trunk/3rdparty/srs-docs/doc/http-api.md @@ -119,7 +119,7 @@ http_api { # default: ./conf/server.key key ./conf/server.key; # The SSL public cert file, generated by: - # openssl req -new -x509 -key server.key -out server.crt -days 3650 -subj "/C=CN/ST=Beijing/L=Beijing/O=Me/OU=Me/CN=ossrs.net" + # openssl req -new -x509 -key server.key -out server.crt -days 3650 -subj "/C=CA/ST=Toronto/L=Toronto/O=Me/OU=Me/CN=ossrs.io" # default: ./conf/server.crt cert ./conf/server.crt; } @@ -258,7 +258,7 @@ http_api { # default: ./conf/server.key key ./conf/server.key; # The SSL public cert file, generated by: - # openssl req -new -x509 -key server.key -out server.crt -days 3650 -subj "/C=CN/ST=Beijing/L=Beijing/O=Me/OU=Me/CN=ossrs.net" + # openssl req -new -x509 -key server.key -out server.crt -days 3650 -subj "/C=CA/ST=Toronto/L=Toronto/O=Me/OU=Me/CN=ossrs.io" # default: ./conf/server.crt cert ./conf/server.crt; } diff --git a/trunk/3rdparty/srs-docs/doc/http-server.md b/trunk/3rdparty/srs-docs/doc/http-server.md index 82ec150e0..296c2ea85 100644 --- a/trunk/3rdparty/srs-docs/doc/http-server.md +++ b/trunk/3rdparty/srs-docs/doc/http-server.md @@ -118,7 +118,7 @@ http_server { # default: ./conf/server.key key ./conf/server.key; # The SSL public cert file, generated by: - # openssl req -new -x509 -key server.key -out server.crt -days 3650 -subj "/C=CN/ST=Beijing/L=Beijing/O=Me/OU=Me/CN=ossrs.net" + # openssl req -new -x509 -key server.key -out server.crt -days 3650 -subj "/C=CA/ST=Toronto/L=Toronto/O=Me/OU=Me/CN=ossrs.io" # Overwrite by env SRS_HTTP_SERVER_HTTPS_CERT # default: ./conf/server.crt cert ./conf/server.crt; diff --git a/trunk/3rdparty/srs-docs/doc/origin-cluster.md b/trunk/3rdparty/srs-docs/doc/origin-cluster.md index 486137a50..9892191cb 100644 --- a/trunk/3rdparty/srs-docs/doc/origin-cluster.md +++ b/trunk/3rdparty/srs-docs/doc/origin-cluster.md @@ -58,6 +58,11 @@ cd proxy-go && make We will support the Docker image in the future, or integrate the proxy server into the Oryx project. +## Legacy + +From SRS 7.0+, the new Origin Cluster is based on proxy server, not the old MESH based SRS servers. +However, if you want to use the old origin cluster, you can switch to SRS 6.0. + ## RTMP Origin Cluster To use the RTMP origin cluster, you need to deploy the proxy server and the origin server. diff --git a/trunk/3rdparty/srs-docs/doc/rtmp.md b/trunk/3rdparty/srs-docs/doc/rtmp.md index 2ddce4016..18c9a9dff 100644 --- a/trunk/3rdparty/srs-docs/doc/rtmp.md +++ b/trunk/3rdparty/srs-docs/doc/rtmp.md @@ -50,6 +50,19 @@ SRS supports converting RTMP to other protocols, described in next sections. The configuration about RTMP: ```bash +# the rtmp listen ports, split by space, each listen entry is <[ip:]port> +# for example, 192.168.1.100:1935 10.10.10.100:1935 +# where the ip is optional, default to 0.0.0.0, that is 1935 equals to 0.0.0.0:1935 +# Overwrite by env SRS_LISTEN +listen 1935; +# the default chunk size is 128, max is 65536, +# some client does not support chunk size change, +# however, most clients support it and it can improve +# performance about 10%. +# Overwrite by env SRS_CHUNK_SIZE +# default: 60000 +chunk_size 60000; + vhost __defaultVhost__ { # whether enable min delay mode for vhost. # for min latency mode: @@ -247,6 +260,78 @@ vhost __defaultVhost__ { > Note: These configurations are for publish and play. Note that there are some other configurations in other sections, for example, converting RTMP to [HTTP-FLV](./flv.md#config) or HTTP-TS. +## RTMPS + +RTMPS (RTMP over SSL/TLS) provides secure RTMP streaming by encrypting the connection between clients and the server. This is essential for protecting sensitive content and ensuring secure communication in production environments. + +SRS (v7.0.56+) supports RTMPS server functionality, allowing publishers and players to connect using encrypted RTMP connections. + +To enable RTMPS, you need to configure SRS with SSL certificates and run it with RTMPS support: + +```bash +./objs/srs -c conf/rtmps.conf +``` + +Publish RTMPS stream by [FFmpeg](https://ffmpeg.org/download.html): + +```bash +ffmpeg -re -i doc/source.flv -c copy -f flv rtmps://localhost:1443/live/livestream +``` + +Play RTMPS stream by [ffplay](https://ffmpeg.org/download.html): + +```bash +ffplay rtmps://localhost:1443/live/livestream +``` + +The RTMPS configuration requires SSL certificate setup similar to other HTTPS services in SRS: + +```bash +# the rtmp listen ports, split by space, each listen entry is <[ip:]port> +# for example, 192.168.1.100:1935 10.10.10.100:1935 +# where the ip is optional, default to 0.0.0.0, that is 1935 equals to 0.0.0.0:1935 +# Overwrite by env SRS_LISTEN +listen 1935; + +# SSL configuration for RTMPS +rtmps { + # Whether rtmps is enabled. + # Overwrite by env SRS_RTMPS_ENABLED + # default: off + enabled on; + # The rtmps listen port + # Overwrite by env SRS_RTMPS_LISTEN + listen 1443; + # The SSL private key file, generated by: + # openssl genrsa -out server.key 2048 + # Overwrite by env SRS_RTMPS_KEY + # default: ./conf/server.key + key ./conf/server.key; + # The SSL public cert file, generated by: + # openssl req -new -x509 -key server.key -out server.crt -days 3650 -subj "/C=CA/ST=Toronto/L=Toronto/O=Me/OU=Me/CN=ossrs.io" + # Overwrite by env SRS_RTMPS_CERT + # default: ./conf/server.crt + cert ./conf/server.crt; +} + +vhost __defaultVhost__ { + # Standard RTMP vhost configuration applies to RTMPS as well +} +``` + +For testing purposes, you can generate a self-signed certificate: + +```bash +# Generate private key +openssl genrsa -out server.key 2048 + +# Generate self-signed certificate +openssl req -new -x509 -key server.key -out server.crt -days 3650 \ + -subj "/C=CN/ST=Beijing/L=Beijing/O=Me/OU=Me/CN=localhost" +``` + +For production environments, use certificates from a trusted Certificate Authority (CA) or Let's Encrypt. + ## On Demand Live Streaming In some situations, you might want to start streaming only when someone starts watching: diff --git a/trunk/3rdparty/srs-docs/doc/rtsp.md b/trunk/3rdparty/srs-docs/doc/rtsp.md new file mode 100644 index 000000000..e52153e90 --- /dev/null +++ b/trunk/3rdparty/srs-docs/doc/rtsp.md @@ -0,0 +1,136 @@ +--- +title: RTSP +sidebar_label: RTSP +hide_title: false +hide_table_of_contents: false +--- + +# RTSP + +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. + +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. + +This version reuses some protocol parsing code from version 2.0, removes the publishing functionality, adds playback support, and only works with TCP transport. + +For more background, please refer to the [FAQ](../../../faq#rtsp). + +## Usage + +First, compile and start SRS (ensure you're using version `7.0.47+`): + +```bash +cd srs/trunk && ./configure --rtsp=on && make +./objs/srs -c conf/rtsp.conf +``` +> You must enable RTSP with `--rtsp=on` during compilation (disabled by default). + +Then, publish a stream using RTMP: + +```bash +ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://localhost/live/livestream +``` + +Finally, play the stream using RTSP (note: only TCP transport is supported): + +```bash +ffplay -rtsp_transport tcp -i rtsp://localhost:8554/live/livestream +``` + +## Config + +Reference `conf/rtsp.conf`: + +```bash +rtsp_server { + enabled on; + listen 8554; +} + +vhost __defaultVhost__ { + rtsp { + enabled on; + rtmp_to_rtsp on; + } +} +``` + +## Port + +The RTSP protocol consists of two parts: signaling (DESCRIBE/SETUP/PLAY, etc.) and media transport (RTP/RTCP packets). + +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`. + +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: + +```bash +ffplay -rtsp_transport udp -i rtsp://localhost:8554/live/livestream + +[rtsp @ 0x7fbc99a14880] method SETUP failed: 461 Unsupported Transport +rtsp://localhost:8554/live/livestream: Protocol not supported + +[2025-07-05 21:30:52.738][WARN][14916][7d7gf623][35] RTSP: setup failed: code=2057 +(RtspTransportNotSupported) : UDP transport not supported, only TCP/interleaved mode is supported +``` + +There are currently no plans to support UDP transport. In practice, UDP is rarely used; the vast majority of RTSP traffic uses TCP. + +## RTP + +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`. + +## Play Before Publish + +RTSP supports audio with AAC and OPUS codecs, which is significantly different from RTMP or WebRTC. + +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. + +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. + +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. + +## Opus Codec + +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. + +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. + +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. + +## Architecture + +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. + +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. + +## Testing + +### Unit Test + +```bash +./configure --utest=on & make utest +./objs/srs_utest +``` + +### Regression Test + +```bash +cd srs/trunk/3rdparty/srs-bench +go test ./srs -mod=vendor -v -count=1 -run=TestRtmpPublish_RtspPlay +``` +> Note: You need to start SRS before running regression tests. + +### BlackBox Test + +```bash +cd srs/trunk/3rdparty/srs-bench +go test ./blackbox -mod=vendor -v -count=1 -run=TestFast_RtmpPublish_RtspPlay_Basic +``` + +## TODO + +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. + +## References + +- [rfc2326-1998-rtsp.pdf](/files/rfc2326-1998-rtsp.pdf) \ No newline at end of file