[webrtc-stats] Audio/Video sync follow-up

henbos has just created a new issue for https://github.com/w3c/webrtc-stats:

== Audio/Video sync follow-up ==
This is a follow-up to: #158 

[estimatedPlayoutTimestamp](http://rawgit.com/w3c/webrtc-stats/master/webrtc-stats.html#dom-rtcmediastreamtrackstats-estimatedplayouttimestamp) was added, but estimatedCaptureTimestamp was not due to being able to estimate the time of the capturer by taking the `estimatedPlayoutTimestamp + rtt/2`.

We have rtt based on STUN pings in [RTCIceCandidatePairStats.currentRoundTripTime](http://rawgit.com/w3c/webrtc-stats/master/webrtc-stats.html#dom-rtcicecandidatepairstats-currentroundtriptime), or based on RTCP Receiver Report in [RTCRemoteInboundRTPStreamStats.roundTripTime](http://rawgit.com/w3c/webrtc-stats/master/webrtc-stats.html#dom-rtcremoteinboundrtpstreamstats-roundtriptime). Will the per-SSRC RTCP RR roundTripTime suffice for `rtt/2`?

The current definition of estimatedPlayoutTimestamp is that we extrapolate the timestamp by the time passed since the last frame/sample was playable, the point of this was to get a timestamp that increases in-between frames/samples but it causes a problem: If the renderer freezes or frames/samples stop coming the extrapolation hides this fact until the next time a frame/sample is playable. We should update the definition such that we extrapolate the timestamp from the last known NTP timestamp up to the last playable timestamp. We should not extrapolate beyond playable frames/samples.

Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/222 using your GitHub account

Received on Friday, 12 May 2017 08:35:50 UTC