Add logging of delay-based bandwidth estimate.

webrtc/modules/congestion_controller/delay_based_bwe.cc

Index: webrtc/modules/congestion_controller/delay_based_bwe.cc
diff --git a/webrtc/modules/congestion_controller/delay_based_bwe.cc b/webrtc/modules/congestion_controller/delay_based_bwe.cc
index fb914828dc53742e1b0250f069ea0e20d62329d3..35578e9b6842a5a077c4ec46e10d93dcb1fa1ea0 100644
--- a/webrtc/modules/congestion_controller/delay_based_bwe.cc
+++ b/webrtc/modules/congestion_controller/delay_based_bwe.cc
@@ -18,6 +18,7 @@
 #include "webrtc/base/constructormagic.h"
 #include "webrtc/base/logging.h"
 #include "webrtc/base/thread_annotations.h"
+#include "webrtc/logging/rtc_event_log/rtc_event_log.h"
 #include "webrtc/modules/congestion_controller/include/congestion_controller.h"
 #include "webrtc/modules/pacing/paced_sender.h"
 #include "webrtc/modules/remote_bitrate_estimator/include/remote_bitrate_estimator.h"
@@ -208,9 +209,10 @@ rtc::Optional<uint32_t> DelayBasedBwe::BitrateEstimator::bitrate_bps() const {
   return rtc::Optional<uint32_t>(bitrate_estimate_ * 1000);
 }
 
-DelayBasedBwe::DelayBasedBwe(Clock* clock)
+DelayBasedBwe::DelayBasedBwe(RtcEventLog* event_log, Clock* clock)
     : in_trendline_experiment_(TrendlineFilterExperimentIsEnabled()),
       in_median_slope_experiment_(MedianSlopeFilterExperimentIsEnabled()),
+      event_log_(event_log),
       clock_(clock),
       inter_arrival_(),
       kalman_estimator_(),
@@ -389,6 +391,10 @@ DelayBasedBwe::Result DelayBasedBwe::IncomingPacketInfo(
     last_update_ms_ = now_ms;
     BWE_TEST_LOGGING_PLOT(1, "target_bitrate_bps", now_ms,
                           result.target_bitrate_bps);
+    if (event_log_) {
+      event_log_->LogBwePacketDelayEvent(result.target_bitrate_bps,

[philipel, 2017/02/16 10:37:56]

In the interest of saving space in the log, shouldn't we only log the detector
state if the detector state is different since last time we logged a change in
the delay based bwe?

[terelius, 2017/02/16 23:15:10]

Changed to only log update if bitrate or detector state has changed. I don't
think this makes a huge difference since we will always change the bitrate
except in application limited, or when underusing.

If you meant logging partial updates by omitting the detector state if that
hasn't changed, that would make it harder to parse the log since we would have
to handle missing data caused by the limited history buffer.

[philipel, 2017/02/17 10:29:08]

I meant the partial update thing :)

+                                         detector_.State());
+    }
   }
 
   return result;