tree 0a5a0096f442bb3b9a2d113d507fc37ea9efbbe3
parent 3d85380ad8f1b8870e713e843bf438cfc37dd1f7
author Cheng Chen <chengchen@google.com> 1584058957 -0700
committer Cheng Chen <chengchen@google.com> 1584722104 +0000

Allow more partition searches for screen content

Summary:
Speed 1: ~2% gain on screen content videos, with ~25% slowdown.

An observation of screen content videos is that it tends to
select large partition block sizes, because of good prediction.
The ml partition search speed features sometimes skip
these partition searches. And these features would limit the
maximum partition block size.
This cl forces the partition search to always start at largest
possible block size, allows search partition none, and rectangular
block sizes.

The result is as follows:
Speed 4          avg_psnr    ovr_psnr    ssim
screen_content     -2.98       -3.02      -4.28

Screenn content videos from other set:
speed 4          avg_psnr    ovr_psnr    ssim
wikipedia420       -8.68       -8.67      -9.31
Dinner_1080p       -6.22       -6.32      -6.31

For speed 1, there's one clip with weird result (down 14%).
If excluding it, the performance is:
Speed 1          avg_psnr    ovr_psnr    ssim
screen_content     -1.83       -1.87      -2.71

Screenn content videos from other set:
speed 1          avg_psnr    ovr_psnr    ssim
wikipedia420       -6.47       -6.49      -6.74
Dinner_1080p       -6.46       -6.59      -6.79

Local speed tests show about ~25% slowdown on screen content
videos, since we allow more partition searches.

Other discoveries and things to address:
(1). Speed 0 is ~7.5% better than speed 1 on screen content set.
On other test sets, the difference is ~2%.
It suggests that the ml partition speed feature is not working
equally well on screen content set than other test sets.

(2). Speed 0 encoding time on screen content videos is 3x of speed 1.
Therefore I think this change getting ~2% back on speed 1,
with 25% slowdown is a good trade-off.

Change-Id: I71668ace8d595f2868d3d19714e315dc3402a25b