From 1d9105396d785512e7c4918d019cceeb77ab1bb3 Mon Sep 17 00:00:00 2001 From: winlin Date: Sun, 26 Oct 2025 12:05:27 -0400 Subject: [PATCH] Update guideline for AI about sanitizer. --- .augment-guidelines | 14 ++++++++++++++ trunk/3rdparty/srs-docs/doc/webrtc.md | 28 ++++++++++++++++++++++++++- 2 files changed, 41 insertions(+), 1 deletion(-) diff --git a/.augment-guidelines b/.augment-guidelines index ddd6de9a1..4c8093f57 100644 --- a/.augment-guidelines +++ b/.augment-guidelines @@ -325,6 +325,20 @@ testing: HELPER_EXPECT_FAILED(some_function_that_should_fail()); } +debugging: + memory_and_pointer_issues: + description: "For memory corruption, crashes, pointer issues, or undefined behavior, proper debugging information is MANDATORY" + required_information: "User MUST provide either coredump stack trace OR sanitizer output - without it, memory issues cannot be diagnosed" + + sanitizer: + description: "AddressSanitizer (ASAN) - Google's memory error detection tool for catching buffer overflows, use-after-free, memory leaks, etc." + when_enabled: "Automatically enabled for unit tests (--utest=on), manually enabled with ./configure --sanitizer=on, disabled by default for production builds (causes memory leak and increasing forever)" + how_to_enable: "./configure --sanitizer=on && make" + + coredump: + description: "When sanitizer cannot be used, coredump with stack trace is required" + how_to_get: "ulimit -c unlimited, run SRS until crash, gdb ./objs/srs core.xxx -ex 'bt' -ex 'quit'" + code_review: github_pull_requests: - When reviewing or understanding GitHub pull requests, use the diff URL to get the code changes diff --git a/trunk/3rdparty/srs-docs/doc/webrtc.md b/trunk/3rdparty/srs-docs/doc/webrtc.md index 83b2939ed..221489f49 100644 --- a/trunk/3rdparty/srs-docs/doc/webrtc.md +++ b/trunk/3rdparty/srs-docs/doc/webrtc.md @@ -453,7 +453,7 @@ docker run --rm --env CANDIDATE=$CANDIDATE \ > Note: Please set CANDIDATE as the ip of server, please read [CANDIDATE](./webrtc.md#config-candidate). -Then startup the signaling, please read [usage](http://ossrs.net/srs.release/wiki/https://github.com/ossrs/signaling#usage): +Then startup the signaling, please read [usage](https://github.com/ossrs/signaling#usage): ```bash docker run --rm -p 1989:1989 ossrs/signaling:1 @@ -585,6 +585,32 @@ This enables: - IPv4 clients to connect via: `http://192.168.1.100:1985/rtc/v1/whip/` - IPv6 clients to connect via: `http://[2001:db8::1]:1985/rtc/v1/whip/` +## Known Limitation: Initial Audio Loss + +When publishing WebRTC streams, you may notice that the **first 4-6 seconds of audio are missing** in recordings (DVR), +RTMP playback, or HTTP-FLV streams. This is a **known limitation** of WebRTC's audio/video synchronization mechanism, +not a bug. + +**Root Cause**: WebRTC uses RTCP Sender Reports (SR) to synchronize audio and video timestamps. When a WebRTC stream +starts, both audio and video RTP packets arrive immediately. However, SRS needs RTCP Sender Reports to calculate proper +timestamps for synchronizing audio and video. The A/V sync calculation requires **TWO** RTCP Sender Reports to establish +the timing rate between RTP timestamps and system time. All RTP packets (both audio and video) with `avsync_time <= 0` +are **discarded** to avoid timestamp problems in the live source. RTCP Sender Reports typically arrive every 2-3 seconds. +After the **second** SR arrives (~4-6 seconds), the A/V sync rate is calculated, and packets start being accepted. If DVR +is configured with `dvr_wait_keyframe on`, recording starts at the first video keyframe anyway. Video keyframes typically +arrive every 2-4 seconds, so by the time the first keyframe arrives, A/V sync is often already established. However, audio +packets that arrived before sync was established are **permanently lost**. + +**Why This Won't Be Fixed**: This is a **fundamental limitation** of WebRTC's A/V synchronization mechanism. The RTCP-based +A/V synchronization is essential for WebRTC. Without it, audio and video timestamps would be misaligned, causing severe sync +issues throughout the entire stream. The current design prioritizes **correct A/V synchronization** over capturing the first +few seconds. This is a reasonable trade-off for most live streaming scenarios where streams run for extended periods (minutes +to hours), losing 4-6 seconds at the start is acceptable, and perfect A/V sync throughout the stream is critical. Fixing this +would require fundamentally redesigning the WebRTC A/V sync mechanism, which is extremely complex and risky. + +**Related Issues**: [#4418](https://github.com/ossrs/srs/issues/4418), [#4151](https://github.com/ossrs/srs/issues/4151), +[#4076](https://github.com/ossrs/srs/issues/4076) + ![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/webrtc)