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.

Documentation

Specification

Public discussion

Status in Chromium

Blink


In development (tracking bug)

Consensus & Standardization

After a feature ships in Chrome, the values listed here are not guaranteed to be up to date.

  • No signal
  • No signal
  • No signal
  • No signals

Owners

Search tags

WebRTC, Audio, Video, Synchronization, End-to-end delay, Blink, Javascript,

Last updated on 2021-01-01