Update VP8 encode options to speed up encoding for remoting

remoting/base/encoder_vp8.cc

 // Copyright (c) 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "remoting/base/encoder_vp8.h"
 
 #include "base/logging.h"
 #include "media/base/callback.h"
 #include "media/base/yuv_convert.h"
 #include "remoting/base/capture_data.h"
@@ skipping 81 matching lines @@
   CHECK(algo);
   vpx_codec_err_t ret = vpx_codec_enc_config_default(algo, &config, 0);
   if (ret != VPX_CODEC_OK)
     return false;
 
   // Initialize active map.
   active_map_width_ = (size.width() + kMacroBlockSize - 1) / kMacroBlockSize;
   active_map_height_ = (size.height() + kMacroBlockSize - 1) / kMacroBlockSize;
   active_map_.reset(new uint8[active_map_width_ * active_map_height_]);
 
-  // TODO(hclam): Tune the parameters to better suit the application.
   config.rc_target_bitrate = size.width() * size.height() *
       config.rc_target_bitrate / config.g_w / config.g_h;
   config.g_w = size.width();
   config.g_h = size.height();
   config.g_pass = VPX_RC_ONE_PASS;
-  config.g_profile = 1;
-  config.g_threads = 1;
+
+  // Value of 2 means using the real time profile. This is basically a
+  // redundant option since we explicitly select real time mode when doing
+  // encoding.
+  config.g_profile = 2;

[Wez, 2011/06/20 19:55:01]

Is the value 2 not defined somewhere as e.g. kVpxRealTimeProfile or something?

If we explicitly select real-time mode when doing encoding, why do we need this
here?  Does the mode we select when encoding override the config, in which case
should we get rid of that override and just set the profile here?

[Alpha Left Google, 2011/06/20 20:02:08]

The value is not defined in the VP8 API. It basically changes context for
different codecs in libvpx. I set it here because this is one of the basic
settings, even though it is overrided by VPX_DL_REALTIME below so we know what
is in the settings.

+
+  // Use 2 threads to do encoding.
+  config.g_threads = 2;

[Wez, 2011/06/20 19:55:01]

nit: Why use 2, not 3 or 4 or 7?  I'd expect a comment like:

// Using two threads gives N% speedup on multi-core systems, with only M% loss
on single-core systems.

or

// Using two threads gives N% speedup; more than two gives less significant
benefit.  We don't care about single-core systems.

[Lambros, 2011/06/20 20:02:07]

Drive-by: I'd also like to know where the numbers below (20, 30, 1, 20) came
from.
On 2011/06/20 19:55:01, Wez wrote:

   config.rc_min_quantizer = 20;
   config.rc_max_quantizer = 30;
   config.g_timebase.num = 1;
   config.g_timebase.den = 20;
 
   if (vpx_codec_enc_init(codec_.get(), algo, &config, 0))
     return false;
+
+  // Value of 16 will have the smallest CPU load. This turns off subpixel
+  // motion search.
+  if (vpx_codec_control(codec_.get(), VP8E_SET_CPUUSED, 16))
+    return false;
+
+  // Use the lowest level of noise sensitivity so as to spend less time
+  // on motion estimation and inter-prediction mode.
+  if (vpx_codec_control(codec_.get(), VP8E_SET_NOISE_SENSITIVITY, 0))
+    return false;
   return true;
 }
 
 static int RoundToTwosMultiple(int x) {
   return x & (~1);
 }
 
 // Align the sides of the rectangle to multiples of 2 (expanding outwards).
 static gfx::Rect AlignRect(const gfx::Rect& rect) {
   int x = RoundToTwosMultiple(rect.x());
@@ skipping 154 matching lines @@
     rect->set_y(updated_rects[i].y());
     rect->set_width(updated_rects[i].width());
     rect->set_height(updated_rects[i].height());
   }
 
   data_available_callback->Run(message);
   delete data_available_callback;
 }
 
 }  // namespace remoting