RTCInboundRtpStreamStats: totalProcessingDelay property
Limited availability
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.
Value
A positive number, in seconds.
Specifications
| Specification |
|---|
| Identifiers for WebRTC's Statistics API # dom-rtcinboundrtpstreamstats-totalprocessingdelay |
Browser compatibility
| desktop | mobile | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
totalProcessingDelay in 'inbound-rtp' stats
|
|
|
|
|
|
|
|
|
|
|
|
|
Legend
Tip: you can click/tap on a cell for more information.
- Full support
- Full support
- No support
- No support