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)
SRS forward feature only supports plain RTMP protocol, not RTMPS (RTMP over SSL/TLS). This is by design - SRS SSL is server-side only (accepting connections), not client-side (initiating connections). The forward feature uses SrsSimpleRtmpClient which has no SSL handshake or encryption capabilities for outgoing connections.
Changes:
1. Add RTMPS URL detection in SrsForwarder::initialize()
2. Return ERROR_NOT_SUPPORTED error when RTMPS destination is detected
3. Add unit test to verify RTMPS URLs are properly rejected
4. Add FAQ section to .augment-guidelines explaining the limitation
For users who need to forward to RTMPS destinations (e.g., AWS IVS), the recommended solution is to use FFmpeg with SRS HTTP Hooks:
- on_publish event: Automatically start FFmpeg to relay stream to RTMPS destination
- on_unpublish event: Automatically stop FFmpeg process when stream ends
This provides a fully automated, production-ready RTMPS relay solution without adding complexity to SRS core.
Related: #4536
---------
Co-authored-by: OSSRS-AI <winlinam@gmail.com>
Regression since 20f6cd595c
The early code might meet bridge is empty when
there is no bridge(e.x. rtc to rtc). Then srs_freep will free the brige.
Remove this code that seems redundant.
---------
Co-authored-by: Jacob Su <suzp1984@gmail.com>
Signed-off-by: Jack Lau <jacklau1222@qq.com>
This PR refactors the stream bridge architecture in SRS to improve code
organization, type safety, and maintainability by replacing the generic
ISrsStreamBridge interface with protocol-specific bridge classes and
target interfaces.
1. New Target Interface Architecture:
- Introduces ISrsFrameTarget for AV frame consumers (RTMP sources)
- Introduces ISrsRtpTarget for RTP packet consumers (RTC sources)
- Introduces ISrsSrtTarget for SRT packet consumers (SRT sources)
2. Protocol-Specific Bridge Classes:
- SrsRtmpBridge: Converts RTMP frames to RTC/RTSP protocols
- SrsSrtBridge: Converts SRT packets to RTMP/RTC protocols
- SrsRtcBridge: Converts RTC packets to RTMP protocol
3. Simplified Bridge Management:
- Removes the generic SrsCompositeBridge chain pattern
- Each source type now uses its appropriate bridge type directly
With this improvement, you are able to implement very complex bridge and
protocol converting, for example, you can bridge RTMP to RTC with opus
audio when you support enhanced RTMP with opus.
Another plan is to support bridging RTC to RTSP, directly without
converting RTP to media frame packet, but directly deliver RTP packet
from RTC source to RTSP source.
---------
Co-authored-by: OSSRS-AI <winlinam@gmail.com>
The issue occurred when srs_rtp_seq_distance(start, end) + 1 resulted in
values <= 0
due to sequence number wraparound (e.g., when end < start). This caused
assertion
failures and server crashes.
SrsRtcFrameBuilder::check_frame_complete(): Added validation to return
false
for invalid sequence ranges instead of asserting.
However, it maybe cause converting RTC to RTMP stream failure, because
this issue
should be caused by the problem of sequence number of RTP, which means
there potentially
be stream problem in RTC stream. Even so, changing assert to warning
logs is better,
because SRS should not crash when stream is corrupt.
---------
Co-authored-by: OSSRS-AI <winlinam@gmail.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 significantly enhances the kernel module by adding comprehensive
unit test coverage and improving interface design for core buffer and
load balancer components.
- **ISrsDecoder**: New interface for decoding/deserialization operations
- **ISrsLbRoundRobin**: Extracted interface from concrete
SrsLbRoundRobin class for better abstraction
- **Enhanced Documentation**: Added comprehensive inline documentation
for ISrsEncoder, ISrsCodec, SrsBuffer, and SrsBitBuffer classes
---------
Co-authored-by: OSSRS-AI <winlinam@gmail.com>
This PR introduces anonymous coroutine macros for easier coroutine
creation and improves the State Threads (ST) mutex and condition
variable handling in SRS.
- **Added coroutine macros**: `SRS_COROUTINE_GO`, `SRS_COROUTINE_GO2`,
`SRS_COROUTINE_GO_CTX`, `SRS_COROUTINE_GO_CTX2`
- **Added `SrsCoroutineChan`**: Channel for sharing data between
coroutines with coroutine-safe operations
- **Simplified coroutine creation**: Go-like syntax for creating
anonymous coroutines with code blocks
---------
Co-authored-by: Jacob Su <suzp1984@gmail.com>
Co-authored-by: OSSRS-AI <winlinam@gmail.com>
Fixes a bug in WebRTC NACK packet recovery mechanism where recovered
packets were being discarded instead of processed.
In `SrsRtcRecvTrack::on_nack()`, when a retransmitted packet arrived
(found in NACK receiver), the method would:
1. ✅ Remove the packet from NACK receiver (correct)
2. ❌ Return early without adding the packet to RTP queue (BUG)
This caused recovered packets to be lost, defeating the purpose of the
NACK mechanism and potentially causing media quality issues.
Restructured the control flow in `on_nack()` to ensure both new and
recovered packets reach the packet insertion logic:
- **Before**: Early return for recovered packets → packets discarded
- **After**: Conditional NACK management + unified packet processing →
all packets queued
Closes#3820
---------
Co-authored-by: Haibo Chen <495810242@qq.com>
Co-authored-by: OSSRS-AI <winlinam@gmail.com>
This PR modernizes SRS's HTTP handling by upgrading from the legacy
http-parser library to the more performant and actively maintained
llhttp library.
* Replace http-parser with llhttp: Migrated from the deprecated
http-parser to llhttp for better performance and maintenance
* API compatibility: Updated all HTTP parsing logic to use llhttp APIs
while maintaining backward compatibility
* Simplified URL parsing: Replaced complex http-parser URL parsing with
custom simple parser implementation
Enhanced error handling: Improved error reporting with llhttp's better
error context and positioning
---------
Co-authored-by: OSSRS-AI <winlinam@gmail.com>
WebRTC RTC publish streams use timer callbacks (`SrsRtcPublishRtcpTimer`
and `SrsRtcPublishTwccTimer`) that can cause race conditions in SRS's
coroutine-based architecture. The timer callbacks are heavy functions
that may trigger coroutine switches, during which the timer object can
be freed by another coroutine, leading to use-after-free crashes.
The race condition occurs because:
1. Timer callbacks (`on_timer`) perform heavy operations that can yield
control
2. During coroutine switches, other coroutines may destroy the timer
object
3. When control returns, the callback continues executing on a freed
object
Fixes potential crashes in WebRTC RTC publish streams under high
concurrency.
