We'd like to add a new feature that enables capturing video corruptions, and that requires a new stats value.

Some background: We're try to catch bugs that cause the input to the encoder to diverge from the output of the decoder in ways that are unexpected (not artifacts that are expected from lossy compression).

These can be cause by bugs in a number of components:

• Encoder implementations
• Incorrect metadata
• RTP Packetization
• SFU/backend logic
• Jitter buffer/frame assembly
• Decoder implementations

Common among these bugs is that they are very hard to catch as they are not visible in any existing statistics, apart from user complaints. That makes them very hard and time consuming to triage and root cause.

In http://www.webrtc.org/experiments/rtp-hdrext/corruption-detection we propose a new header extension that adds metadata to the encoded frames that a receiver can use to validate that the decoder is in a consistent state. In order to surface this signal to the application layer, we need a new value in RTCInboundRtpStreamStats.

Note that we don't wish to tie the definition of the statistics too hard to our proposed implementation. Rather, we'd like to use a "probability of corruption" likelihood measure that may be produced using that header extension, or it may be produced some other way (e.g. using image recognition techniques on the receive side alone).