RTCStatsReport - add stats-type features and stats

[hamishwillee]

This PR updates RTCStatsReport to include returned stats, sorted by type_ key. It combines data from:

• RTCIceCandidatePairStats, RTCIceCandidateStats, RTCRemoteOutboundRtpStreamstats, RTCRtpStreamStats (all removed)
• Data from Bugzilla and Internet, as shown below
• Data from this webRTC test: https://wpt.live/webrtc-stats/supported-stats.https.html
• Data from an updated BCD collector: https://mdn-bcd-collector.gooborg.com/tests/api/RTCStatsReport

The BCD collector resulted in a large number of ranged values. In order to get this in:

• In one commit
  • all ranged values in derived platforms have been set to mirrored. (e.g. android platforms, safari ios, edge, ff android
  • ranged values like Chrome >= 80 were modified to be precise Chrome = 80.
• In next commit:
  • Fixed up the parent type_ range to the minimum for contained subfeatures.

The ranged value commit was done separately so should be easy to review.

---

FF Data

• FF55 data https://bugzilla.mozilla.org/show_bug.cgi?id=1348657 : Implement framesEncoded, pliCount, nackCount and firCount in webrtc stats
• FF56 https://bugzilla.mozilla.org/show_bug.cgi?id=1374465 framesDecoded
• FF104 https://bugzilla.mozilla.org/show_bug.cgi?id=1780282 Implement some more inbound rtp stats.
  framesPerSecond, jitterBufferDelay, jitterBufferEmittedCount, totalSamplesReceived, concealedSamples, silentConcealedSamples
• FF101: https://bugzilla.mozilla.org/show_bug.cgi?id=1766473 Implement some inbound and outbound rtc stats needed for MS Teams : frameWidth, frameHeight, framesReceived
• FF111 https://bugzilla.mozilla.org/show_bug.cgi?id=1728357 framesDropped
• FF106 https://bugzilla.mozilla.org/show_bug.cgi?id=1790508 Add newly available RTP and RTCP stats: qpSum, totalDecodeTime, totalInterFrameDelay, totalSquaredInterFrameDelay, lastPacketReceivedTimestamp, headerBytesReceived, fecPacketsReceived, fecPacketsDiscarded, totalProcessingDelay, concealmentEvents, insertedSamplesForDeceleration, removedSamplesForAcceleration, audioLevel, totalAudioEnergy, totalSamplesDuration
• FF68 https://bugzilla.mozilla.org/show_bug.cgi?id=1515716 Refactor WebRTC RTP stats types: remoteId, framesDecoded, bytesReceived, nackCount
• FF63 https://bugzilla.mozilla.org/show_bug.cgi?id=1481851 getStats: kind is missing from RTPStreamStats - but note this is seen as inbound by recipient
• FF tests - what is expected: https://searchfox.org/mozilla-central/source/dom/media/webrtc/tests/mochitests/stats.js#8_
• Chrome 79 bytesReceived: https://groups.google.com/g/discuss-webrtc/c/X8q5Ae9VKco/m/oEiGuteoBAAJ
• Chrome 111 totalInterFrameDelay: https://groups.google.com/g/discuss-webrtc/c/qo2-96L5jEw
• Chrome 111 playoutid. From link above, can then find it in changelist: https://webrtc.googlesource.com/src.git/+log/refs/branch-heads/5563?pli=1#

Fixes #6879.

[hamishwillee]

@queengooborg I have updated the FF results using searchfox and bugzill - it turns out the IDL is quite accurate at working out what is supported. Also added a few values from various Chrome notes around the place.
But vast majority for Safari and Chrome I can't work out - it isn't just bisecting, some require specialist setup.

We can guess for some of them using data from here: https://webrtc-stats.callstats.io/verify/ i.e. use the tested versions as introduced versions. For Chrome at least that is probably reasonable, because most of this came in on the reported version M79/8 as far as I can tell.

Advicde appreciated.

[hamishwillee]

Actually, maybe I can reasonably bisect using a combination of https://wpt.live/webrtc-stats/supported-stats.https.html and https://webrtc-stats.callstats.io/verify/

[hamishwillee]

@queengooborg This is the start of what is going to replace RTCInbountRtpStreamStats. My current plan is to do all the values like this - so all inbounds will be inbound_rtp_Xxxx and there will be keys for outbound_rtp_Xxxx and so on that will be peers.

Do you think this is OK? Or should we have deeper grouping - e.g. a feature inbound_rtp and fields below it?

[queengooborg]

This looks good to me, we can always make changes to the structure in the future if we need to!

[hamishwillee]

@queengooborg Not as much success as I'd hoped:

1. Browserstack
   • won't run the https://wpt.live/webrtc-stats/supported-stats.https.html on FF (windows 11) or macOS (safari).
   • Allows me to test Chrome back to v80.
   • Allows me to test on Safari on iOS at least in current version.
   • I don't think the test is particularly robust.
2. So what I have here is a BCD with
   • features for all stats in the test and spec, with spec links
   • All values are true, false, or a particular value.
   • True means "supported in earliest version I could test" (FF that is 110, for chrome 80, for Safari iOS latest) OR,
   • for FF it means I found additional info in bugzilla. Some of this info is a bit confusing. I suspect that some of the stuff went in earlier.
3. Summary of testing so far here: https://docs.google.com/spreadsheets/d/12N5lcpT8DUqiL7G7wyocYgf5OAeYfUQHKO6OwflZos8/edit?usp=sharing

I think we are going to have little choice but to mark things as either "true" or better ">=Version" for the unknown cases and add an exception. That is not great, but it is better than what we have by a mile, and will get progressively better as time goes on.

Thoughts? If not, I need direction.

[queengooborg]

I'm going to mark this as blocked on #19014. We're going to need to spend a lot of time researching this to determine the proper version numbers, and it doesn't align with the 2020+ data goal so I'm not sure we can justify the research time right now (even though it's a part of our dictionary removals goal).

[hamishwillee]

@queengooborg PS, on further thought, all this data should be in RTCStatsReport - this is the object used to access the data - which is returned by getStats - make sense?

[queengooborg]

Yes, we should put all the data into RTCStatsReport.

While we're at it, maybe we should structure the data into a tree, with subfeatures for each stats type and subfeatures under those for each property? Example:

{
	"api": {
		"RTCStatsReport": {
			"__compat": { ... },
			"candidate-pair_type": {
				"__compat": {
					"description": "<code>candidate-pair</code> stats type",
					...
				},
				"availableIncomingBitrate": {
					"__compat": { ... }
				}
			}
		}
	}
}

WDYT?

[hamishwillee]

@queengooborg

While we're at it, maybe we should structure the data into a tree, with subfeatures for each stats type and subfeatures under those for each property? Example:

Yes :-). I didn't think it mattered originally, but we may well want to link different parts of these subfeatures into different docs. Easier if we split it this way.

[hamishwillee]

@queengooborg Done - now all in RTCStatsReport and renamed. I dropped the old commits from the history.

[queengooborg]

I dropped the old commits from the history.

Oh no need to worry about dropping commits and such! BCD strictly squash merges all PRs so they're all compressed into one anyways!

[hamishwillee]

Thanks for merging those @queengooborg . I wish we could just merge this - we'd be no worse off in any way, and significantly better for end users.

I am assuming that this is basically on hold while you try make better tests and until decisions on ranged values is made.

[jan-ivar]

I see this duplicates some fields which I suppose is to be expected based on mdn/mdn#384 (comment)?

[schalkneethling]

I see this duplicates some fields which I suppose is to be expected based on mdn/mdn#384 (comment)?

Thanks so much for jumping in here @jan-ivar - @queengooborg, Jan-Ivar is the person I mentioned yesterday (WebRTC Media Senior Staff Software Engineer).

[hamishwillee]

I see this duplicates some fields which I suppose is to be expected based on mdn/mdn#384 (comment)?

@jan-ivar Yes. They are duplicated as sub features of the different selectors, and that is both desirable and expected. I added a response to your response in the linked topic.

[queengooborg]

Thank you @jan-ivar for joining in!

As mentioned in the issue on mdn/mdn, our biggest issue is working out what browser versions each type and property was introduced. While http://wpt.live/webrtc/RTCPeerConnection-mandatory-getStats.https.html is helpful, it doesn't work on all browser versions, nor does it cover all of the properties.

I've attempted to reverse engineer the code for use in our own tooling (see openwebdocs/mdn-bcd-collector@fcd51bc), but I'm running into some issues with it, namely:

• I don't know what triggers remote-inbound-rtp and remote-outbound-rtp stats. In the WPT.live test, there's just a 20 second maximum delay, but adding that into our own code doesn't seem to trigger the stats types.
  • I haven't been able to trigger remote-outbound-rtp stats.
  • Related properties to those stats don't seem to be working either.

[hamishwillee]

@queengooborg YEEE HAAARRR. All done. Ready for you to look at.

Last pass was to get a few cases which had "true" against them. Just FYI:

• api.RTCStatsReport.type_data-channel - FF - changed to earliest version of contained subfeatures
• api.RTCStatsReport.type_inbound-rtp.audioLevel - safari - bsection testing indictates "version_added": "14.1", removed 16.3
• api.RTCStatsReport.type_remote-inbound-rtp.roundTripTime - FF - v96 by bisection.
• api.RTCStatsReport.type_remote-outbound-rtp - - safari - used earliest of subfeatures = 11
• api.RTCStatsReport.type_remote-outbound-rtp.roundTripTime -
  • chrome BCD collector can't tell. Used https://wpt.live/webrtc-stats/supported-stats.https.html and it said fail. Set to false
  • safari BCD collector can't tell. https://wpt.live/webrtc-stats/supported-stats.https.html cannot tell - so set to false.
  • That means all false, so I remove it.
  • Could be a test issue, you can review at will :-)

[queengooborg]

Thanks for all your hard work on this, @hamishwillee! Let's go ahead and get this landed right away!

[hamishwillee]

@queengooborg YOU TOO!!!! This is such a good step.

FYI, once I have the docs I'll come back and link to the MDN pages.