- From: Chen Xing via GitHub <sysbot+gh@w3.org>
- Date: Thu, 25 Apr 2019 13:45:03 +0000
- To: public-webrtc-logs@w3.org
> Btw has it not already been decoded when it exits the jitter buffer? Maybe the difference between "exists the jitter buffer" and "delivered to the track" is splitting hairs? (In case implementation difficulty varies between the two but its not noticeable?) The flow is roughly: 1. Network 2. Jitter Buffer 3. Decoder 4. Sync Buffer (Audio) or Render Buffer (Video) 5. MediaStreamTrack 6. Other kinds of intentional delays? 7. OS and Hardware Buffers 8. Playout An implementation could decide to pop packets from the jitter buffer as soon as all earlier packets (i.e. packets with lower sequence numbers) have arrived. Frames that are decoded too early (to be sent to the track) could be parked in the sync/render buffer. I think that WebRTC's video code (unlike its audio code) might already behave this way today. -- GitHub Notification of comment by chxg Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2172#issuecomment-486678751 using your GitHub account
Received on Thursday, 25 April 2019 13:45:15 UTC