You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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:
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).
The text was updated successfully, but these errors were encountered: