Skip to content

Commit 961c95c

Browse files
committed
WHIP: Occasionally, the timestamp of OPUS audio may be inaccurate, particularly when the input is an MP4 file.
1 parent 6598ffc commit 961c95c

File tree

1 file changed

+9
-25
lines changed

1 file changed

+9
-25
lines changed

libavformat/rtcenc.c

Lines changed: 9 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -986,9 +986,6 @@ typedef struct RTCContext {
986986
/* The SRTP receive context, to decrypt incoming packets. */
987987
SRTPContext srtp_recv;
988988

989-
/* The time jitter base for audio OPUS stream. */
990-
int64_t audio_jitter_base;
991-
992989
/* The UDP transport is used for delivering ICE, DTLS and SRTP packets. */
993990
URLContext *udp_uc;
994991
/* The buffer for UDP transmission. */
@@ -1107,6 +1104,15 @@ static av_cold int whip_init(AVFormatContext *s)
11071104
*
11081105
* @param s Pointer to the AVFormatContext
11091106
* @returns Returns 0 if successful or AVERROR_xxx in case of an error.
1107+
*
1108+
* TODO: FIXME: There is an issue with the timestamp of OPUS audio, especially when
1109+
* the input is an MP4 file. The timestamp deviates from the expected value of 960,
1110+
* causing Chrome to play the audio stream with noise. This problem can be replicated
1111+
* by transcoding a specific file into MP4 format and publishing it using the WHIP
1112+
* muxer. However, when directly transcoding and publishing through the WHIP muxer,
1113+
* the issue is not present, and the audio timestamp remains consistent. The root
1114+
* cause is still unknown, and this comment has been added to address this issue
1115+
* in the future. Further research is needed to resolve the problem.
11101116
*/
11111117
static int parse_codec(AVFormatContext *s)
11121118
{
@@ -1158,15 +1164,6 @@ static int parse_codec(AVFormatContext *s)
11581164
av_log(rtc, AV_LOG_ERROR, "WHIP: Unsupported audio sample rate %d by RTC, choose 48000\n", par->sample_rate);
11591165
return AVERROR_PATCHWELCOME;
11601166
}
1161-
1162-
// TODO: FIXME: Use opus_metadata BSF to parse it.
1163-
if (rtc->audio_par->frame_size <= 0)
1164-
rtc->audio_par->frame_size = 960;
1165-
1166-
if (rtc->audio_par->frame_size <= 0) {
1167-
av_log(rtc, AV_LOG_ERROR, "WHIP: Unsupported audio frame size %d by RTC\n", rtc->audio_par->frame_size);
1168-
return AVERROR_PATCHWELCOME;
1169-
}
11701167
break;
11711168
default:
11721169
av_log(rtc, AV_LOG_ERROR, "WHIP: Codec type '%s' for stream %d is not supported by RTC\n",
@@ -2282,19 +2279,6 @@ static int rtc_write_packet(AVFormatContext *s, AVPacket *pkt)
22822279
goto end;
22832280
}
22842281

2285-
/* For audio stream, correct the timestamp. */
2286-
if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
2287-
pkt->dts = pkt->pts = rtc->audio_jitter_base;
2288-
/**
2289-
* TODO: FIXME: For opus 48khz, each frame is 20ms which is 48000*20/1000 = 960. It appears that there is a
2290-
* bug introduced by libopus regarding the timestamp. Instead of being exactly 960, there is a slight
2291-
* deviation, such as 956 or 970. This deviation can cause Chrome to play the audio stream with noise.
2292-
* Although we are unsure of the root cause, we can simply correct the timestamp by using the timebase of
2293-
* Opus. We need to conduct further research and remove this line.
2294-
*/
2295-
rtc->audio_jitter_base += rtc->audio_par->frame_size;
2296-
}
2297-
22982282
ret = ff_write_chained(rtp_ctx, 0, pkt, s, 0);
22992283
if (ret < 0) {
23002284
if (ret == AVERROR(EINVAL)) {

0 commit comments

Comments
 (0)