Experimental patch for adapting adaptation to CPU count on Mac.

webrtc/video/overuse_frame_detector.cc

Index: webrtc/video/overuse_frame_detector.cc
diff --git a/webrtc/video/overuse_frame_detector.cc b/webrtc/video/overuse_frame_detector.cc
index e589c191f42c4b926e766003742690e934881d00..3f340c349fa7fd23faa565e16621661a47f660d2 100644
--- a/webrtc/video/overuse_frame_detector.cc
+++ b/webrtc/video/overuse_frame_detector.cc
@@ -24,6 +24,10 @@
 #include "webrtc/system_wrappers/include/clock.h"
 #include "webrtc/video_frame.h"
 
+#if defined(WEBRTC_MAC)
+#include <mach/mach.h>
+#endif
+
 namespace webrtc {
 
 namespace {
@@ -46,6 +50,50 @@ const float kMaxExp = 7.0f;
 
 }  // namespace
 
+CpuOveruseOptions::CpuOveruseOptions()
+    : low_encode_usage_threshold_percent(42),
+      frame_timeout_interval_ms(1500),
+      min_frame_samples(120),
+      min_process_count(3),
+      high_threshold_consecutive_count(2) {
+#if defined(WEBRTC_MAC)
+  // This is a proof-of-concept hack for letting the physical core count affect
+  // the interval into which we attempt to scale.  For now, the code is Mac OS
+  // specific, since that's the platform were we saw the problem.
+  // TODO(torbjorng): Enhance SystemInfo to return this metric.
+
+  mach_port_t mach_host = mach_host_self();
+  host_basic_info hbi;

[tommi, 2016/02/05 22:56:35]

zero initialize
host_basic_info hbi = {};

[torbjorng (webrtc), 2016/02/06 14:02:26]

Done.

+  mach_msg_type_number_t info_count = HOST_BASIC_INFO_COUNT;
+  kern_return_t kr =
+      host_info(mach_host, HOST_BASIC_INFO, reinterpret_cast<host_info_t>(&hbi),

[tommi, 2016/02/05 22:56:35]

Can you confirm that this works within the sandbox?  If it fails, I think we'll
need to do what I proposed offline.

[torbjorng (webrtc), 2016/02/06 14:02:26]

It works fine in the current use. (I confess that I haven't checked how it is
called.)

I think we may want to extend base/systeminfo.{cc,h} anyway at some point, but
that'd require physical core count implementations for all supported platforms.
I haven't done that since it is more work, and because I wanted to evaluate this
approach specifically for Mac OS. (I have checked with the help of hbos@ that
similar hardware running Windows does not exhibit system lag. I have yet to
check iOS and GNU/Linux.)

+                &info_count);
+  mach_port_deallocate(mach_task_self(), mach_host);
+
+  int ncpus;
+  if (kr != KERN_SUCCESS) {
+    // If we couldn't get # of physical CPUs, don't panic. Assume we have 1.
+    ncpus = 1;
+    LOG(LS_ERROR) << "Failed to determine number of physical cores, assuming 1";
+  } else {
+    ncpus = hbi.physical_cpu;
+    LOG(LS_INFO) << "Number of physical cores:" << ncpus;
+  }
+
+  // Change init list default for few core systems.
+  if (ncpus == 1)
+    low_encode_usage_threshold_percent = 17;
+  else if (ncpus == 2)
+    low_encode_usage_threshold_percent = 27;
+
+#endif  // WEBRTC_MAC
+  // Note that we make the interval 2x+epsilon wide, since scaling steps are
+  // close to that (when squared). This wide interval makes sure that scaling
+  // up or down does not jump all the way across the interval.
+  high_encode_usage_threshold_percent =
+      33 * low_encode_usage_threshold_percent / 16 + 1;
+}
+
 // Class for calculating the processing usage on the send-side (the average
 // processing time of a frame divided by the average time difference between
 // captured frames).