Reland [Mojo Video Capture] Add test coverage for accelerated jpeg decoding

Reland [Mojo Video Capture] Add test coverage for accelerated jpeg decoding

PatchSet 1 is state as reviewed previously in https://codereview.chromium.org/2735083002/
PatchSet 2 fixes the reason for the revert.

Description of issue and fix:

VideoCaptureBrowserTest.ReceiveFramesFromFakeCaptureDevice never called
VideoCaptureController::ReturnBuffer(). As a result, after the maximum number
of allowed in-flight buffers (which is 3) had been reached, subsequent frames
were dropped. The tests using the software decoding path would always pass,
because kMinFramesToReceive was set to 3. It would have failed if set to >3.
The new test case for the accelerated decoding path would pass if the fake
decoder would be initialized and used within the first 3 frames. It would fail
otherwise.

The fix is to call VideoCaptureController::ReturnBuffer() when receiving a
frame. To allow calling this synchronously from within an invokaction of
OnBufferReady(), the order of corresponding invocations in
VideoCaptureController had to be updated.


Description of original CL:

This CL adds test cases to VideoCaptureBrowserTest that exercise the code path
for accelerated jpeg decoding using a fake decode accelerator.

* Add a FakeJpegDecodeAccelerator that can run in the GPU process and decodes
  jpeg frames in software using libyuv.
* Add a command-line flag kUseFakeJpegDecodeAccelerator to enable the fake
  accelerator (and suppress any "real" ones if present).
* Fix threading-related DCHECKs in GpuJpegDecodeAccelerator::Client to match
  what is actually happening. This is needed to make the new test cases pass.
  It also fixes issue 688184 [1].

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [2] CL14.

BUG=584797, 688184
TEST=
  content_browsertests --gtest_filter="VideoCaptureBrowserTest.*"
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

TBR=posciak@chromium.org,piman@chromium.org,sandersd@chromium.org

