- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Sat, 11 Feb 2023 08:17:40 +0000
- To: public-webrtc-logs@w3.org
> My understanding is: ... Your understanding is correct but one clarification is needed in your use of the word "any". It's not "if MC's powerEfficient is exposed for any device, period" rather it is "if MC's powerEfficient is exposed for the same codec, resolution, frame rate and scalability mode that WebRTC is using right now". 99% of the time the device queried in MC is the same device that is in use by WebRTC and getStats's powerEfficientDecoder exposes the _same bit of information_. But 1% of the time HW fails resulting in WebRTC falling back to a SW implementation for the same codec configuration. Basically: - MC's powerEfficient already allows querying for HW device support before even using the HW. - getStats' powerEfficient is initially expected to be the same as MC's powerEfficient, but if HW error happens during the use of the device, SW fallback can happen, changing this bit. Simply put, if you want to query device support you use MC with any configuration you like and you can make repeated queries for a range of different configurations. If you want to query current operational status of a WebRTC session, you use getStats for the current configuration. Using getStats to query support in a scenario where MC is already available is technically possible by reconfiguring the encoder/decoder, but is backwards and jumping through unnecessary hoops when MC already exposes this information for you without the additional overhead and API complexity. > If [well-defined MC gating steps] doesn't exist, then the change in this PR is worrying, since it would change a useful, well defined privacy protection, into a privacy protection that was loosely or (un-)defined. Correct. MC's [fingerprinting note](https://w3c.github.io/media-capabilities/#decoding-encoding-fingerprinting) is not a well-defined algorithm. We may want to file an issue on the MC spec to clarify this. But there are problems too with having getStats be more restrictive than MC (breaks Cloud Gaming) and it is also a problem if multiple specs try to solve how to expose the same bit of information differently. We should be consistent amongst specs and to me it makes more sense if getStats references the HW exposure spec than the other way around. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-stats/pull/732#issuecomment-1426657623 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 11 February 2023 08:17:41 UTC