Files
srs/trunk/conf/regression-test.conf

84 lines
1.5 KiB
Plaintext
Raw Normal View History

2021-03-04 10:41:23 +08:00
max_connections 1000;
# Force to daemon and write logs to file.
daemon on;
disable_daemon_for_docker off;
srs_log_tank file;
# RTMP server configuration
rtmp {
listen 1935;
}
stream_caster {
enabled on;
caster gb28181;
output rtmp://127.0.0.1/live/[stream];
listen 9000;
sip {
enabled on;
listen 5060;
timeout 2.1;
reinvite 1.2;
}
}
2021-03-04 10:41:23 +08:00
http_server {
enabled on;
listen 8080;
dir ./objs/nginx/html;
}
http_api {
enabled on;
listen 1985;
}
stats {
network 0;
}
NEW PROTOCOL: Support viewing stream over RTSP. v7.0.47 (#4333) ## Introduce This PR adds support for viewing streams via the RTSP protocol. Note that it only supports viewing streams, not publishing streams via RTSP. Currently, only publishing via RTMP is supported, which is then converted to RTSP. Further work is needed to support publishing RTC/SRT streams and converting them to RTSP. ## Usage Build and run SRS with RTSP support: ``` cd srs/trunk && ./configure --rtsp=on && make -j16 ./objs/srs -c conf/rtsp.conf ``` Push stream via RTMP by FFmpeg: ``` ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://localhost/live/livestream ``` View the stream via RTSP protocol, try UDP first, then use TCP: ``` ffplay -i rtsp://localhost:8554/live/livestream ``` Or specify the transport protocol with TCP: ``` ffplay -rtsp_transport tcp -i rtsp://localhost:8554/live/livestream ``` ## Unit Test Run utest for RTSP: ``` ./configure --utest=on & make utest -j16 ./objs/srs_utest ``` ## Regression Test You need to start SRS for regression testing. ``` ./objs/srs -c conf/regression-test-for-clion.conf ``` Then run regression tests for RTSP. ``` cd srs/trunk/3rdparty/srs-bench go test ./srs -mod=vendor -v -count=1 -run=TestRtmpPublish_RtspPlay ``` ## Blackbox Test For blackbox testing, SRS will be started by utest, so there is no need to start SRS manually. ``` cd srs/trunk/3rdparty/srs-bench go test ./blackbox -mod=vendor -v -count=1 -run=TestFast_RtmpPublish_RtspPlay_Basic ``` ## UDP Transport As UDP requires port allocation, this PR doesn't support delivering media stream via UDP transport, so it will fail if you try to use UDP as transport: ``` 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 no plans to support UDP transport for RTSP. In the real world, UDP is rarely used; the vast majority of RTSP traffic uses TCP. ## 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. ## AI Contributor Below commits are contributed by AI: * [AI: Remove support for media transport via UDP.](https://github.com/ossrs/srs/pull/4333/commits/755686229f0d3910f058e6f75993112a68c5f60a) * [AI: Add crutial logs for each RTSP stage.](https://github.com/ossrs/srs/pull/4333/commits/9c8cbe7bdefda19087f87fdb5e041a8934e4db1d) * [AI: Support AAC doec for RTSP.](https://github.com/ossrs/srs/pull/4333/commits/7d7cc12bae269850011d4757eae635a61de99f36) * [AI: Add option --rtsp for RTSP.](https://github.com/ossrs/srs/pull/4333/commits/f67414d9ee98da39cda1f7d47cdf793c0e5a8412) * [AI: Extract SrsRtpVideoBuilder for RTC and RTSP.](https://github.com/ossrs/srs/pull/4333/commits/562e76b90469a1b016857eb23b090e8e45b52de3) --------- Co-authored-by: Jacob Su <suzp1984@gmail.com> Co-authored-by: winlin <winlinvip@gmail.com>
2025-07-11 20:18:40 +08:00
rtsp_server {
enabled on;
listen 8554;
}
2021-03-04 10:41:23 +08:00
rtc_server {
enabled on;
listen 8000;
candidate $CANDIDATE;
}
vhost __defaultVhost__ {
rtc {
enabled on;
rtmp_to_rtc on;
keep_bframe off;
rtc_to_rtmp on;
}
NEW PROTOCOL: Support viewing stream over RTSP. v7.0.47 (#4333) ## Introduce This PR adds support for viewing streams via the RTSP protocol. Note that it only supports viewing streams, not publishing streams via RTSP. Currently, only publishing via RTMP is supported, which is then converted to RTSP. Further work is needed to support publishing RTC/SRT streams and converting them to RTSP. ## Usage Build and run SRS with RTSP support: ``` cd srs/trunk && ./configure --rtsp=on && make -j16 ./objs/srs -c conf/rtsp.conf ``` Push stream via RTMP by FFmpeg: ``` ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://localhost/live/livestream ``` View the stream via RTSP protocol, try UDP first, then use TCP: ``` ffplay -i rtsp://localhost:8554/live/livestream ``` Or specify the transport protocol with TCP: ``` ffplay -rtsp_transport tcp -i rtsp://localhost:8554/live/livestream ``` ## Unit Test Run utest for RTSP: ``` ./configure --utest=on & make utest -j16 ./objs/srs_utest ``` ## Regression Test You need to start SRS for regression testing. ``` ./objs/srs -c conf/regression-test-for-clion.conf ``` Then run regression tests for RTSP. ``` cd srs/trunk/3rdparty/srs-bench go test ./srs -mod=vendor -v -count=1 -run=TestRtmpPublish_RtspPlay ``` ## Blackbox Test For blackbox testing, SRS will be started by utest, so there is no need to start SRS manually. ``` cd srs/trunk/3rdparty/srs-bench go test ./blackbox -mod=vendor -v -count=1 -run=TestFast_RtmpPublish_RtspPlay_Basic ``` ## UDP Transport As UDP requires port allocation, this PR doesn't support delivering media stream via UDP transport, so it will fail if you try to use UDP as transport: ``` 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 no plans to support UDP transport for RTSP. In the real world, UDP is rarely used; the vast majority of RTSP traffic uses TCP. ## 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. ## AI Contributor Below commits are contributed by AI: * [AI: Remove support for media transport via UDP.](https://github.com/ossrs/srs/pull/4333/commits/755686229f0d3910f058e6f75993112a68c5f60a) * [AI: Add crutial logs for each RTSP stage.](https://github.com/ossrs/srs/pull/4333/commits/9c8cbe7bdefda19087f87fdb5e041a8934e4db1d) * [AI: Support AAC doec for RTSP.](https://github.com/ossrs/srs/pull/4333/commits/7d7cc12bae269850011d4757eae635a61de99f36) * [AI: Add option --rtsp for RTSP.](https://github.com/ossrs/srs/pull/4333/commits/f67414d9ee98da39cda1f7d47cdf793c0e5a8412) * [AI: Extract SrsRtpVideoBuilder for RTC and RTSP.](https://github.com/ossrs/srs/pull/4333/commits/562e76b90469a1b016857eb23b090e8e45b52de3) --------- Co-authored-by: Jacob Su <suzp1984@gmail.com> Co-authored-by: winlin <winlinvip@gmail.com>
2025-07-11 20:18:40 +08:00
rtsp {
enabled on;
rtmp_to_rtsp on;
}
play {
atc on;
2021-03-04 10:41:23 +08:00
}
http_remux {
enabled on;
# Disabling 'guess_has_av' as it is not required for the current test setup.
guess_has_av off;
mount [vhost]/[app]/[stream].flv;
2021-03-04 10:41:23 +08:00
}
ingest livestream {
enabled on;
input {
type file;
url ./doc/source.200kbps.768x320.flv;
}
ffmpeg ./objs/ffmpeg/bin/ffmpeg;
engine {
enabled off;
output rtmp://127.0.0.1:[port]/live/livestream;
}
}
}