Review-Url: https://codereview.chromium.org/2772963002
Cr-Commit-Position: refs/heads/master@{#461060}
Committed: https://chromium.googlesource.com/chromium/src/+/0f72e9da2531d02d80511e54584b6da18ffa41d3

[chfremer, 2017-03-23 22:50:49]

Description was changed from

==========
Reland [Mojo Video Capture] Add test coverage for accelerated jpeg decoding

PatchSet 1 is state as reviewed previously in
https://codereview.chromium.org/2735083002/
PatchSet 2 fixes the reason for the revert.

Description of issue and fix:

VideoCaptureBrowserTest.ReceiveFramesFromFakeCaptureDevice never called
VideoCaptureController::ReturnBuffer(). As a result, after the maximum number
of allowed in-flight buffers (which is 3) had been reached, subsequent frames
were dropped. The tests using the software decoding path would always pass,
because kMinFramesToReceive was set to 3. It would have failed if set to >3.
The new test case for the accelerated decoding path would pass if the fake
decoder would be initialized and used within the first 3 frames. It would fail
otherwise.

The fix is to call VideoCaptureController::ReturnBuffer() when receiving a
frame. To allow calling this synchronously from within an invokaction of
OnBufferReady(), the order of corresponding invocations in
VideoCaptureController had to be updated.


Description of original CL:

This CL adds test cases to VideoCaptureBrowserTest that exercise the code path
for accelerated jpeg decoding using a fake decode accelerator.

* Add a FakeJpegDecodeAccelerator that can run in the GPU process and decodes
  jpeg frames in software using libyuv.
* Add a command-line flag kUseFakeJpegDecodeAccelerator to enable the fake
  accelerator (and suppress any "real" ones if present).
* Fix threading-related DCHECKs in GpuJpegDecodeAccelerator::Client to match
  what is actually happening. This is needed to make the new test cases pass.
  It also fixes issue 688184 [1].

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [2] CL14.

BUG=584797, 688184
TEST=
  content_browsertests --gtest_filter="VideoCaptureBrowserTest.*"
==========

to

==========
Reland [Mojo Video Capture] Add test coverage for accelerated jpeg decoding

PatchSet 1 is state as reviewed previously in
https://codereview.chromium.org/2735083002/
PatchSet 2 fixes the reason for the revert.

Description of issue and fix:

VideoCaptureBrowserTest.ReceiveFramesFromFakeCaptureDevice never called
VideoCaptureController::ReturnBuffer(). As a result, after the maximum number
of allowed in-flight buffers (which is 3) had been reached, subsequent frames
were dropped. The tests using the software decoding path would always pass,
because kMinFramesToReceive was set to 3. It would have failed if set to >3.
The new test case for the accelerated decoding path would pass if the fake
decoder would be initialized and used within the first 3 frames. It would fail
otherwise.

The fix is to call VideoCaptureController::ReturnBuffer() when receiving a
frame. To allow calling this synchronously from within an invokaction of
OnBufferReady(), the order of corresponding invocations in
VideoCaptureController had to be updated.


Description of original CL:

This CL adds test cases to VideoCaptureBrowserTest that exercise the code path
for accelerated jpeg decoding using a fake decode accelerator.

* Add a FakeJpegDecodeAccelerator that can run in the GPU process and decodes
  jpeg frames in software using libyuv.
* Add a command-line flag kUseFakeJpegDecodeAccelerator to enable the fake
  accelerator (and suppress any "real" ones if present).
* Fix threading-related DCHECKs in GpuJpegDecodeAccelerator::Client to match
  what is actually happening. This is needed to make the new test cases pass.
  It also fixes issue 688184 [1].

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [2] CL14.

BUG=584797, 688184
TEST=
  content_browsertests --gtest_filter="VideoCaptureBrowserTest.*"
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[chfremer, 2017-03-23 22:57:10]

chfremer@chromium.org changed reviewers:
+ emircan@chromium.org, mcasas@chromium.org

[chfremer, 2017-03-23 22:57:11]

mcasas@: PTAL
emircan@: FYI

[chfremer, 2017-03-23 22:58:20]

Description was changed from

==========
Reland [Mojo Video Capture] Add test coverage for accelerated jpeg decoding

PatchSet 1 is state as reviewed previously in
https://codereview.chromium.org/2735083002/
PatchSet 2 fixes the reason for the revert.

Description of issue and fix:

VideoCaptureBrowserTest.ReceiveFramesFromFakeCaptureDevice never called
VideoCaptureController::ReturnBuffer(). As a result, after the maximum number
of allowed in-flight buffers (which is 3) had been reached, subsequent frames
were dropped. The tests using the software decoding path would always pass,
because kMinFramesToReceive was set to 3. It would have failed if set to >3.
The new test case for the accelerated decoding path would pass if the fake
decoder would be initialized and used within the first 3 frames. It would fail
otherwise.

The fix is to call VideoCaptureController::ReturnBuffer() when receiving a
frame. To allow calling this synchronously from within an invokaction of
OnBufferReady(), the order of corresponding invocations in
VideoCaptureController had to be updated.


Description of original CL:

This CL adds test cases to VideoCaptureBrowserTest that exercise the code path
for accelerated jpeg decoding using a fake decode accelerator.

* Add a FakeJpegDecodeAccelerator that can run in the GPU process and decodes
  jpeg frames in software using libyuv.
* Add a command-line flag kUseFakeJpegDecodeAccelerator to enable the fake
  accelerator (and suppress any "real" ones if present).
* Fix threading-related DCHECKs in GpuJpegDecodeAccelerator::Client to match
  what is actually happening. This is needed to make the new test cases pass.
  It also fixes issue 688184 [1].

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [2] CL14.

BUG=584797, 688184
TEST=
  content_browsertests --gtest_filter="VideoCaptureBrowserTest.*"
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Reland [Mojo Video Capture] Add test coverage for accelerated jpeg decoding

PatchSet 1 is state as reviewed previously in
https://codereview.chromium.org/2735083002/
PatchSet 2 fixes the reason for the revert.

Description of issue and fix:

VideoCaptureBrowserTest.ReceiveFramesFromFakeCaptureDevice never called
VideoCaptureController::ReturnBuffer(). As a result, after the maximum number
of allowed in-flight buffers (which is 3) had been reached, subsequent frames
were dropped. The tests using the software decoding path would always pass,
because kMinFramesToReceive was set to 3. It would have failed if set to >3.
The new test case for the accelerated decoding path would pass if the fake
decoder would be initialized and used within the first 3 frames. It would fail
otherwise.

The fix is to call VideoCaptureController::ReturnBuffer() when receiving a
frame. To allow calling this synchronously from within an invokaction of
OnBufferReady(), the order of corresponding invocations in
VideoCaptureController had to be updated.


Description of original CL:

This CL adds test cases to VideoCaptureBrowserTest that exercise the code path
for accelerated jpeg decoding using a fake decode accelerator.

* Add a FakeJpegDecodeAccelerator that can run in the GPU process and decodes
  jpeg frames in software using libyuv.
* Add a command-line flag kUseFakeJpegDecodeAccelerator to enable the fake
  accelerator (and suppress any "real" ones if present).
* Fix threading-related DCHECKs in GpuJpegDecodeAccelerator::Client to match
  what is actually happening. This is needed to make the new test cases pass.
  It also fixes issue 688184 [1].

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [2] CL14.

BUG=584797, 688184
TEST=
  content_browsertests --gtest_filter="VideoCaptureBrowserTest.*"
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

TBR=posciak@chromium.org,piman@chromium.org,sandersd@chromium.org
==========

[mcasas, 2017-03-24 20:33:20]

ps1 deltas lgtm

[chfremer, 2017-03-24 20:34:35]

The CQ bit was checked by chfremer@chromium.org

[commit-bot: I haz the power, 2017-03-24 20:35:24]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-24 23:15:07]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-24 23:15:08]

Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[chfremer, 2017-03-28 23:08:30]

