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..9f12137940ab297eeddbe39db73daf424eef3074 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,55 @@ const float kMaxExp = 7.0f;
 
 }  // namespace
 
+CpuOveruseOptions::CpuOveruseOptions()
+    : high_encode_usage_threshold_percent(85),
+      frame_timeout_interval_ms(1500),
+      min_frame_samples(120),
+      min_process_count(3),
+      high_threshold_consecutive_count(2) {
+#if defined(WEBRTC_MAC)
+  // This is proof-of-concept code 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 most problems.
+  // TODO(torbjorng): Enhance SystemInfo to return this metric.
+
+  mach_port_t mach_host = mach_host_self();
+  host_basic_info hbi = {};
+  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),
+                &info_count);
+  mach_port_deallocate(mach_task_self(), mach_host);
+
+  int n_physical_cores;
+  if (kr != KERN_SUCCESS) {
+    // If we couldn't get # of physical CPUs, don't panic. Assume we have 1.
+    n_physical_cores = 1;
+    LOG(LS_ERROR) << "Failed to determine number of physical cores, assuming 1";
+  } else {
+    n_physical_cores = hbi.physical_cpu;
+    LOG(LS_INFO) << "Number of physical cores:" << n_physical_cores;
+  }
+
+  // Change init list default for few core systems. The assumption here is that
+  // encoding, which we measure here, takes about 1/4 of the processing of a
+  // two-way call. This is roughly true for x86 using both vp8 and vp9 without
+  // hardware encoding. Since we don't affect the incoming stream here, we only
+  // control about 1/2 of the total processing needs, but this is not taken into
+  // account.
+  if (n_physical_cores == 1)
+    high_encode_usage_threshold_percent = 20;  // Roughly 1/4 of 100%.
+  else if (n_physical_cores == 2)
+    high_encode_usage_threshold_percent = 40;  // Roughly 1/4 of 200%.
+
+#endif  // WEBRTC_MAC
+  // Note that we make the interval 2x+epsilon wide, since libyuv 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.
+  low_encode_usage_threshold_percent =
+      (high_encode_usage_threshold_percent - 1) / 2;
+}
+
 // 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).