- From: Varun Singh via GitHub <sysbot+gh@w3.org>
- Date: Mon, 18 Mar 2019 14:27:44 +0000
- To: public-webrtc-logs@w3.org
I thought most Jitter Buffer (JB) were timestamp oriented, i.e., the JB would push out to the decoder at the indicated timestamp. My understanding was as follows -- If a JB is going to underflow (assume there is a low water mark threshold which triggers before underflow actually occurs), the JB would add a constant delay to each audio packet/ video frame, thus slowing down the time to underflow because the JB is not triggering at the intended timeout but delaying it. The way I read the proposal here is suggesting (AFAICT) that the JB sends the audio packets out for decoding at the intended and in the Playout Buffer (PB) where data is played out at the sampling rate, silent samples are added to slow down playback? Is my understanding of your proposal correct? Why do we need acceleratedSamples, based on above would the jitter buffer not discard the packet earlier before sending it to playout? Is there a reason to send the packet from the JB even though it was late? -- GitHub Notification of comment by vr000m Please view or discuss this issue at https://github.com/w3c/webrtc-stats/pull/408#issuecomment-473932379 using your GitHub account
Received on Monday, 18 March 2019 14:27:46 UTC