Fix formatting for corruption detection header explainer.
Bug: webrtc:358039777
Change-Id: Ic9e860fbfdaf0bfe4b3e1d29f75913fb8d1080d0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360742
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Fanny Linderborg <linderborg@webrtc.org>
Auto-Submit: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42869}
diff --git a/docs/native-code/rtp-hdrext/corruption-detection/README.md b/docs/native-code/rtp-hdrext/corruption-detection/README.md
index 187a102..50dc779 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:**
<http://www.webrtc.org/experiments/rtp-hdrext/corruption-detection>
-** Status: ** This extension is defined here to allow for experimentation.
-** Contact: ** <sprang@google.com>
+
+**Status:** This extension is defined here to allow for experimentation.
+
+**Contact:** <sprang@google.com>
NOTE: This explainer is a work in progress and may change without notice.
@@ -14,7 +17,7 @@
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 @@
### 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 @@
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 @@
} 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 @@
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 @@
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
