← 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

WPT details: Test will be added

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

Ecosystem

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