- Move build output from `./srs-proxy` to `bin/srs-proxy` following Go
project conventions, updating Makefile, .gitignore, and all
documentation references
- Replace third-party `godotenv` dependency with a custom `.env` parser
that supports comments, `export` prefix, quoted values, escape
sequences, and inline comments — with full unit tests
- Remove `ignore-worklog.md` and update `README.md` with skill-based AI
prompts
- Bump copyright year from 2025 to 2026 across all source files
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
try to fix#4428.
## Cause
rtmp do not support hevc, rtmp enhanced do.
## How to reproduce
1. start srs.
`./objs/srs -c conf/srt.conf`
2. publish hevc (h.265) stream to srs by srt.
`ffmpeg -re -i ./doc/source.flv -c:v libx265 -crf 28 -preset medium -c:a
copy -pes_payload_size 0 -f mpegts
'srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=publish'`
3. probe the rtmp stream
`ffprobe rtmp://localhost/live/livestream`
## About the Failed BlackBox test
The failed blackbox test: `TestSlow_SrtPublish_RtmpPlay_HEVC_Basic`
`TestSlow_SrtPublish_HttpFlvPlay_HEVC_Basic`
### Cause:
The ffmpeg 5 is used to record a piece of video (DRV), the ffmpeg will
transcode the enhanced flv format to TS format, but ffmpeg 5 don't
support enhanced rtmp (or flv) in this case.
The solution is to replace the ffmpeg to version 7 in those 2 test
cases.
### why not upgrade ffmpeg to version 7?
The black tests dependency on ffmpeg 5 will fail, and there are a few of
them are not easy to resolve in ffmpeg 7.
---------
Co-authored-by: winlin <winlinvip@gmail.com>
This PR makes WebRTC a core feature of SRS and enforces C++98
compatibility by:
1. Always Enable WebRTC Support
- Remove `--rtc=on|off` configuration option - WebRTC is now always
enabled
- Eliminate all `#ifdef SRS_RTC` conditional compilation blocks
- Include WebRTC-related modules (RTC, SRTP, DTLS) in all builds
- Update build scripts to always link WebRTC dependencies
2. Enforce C++98 Compatibility
- Remove `--cxx11=on|off` and `--cxx14=on|off` configuration options
- Force `SRS_CXX11=NO` and `SRS_CXX14=NO` in build system
- Move these options to deprecated section with warnings
- Ensure codebase maintains C++98 standard compatibility
3. Remove Windows/Cygwin Support
- Remove all Windows and Cygwin64 conditional compilation blocks (#ifdef
_WIN32, #ifdef CYGWIN64)
- Delete Cygwin64 build configurations from build scripts (
auto/options.sh, auto/depends.sh, configure)
- Remove Cygwin64 assembly files and State Threads platform support (
md_cygwin64.S)
- Eliminate Windows-specific GitHub Actions workflows and CI/CD jobs
- Remove NSIS packaging files and Windows installer generation
- Delete Windows documentation and update feature lists to mark support
as removed in v7.0
- Simplify OS detection to only support Unix-like systems (Linux, macOS)
4. Code Cleanup
- Remove conditional WebRTC code blocks throughout the codebase
- Simplify build configuration by removing WebRTC-related conditionals
- Update constructor delegation patterns to be C++98 compatible
- Fix vector initialization to use C++98 syntax
- Eliminate Windows-specific implementations for file operations, time
handling, and networking
- Unified platform handling with consistent POSIX API usage
---------
Co-authored-by: OSSRS-AI <winlinam@gmail.com>
Currently, SRS only supports HLS with MPEG-TS format segment files, but
for LL-HLS and HEVC, it requires the fMP4 format. See #4327 for details.
Furthermore, fMP4 has a smaller overhead compared to TS, and fMP4 can be
used for DVR. In short, fMP4 is definitely the future segment format for
HLS.
Start SRS with the config file that enables HLS with fMP4:
```
./objs/srs -c conf/hls.mp4.conf
```
Publish stream by FFmpeg:
```
ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://localhost/live/livestream
```
Play the stream by SRS player:
[http://localhost:8080/live/livestream.m3u8](http://localhost:8080/players/srs_player.html?stream=livestream.m3u8)
Finished by AI:
* [AI: Change init.mp4 to the same directory of
m3u8.](17621c8442)
* [AI: Fix the error handling
bug.](af3758a592)
* [AI: Fix Chrome stuttering
problem.](aaab60c314)
---------
Co-authored-by: winlin <winlinvip@gmail.com>
## 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.](755686229f)
* [AI: Add crutial logs for each RTSP
stage.](9c8cbe7bde)
* [AI: Support AAC doec for
RTSP.](7d7cc12bae)
* [AI: Add option --rtsp for
RTSP.](f67414d9ee)
* [AI: Extract SrsRtpVideoBuilder for RTC and
RTSP.](562e76b904)
---------
Co-authored-by: Jacob Su <suzp1984@gmail.com>
Co-authored-by: winlin <winlinvip@gmail.com>
**Introduce**
This pull request builds upon the foundation laid in
https://github.com/ossrs/srs/pull/4289 . While the previous work solely
implemented unidirectional HEVC support from RTMP to RTC, this
submission further enhances it by introducing support for the RTC to
RTMP direction.
**Usage**
Launch SRS with `rtc2rtmp.conf`
```bash
./objs/srs -c conf/rtc2rtmp.conf
```
**Push with WebRTC**
Upgrade browser to Chrome(136+) or Safari(18+), then open [WHIP
encoder](http://localhost:8080/players/whip.html?schema=http&&codec=hevc),
push stream with URL that enables HEVC by query string `codec=hevc`:
```bash
http://localhost:1985/rtc/v1/whip/?app=live&stream=livestream&codec=hevc
```
This query string `codec=hevc` is used to select the video codec, and
generate lines in the answer SDP.
```
m=video 9 UDP/TLS/RTP/SAVPF 49 123
a=rtpmap:49 H265/90000
```
The encoder log also show the codec:
```
Audio: opus, 48000HZ, channels: 2, pt: 111
Video: H265, 90000HZ, pt: 49
```
**Play with RTMP**
Play HEVC stream via RTMP.
```bash
ffplay -i rtmp://localhost/live/livestream
```
You will see the codec in logs:
```
Stream #0:0: Audio: aac (LC), 48000 Hz, stereo, fltp
Stream #0:1: Video: hevc (Main), yuv420p(tv, bt709), 320x240, 30 fps, 30 tbr, 1k tbn
```
You can also use [WHEP
player](http://localhost:8080/players/whep.html?schema=http&&codec=hevc)
to play the stream.
Important refactor with AI:
* [AI: Refactor packet cache for RTC frame
builder.](b8ffa1630e)
* [AI: Refactor the packet copy and free for
SrsRtcFrameBuilder](f3487b45d7)
* [AI: Refactor the frame detector for
SrsRtcFrameBuilder](4ffc1526b9)
* [AI: Refactor the packet_video_rtmp for
SrsRtcFrameBuilder](81f6aef4ed)
* [AI: Add utests for
SrsCodecPayload.codec](61eb1c0bfc)
* [AI: Add utests for VideoPacketCache in
SrsRtcFrameBuilder.](fd25480dfa)
* [AI: Add utests for VideoFrameDetector in
SrsRtcFrameBuilder.](b4aa977bbd)
* [AI: Add regression test for RTC2RTMP with
HEVC.](5259a2aac3)
---------
Co-authored-by: Jacob Su <suzp1984@gmail.com>
Co-authored-by: winlin <winlinvip@gmail.com>
In the scenario of converting WebRTC to RTMP, this conversion will not
proceed until an SenderReport is received; for reference, see:
https://github.com/ossrs/srs/pull/2470.
Thus, if HTTP-FLV streaming is attempted before the SR is received, the
FLV Header will contain only audio, devoid of video content.
This error can be resolved by disabling `guess_has_av` in the
configuration file, since we can guarantee that both audio and video are
present in the test cases.
However, in the original regression tests, the
`TestRtcPublish_HttpFlvPlay` test case contains a bug:
5a404c089b/trunk/3rdparty/srs-bench/srs/rtc_test.go (L2421-L2424)
The test would pass when `hasAudio` is true and `hasVideo` is false,
which is actually incorrect. Therefore, it has been revised so that the
test now only passes if both values are true.
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: winlin <winlinvip@gmail.com>
To enable H.265 support for the WebRTC protocol, upgrade the pion/webrtc
library to version 4.
---------
Co-authored-by: john <hondaxiao@tencent.com>
Co-authored-by: winlin <winlinvip@gmail.com>
1. Add live benchmark support in srs-bench, which only connects and
disconnects without any media transport, to test source creation and
disposal and verify source memory leaks.
2. SmartPtr: Support cleanup of HTTP-FLV stream. Unregister the HTTP-FLV
handler for the pattern and clean up the objects and resources.
3. Support benchmarking RTMP/SRT with srs-bench by integrating the gosrt
and oryx RTMP libraries.
4. Refine SRT and RTC sources by using a timer to clean up the sources,
following the same strategy as the Live source.
---------
Co-authored-by: Haibo Chen <495810242@qq.com>
Co-authored-by: Jacob Su <suzp1984@gmail.com>
Try to fix two blackbox test:
1. TestSlow_SrtPublish_HttpTsPlay_HEVC_Basic: fixed by enlarge the wait
time from 3 seconds to 4 before run ffprobe task, which will record the
stream by ffmpeg first.
2 TestSlow_SrtPublish_HlsPlay_HEVC_Basic: fixed by wait 16 seconds
before run ffprobe task.
About the 2 case: it seems ridiculous to add 16 seconds delay before run
ffprobe task.
> So, I start #4088 to check the github action workflow process, I start
this branch from a very earlier version `6.0.113
(srs/core/srs_core_version6.hpp)`, what I found it that, inside `SRS
blackbox-test`, the srs version `6.0.128`, the latest version, was
printed. That's really wired.
I confirmed this is not the SRS source code's problem, check
https://github.com/suzp1984/srs/actions/runs/9511600525/job/26218025559
the srs code 6.0.113 was checkout and running actions based on them,
still met same problem.
---------
Co-authored-by: winlin <winlinvip@gmail.com>
When debugging the RTMP protocol, we can capture packets using tcpdump
and then replay the pcap file. For example:
```bash
cd ~/git/srs/trunk/3rdparty/srs-bench/pcap
tcpdump -i any -w t.pcap tcp port 1935
go run . -f ./t.pcap -s 127.0.0.1:1935
```
However, sometimes due to poor network conditions between the server and
the client, there may be many retransmitted packets. In such cases,
setting up a transparent TCP proxy that listens on port 1935 and
forwards to port 19350 can be a solution:
```bash
./objs/srs -c conf/origin.conf
cd 3rdparty/srs-bench/tcpproxy/ && go run main.go
tcpdump -i any -w t.pcap tcp port 19350
```
This approach allows for the implementation of packet dumping,
multipoint replication, or the provision of detailed timestamps and byte
information at the proxy. It enables the collection of debugging
information without the need to modify the server.
---------
`TRANS_BY_GPT4`
---------
Co-authored-by: john <hondaxiao@tencent.com>
1. After enabling FFmpeg opus, the transcoding time for each opus packet
is around 4ms.
2. To speed up case execution, our test publisher sends 400 opus packets
at intervals of 1ms.
3. After the publisher starts, wait for 30ms, then the player starts.
4. Due to the lengthy processing time for each opus packet, SRS
continuously receives packets from the publisher, so it doesn't switch
coroutines and can't accept the player's connection.
5. Only after all opus packets are processed will it accept the player
connection. Therefore, the player doesn't receive any data, leading to
the failure of the case.
---------
Co-authored-by: winlin <winlinvip@gmail.com>
When accessing the SRS Stack, you should log in and use a token for each
request, or utilize the HTTP API with a secret Bearer token included in
every request. The SRS Stack HTTP API proxies both /api/v1 and /rtc/v1
to the SRS HTTP API while ensuring secure authentication. Additionally,
there is a console in the SRS Stack that requires the same token to
request the SRS Stack HTTP API, which is then proxied to the SRS HTTP
API.
The SRS Stack runs SRS with the HTTP API listening at 127.0.0.1:1985 on
the local loopback interface, allowing only the SRS Stack to access it
without authentication. All other users must login and access the SRS
Stack through its interface, rather than directly accessing the SRS HTTP
API within the SRS Stack.
---------
Co-authored-by: panda <542638787@qq.com>
For the DJI M30, there is a bug where empty NALU packets with a size of
zero are causing issues with HLS streaming. This bug leads to random
unpublish events due to the SRS disconnecting the connection for the HLS
module when it fails to handle empty NALU packets.
To address this bug, we have patched the system to ignore any empty NALU
packets with a size of zero. Additionally, we have created a tool in the
srs-bench to replay pcapng files captured by tcpdump or Wireshark. We
have also added utest using mprotect and asan to detect any memory
corruption.
It is important to note that this bug has been fixed in versions 4.0.271
6477f31004 and 5.0.170
939f6b484b. This patch specifically
addresses the issue in SRS 6.0.
Please be aware that there is another commit related to this bug that
partially fixes the issue but still leaves a small problem for asan to
detect memory corruption. This commit,
577cd299e1, only ignores empty NALU
packets but still reads beyond the memory.
---------
Co-authored-by: chundonglinlin <chundonglinlin@163.com>
1. Enable blackbox test for each PR and push.
2. Refine Makefile and README for srs-bench.
3. Add blackbox using FFmpeg and ffprobe.
4. Add blackbox basic test for RTMP stream.
5. Add blackbox basic test for HTTP-FLV stream.
6. Fix utest rand seed issue.
PICK 2141d220b4
1. Build regression test tool for gb28181.
2. Run regression test for gb28181.
3. Format go code and eliminate logs.
4. Change base docker to ubuntu20.
PICK 7750bdae10
* FLV: Support set default has_av and disable guessing. v5.0.110
1. Support config default has_audio and has_video.
2. Support disable guessing has_audio or has_video.
* FLV: Reset to false if start to guess has_av.
* FLV: Add regression test for FLV header av metadata.
1. Ignore audo or video packets if FLV header disable it.
2. Run: Add regression test config and run for IDEA.
3. Test: Refine regression test to allow no audio/video for FLV
4. Config: Whether drop packet if not match header.
01. Support GB config as StreamCaster.
02. Support disable GB by --gb28181=off.
03. Add utests for SIP examples.
04. Wireshark plugin to decode TCP/9000 as rtp.rfc4571
05. Support MPEGPS program stream codec.
06. Add utest for PS stream codec.
07. Decode MPEGPS packet stream.
08. Carry RTP and PS packet as helper in PS message.
09. Support recover from error mode.
10. Support process by a pack of PS/TS messages.
11. Add statistic for recovered and msgs dropped.
12. Recover from err position fastly.
13. Define state machine for GB session.
14. Bind context to GB session.
15. Re-invite when media disconnected.
16. Update GitHub actions with GB28181.
17. Support parse CANDIDATE by env or pip.
18. Support mux GB28181 to RTMP.
19. Support regression test by srs-bench.
