← Back to release summary

Adding captureTimestamp and senderCaptureTimeOffset to RTCRtpContributingSource.

Category
WebRTC
Type
New or changed feature
Status
Enabled by default (Chrome 96)
Intent stage
Shipped

Summary

Two new data properties, captureTimestamp and senderCaptureTime, will be added to the RTCRtpContributingSource, returned by RTCRtpReceiver.getContributingSources(). (See https://w3c.github.io/webrtc-extensions/#rtcrtpcontributingsource-dictionary.) These new properties are used to measure A/V sync and end-to-end delay in real-time communication (RTC) systems.

Motivation

CaptureTimestamp and senderCaptureTime are introduced to overcome the difficulty of measuring A/V sync and end-to-end delay in an RTC system is that one or more RTCP-terminating sub-system are involved. In such a system, the round trip time measurement on RTCRemoteInboundRtpStreamStats only accounts for the "last hop": the connection between the receiver and the nearest RTCP-terminating sub-system that it receives RTCP packets from. This makes it hard to estimate the offset between the receiver's clock and the capturer's clock, and thus end-to-end delay. CaptureTimestamp and senderCaptureTime, as originated from RTP Header Extension for Absolute Capture Time, see https://github.com/webrtc/webrtc-org/blob/gh-pages/experiments/rtp-hdrext/abs-capture-time/index.md can mitigate the problem.

Standards & signals

Docs: https://w3c.github.io/webrtc-extensions/#rtcrtpcontributingsource-dictionary https://github.com/webrtc/webrtc-org/blob/gh-pages/experiments/rtp-hdrext/abs-capture-time/index.md

Explainers: https://w3c.github.io/webrtc-extensions/#rtcrtpcontributingsource-dictionary

View on chromestatus.com