Add QP sum stats for received streams.

webrtc/video/video_stream_decoder.cc

 /*
  *  Copyright (c) 2012 The WebRTC project authors. All Rights Reserved.
  *
  *  Use of this source code is governed by a BSD-style license
  *  that can be found in the LICENSE file in the root of the source
  *  tree. An additional intellectual property rights grant can be found
  *  in the file PATENTS.  All contributing project authors may
  *  be found in the AUTHORS file in the root of the source tree.
  */
 
@@ skipping 57 matching lines @@
   video_receiver_->RegisterDecoderTimingCallback(nullptr);
   video_receiver_->RegisterReceiveStatisticsCallback(nullptr);
   video_receiver_->RegisterFrameTypeCallback(nullptr);
   video_receiver_->RegisterReceiveCallback(nullptr);
 }
 
 // Do not acquire the lock of |video_receiver_| in this function. Decode
 // callback won't necessarily be called from the decoding thread. The decoding
 // thread may have held the lock when calling VideoDecoder::Decode, Reset, or
 // Release. Acquiring the same lock in the path of decode callback can deadlock.
-int32_t VideoStreamDecoder::FrameToRender(VideoFrame& video_frame) {  // NOLINT
+int32_t VideoStreamDecoder::FrameToRender(VideoFrame& video_frame,
+                                          rtc::Optional<uint8_t> qp) {
   if (pre_render_callback_) {
     // Post processing is not supported if the frame is backed by a texture.
     if (!video_frame.video_frame_buffer()->native_handle()) {
       pre_render_callback_->FrameCallback(&video_frame);
     }
   }
 
+  receive_stats_callback_->OnDecodedFrame(qp);

[hbos, 2017/01/26 15:04:45]

Does this really give the same behavior as before?

Could a frame to be decoded and then never rendered (CPU/GPU adaptation)? Or
rendered multiple times (multiple sinks)?
Or maybe that is handled further down.

[sakal, 2017/01/26 15:46:52]

VideoReceiveStream::OnFrame is actually further down than this method. This
method calls IncomingVideoStream::OnFrame which does frame phasing and calls
VideoReceiveStream::OnFrame on another thread.

So calling it here leads to it being called earlier and not being phased but I
don't think that is a problem.

[sprang_webrtc, 2017/01/26 15:48:03]

I think that's all further downstream. incoming_video_stream_ is the first place
I know of that can drop a frame after decoding. 

[hbos, 2017/01/26 15:48:57]

Acknowledged.

   incoming_video_stream_->OnFrame(video_frame);
 
   return 0;
 }
 
 int32_t VideoStreamDecoder::ReceivedDecodedReferenceFrame(
   const uint64_t picture_id) {
   RTC_NOTREACHED();
   return 0;
 }
@@ skipping 38 matching lines @@
       jitter_buffer_ms, min_playout_delay_ms, render_delay_ms, last_rtt);
 }
 
 void VideoStreamDecoder::OnRttUpdate(int64_t avg_rtt_ms, int64_t max_rtt_ms) {
   video_receiver_->SetReceiveChannelParameters(max_rtt_ms);
 
   rtc::CritScope lock(&crit_);
   last_rtt_ms_ = avg_rtt_ms;
 }
 }  // namespace webrtc