Add CPU metrics about webrtc-stats HOT 12 OPEN

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.

from webrtc-stats.

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.

from webrtc-stats.

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!

from webrtc-stats.

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

from webrtc-stats.

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

from webrtc-stats.

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)

from webrtc-stats.

Also related to #245

from webrtc-stats.

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）

from webrtc-stats.

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.

from webrtc-stats.

@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

from webrtc-stats.

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

from webrtc-stats.

Sure no problem #712

from webrtc-stats.