This reverts commit 9b25f3067485b32442e13964df098903736c3fd8 to
reinstate the reverted commit with fixes that solved the build issues
when --enalbe-clpf is used in configure.
Change-Id: I15447cae7fa9b3deb27976345dc3db230a4a7a60
These signals were in the uncompressed frame header (as a temporary
hack), which caused two problems:
* We don't want that header to be duplicated in the slice header
* It was necessary to signal the number of bits to transmit up front
However, the filter size can be 128x128 which is greater than the SB
size, and a decoder wouldn't be able to know whether to read a bit or
not until the final SB of that 128x128 block has been decoded
(depending on whether the 128x128 is all skip or not). Therefore the
signalling was changed for 128x128 blocks so that every top left SB of
a 128x128 filter block contains a signal regardless of whether the
block is all skip or not. Also, all the MB's of 128x128 block are
filtered even if they are skip MB's. This gives the signal a purpose
even when the 128x128 block is all skip, and it also gives a slight
coding gain as it leaves a way to filter skip blocks, which was
previously forbidden.
Low latency:
PSNR YCbCr: -0.19% -0.14% -0.06%
PSNRHVS: -0.15%
SSIM: -0.13%
MSSSIM: -0.15%
CIEDE2000: -0.19%
High latency:
PSNR YCbCr: -0.03% -0.01% -0.09%
PSNRHVS: 0.04%
SSIM: 0.00%
MSSSIM: 0.02%
CIEDE2000: -0.02%
Change-Id: I69ba7144d07d388b4f0968f6a53558f480979171
When CLPF was extended to chroma, the chroma RDO accidentally
discarded the optimal block size found in the luma RDO.
PSNR YCbCr: -0.25% 0.05% 0.06%
PSNRHVS: -0.19%
SSIM: -0.36%
MSSSIM: -0.23%
Conflicts:
av1/common/clpf.c
Change-Id: Ie49cd30f9276a311ada88cb2f13d14757617f030
This commit ports a CLPF change from aom/master by manually
cherry-picking:
7560123c066854aa40c4685625454aea03410b18
Change-Id: I61eb08862a101df74a6b65ece459833401e81117
