VP9 firstpass: Bugfix when mi_col_start/end is odd
Before this patch, if mi_col_end was odd, then the for loop for 'mb_col'
was looping once LESS than it should have been.
For example, if mi_col_end = 47, then the loop was terminating when
mb_col == 23. However, the correct behavior would be to terminate when
mb_col == 24.
The issue was introduced in:
https://chromium-review.googlesource.com/c/webm/libvpx/+/423279
This can lead to many of the stats being inaccurate, for such videos
(with mi_col_start/end having an odd value).
As an example:
Even for very static content, fp_acc_data->intercount can never reach the
same value as num_mbs. And in turn, pcnt_inter can never reach the value 1
(that is, 100%). This would lead to very static videos NOT being marked
static, and encoded like regular videos.
Note: this is just one possible effect based on observation. Other
issues are also possible based on other stats.
Improvement on some test clips:
-------------------------------
- One test clip saw a gain of -2.580% in VBR mode (and -3.153% in Q
mode). The reason for improvement: a wrongly detected scene cut was
avoided due to corrected value in 'this_frame->pcnt_inter'.
- Some very static clips correctly marked as having 100% zero motion.
This avoided addition of unncecessary alt-refs, thereby reducing the
bitrate.
BDRate (PSNR) on regular sets (VBR mode):
-----------------------------------------
lowres: 0.0
midres: -0.027 (some clips were better/worse, but I double checked that
changes were as expected, given correction in stats calculation).
hdres: 0.0
STATS_CHANGED for the types of videos described above.
projects / libvpx / commit