- From: Erik Språng via GitHub <sysbot+gh@w3.org>
- Date: Fri, 18 Apr 2025 18:43:21 +0000
- To: public-webrtc-logs@w3.org
> My understanding is that, if the encoder is providing PSNR, there is probably no perf issue in doing so for every frame. For encoders that do not support PSNR, it is ok to not expose that value (modulo maybe a fingerprinting note). > > Based on this, I would tend to remove `psnrMeasurements` and just keep `psnrSum`. That's not quite the case. Some hardware encoders do expose PSNR at a minimum of performance penalty, so exposing it for every frame is fine there. However, there are a number of software encoders (e.g. libvpx) that have the ability to calculate PSNR but do not typically do so. It's commonly use in RD based control methods which use a lot of CPU are not suitable for realtime encoding. However, the PSNR feature _can_ be enabled/disabled on a per-frame basis even in the fast encoding modes, which is what is being discussed here. Getting the values are still valuable, but we don't want to enable it for every frame as that will come at a noticeable CPU penalty. Then of course there are encoders that don't have the ability to output PSNR at all. Say we have a software encoders that does expose and hardware encoder of the same type the does not - and at runtime encoding is switched back and forth between hardware and software (e.g. due to resolution constraints or just random failures), what do we do then? I still think the easiest way is to allow the update frequency be zero for extended periods of time. The user just has to be aware that the metric may or may not be available at any given time, so if no PSNR measurements have been added between calls to getStats() you have to interpret that as "undefined" not "not available". -- GitHub Notification of comment by sprangerik Please view or discuss this issue at https://github.com/w3c/webrtc-stats/pull/794#issuecomment-2816008582 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 18 April 2025 18:43:22 UTC