Commit e15be302 authored by paulwilkins's avatar paulwilkins

Fix for encoder slowdown (for speeds >= 3)

Some clips in nightly unit test exhibiting significant encoder slowdown which
appears to bisect to Change-Id: I692311a709ccdb6003e705103de9d05b59bf840a.

The above change allowed for emergency iterations of the recode loop and
adjustment of the Q range if there is a large rate miss.

This patch disables the above adaptation for cases of cpu_speed >= 3 or more
specifically where cpi->sf.recode_loop >= ALLOW_RECODE_KFARFGF.

For speeds >= 3 the code does not currently run a dummy bit pack operation
inside the recode loop. Without this dummy pack operation there is no up to
date estimate of the current frame's size to use as a basis for assessing the
requirement for a recode. In practice it was using the previous frames size (or 0
for the first frame) which could cause odd behavior.

If we require the emergency rate correction added in  Change-Id: I6923.. for
the higher speed settings it will be necessary to enable the dummy pack
which will in turn hurt encode speed.


Change-Id: I4fb3c6062ca9508325a6f31582f8e80f1a9b126f
parent 6843e7c7
......@@ -2740,7 +2740,8 @@ static int recode_loop_test(VP9_COMP *cpi, int high_limit, int low_limit, int q,
// Force recode for extreme overshoot.
if ((rc->projected_frame_size >= rc->max_frame_bandwidth) ||
(rc->projected_frame_size >= big_rate_miss_high_threshold(cpi))) {
(cpi->sf.recode_loop >= ALLOW_RECODE_KFARFGF &&
rc->projected_frame_size >= big_rate_miss_high_threshold(cpi))) {
return 1;
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment