Allow calculating PSNR for Y/U/V components #3824
Conversation
by requesting this either as a option for all frames in SEncParamExt.bPsnrY (and U/V) or per-frame using SSourcePicture.bPsnrY (and U/V) The resulting data goes into SLayerBSInfo.rPsnr with is a three-element array for the Y/U/V components of the PSNR. This is disabled by default. Also removes the ENABLE_PSNR_CALC preprocessor define in favor of the API. See https://www.researchgate.net/publication/383545049_Low-Complexity_Video_PSNR_Measurement_in_Real-Time_Communication_Products by @YCSun-Meta for a research paper explaining the background.
|
@fippo Have you done any performance testing? |
|
Hi @BenzhengZhang , We did performance test on a mid-range device (Pixel 4 phone), and the psnr calculation takes ~350us. In addition, the patch also provides frame-level control. Meta have tested and enabled the feature on the RTC apps on all devices. Its reliability as a metric at scale has been |
|
if this is an API change, should you not increase .so version as well? |
Should be increased in next release. |
| @@ -3956,6 +3956,19 @@ int32_t WelsEncoderEncodeExt (sWelsEncCtx* pCtx, SFrameBSInfo* pFbi, const SSour | |||
| (iLayerSize << 3)); | |||
| #endif//LAYER_INFO_OUTPUT | |||
|
|
|||
| pLayerBsInfo->rPsnr[0] = NAN; | |||
There was a problem hiding this comment.
This change broke compiling with MSVC 2010 and 2012; they lack the NAN constant in math.h.
Not sure if MSVC 2012 really is within the scope of targets we need to support - but it did compile fine before this.
There was a problem hiding this comment.
Or put another way - does this strictly need to be NAN, or could we initialize it to some other trivial value, like 0 or -1 or something like that?
There was a problem hiding this comment.
I think setting it to 0.0 should work, will do a PR
which is not supported in some older compilers as pointed out in cisco#3824 Applications should always check whether they requested calculating PSNR before evaluating that field in the result.
which is not supported in some older compilers as pointed out in #3824 Applications should always check whether they requested calculating PSNR before evaluating that field in the result.
by requesting this either as a option for all frames in
SEncParamExt.bPsnrY (and U/V)
or per-frame using
SSourcePicture.bPsnrY (and U/V)
The resulting data goes into
SLayerBSInfo.rPsnr
with is a three-element array for the Y/U/V components of the PSNR.
This is disabled by default. Also removes the ENABLE_PSNR_CALC preprocessor define in favor of the API.
See
https://www.researchgate.net/publication/383545049_Low-Complexity_Video_PSNR_Measurement_in_Real-Time_Communication_Products
by @YCSun-Meta for a research paper explaining the background.