Re: [webrtc-pc] RTCRtpContributingSource.audioLevel not guaranteed to be in sync with audio playout

> Moving the point from packet reception to packet-coming-out-of-jitter-buffer (i.e. when it's played) is straightforward, and roughly what was intended.

So it sounds like you're in favor of this approach? Do you have any suggestion about the correct spec terminology? Since there's no concept of a jitter buffer, would it be accurate to say "when the `RTCRtpReceiver`'s **remote source** produces a frame of media", or maybe "delivers a frame of media to the `MediaStreamTrack`"?

> getting the notification 'early' compensates for the lag due to polling

I don't feel good about this, though; there's no guarantee that the polling lag and jitter buffer delay will always cancel each other out perfectly.

GitHub Notification of comment by taylor-b
Please view or discuss this issue at using your GitHub account

Received on Friday, 17 March 2017 17:28:55 UTC