Bug Fix: Remote Video Hang For Apprtc Loopback

content/renderer/media/webmediaplayer_ms_compositor.cc

Index: content/renderer/media/webmediaplayer_ms_compositor.cc
diff --git a/content/renderer/media/webmediaplayer_ms_compositor.cc b/content/renderer/media/webmediaplayer_ms_compositor.cc
index 7bd992de607e8b0921affac52f3cc1a0716db05c..e53e074c560087e52582ab53c0105723ed237fc9 100644
--- a/content/renderer/media/webmediaplayer_ms_compositor.cc
+++ b/content/renderer/media/webmediaplayer_ms_compositor.cc
@@ -216,15 +216,12 @@ void WebMediaPlayerMSCompositor::EnqueueFrame(
   rendering_frame_buffer_->EnqueueFrame(frame);
 
   const base::TimeTicks now = base::TimeTicks::Now();
-  if (now <= last_deadline_max_)
+  if (now <= last_deadline_max_ || !current_frame_)
     return;
 
   // This shows vsyncs stops rendering frames. A probable cause is that the
   // tab is not in the front. But we still have to let old frames go.
-  const base::TimeTicks deadline_max =
-      std::max(now, last_deadline_max_ + last_render_length_);
-
-  Render(deadline_max - last_render_length_, deadline_max);
+  rendering_frame_buffer_->Reset();

[DaleCurtis, 2016/03/09 00:42:23]

Hmm, is this really what you want? This will drop the frame that was just
enqueued. Do you instead want to use RemoveExpiredFrames(now) ?

[qiangchen, 2016/03/09 19:55:02]

Probably RemoveExpiredFrames(now) will not work. As it sets the deadline as now
- frame_length - acceptable_drift, which is almost now - 1.5*frame_length. But
most queued frames have render_time in the future. 

I changed the code to preserve exactly one frame when tab is inactive.
Theoretically this would affect smoothness for the first several frames when the
tab is activated later. But in reality considering the start up over head of
renderer, the effect is unnoticable.

 }
 
 bool WebMediaPlayerMSCompositor::UpdateCurrentFrame(