Don't underflow for background rendering. Ensure accurate counts.

media/renderers/video_renderer_impl.cc

Index: media/renderers/video_renderer_impl.cc
diff --git a/media/renderers/video_renderer_impl.cc b/media/renderers/video_renderer_impl.cc
index b858a6904030b11cfba3eacf45f1ddf7f284ca08..2b662c65f264318900524d15e4234134ccd6e745 100644
--- a/media/renderers/video_renderer_impl.cc
+++ b/media/renderers/video_renderer_impl.cc
@@ -186,13 +186,11 @@ scoped_refptr<VideoFrame> VideoRendererImpl::Render(
   // Declare HAVE_NOTHING if we reach a state where we can't progress playback
   // any further.  We don't want to do this if we've already done so, reached
   // end of stream, or have frames available.  We also don't want to do this in
-  // background rendering mode unless this isn't the first background render
-  // tick and we haven't seen any decoded frames since the last one.
+  // background rendering mode, as the frames aren't visible anyways.
   MaybeFireEndedCallback_Locked(true);
   if (buffering_state_ == BUFFERING_HAVE_ENOUGH && !received_end_of_stream_ &&
-      !algorithm_->effective_frames_queued() &&
-      (!background_rendering ||
-       (!frames_decoded_ && was_background_rendering_))) {
+      !algorithm_->effective_frames_queued() && !background_rendering &&
+      !was_background_rendering_) {

[chcunningham, 2016/09/09 21:27:06]

So, IIUC this is just giving us one more tick to get the queue full, right?
Expected to make a big difference?

[DaleCurtis, 2016/09/09 21:51:41]

Yes, because whenever the previous state was reached this would always be the
underflow state.

[chcunningham, 2016/09/09 22:17:46]

You're saying that every time we will *never* have frames decoded between the
transition of Background and Foreground rendering? I expect that this may
sometimes occur, but not always?

[DaleCurtis, 2016/09/09 22:20:46]

I mean every time we get into a state where we were previously flip flopping on
underflow we would always hit underflow on the first non-background-render tick.

     // Do not set |buffering_state_| here as the lock in FrameReady() may be
     // held already and it fire the state changes in the wrong order.
     DVLOG(3) << __func__ << " posted TransitionToHaveNothing.";