Use generic CPU-overuse thresholds for iOS.

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 96e21596bb75b910c4305b015379b2bd90e51cf1..8498008f974c09b449cacdbc0d2a6b136fc14701 100644
--- a/webrtc/video/overuse_frame_detector.cc
+++ b/webrtc/video/overuse_frame_detector.cc
@@ -24,9 +24,9 @@
 #include "webrtc/system_wrappers/include/clock.h"
 #include "webrtc/video_frame.h"
 
-#if defined(WEBRTC_MAC)
+#if defined(WEBRTC_MAC) && !defined(WEBRTC_IOS)
 #include <mach/mach.h>
-#endif
+#endif  // defined(WEBRTC_MAC) && !defined(WEBRTC_IOS)
 
 namespace webrtc {
 
@@ -56,7 +56,7 @@ CpuOveruseOptions::CpuOveruseOptions()
       min_frame_samples(120),
       min_process_count(3),
       high_threshold_consecutive_count(2) {
-#if defined(WEBRTC_MAC)
+#if defined(WEBRTC_MAC) && !defined(WEBRTC_IOS)
   // 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.
@@ -90,8 +90,8 @@ CpuOveruseOptions::CpuOveruseOptions()
     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  // defined(WEBRTC_MAC) && !defined(WEBRTC_IOS)
 
-#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.