vda_unittest: Fix Flush() is not called when decoding is slow.

vda_unittest: Fix Flush() is not called when decoding is slow.

When |decode_calls_per_second_| is set (not 0),  DecodeNextFragment()
will be called at the given rate. When decoding is slow, a
BitstreamBuffer may be released after the last DcodeNextFragment()
being called. In that case, decoder's Flush() will not be called,
and the test will hang forever.

To fix this issue, we call Flush() when all BitstreamBuffers are
processed in NotifyEndOfBitstreamBuffer().

BUG=439831
Test=Run the test on veyron_minnie

patch from issue 791573002 at patchset 80001 (http://crrev.com/791573002#ps80001)

Committed: https://crrev.com/b85621fa3e63cc4aaa8aff05f2cabc9206c5fab5
Cr-Commit-Position: refs/heads/master@{#347599}

[Owen Lin, 2015-09-02 06:02:17]

owenlin@chromium.org changed reviewers:
+ posciak@chromium.org, zallychao@intel.com

[Owen Lin, 2015-09-02 06:02:17]

PTAL. Thanks.

[Owen Lin, 2015-09-04 02:08:48]

owenlin@chromium.org changed reviewers:
+ wuchengli@chromium.org

[wuchengli, 2015-09-04 03:26:06]

lgtm

https://codereview.chromium.org/1321423004/diff/1/content/common/gpu/media/vi...
File content/common/gpu/media/video_decode_accelerator_unittest.cc (right):

https://codereview.chromium.org/1321423004/diff/1/content/common/gpu/media/vi...
content/common/gpu/media/video_decode_accelerator_unittest.cc:735:
outstanding_decodes_ == 0) {
No need to call DecodeNextFragment if reaching the end of encoded data.
if (encoded_data_next_pos_to_decode_ == encoded_data_.size()) {
  if (outstanding_decodes_ == 0) {
    ... 
  }
} else if ... {
}

[Pawel Osciak, 2015-09-04 06:04:40]

https://chromiumcodereview.appspot.com/1321423004/diff/1/content/common/gpu/m...
File content/common/gpu/media/video_decode_accelerator_unittest.cc (right):

https://chromiumcodereview.appspot.com/1321423004/diff/1/content/common/gpu/m...
content/common/gpu/media/video_decode_accelerator_unittest.cc:735:
outstanding_decodes_ == 0) {
Do we need to check outstanding_decodes_? I think it would be better to test by
sending Flush as soon a possible, while decodes are still running, to check the
decoders are behaving correctly.
To avoid sending it more than once, we could do it only if CS_INITIALIZED.

[Owen Lin, 2015-09-04 07:15:44]

https://chromiumcodereview.appspot.com/1321423004/diff/1/content/common/gpu/m...
File content/common/gpu/media/video_decode_accelerator_unittest.cc (right):

https://chromiumcodereview.appspot.com/1321423004/diff/1/content/common/gpu/m...
content/common/gpu/media/video_decode_accelerator_unittest.cc:735:
outstanding_decodes_ == 0) {
On 2015/09/04 03:26:06, wuchengli wrote:
> No need to call DecodeNextFragment if reaching the end of encoded data.
> if (encoded_data_next_pos_to_decode_ == encoded_data_.size()) {
>   if (outstanding_decodes_ == 0) {
>     ... 
>   }
> } else if ... {
> }

Done.

https://chromiumcodereview.appspot.com/1321423004/diff/1/content/common/gpu/m...
content/common/gpu/media/video_decode_accelerator_unittest.cc:735:
outstanding_decodes_ == 0) {
On 2015/09/04 06:04:40, Pawel Osciak wrote:
> Do we need to check outstanding_decodes_? I think it would be better to test
by
> sending Flush as soon a possible, while decodes are still running, to check
the
> decoders are behaving correctly.
> To avoid sending it more than once, we could do it only if CS_INITIALIZED.

This is what I thought. (So I issue the Flush once we send the last frame for
decode). But the test failed on minnie. I think this should be another issue.
How about we still keep the same behavior for this CL and fix the bug (I think
it is) in another.

[Pawel Osciak, 2015-09-04 08:15:30]

lgtm % nit

https://chromiumcodereview.appspot.com/1321423004/diff/20001/content/common/g...
File content/common/gpu/media/video_decode_accelerator_unittest.cc (right):

https://chromiumcodereview.appspot.com/1321423004/diff/20001/content/common/g...
content/common/gpu/media/video_decode_accelerator_unittest.cc:735: if
(outstanding_decodes_ == 0) {
Please add a TODO explaining we should not have to check this, because decoder_
should be able to accept Flush() before it's done with outstanding decodes (and
a link to crbug please).

[Owen Lin, 2015-09-07 03:54:18]

https://codereview.chromium.org/1321423004/diff/20001/content/common/gpu/medi...
File content/common/gpu/media/video_decode_accelerator_unittest.cc (right):

https://codereview.chromium.org/1321423004/diff/20001/content/common/gpu/medi...
content/common/gpu/media/video_decode_accelerator_unittest.cc:735: if
(outstanding_decodes_ == 0) {
On 2015/09/04 08:15:30, Pawel Osciak wrote:
> Please add a TODO explaining we should not have to check this, because
decoder_
> should be able to accept Flush() before it's done with outstanding decodes
(and
> a link to crbug please).

Done.

[Owen Lin, 2015-09-07 03:54:21]

The CQ bit was checked by owenlin@chromium.org

[Owen Lin, 2015-09-07 03:54:22]

The patchset sent to the CQ was uploaded after l-g-t-m from
wuchengli@chromium.org, posciak@chromium.org
Link to the patchset: https://codereview.chromium.org/1321423004/#ps40001
(title: "Add TODO for Pawel's comment.")

[commit-bot: I haz the power, 2015-09-07 03:54:33]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1321423004/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1321423004/40001

[commit-bot: I haz the power, 2015-09-07 04:09:35]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-09-07 04:10:21]

Patchset 3 (id:??) landed as
https://crrev.com/b85621fa3e63cc4aaa8aff05f2cabc9206c5fab5
Cr-Commit-Position: refs/heads/master@{#347599}