W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > April 2019

Re: [webrtc-pc] Clarify the definition of "playout" for `RTCRtpContributingSource`. (#2172)

From: Chen Xing via GitHub <sysbot+gh@w3.org>
Date: Thu, 25 Apr 2019 13:45:03 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-486678751-1556199902-sysbot+gh@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

This archive was generated by hypermail 2.3.1 : Wednesday, 9 October 2019 15:15:03 UTC