admin/webrtc_m130
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Experimental patch for adapting adaptation to CPU count on Mac.

Browse Source 
BUG=

Review URL: https://codereview.webrtc.org/1665173002

Cr-Commit-Position: refs/heads/master@{#11553}
This commit is contained in:
torbjorng 2016-02-10 08:11:57 -08:00 committed by Commit bot
parent b24317bfda
commit 448468d575
2 changed files with 54 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
webrtc/video/overuse_frame_detector.cc
View File

@ -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).

8
webrtc/video/overuse_frame_detector.h
View File

@ -42,13 +42,7 @@ class CpuOveruseObserver {
};
struct CpuOveruseOptions {
CpuOveruseOptions()
: low_encode_usage_threshold_percent(55),
high_encode_usage_threshold_percent(85),
frame_timeout_interval_ms(1500),
min_frame_samples(120),
min_process_count(3),
high_threshold_consecutive_count(2) {}
CpuOveruseOptions();
int low_encode_usage_threshold_percent; // Threshold for triggering underuse.
int high_encode_usage_threshold_percent; // Threshold for triggering overuse.