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}
This commit is contained in:
Ilya Nikolaevskiy 2018-10-17 14:41:52 +02:00 committed by Commit Bot
parent d28efe5186
commit f203d736f5

View File

@ -816,8 +816,15 @@ void ReceiveStatisticsProxy::OnCompleteFrame(bool is_keyframe,
++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) {