RTCCodecStats - add docs

[hamishwillee]

This adds docs for RTCCodecStats, a "codec statistics" object you can get by iterating a RTCStatsReport.

This is part of the ongoing work to finished RTC stats, which was started in #27028

As with the other ones, this is not "exciting work". Many of these stats are just reflections of data from other webRTC objects. I've tried to properly cross link, but not to provide examples etc.
The value in this is largely around exposing the BCD table.

[github-actions]

Preview URLs (10 pages)

• /en-US/docs/Web/API/RTCCodecStats/channels
• /en-US/docs/Web/API/RTCCodecStats/clockRate
• /en-US/docs/Web/API/RTCCodecStats/id
• /en-US/docs/Web/API/RTCCodecStats/mimeType
• /en-US/docs/Web/API/RTCCodecStats/payloadType
• /en-US/docs/Web/API/RTCCodecStats/sdpFmtpLine
• /en-US/docs/Web/API/RTCCodecStats/timestamp
• /en-US/docs/Web/API/RTCCodecStats/transportId
• /en-US/docs/Web/API/RTCCodecStats/type
• /en-US/docs/Web/API/RTCCodecStats

External URLs (3)

URL: /en-US/docs/Web/API/RTCCodecStats/sdpFmtpLine
Title: RTCCodecStats: sdpFmtpLine property

• https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-jsep-24 (1 time) (Note! This may be a new URL 👀)

---

URL: /en-US/docs/Web/API/RTCCodecStats/payloadType
Title: RTCCodecStats: payloadType property

• https://www.rfc-editor.org/rfc/rfc3551 (1 time) (Note! This may be a new URL 👀)

---

URL: /en-US/docs/Web/API/RTCCodecStats/mimeType
Title: RTCCodecStats: mimeType property

• https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml (1 time) (Note! This may be a new URL 👀)

(comment last updated: 2024-03-14 22:51:10)

[hamishwillee]

Reviewer, note that this shouldn't affect your review, as it is what the spec says.

---

Specifically, "media sampling rate" is what the spec says. However this does not match RTCRtpCodecParameters.clockRate - which is usually where I'd expect the data to come from.

Note that RTCCodecStats.clockRate is the media sampling rate, and RTCRtpCodecParameters.clockRate is the clock rate is the rate at which the codec's RTP timestamp advances (according to docs).
Most codecs have specific values or ranges of values they permit; see the IANA payload format media type registry for details.

This need not be the same as the codecs sampling rate - according to wikipedia the video codecs typically use a clock rate of 90000 so their frames can be more precisely aligned with the RTCP NTP timestamp, even though video sampling rates are typically in the range of 1–60 samples per second.

EDITED - confirming in w3c/webrtc-stats#785

[wbamberg]

Right, so we could fix this in a follow-up if it turns out to be wrong.

[dipikabh]

Hi @hamishwillee, thanks for this work!
I've only done a language review. I understand some of the sentences are as they appear on other similar pages. I've commented/asked questions in case there is scope for improving clarity.

[dipikabh]

Suggested change

	A {{domxref("DOMHighResTimeStamp")}} value indicating the time at which the activity described by the statistics in this object was recorded, in milliseconds elapsed since the beginning of January 1, 1970, UTC.
	A {{domxref("DOMHighResTimeStamp")}} value indicating the time when the activity described by the statistics in this object was recorded. It is measured in milliseconds since January 1, 1970, UTC.

[hamishwillee]

I'm good with this but have added to my notes to change globally once this and my other ones merge.

[dipikabh]

Is this what we intend to say here:

Suggested change

	The value should be accurate to within a few milliseconds but may not be entirely precise, either because of hardware or operating system limitations or because of [fingerprinting](/en-US/docs/Glossary/Fingerprinting) protection in the form of reduced clock precision or accuracy.
	The value is accurate to within a few milliseconds, though it might not be entirely precise because of hardware or operating system limitations. Additionally, [fingerprinting](/en-US/docs/Glossary/Fingerprinting) protection could reduce the precision or accuracy of the time reported.

[hamishwillee]

No. My versions says "should be" within a few ms, whereas your version must be accurate to within a few ms irrespective of all factors. I actually don't know which it is, so would rather say "should be".

The bigger problem is that this text is many years old - all I've done is propagated the original info in a dictionary. I can't be sure from the spec that this is still true. I've asked here w3c/webrtc-stats#786

[dipikabh]

Got it - "is" vs "should be", makes sense

Good move to to seek clarification 👍

[hamishwillee]

@dipikabh Thanks for the review. I've accepted most of it. For the remainder I'll do as a post process against all the duplicates "at some point" (have taken a copy of actions)

[dipikabh]

Thanks, @hamishwillee. The changes and your clarifications/edits look good.

Only one nit in the RTCCodecStats/clockRate page (#32452 (comment)), but leaving my +1

[hamishwillee]

thanks @dipikabh - appreciate your patience.

[hamishwillee]

@wbamberg Can you please give this a look since you reviewed my other WebRTC stats PRs? It's had editorial/language review from @dipikabh already - some of those are outstanding because I'll do them as a job-lot later across all the docs.

There is a technical question about timestamps in #32452 (comment) - still hoping to get some info to be "certain" on that. But if you know about this already ...

[wbamberg]

Thanks Hamish! It's been a while since I saw one of these, it was hard to remember what they are supposed to look like! I had one super-nit, so approving anyway.

[hamishwillee]

Thanks very much @wbamberg (and @dipikabh ). I appreciate these are not fun to review!