On 2017/03/24 23:15:08, commit-bot: I haz the power wrote:
> Try jobs failed on following builders:
>   linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
>
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

Turns out we are hitting a (pre-existing) deadlock condition in the trybot.
Waiting to land a fix for that before proceeding. See
https://codereview.chromium.org/2786503002/.

[chfremer, 2017-03-28 23:55:51]

The CQ bit was checked by chfremer@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-28 23:56:42]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-29 01:51:10]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-29 01:51:11]

Dry run: Try jobs failed on following builders:
  linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[chfremer, 2017-03-30 17:58:48]

The CQ bit was checked by chfremer@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-30 17:59:23]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-30 20:00:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-30 20:00:51]

Dry run: Try jobs failed on following builders:
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)

[chfremer, 2017-03-30 23:23:29]

The CQ bit was checked by chfremer@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-30 23:24:38]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-31 01:23:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-31 01:23:47]

Dry run: Try jobs failed on following builders:
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)

[chfremer, 2017-03-31 06:44:42]

The CQ bit was checked by chfremer@chromium.org

[chfremer, 2017-03-31 06:44:42]

The patchset sent to the CQ was uploaded after l-g-t-m from mcasas@chromium.org
Link to the patchset: https://codereview.chromium.org/2772963002/#ps80001
(title: "Rebase to March 30")

[commit-bot: I haz the power, 2017-03-31 06:45:03]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-31 06:50:21]

CQ is committing da patch.

Bot data: {"patchset_id": 80001, "attempt_start_ts": 1490942682228240,
"parent_rev": "e714f2ca03dd306dc98407c09229987cfef24ba0", "commit_rev":
"0f72e9da2531d02d80511e54584b6da18ffa41d3"}

[commit-bot: I haz the power, 2017-03-31 06:51:33]

Description was changed from

==========
Reland [Mojo Video Capture] Add test coverage for accelerated jpeg decoding

