Add logging statements to places where the frame might be dropped in WebRTC pipeline.

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 68 matching lines @@
 int32_t VideoStreamDecoder::FrameToRender(VideoFrame& video_frame) {  // NOLINT
   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);
     }
   }
 
   if (incoming_video_stream_)
     incoming_video_stream_->OnFrame(video_frame);
+  else
+    LOG(LS_INFO) << "Dropping frame because incoming_video_stream_ is NULL.";

[stefan-webrtc, 2016/09/26 10:44:09]

AFAICT this can never happen as incoming_video_stream_ is always set. DCHECK?

[sakal, 2016/09/26 11:23:59]

It looks like this class is instantiated here:
https://cs.chromium.org/chromium/src/third_party/webrtc/video/video_receive_s...

incoming_video_stream_ is set to nullptr if config_.renderer is nullptr. Comment
on that member says "'nullptr' disables rendering of this stream.". So I guess
it is possible?

[stefan-webrtc, 2016/09/26 11:39:22]

Seems like it's always being set outside of Call though?
https://cs.chromium.org/chromium/src/third_party/webrtc/media/engine/webrtcvi...

If you think there are good reasons to support not attaching a renderer, then I
can live with this one. But in that case perhaps we should throttle the logs to
not show 30 logs per second for 30 fps video?

[magjed_webrtc, 2016/09/27 15:06:11]

There is probably no reason to not attach a renderer so when this happens it's
probably an error. Therefore I don't think we need to throttle the logs. The
purpose of this log is to be able to find the cause from bugreports when video
is missing in either direction. We could use RTC_CHECK instead, but that seems a
bit harsh.

 
   return 0;
 }
 
 int32_t VideoStreamDecoder::ReceivedDecodedReferenceFrame(
   const uint64_t picture_id) {
   RTC_NOTREACHED();
   return 0;
 }
 
@@ skipping 37 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