commit f203d736f5cfcd9d01cce501a5eeb8c2f07a0bd4
author Ilya Nikolaevskiy <ilnik@webrtc.org> Wed Oct 17 12:41:52 2018
committer Commit Bot <commit-bot@chromium.org> Thu Oct 18 12:09:58 2018
tree 534a3810f2d7c5ecca61eda777886a7aa1be19f7
parent d28efe5186e0e630e73f6e7d79c852b19a87efee

Correctly slice MediaBitrateRecieved on content type in ReceiveStatisticsProxy

Now WebRTC.Video.MediaBitrateReceived.S0 UMA metric will be counted more
correctly. Before, only keyframes were counted there. Now except some
occasional reorderings near content_type switch, all frames should be
counted correctly.

Note,
WebRTC.Video.MediaBitrateReceived will still be larger than sum of sliced
variants because it includes header overhead while sliced metrics do not.

Bug: none
Change-Id: Ia25d6e3efb572f3fe2e9651996b2243716698140
Reviewed-on: https://webrtc-review.googlesource.com/c/106702
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25253}

video/receive_statistics_proxy.cc

diff --git a/video/receive_statistics_proxy.cc b/video/receive_statistics_proxy.cc
index bffae16..e20b7d2 100644
--- a/video/receive_statistics_proxy.cc
+++ b/video/receive_statistics_proxy.cc
@@ -816,8 +816,15 @@
     ++stats_.frame_counts.delta_frames;
   }
 
+  // Content type extension is set only for keyframes and should be propagated
+  // for all the following delta frames. Here we may receive frames out of order
+  // and miscategorise some delta frames near the layer switch.
+  // This may slightly offset calculated bitrate and keyframes permille metrics.
+  VideoContentType propagated_content_type =
+      is_keyframe ? content_type : last_content_type_;
+
   ContentSpecificStats* content_specific_stats =
-      &content_specific_stats_[content_type];
+      &content_specific_stats_[propagated_content_type];
 
   content_specific_stats->total_media_bytes += size_bytes;
   if (is_keyframe) {