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

webrtc/video/video_stream_decoder.cc

Index: webrtc/video/video_stream_decoder.cc
diff --git a/webrtc/video/video_stream_decoder.cc b/webrtc/video/video_stream_decoder.cc
index 6797353161dce52cb74a8d8dac1370a7bce871c1..cf77833a5182e3170225ab1445ea12f5e311f7c4 100644
--- a/webrtc/video/video_stream_decoder.cc
+++ b/webrtc/video/video_stream_decoder.cc
@@ -86,6 +86,8 @@ int32_t VideoStreamDecoder::FrameToRender(VideoFrame& video_frame) {  // NOLINT
 
   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;
 }