Monty authored May 28, 2019 and Monty Montgomery committed May 28, 2019

Move to unsigend arithmetic in LRF box accumulations, and simply guard
the one subtraction that can underflow (that was the reason we were
using signed ints to begin with).  Fixes an overflow in 12-bit encodes.

Otherwise trying to use `eprintln!` and `dbg!` would lead to an hang.

With the default max keyint of 10s, and common length fades found
in content, 256 frames is not sufficient to allow rate control
to adapt properly; it is barely even past the GOP boundary for
24 fps content.

This will introduce possible overflow problems with log_scale when
2-pass mode is introduced, if required.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

To ease validate the input from the C functions.

The number of ones to write the number of tile _rows_ in the bitstream
was incorrectly computed from the minimum tile _columns_.

The bug remained undetected because unless the video is larger than
MAX_TILE_WIDTH or bigger than MAX_TILE_AREA:

    min_tile_rows_log2 = min_tile_cols_log2 = 0

We performed a simple linear regression of the bitrate with
respect to the quantizer, operating on the logarithm of both.

The data set used was all of the video clips on
https://media.xiph.org/video/derf/
as well as subset3 (for extra I frame data).

To enable processing an arbitrarily large data set,
an online regression algorithm was implemented.
In practice, 440MB of text formatted data were sufficient.

An optimal content-independent scale estimator is up to an order of
magnitude off, depending on content complexity. Account for that.

These were derived by running encodes of many clips at each quantizer,
an logging their resolution, coded size, and log-space target quantizer.
The relationship appeears to be linear, unlike Theora, so the bucketing
by ibpp was removed in favour of a single value per frame type.

These values seem to give pretty good ballpark results; enough to
base trial frame encodes on them.

This also includes proper values for both B frame depths, and thus
removes the reuse of P frame scale/exp for B frames.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

The help text said it was, but we were not actually multiplying by
 1000.
Thanks to Derek Buitenhuis for the report.

Reduce the number of memory allocations by 75% by increasing the memory usage by
20%.

Yushin Cho authored May 13, 2019 and Yushin Cho committed May 20, 2019

The fix applies when tx rdo is turned on and "--tune Psnr" is used.

The coding gain with this fix at speed 2 with --tune Psnr

   PSNR | PSNR Cb | PSNR Cr | PSNR HVS |    SSIM | MS SSIM | CIEDE 2000
-0.4020 | -0.1592 | -0.0924 |  -0.2546 | -0.4039 | -0.3031 |    -0.1819

It's still sketchy, but not 100% broken, now.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Yushin Cho authored May 20, 2019 and Yushin Cho committed May 20, 2019

Because it has been quite confusing, when its sole effect is
to decide whether doing pixel reconstruction or not.

Enforce a lower bound of 1. Fixes #1211.

Now it is possible again to run both aom and dav1d decode tests in
parallel.

So that "use_filter_intra = false" is not coded for every intra mode block.

These are fixed size and stack allocated rather than malloc()'ed,
hopefully improving speed and reducing memory fragmentation.

Vecs that are passed across functions have not been converted.

Numeric analysis indicated 1089 +/- 5 in Q12.

Yushin Cho authored Apr 30, 2019 and Yushin Cho committed Apr 30, 2019

speed 5, (encoding time increase 14%~1%)
   PSNR | PSNR Cb | PSNR Cr | PSNR HVS |    SSIM | MS SSIM | CIEDE 2000
-1.4529 | -1.9177 | -1.8769 |  -1.4698 | -1.3873 | -1.3750 |    -1.6576

speed 1, 5 frames, (encoding time increase 44%~11%)
   PSNR | PSNR Cb | PSNR Cr | PSNR HVS |    SSIM | MS SSIM | CIEDE 2000
-1.3921 | -2.0810 | -1.5809 |  -1.4713 | -1.2711 | -1.2584 |    -1.7207

Add documentation of the encoderConfig for both impl and  public fields
Ref #1078