Add frame level on/off bawp

[jianle973]

Enable frame level bawp based on histogram. Enabled for speed 2 and above.

33 frame RA results for speed 2 and 3 are as follows:

+---------+--------+-------+-------+-------+----------+----------+
| Summary | Y | U | V | YUV | Enc-time | Dec-time |
+---------+--------+-------+-------+-------+----------+----------+
Speed2, Overall w/o B2 (RA) +0.00% +0.01% +0.01% +0.00% 99.51% 100.12%
Speed3, Overall w/o B2 (RA) +0.00% +0.01% +0.03% +0.00% 99.45% 99.53%

+---------+--------+-------+-------+-------+----------+----------+

[jianle973]

Thanks @yeqing-wu for reviewing the PR. I have tried to address all the comments in the new commit.

[yeqing-wu]

LGTM.

It is required to provide the anchor commit number and the A1/A2 results in the commit message. I think you can put this info in the PR conversation message. To prevent GitHub from messing up your table, you can wrap it with ``` before and after, like:

+---------+--------+-------+-------+-------+----------+----------+
| Summary |   Y    |   U   |   V   |  YUV  | Enc-time | Dec-time |
+---------+--------+-------+-------+-------+----------+----------+
| A1      | -0.02% | 0.24% | 0.21% | 0.00% | 97.8%    | 100.5%   |
| A2      | 0.10%  | 0.15% | 0.03% | 0.09% | 95.8%    | 99.8%    |
+---------+--------+-------+-------+-------+----------+----------+

[leolzhao]

Please add the separate class A1 and A2 results in the MR message? @jianle973

[jianle973]

33 frames results (speed 1) as follows:

+---------+--------+-------+-------+-------+----------+----------+
| Summary | Y | U | V | YUV | Enc-time | Dec-time |
+---------+--------+-------+-------+-------+----------+----------+
| A1 | +0.01% | +0.02% | +0.02% | +0.02% | 99.42% | 100.70% |
| A2 | +0.01% | -0.02% | +0.13% | +0.02% | 99.34% | 99.96% |

+---------+--------+-------+-------+-------+----------+----------+

[yeqing-wu]

Since it doesn’t meet the acceptance criteria for speed 1, should we move it to speed 4? And what is the commit ID of the anchor?

[leolzhao]

Since it doesn’t meet the acceptance criteria for speed 1, should we move it to speed 4?

Yes, we can enable it for speed 4 if the resutls with cpu-used = 4 is similar or better.

[jianle973]

Since it doesn’t meet the acceptance criteria for speed 1, should we move it to speed 4?

Yes, we can enable it for speed 4 if the resutls with cpu-used = 4 is similar or better.

It was 98.5% encoding time when I tested it on top v15. Not sure what's the problem. The running time deviation on our cluster could be the reason.

[jianle973]

Since it doesn’t meet the acceptance criteria for speed 1, should we move it to speed 4?

Yes, we can enable it for speed 4 if the resutls with cpu-used = 4 is similar or better.

33 frame RA results for speed 2 and 3 are as follows, no loss with 0.5% encoding time reduction.
+---------+--------+-------+-------+-------+----------+----------+
| Summary | Y | U | V | YUV | Enc-time | Dec-time |
+---------+--------+-------+-------+-------+----------+----------+
Speed2, Overall w/o B2 (RA) +0.00% +0.01% +0.01% +0.00% 99.51% 100.12%
Speed3, Overall w/o B2 (RA) +0.00% +0.01% +0.03% +0.00% 99.45% 99.53%

Now, it's enabled for speed 2+.

@yeqing-wu @leolzhao

[urvangjoshi]

@yeqing-wu @leolzhao : pls review again and resolve comments if ok.

[yeqing-wu]

Based on the FG16 agreement, the encoding savings required for lossy changes should be at least 1% to prevent the encoding time savings from being negated by machine variations. However, if there are no losses, it is okay to me.

[urvangjoshi]

@jianle973 : pls rebase and force-push to fix conflicts.

[jianle973]

@jianle973 : pls rebase and force-push to fix conflicts.

Rebased, thanks!