You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As the QP value increases, the blocking defects around the edges of the moving object with noticeable changes become more obvious. When the motion is slow, the defects are very visible even if I don't pause.
To mitigate this problem, I modified the weights of va.hpTempAct based on m_QP.
These weights are based on traversing the coded of Adaptive QP from 15 to 45 after each modification of my qpFactor and were obtained after VMAF, SSIM detection plus actual viewing inspection.
I think XPSNR is extremely valid, but motion defects at high QP may not be an issue with XPSNR. It's just a solution I'm currently using with VVC.
Even if I have to move the qpFactor, in my opinion it should be in a small range of intervals like 1.0 to 2.0, otherwise the point of XPSNR may be lost.
For example when I coded an clean 1920x1080 25fps 10bit 4:2:0 Y4M by Adaptive QP39: vvencFFapp -i MQPA-PreRAW_10_420.y4m --Preset slow --Level 5.1 --FrameRate 25 --QP 39 --PerceptQPA 1 --IntraPeriod 250 --GOPSize 32 --MinIntraDistance 1 -b MQPA-39.266
e.g. In a long shot, the girl rides a wooden horse that rotates sideways to the front as the camera slowly pulls up.
Results from programmes compiled using different weights:
Mitigation, not solution.
Defects are reduced to visually negligible when 0.4 * va.hpTempAct in QPA39.
Random blocks still appear to surround the edges.
Here's my entire project change, based on vvenc-v1.13.0-rc1 before merging the ARM optimisation:
As the QP value increases, the blocking defects around the edges of the moving object with noticeable changes become more obvious. When the motion is slow, the defects are very visible even if I don't pause.
To mitigate this problem, I modified the weights of
va.hpTempAct
based onm_QP
.These weights are based on traversing the coded of Adaptive QP from 15 to 45 after each modification of my
qpFactor
and were obtained after VMAF, SSIM detection plus actual viewing inspection.I think XPSNR is extremely valid, but motion defects at high QP may not be an issue with XPSNR. It's just a solution I'm currently using with VVC.
Even if I have to move the qpFactor, in my opinion it should be in a small range of intervals like 1.0 to 2.0, otherwise the point of XPSNR may be lost.
For example when I coded an clean
1920x1080 25fps 10bit 4:2:0 Y4M
by Adaptive QP39:vvencFFapp -i MQPA-PreRAW_10_420.y4m --Preset slow --Level 5.1 --FrameRate 25 --QP 39 --PerceptQPA 1 --IntraPeriod 250 --GOPSize 32 --MinIntraDistance 1 -b MQPA-39.266
e.g. In a long shot, the girl rides a wooden horse that rotates sideways to the front as the camera slowly pulls up.
Results from programmes compiled using different weights:
va.hpVisAct = std::max(double(1 << (bitDepth - 6)), va.hpSpatAct + 2.0 * va.hpTempAct)
va.hpVisAct = std::max(double(1 << (bitDepth - 6)), va.hpSpatAct + 1.0 * va.hpTempAct)
va.hpVisAct = std::max(double(1 << (bitDepth - 6)), va.hpSpatAct + 0.4 * va.hpTempAct)
Mitigation, not solution.
Defects are reduced to visually negligible when
0.4 * va.hpTempAct
in QPA39.Random blocks still appear to surround the edges.
Here's my entire project change, based on vvenc-v1.13.0-rc1 before merging the ARM optimisation:
Many thanks to all the vvenc contributors.
The text was updated successfully, but these errors were encountered: