- Add a comprehensive ST knowledge base document:
- openclaw/memory/srs-coroutines.md
- Add ST-focused developer skill:
- openclaw/skills/st-develop/SKILL.md
- openclaw/skills/st-develop/scripts/verify.sh
- Add KB workflow skills that support ST documentation quality and
learning:
- openclaw/skills/kb-review/SKILL.md
- openclaw/skills/srs-learn/SKILL.md
- Update openclaw/skills/srs-support/SKILL.md to use dynamic SRS_ROOT
path resolution, improving portability for KB/source
loading.
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: chatgpt-codex-connector[bot] <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>
Move the SRS proxy server code from the standalone repository
https://github.com/ossrs/proxy into the proxy/ directory of the
main SRS repo. Also update build instructions in origin-cluster.md.
# HLS/DASH: Fix dispose() to cleanup files after unpublish
## Summary
Fixes a bug where HLS/DASH files are not deleted after the configured
`hls_dispose`/`dash_dispose` timeout.
## Problem
When a stream is unpublished:
1. `on_unpublish()` is called and sets `enabled_ = false`
2. After the dispose timeout, `cycle()` calls `dispose()`
3. `dispose()` immediately returns due to `if (!enabled_)` check at line
2722 (HLS) and line 891 (DASH)
4. `controller_->dispose()` is never called
5. Files remain on disk indefinitely
**Observed behavior**:
- Stream stopped at 11:32:42
- `dispose()` called at 11:33:14 (after 30s timeout)
- Log shows "hls cycle to dispose hls" but no "gracefully dispose hls"
message
- Files remain on disk
## Root Cause
Commit 550760f2d introduced an early return in `dispose()` when
`!enabled_`, which prevents file cleanup after `on_unpublish()` has
already been called and set `enabled_` to false.
## Solution
Reorder the logic in `dispose()` to:
1. Check if dispose is enabled (hls_dispose/dash_dispose > 0) first
2. Call `on_unpublish()` only if `enabled_` is still true (prevents
duplicate calls)
3. Always call `controller_->dispose()` to cleanup files when dispose
timeout occurs
This ensures files are properly cleaned up while still preventing
duplicate `on_unpublish()` calls.
## Changes Made
- **trunk/src/app/srs_app_hls.cpp** (lines 2718-2734): Reordered
dispose() logic
- **trunk/src/app/srs_app_dash.cpp** (lines 887-902): Reordered
dispose() logic
- **trunk/doc/CHANGELOG.md**: Added v7.0.137 entry
## Testing Recommendation
To verify the fix:
1. Start RTMP stream to `/live/test`:
```bash
ffmpeg -re -i test.mp4 -c copy -f flv rtmp://localhost:1935/live/test
```
2. Wait for HLS segments to be created:
```bash
ls -la /path/to/hls/live/test/
```
3. Stop the stream (Ctrl+C)
4. Wait for `hls_dispose` timeout (default 120s, or 30s with your
config):
```bash
# Watch logs for "hls cycle to dispose hls" and "gracefully dispose hls"
tail -f srs.log
```
5. Verify files are deleted:
```bash
ls -la /path/to/hls/live/test/
# Should be empty or directory removed
```
**Expected results**:
- Before fix: Files remain on disk
- After fix: Files are deleted, logs show "gracefully dispose hls"
## Impact
- **Risk**: Low - minimal logic change, only reordering of checks
- **Breaking changes**: None
- **Performance**: No impact
- **Compatibility**: Fixes existing bug, improves expected behavior
## Checklist
- [x] Code follows project style
- [x] Both HLS and DASH are fixed
- [x] CHANGELOG updated
- [x] Tested locally (recommended before merge)
- [x] No breaking changes
## Related Issues
- Regression introduced in: 550760f2d
- Related to: #865 (hls_dispose feature)
---------
Co-authored-by: Jacob Su <suzp1984@gmail.com>
based on @HeeJoon-Kim's patch, try to fix#4594
Fix audio-only HLS fMP4 streams causing players to skip segments.
The bug was in segment_close() which always used video_dts_ (0 for
audio-only) to calculate the final sample duration, causing unsigned
integer overflow and corrupted m4s files.
The fix passes max(audio_dts_, video_dts_) from the controller to
segment_close(), ensuring correct duration calculation for both
audio-only and video streams.
---------
Co-authored-by: OSSRS-AI <winlinam@gmail.com>
When recording HEVC streams to MP4, DVR fails with error "doesn't
support
hvcC change" (ERROR_MP4_HVCC_CHANGE).
The root cause is in video_avc_demux(): the SrsVideoFrame object is
reused
across frames, and its initialize() method does not reset
avc_packet_type.
When a sequence header is processed, avc_packet_type is set to 0
(SrsVideoAvcFrameTraitSequenceHeader). When the next video info frame
arrives (which only appears in HEVC streams), the function returns early
without assigning video->avc_packet_type, so it retains the value 0 from
the previous sequence header frame.
When DVR processes this video info frame, it checks avc_packet_type and
incorrectly identifies it as a sequence header. Since the real HEVC
sequence
header was already recorded, DVR returns the "hvcC change" error.
The fix assigns video->avc_packet_type = packet_type before returning
early for VideoInfoFrame. After the fix, avc_packet_type is correctly
set
to the actual packet type (1 or 3 for coded frames), so DVR correctly
identifies it as NOT a sequence header.
---------
Co-authored-by: OSSRS-AI <winlinam@gmail.com>
When SRT publisher disconnects, player hangs indefinitely instead of
exiting after the configured peer_idle_timeout. This is because the
consumer wait() never checks if the publisher is still connected.
After fix, player waits for peer_idle_timeout (default 10s) then exits
gracefully when no packets arrive and publisher has disconnected.
We have discovered that some IP cameras send two publish packets in a
row.
The first packet is flash publish `publish('xxx')`
The second packet is FMLE publish `FCPublish('xxx|@setDataFrame()`
It seems that this is not processed correctly on the SRS side. In fact,
the stream is simply deinitialized, and republish is simply not
supported in this case.
As a fix, I suggest simply ignoring the FMLE publish packet after the
flash publish.
<img width="720" alt="screen"
src="https://github.com/user-attachments/assets/2db806ab-71b9-4e7b-bcf9-c16ea12df671"
/>
**Problem**: Newly created sources (RTMP/SRT/RTC/RTSP) were being
immediately marked as "dead" and deleted by the cleanup timer before
publishers could connect, causing "new live source, dead=1" errors.
**Root Cause**: All source constructors initialized `stream_die_at_ =
0`, causing `stream_is_dead()` to return `true` immediately since
current time was always greater than `0 + 3 seconds`.
**Solution**: Changed all four source constructors to initialize
`stream_die_at_ = srs_time_now_cached()`, giving newly created sources a
proper 3-second grace period before cleanup.
Fix issue #4570 by supporting optional `msid` attribute in WebRTC SDP
negotiation, enabling compatibility with libdatachannel and other
clients that don't include msid information.
SRS failed to negotiate WebRTC connections from libdatachannel clients
because:
- libdatachannel SDP lacks `a=ssrc:XX msid:stream_id track_id`
attributes
- SRS required msid information to create track descriptions
- According to RFC 8830, the msid attribute and its appdata (track_id)
are **optional**
If diligently look at the SDP generated by libdatachannel:
```
a=ssrc:42 cname:video-send
a=ssrc:43 cname:audio-send
```
It's deliberately missing the `a=ssrc:XX msid:stream_id track_id` line,
comparing that with this one:
```
a=ssrc:42 cname:video-send
a=ssrc:42 msid:stream_id video_track_id
a=ssrc:43 cname:audio-send
a=ssrc:43 msid:stream_id audio_track_id
```
In such a situation, to keep compatible with libdatachannel, if no msid
line in sdp, SRS comprehensively and consistently uses:
* app/stream as stream_id, such as live/livestream
* type=video|audio, cname, and ssrc as track_id, such as
track-video-video-send-43
Fix log flooding issue when processing SRT streams containing SCTE-35
PIDs or other unrecognized stream types.
The `SrsSrtFormat::on_srt_packet()` method continuously parses TS
packets throughout the entire stream lifetime. The TS parser logs
warnings for every unrecognized stream type (like SCTE-35) in the PMT,
causing log flooding.
However, `SrsFormat` is only used to detect audio/video codec
information. Once both codecs are detected, there's no need to continue
parsing TS packets.
Note: This fix mitigates the problem - there will still be some warning
logs during the initial codec detection phase (typically 5-10 seconds),
but the continuous log flooding after codec detection is completely
eliminated.
This PR adds G.711 (PCMU/PCMA) audio codec support for WebRTC in SRS,
enabling relay-only streaming of G.711 audio between WebRTC clients via
WHIP/WHEP. G.711 is a widely-used, royalty-free audio codec with
excellent compatibility across VoIP systems, IP cameras, and legacy
telephony equipment.
Fixes#4075
Many IP cameras, VoIP systems, and IoT devices use G.711 (PCMU/PCMA) as
their default audio codec. Previously, SRS only supported Opus for
WebRTC audio, requiring transcoding or rejecting G.711 streams entirely.
This PR enables direct relay of G.711 audio streams in WebRTC, similar
to how VP9/AV1 video codecs are supported.
Enhanced WHIP/WHEP players with URL-based codec selection:
```
# Audio codec only
http://localhost:8080/players/whip.html?acodec=pcmuhttp://localhost:8080/players/whip.html?acodec=pcma
# Video + audio codecs
http://localhost:8080/players/whip.html?vcodec=vp9&acodec=pcmuhttp://localhost:8080/players/whep.html?vcodec=h264&acodec=pcma
# Backward compatible (codec = vcodec)
http://localhost:8080/players/whip.html?codec=vp9
```
Testing
```bash
# Build and run unit tests
cd trunk
make utest -j && ./objs/srs_utest
# Test with WHIP player
# 1. Start SRS server
./objs/srs -c conf/rtc.conf
# 2. Open WHIP publisher with PCMU audio
http://localhost:8080/players/whip.html?acodec=pcmu
# 3. Open WHEP player to receive stream
http://localhost:8080/players/whep.html
```
## Related Issues
- Fixes#4075 - WebRTC G.711A Audio Codec Support
- Related to #4548 - VP9 codec support (similar relay-only pattern)
This PR adds separate audio and video frame counting to the HTTP API
(`/api/v1/streams/`) for better stream observability. The API now
reports three frame fields:
- `frames` - Total frames (video + audio)
- `video_frames` - Video frames/packets only
- `audio_frames` - Audio frames/packets only
This enhancement provides better visibility into stream composition and
helps detect issues with CBR/VBR streams, audio/video sync problems, and
codec-specific behavior.
**Before:**
```json
{
"streams": [
{
"frames": 0, // video frames.
}
]
}
```
**After:**
```json
{
"streams": [
{
"frames": 6912, // video frames.
"audio_frames": 5678, // audio frames.
"video_frames": 1234, // video frames.
}
]
}
```
Frame Counting Strategy
- All protocols report frames every N frames to balance accuracy and
performance
- Frames are counted at the protocol-specific message/packet level:
- RTMP: Counts RTMP messages (video/audio)
- WebRTC: Counts RTP packets (video/audio)
- SRT: Counts MPEG-TS messages (H.264/HEVC/AAC)
for issue #4418, #4151, #4076 .DVR Missing First Few Seconds of
Audio/Video
### Root Cause
When recording WebRTC streams to FLV files using DVR, the first 4-6
seconds of audio/video are missing. This occurs because:
1. **Packets are discarded before A/V sync is available**: The
RTC-to-RTMP conversion pipeline actively discards all RTP packets when
avsync_time <= 0.
2. **Original algorithm requires 2 RTCP SR packets**: The previous
implementation needed to receive two RTCP Sender Report (SR) packets
before it could calculate the rate for audio/video synchronization
timestamp conversion.
3. **Delay causes packet loss**: Since RTCP SR packets typically arrive
every 2-3 seconds, waiting for 2 SRs means 4-6 seconds of packets are
discarded before A/V sync becomes available.
4. **Audio SR arrives slower than video SR**: As reported in the issue,
video RTCP SR packets arrive much faster than audio SR packets. This
asymmetry causes audio packets to be discarded for a longer period,
resulting in the audio loss observed in DVR recordings.
### Solution
1. **Initialize rate from SDP**: Use the sample rate from SDP (Session
Description Protocol) to calculate the initial rate immediately when the
track is created.
Audio (Opus): 48000 Hz → rate = 48 (RTP units per millisecond)
Video (H.264/H.265): 90000 Hz → rate = 90 (RTP units per millisecond)
2. **Enable immediate A/V sync:** With the SDP rate available,
cal_avsync_time() can calculate valid timestamps from the very first RTP
packet, eliminating packet loss.
3. **Smooth transition to precise rate**: After receiving the 2nd RTCP
SR, update to the precisely calculated rate based on actual RTP/NTP
timestamp mapping.
## Configuration
Added new configuration option `init_rate_from_sdp` in the RTC vhost
section:
```nginx
vhost rtc.vhost.srs.com {
rtc {
# Whether initialize RTP rate from SDP sample rate for immediate A/V sync.
# When enabled, the RTP rate (units per millisecond) is initialized from the SDP
# sample rate (e.g., 90 for video 90kHz, 48 for audio 48kHz) before receiving
# 2 RTCP SR packets. This allows immediate audio/video synchronization.
# The rate will be updated to a more precise value after receiving the 2nd SR.
# Overwrite by env SRS_VHOST_RTC_INIT_RATE_FROM_SDP for all vhosts.
# Default: off
init_rate_from_sdp off;
}
}
```
**⚠️ Important Note**: This config defaults to **off** because:
- ✅ When **enabled**: Fixes the audio loss problem (no missing first 4-6
seconds)
- ❌ When **enabled**: VLC on macOS cannot play the video properly
- ✅ Other platforms work fine (Windows, Linux)
- ✅ FFplay works fine on all platforms
Users experiencing audio loss in DVR recordings can enable this option
if they don't need VLC macOS compatibility. We're investigating the VLC
macOS issue to make this feature safe to enable by default in the
future.
---------
Co-authored-by: winlin <winlinvip@gmail.com>
Co-authored-by: OSSRS-AI <winlinam@gmail.com>
