fix video_decode_accelerator_unittest issue when decode speed is slow

content/common/gpu/media/video_decode_accelerator_unittest.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 //
 // The bulk of this file is support code; sorry about that.  Here's an overview
 // to hopefully help readers of this code:
 // - RenderingHelper is charged with interacting with X11/{EGL/GLES2,GLX/GL} or
 //   Win/EGL.
 // - ClientState is an enum for the state of the decode client used by the test.
 // - ClientStateNotification is a barrier abstraction that allows the test code
@@ skipping 528 matching lines @@
 }
 
 void GLRenderingVDAClient::NotifyEndOfBitstreamBuffer(
     int32 bitstream_buffer_id) {
   // TODO(fischman): this test currently relies on this notification to make
   // forward progress during a Reset().  But the VDA::Reset() API doesn't
   // guarantee this, so stop relying on it (and remove the notifications from
   // VaapiVideoDecodeAccelerator::FinishReset()).
   ++num_done_bitstream_buffers_;
   --outstanding_decodes_;
-  if (decode_calls_per_second_ == 0)
+
+  // flush decoder after all BitstreamBuffer are processed

[Pawel Osciak, 2015/01/20 02:18:00]

Comments should be full English sentences when possible. Please capitalize and
use a dot at the end of the sentence.

+  if (encoded_data_next_pos_to_decode_ == encoded_data_.size() &&
+      outstanding_decodes_ == 0) {

[Pawel Osciak, 2015/01/20 02:18:00]

If the issue is with the decode being slow, shouldn't the proper place for flush
be after we receive the final decoded picture via PictureReady? Decoders may be
returning bitstream buffers before finishing decode for it.

[Owen Lin, 2015/01/20 02:43:00]

The issue happens only when |decode_calls_per_second_| is not 0. In that mode,
we will call DecodeNextFragment() at a constant rate (see l.803 of the base
code). However, when we try to decode the last fragment. The previous bitstream
buffer may still be used by the decoder (This is the slowness). So that
|outstanding_decodes_| is not 0 and we will refuse to flush the decoder (see
l.746 of the base code). That's the bug. 

I think it is correct to move Flush() here since we would like to do the Flush()
after the decoder processes the last bitstream buffer. Besides, it is hard to
tell which one is the "final" picture (I thought the decoder is allowed to keep
some reference frames until we call Flush()).

+    decoder_->Flush();
+    SetState(CS_FLUSHING);
+  } else if (decode_calls_per_second_ == 0)
     DecodeNextFragment();
 }
 
 void GLRenderingVDAClient::NotifyFlushDone() {
   if (decoder_deleted())
     return;
 
   SetState(CS_FLUSHED);
   --remaining_play_throughs_;
   DCHECK_GE(remaining_play_throughs_, 0);
@@ skipping 175 matching lines @@
     return (size > 0 && !(data[0] & 0x01));
   }
   // Shouldn't happen at this point.
   LOG(FATAL) << "Invalid profile: " << profile;
   return false;
 }
 
 void GLRenderingVDAClient::DecodeNextFragment() {
   if (decoder_deleted())
     return;
-  if (encoded_data_next_pos_to_decode_ == encoded_data_.size()) {
-    if (outstanding_decodes_ == 0) {
-      decoder_->Flush();
-      SetState(CS_FLUSHING);
-    }
+  if (encoded_data_next_pos_to_decode_ == encoded_data_.size())
     return;
-  }
+
   size_t end_pos;
   std::string next_fragment_bytes;
   if (encoded_data_next_pos_to_decode_ == 0) {
     next_fragment_bytes = GetBytesForFirstFragment(0, &end_pos);
   } else {
     next_fragment_bytes =
         GetBytesForNextFragment(encoded_data_next_pos_to_decode_, &end_pos);
   }
   size_t next_fragment_size = next_fragment_bytes.size();
 
@@ skipping 677 matching lines @@
     if (it->first == "v" || it->first == "vmodule")
       continue;
     LOG(FATAL) << "Unexpected switch: " << it->first << ":" << it->second;
   }
 
   base::ShadowingAtExitManager at_exit_manager;
   content::RenderingHelper::InitializeOneOff();
 
   return RUN_ALL_TESTS();
 }