From 54559d354e214412df9635c173ca3c465e5f15e1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Erik=20Spr=C3=A5ng?= Date: Tue, 27 Aug 2024 13:29:07 +0200 Subject: [PATCH] Fix formatting for corruption detection header explainer. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Bug: webrtc:358039777 Change-Id: Ic9e860fbfdaf0bfe4b3e1d29f75913fb8d1080d0 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360742 Commit-Queue: Erik Språng Reviewed-by: Fanny Linderborg Auto-Submit: Erik Språng Cr-Commit-Position: refs/heads/main@{#42869} --- .../rtp-hdrext/corruption-detection/README.md | 37 ++++++++++--------- 1 file changed, 20 insertions(+), 17 deletions(-) diff --git a/docs/native-code/rtp-hdrext/corruption-detection/README.md b/docs/native-code/rtp-hdrext/corruption-detection/README.md index 187a10274d..50dc779526 100644 --- a/docs/native-code/rtp-hdrext/corruption-detection/README.md +++ b/docs/native-code/rtp-hdrext/corruption-detection/README.md @@ -1,11 +1,14 @@ # Corruption Detection -** Name: ** +**Name:** "Corruption Detection"; "Extension for Automatic Detection of Video Corruptions" -** Formal name: ** + +**Formal name:** -** Status: ** This extension is defined here to allow for experimentation. -** Contact: ** + +**Status:** This extension is defined here to allow for experimentation. + +**Contact:** NOTE: This explainer is a work in progress and may change without notice. @@ -14,7 +17,7 @@ detection or ACD) extension is intended to be a part of a system that allows estimating a likelihood that a video transmission is in a valid state. That is, the input to the video encoder on the send side corresponds to the output of the video decoder on the receive side with the only difference being the expected -distortions from lossy compression. +distortions from lossy compression. The goal is to be able to detect outright coding errors caused by things such as bugs in encoder/decoders, malformed packetization data, incorrect relay @@ -152,7 +155,7 @@ them. ### Sequence Index Handling The quasi-random sequence of choice for this extension is a 2D -[Halton Sequence](https://en.wikipedia.org/wiki/Halton_sequence). +[Halton Sequence](https://en.wikipedia.org/wiki/Halton_sequence). The index into the Halton Sequence is indicated by the header extension and results in a 14 bit unsigned integer which on overflow will wrap around back to @@ -226,11 +229,11 @@ subsampling format. When determining which plane a location belongs to, it is easiest to visualize it as the chroma planes being “stacked” to the side of the luma plane: -+------+---+ -| | U | -+ Y +---+ -| | V | -+------+---+ + +------+---+ + | | U | + + Y +---+ + | | V | + +------+---+ In pseudo code: ``` @@ -244,7 +247,7 @@ In pseudo code: } else { HandleSample(V_PLANE, row - (image_height / 2), col - image_width); } - + seq_index++; ``` Support for other layout types may be added in later versions of this extension. @@ -268,14 +271,14 @@ max_d = ceil(sqrt(-2.0 * ln(0.2) * stddev^2) - 1. Any samples outside the plane are considered to have weight 0. In pseudo-code, that means we get the following: -``` +``` sample_sum = 0; weight_sum = 0; for (y = max(0, row - max_d) to min(plane_height, row + max_d) { for (x = max(0, col - max_d) to min(plane_width, col + max_d) { - weight = e^(-1 * ((y - row)^2 + (x - col)^2) / (2 * stddev^2)); - sample_sum += SampleAt(x, y) * weight; - weight_sum += weight; + weight = e^(-1 * ((y - row)^2 + (x - col)^2) / (2 * stddev^2)); + sample_sum += SampleAt(x, y) * weight; + weight_sum += weight; } } filtered_sample = sample_sum / weight_sum; @@ -341,7 +344,7 @@ all. There are also possibly more accurate but probably much more costly alternatives as well, such as training an ML model to determine the settings based on both the content of the source frame and any metadata present in the encoded -bitstream. +bitstream. Regardless of method, the implementation at the send side SHOULD strive to set the filter size and error thresholds such that 99.5% of filtered samples end up