This feature is not Baseline because it does not work in some of the most widely-used browsers.
The totalProcessingDelay property of the RTCInboundRtpStreamStats dictionary indicates the total accumulated time spent processing audio or video samples, in seconds.
The processing time for each audio or video sample is calculated from the time the first RTP packet is received (reception timestamp) to the time that the corresponding sample or frame is decoded (decoded timestamp). At this point the audio sample or video frame is fully decoded by the decoder and is ready for playout by the MediaStreamTrack.
For audio streams, an RTP packet may contain multiple audio samples: these will share the same reception timestamp. For video streams, a complete frame may arrive in several RTP packets, and the reception timestamp is that of the first RTP packet that was received that contains data for the frame. In both cases the decoded timestamp is the time at which the sample or frame is ready to play.
For video, the property only accumulates for decoded frames (not those that were dropped). The average processing delay can be calculated by dividing the totalProcessingDelay with the framesDecoded.
A positive number, in seconds.
| Specification |
|---|
| Identifiers for WebRTC's Statistics API> # dom-rtcinboundrtpstreamstats-totalprocessingdelay> |
| Desktop | Mobile | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Chrome | Edge | Firefox | Opera | Safari | Chrome Android | Firefox for Android | Opera Android | Safari on IOS | Samsung Internet | WebView Android | WebView on iOS | |
totalProcessingDelay |
103 | 103 | 106 | 89 | No | 103 | 106 | 71 | No | 20.0 | 103 | No |
© 2005–2025 MDN contributors.
Licensed under the Creative Commons Attribution-ShareAlike License v2.5 or later.
https://developer.mozilla.org/en-US/docs/Web/API/RTCInboundRtpStreamStats/totalProcessingDelay