- From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
- Date: Thu, 27 Feb 2025 17:41:55 +0000
- To: public-webrtc-logs@w3.org
PSNR is similar to qp so having it in getStats makes sense. As the paper says we have done this at a frequency higher than one per second on devices where battery consumption is a concern and it works there. Hardware encoder support makes this "cheaper" even. Note that the calculation is done by the encoder so can not be triggered by calling getStats with some magic option. I considered whether it was possible to gate it on the corruption detection RTP header extension but that would have been quite awkward since it is not closely related (not without precedence, quite a few statistics depend on header extensions) When I say "A/B testing" consider a project like [Jitsi moving to AV1](https://jitsi.org/blog/av1-and-more-how-does-jitsi-meet-pick-video-codecs/), in particular the "Metrics Captured" which, unsurprisingly, relies on getStats. See [here](https://youtu.be/zWvteeEkjJg?si=5wYeyGbNCXjjb7mF&t=465) for one uses PSNR to evaluate when it is available. Such experiments are designed not to compare :apple: to :banana: (different browsers, different operating systems) so letting a UA decide on sampling frequency is not a concern as long as it does so consistently. -- GitHub Notification of comment by fippo Please view or discuss this issue at https://github.com/w3c/webrtc-stats/pull/794#issuecomment-2688666883 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 27 February 2025 17:41:56 UTC