PatchSet 1 is state as reviewed previously in
https://codereview.chromium.org/2735083002/
PatchSet 2 fixes the reason for the revert.

Description of issue and fix:

VideoCaptureBrowserTest.ReceiveFramesFromFakeCaptureDevice never called
VideoCaptureController::ReturnBuffer(). As a result, after the maximum number
of allowed in-flight buffers (which is 3) had been reached, subsequent frames
were dropped. The tests using the software decoding path would always pass,
because kMinFramesToReceive was set to 3. It would have failed if set to >3.
The new test case for the accelerated decoding path would pass if the fake
decoder would be initialized and used within the first 3 frames. It would fail
otherwise.

The fix is to call VideoCaptureController::ReturnBuffer() when receiving a
frame. To allow calling this synchronously from within an invokaction of
OnBufferReady(), the order of corresponding invocations in
VideoCaptureController had to be updated.


Description of original CL:

This CL adds test cases to VideoCaptureBrowserTest that exercise the code path
for accelerated jpeg decoding using a fake decode accelerator.

* Add a FakeJpegDecodeAccelerator that can run in the GPU process and decodes
  jpeg frames in software using libyuv.
* Add a command-line flag kUseFakeJpegDecodeAccelerator to enable the fake
  accelerator (and suppress any "real" ones if present).
* Fix threading-related DCHECKs in GpuJpegDecodeAccelerator::Client to match
  what is actually happening. This is needed to make the new test cases pass.
  It also fixes issue 688184 [1].

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [2] CL14.

BUG=584797, 688184
TEST=
  content_browsertests --gtest_filter="VideoCaptureBrowserTest.*"
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

TBR=posciak@chromium.org,piman@chromium.org,sandersd@chromium.org
==========

to

==========
Reland [Mojo Video Capture] Add test coverage for accelerated jpeg decoding

PatchSet 1 is state as reviewed previously in
https://codereview.chromium.org/2735083002/
PatchSet 2 fixes the reason for the revert.

Description of issue and fix:

VideoCaptureBrowserTest.ReceiveFramesFromFakeCaptureDevice never called
VideoCaptureController::ReturnBuffer(). As a result, after the maximum number
of allowed in-flight buffers (which is 3) had been reached, subsequent frames
were dropped. The tests using the software decoding path would always pass,
because kMinFramesToReceive was set to 3. It would have failed if set to >3.
The new test case for the accelerated decoding path would pass if the fake
decoder would be initialized and used within the first 3 frames. It would fail
otherwise.

The fix is to call VideoCaptureController::ReturnBuffer() when receiving a
frame. To allow calling this synchronously from within an invokaction of
OnBufferReady(), the order of corresponding invocations in
VideoCaptureController had to be updated.


Description of original CL:

This CL adds test cases to VideoCaptureBrowserTest that exercise the code path
for accelerated jpeg decoding using a fake decode accelerator.

* Add a FakeJpegDecodeAccelerator that can run in the GPU process and decodes
  jpeg frames in software using libyuv.
* Add a command-line flag kUseFakeJpegDecodeAccelerator to enable the fake
  accelerator (and suppress any "real" ones if present).
* Fix threading-related DCHECKs in GpuJpegDecodeAccelerator::Client to match
  what is actually happening. This is needed to make the new test cases pass.
  It also fixes issue 688184 [1].

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [2] CL14.

BUG=584797, 688184
TEST=
  content_browsertests --gtest_filter="VideoCaptureBrowserTest.*"
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

TBR=posciak@chromium.org,piman@chromium.org,sandersd@chromium.org

Review-Url: https://codereview.chromium.org/2772963002
Cr-Commit-Position: refs/heads/master@{#461060}
Committed:
https://chromium.googlesource.com/chromium/src/+/0f72e9da2531d02d80511e54584b...
==========

[commit-bot: I haz the power, 2017-03-31 06:51:34]

Committed patchset #5 (id:80001) as
https://chromium.googlesource.com/chromium/src/+/0f72e9da2531d02d80511e54584b...