tree 45803631ddf2042dead9976275dd4ae87bd8aa10
parent bf71fb9f3d9c6d62abe0e69ea45bf1276f99841c
author Urvang Joshi <urvang@google.com> 1551216162 -0800
committer Urvang Joshi <urvang@google.com> 1551470312 +0000

Remove gf_zeromotion_pct.

The use of this value is preventing rate adjustment on clips
or sections that have very little motion but high noise and
this can give rise to some sections with massive overshoot/undershoot.

Cherry-picked from VP9:
https://chromium-review.googlesource.com/c/webm/libvpx/+/349170

On a test clip (VBR 150 frames)
-------------------------------
Earlier, the per-frame PSNR for AV1 was gradually getting worse, as 'q'
was fixed from 2nd frame onwards.
Now, a gradually better q is used, so that per-frame PSNR stays
relatively stable.

AV1 before: PSNR = 52.940, bitrate = 11971]
AV1 after:  PSNR = 53.556, bitrate = 12457]
[VP9:       PSNR = 53.866, bitrate = 13372]

Standard sets (VBR 150 frames)
-------------------------------
lowres: 0.082
- All neutral except one
- bridge_close_cif.y4m which looks worse in metrics at very high bitrate
end. But we reduced a massive overshoot in that video:
e.g. at target-bitrate=2800, actual bitrate = 6920 before, 4758 after.

midres: -0.013
- A few clips slightly better.
- And we reduced a massive overshoot in snow_mnt_480p.y4m:
e.g. at target-bitrate=3600, actual bitrate = 6300 before, 5375 after.

hdres (60 frames): -0.013
- mobcal_720p50.y4m: -0.377
- Others neutral

STATS_CHANGED

BUG=b/119104564

Change-Id: I08450c507ee3bdbef6d9bf317721a5b5b03303aa