Comments (12)
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.
Related Issues (20)
- Conformance criteria incompatible with standards-track HOT 7
- RTX and FEC stats are incomplete. HOT 12
- Should we flatten the hierarchy? HOT 5
- Change playoutdelay to jitterbuffertarget HOT 2
- Add clarification that inbound-rtp.bytesReceived includes retransmissions. HOT 6
- RTCAudioSourceStats.audioLevel - what algorithm described in totalAudioEnergy? HOT 3
- Delete the obsolete section, "track" and "stream" stats - they don't exist anymore HOT 3
- Improve test coverage HOT 1
- add framesInput stats to rtcoutboundrtpstreamstats HOT 6
- Stats example uses confusing variable names
- Exposing audio interruption metrics to JavaScript
- Define a mechanism for setting the trigger duration for a video freeze
- Sender-side packetsReceived can be negative from garbage RRs HOT 1
- Change "Does not" to "must not"
- Make "not present" reference "map/exist"
- Is codec.sdpFmtpLine present when there is no fmtp line in the SDP? HOT 2
- Lifetime of outbound-rtp should start BEFORE first packet is sent HOT 3
- Should RTCRtptransceiver.stop() cause inbound-rtp stats to disappear?
- RTCCodecStats.clockRate - media sampling rate or the codec clock rate?
- RTCStats.timestamp - fingerprinting and since epoch
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webrtc-stats.