Sending cached GOP data during the start of broadcasting cause continuous stuttering

[陈鹏越]

Hi! I am trying to send cached data from the server (up to the previous I-frame) at a faster rate (around 1.1x) when a new user requests to play.The time interval between the RTP timestamps of all data remains consistent. However, I noticed that every time I switch back to normal speed, Chrome keeps trying to render more frames per second, causing the jitter buffer to periodically empty and stutter (freeze in webrtc-internal). I have tried disabling the sender report, but it did not help. Could you please help me identify the issue?

[shakeeb nazmus]

Hi Chen Pengyue,

>>  I am trying to send cached data from the server

By the cached data, do you mean cached RTP data or cached video data in the codec layer ?

Thanks,

Shakeeb

[chen jony]

Hi shakeeb nazmus,

I store the original h264 and opus data up to the previous I-frame in the cache, but before putting the data into the buffer, I have already stamped the RTP timestamp according to the original frame timestamp. For example, I set a 2970 RTP timestamp interval for 30fps H264/90000 video data and 960 RTP timestamp interval for 50fps opus/48000/2 audio data, which is equivalent to 33ms and 20ms. However, due to 1.1x accelerated sending, the actual sending frame interval of this part of the data is less than 33ms/20ms, about 30ms/18ms.

In addition, during my test today, I found that if I remove the audio data, the browser will not attempt to render the video at an excessively high frame rate. I checked Chrome's debug log and found that Chrome would increase the jitter buffer at the beginning, and when the jitter buffer is reduced, the aforementioned periodic stuttering would occur. I suspect it is related to audio and video synchronization, but I have checked the frame count and timestamps of the audio and video, and it doesn't seem to be abnormal. Do you have any ideas?

Thanks,

Chen Pengyue

shakeeb nazmus 在 2023年9月21日 星期四下午2:39:39 [UTC+8] 的信中寫道：