address comments

w3c · Oct 25, 2024 · 39ccc35 · 39ccc35
1 parent 25e854c
commit 39ccc35
Showing 1 changed file with 12 additions and 17 deletions.
diff --git a/webrtc-stats.html b/webrtc-stats.html
@@ -1766,6 +1766,16 @@ <h2>
                   likely some corruption visible, but it could for instance have a low magnitude or be present
                   only in a small portion of the frame.
                 </p>
+                <p class="note">
+                  The corruption likelihood values are estimates - not guarantees. Even if the estimate is
+                  0.0 there could be corruptions present (i.e. it's a false negative) for instance if only a
+                  very small area of the frame is affected. Similarly, even if the estimate is 1.0 there might
+                  not be a corruption present (i.e. it's a false positive) for instance if there are
+                  macroblocks with a QP far higher than the frame average.
+                  Just like there are edge cases for e.g. PSNR measurements, these metrics should primarily
+                  be used as a basis for statistical analysis rather than be used as an absolute truth on a
+                  per-frame basis.
+                </p>
               </dd>
               <dt>
                 <dfn>totalSquaredCorruptionProbability</dfn> of type <span class=
@@ -1789,25 +1799,10 @@ <h2>
                   {{totalCorruptionProbability}} and {{totalSquaredCorruptionProbability}} are aggregated
                   with this measurement and measurement squared respectively.
                   If the <a href="http://www.webrtc.org/experiments/rtp-hdrext/corruption-detection">
-                  corruption-detection</a> header extension has been negotiated, corruptioned probability
-                  measurements SHOULD be [= map/exist | present =].
+                  corruption-detection</a> header extension is present in the RTP packets, corruption
+                  probability measurements MUST be [= map/exist | present =].
                 </p>
                 <p class="note">
-                  The user agent MAY produce corruption likelihood measurements using any method available.
-                  That could be facilitated by e.g. the mentioned corruption detection header extension,
-                  reference-less image analysis such as natural image statistics, ML-based classification,
-                  or anything else capable of producing an estimate.<br>
-                  <br>
-                  The corruption likeliehood values are estimates - not guarantess. Even if the estimate is
-                  0.0 there could be corruptions present (i.e. it's a false negative) for instance if random
-                  sampling is used and only a very small area of the frame is affected. Similarly, even if the
-                  estimate is 1.0 there might not be corruptions present (i.e. it's a false positive) for
-                  instance if an image recognition technique is used while presenting a screenshot of a
-                  video encoding corruption.<br>
-                  Just like there are edge cases for e.g. PSNR measrumenets, these metrics should primarily
-                  be used as a basis for statistical analysis rather than be used as an absolute truth on a
-                  per-frame basis.<br>
-                  <br>
                   The corruption-detection header extension documented at
                   <a href="http://www.webrtc.org/experiments/rtp-hdrext/corruption-detection">
                   http://www.webrtc.org/experiments/rtp-hdrext/corruption-detection</a> is experimental. The