Add CPU metrics

[henbos]

Now that we have a gate for hardware exposure, can we add CPU% metrics to getStats()?

Tagging @pes10k for privacy concerns.

[vr000m]

I am supportive of this, is there a proposal for this? vis-a-vis the compute-pressure proposal?

[anssiko]

@kenchris can speak for the Compute Pressure if some type of coordination would be beneficial.

[henbos]

The context here is for evaluating the performance of intensive video conferencing web apps e.g. encoding, recoding, rendering, effects processing, etc. Google Meet is one example. We do specifically want the granularity of CPU% rather than an enum. This gives more fingerprinting surface than an enum, but it is also guarded behind a getUserMedia() permission prompt (camera/microphone actively capturing) or fullscreen usage, so this is not useful for passive tracking.

[fippo]

This would be much easier than the current approach of summing up the total encode and decode times, dividing them by the core count (and multiplying by some factor)

[vr000m]

Also related to #245

[bdrtc]

so, CPU% metric will add to which stats object ? or add a new rtcstatstype.?

it's useful in video conference for performing quality limitation in receiver end（webrtc support this in sender side）

[bc-lee]

This would be much easier than the current approach of summing up the total encode and decode times, dividing them by the core count (and multiplying by some factor)

Hardware encoders/decoders may also queue frames internally, so abnormally high encode/decode times may be reported even in situations where performance is not degraded.

[henbos]

Because the CPU% is a system-wide metric I think we should add a new stats dictionary, e.g. RTCSystemStats, and we could guard the exposure of that entire object on the HW exposure criterion. The alternative would be to add it to RTCPeerConnectionStats simply because that is a singleton that always exists.

Hardware encoders/decoders may also queue frames internally, so abnormally high encode/decode times may be reported even in situations where performance is not degraded.

Agree it's just a heuristic and sometimes it is wrong. This issue is about adding actual system information, not proxy info!

[pes10k]

Regarding the gate, I understand why gating on capturing context makes sense, but I dont think its appropriate to consider fullscreenElement !== undefined as a gate. If I understand correctly, there are sites where i might have a fullscreen element that are both low engagement and not related to WebRTC (for example, <video>) and where I don't wish to be fingerprintable.

[henbos]

@pes10k Can you file a separate issue regarding fullscreen and fingerprinting? The intended use case for that was Cloud Gaming and being able to detect HW decoders even though the client is not sending, only receiving

[henbos]

Or are you OK with the gate for for previously exposed metrics (e.g. HW encoder/decoder support) but not OK with it for CPU%? If so we could split up the gate into two different gates as part of this issue

[pes10k]

Sure no problem #712