Fix for issue 696098 (potential video capture crash ChromeOS)

Fix for issue 696098 (potential video capture crash ChromeOS)

In a previous CL [1], the contract between VideoCaptureDeviceClient and 
VideoFrameReceiver has changed such that VideoCaptureDeviceClient is required 
to call VideoFrameReceiver::OnNewBufferHandle() before using the corresponding 
buffer to push frames. 

The call to OnNewBufferHandle() was made in OnIncomingCapturedBufferExt().
However, in the case of accelerated MJPEG decoding, this code path is not 
actually getting used for the delivery of frames. And the code path that does 
get used for delivery of accelerated MJPEG frames does not make the required 
calls to OnNewBufferHandle().

This CL moves the calls to OnNewBufferHandle() to a location that is used in 
both cases, which is immediately after a buffer is reserved.

[1] https://codereview.chromium.org/2686763002/

BUG=696098
TEST=Currently not covered by any automated test. For manual test, run video 
capture on a ChromeOS device that uses accelerated MJPEG decoding.

Review-Url: https://codereview.chromium.org/2715713006
Cr-Commit-Position: refs/heads/master@{#453077}
Committed: https://chromium.googlesource.com/chromium/src/+/1339655a2c52f3e775166de7a21caa92d831c55d

[chfremer, 2017-02-25 00:55:48]

Description was changed from

==========
Fix for issue 696098 (potential video capture crash ChromeOS)

BUG=
==========

to

==========
Fix for issue 696098 (potential video capture crash ChromeOS)

In a previous CL [1], the contract between VideoCaptureDeviceClient and 
VideoFrameReceiver has changed such that VideoCaptureDeviceClient is required 
to call VideoFrameReceiver::OnNewBufferHandle() before using the corresponding 
buffer to push frames. 

The call to OnNewBufferHandle() was made in OnIncomingCapturedBufferExt().
However, in the case of accelerated MJPEG decoding, this code path is not 
actually getting used for the delivery of frames. And the code path that does 
get used for delivery of accelerated MJPEG frames does not make the required 
calls to OnNewBufferHandle().

This CL moves the calls to OnNewBufferHandle() to a location that is used in 
both cases, which is immediately after a buffer is reserved.

[1] https://codereview.chromium.org/2686763002/

BUG=696098
TEST=Currently not covered by any automated test. For manual test, run video 
capture on a ChromeOS device that uses accelerated MJPEG decoding.
==========

[chfremer, 2017-02-25 00:57:03]

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

[chfremer, 2017-02-25 00:57:03]

PTAL

[chfremer, 2017-02-25 00:57:10]

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

[commit-bot: I haz the power, 2017-02-25 00:57:22]

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-02-25 00:58:46]

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

[commit-bot: I haz the power, 2017-02-25 00:58:47]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[chfremer, 2017-02-25 02:10:59]

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

[commit-bot: I haz the power, 2017-02-25 02:11:18]

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-02-25 03:30:06]

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

[commit-bot: I haz the power, 2017-02-25 03:30:06]

Dry run: This issue passed the CQ dry run.

[miu, 2017-02-25 03:48:25]

lgtm

[chfremer, 2017-02-25 07:54:37]

The CQ bit was checked by chfremer@chromium.org

[commit-bot: I haz the power, 2017-02-25 07:54:42]

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-02-25 08:02:32]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1488009277209440, "parent_rev":
"87d16a7d41eb8be4e60aafdbf7fab4c16644ee17", "commit_rev":
"1339655a2c52f3e775166de7a21caa92d831c55d"}

[commit-bot: I haz the power, 2017-02-25 08:03:06]

Description was changed from

==========
Fix for issue 696098 (potential video capture crash ChromeOS)

In a previous CL [1], the contract between VideoCaptureDeviceClient and 
VideoFrameReceiver has changed such that VideoCaptureDeviceClient is required 
to call VideoFrameReceiver::OnNewBufferHandle() before using the corresponding 
buffer to push frames. 

The call to OnNewBufferHandle() was made in OnIncomingCapturedBufferExt().
However, in the case of accelerated MJPEG decoding, this code path is not 
actually getting used for the delivery of frames. And the code path that does 
get used for delivery of accelerated MJPEG frames does not make the required 
calls to OnNewBufferHandle().

This CL moves the calls to OnNewBufferHandle() to a location that is used in 
both cases, which is immediately after a buffer is reserved.

[1] https://codereview.chromium.org/2686763002/

BUG=696098
TEST=Currently not covered by any automated test. For manual test, run video 
capture on a ChromeOS device that uses accelerated MJPEG decoding.
==========

to

==========
Fix for issue 696098 (potential video capture crash ChromeOS)

In a previous CL [1], the contract between VideoCaptureDeviceClient and 
VideoFrameReceiver has changed such that VideoCaptureDeviceClient is required 
to call VideoFrameReceiver::OnNewBufferHandle() before using the corresponding 
buffer to push frames. 

The call to OnNewBufferHandle() was made in OnIncomingCapturedBufferExt().
However, in the case of accelerated MJPEG decoding, this code path is not 
actually getting used for the delivery of frames. And the code path that does 
get used for delivery of accelerated MJPEG frames does not make the required 
calls to OnNewBufferHandle().

This CL moves the calls to OnNewBufferHandle() to a location that is used in 
both cases, which is immediately after a buffer is reserved.

[1] https://codereview.chromium.org/2686763002/

BUG=696098
TEST=Currently not covered by any automated test. For manual test, run video 
capture on a ChromeOS device that uses accelerated MJPEG decoding.

Review-Url: https://codereview.chromium.org/2715713006
Cr-Commit-Position: refs/heads/master@{#453077}
Committed:
https://chromium.googlesource.com/chromium/src/+/1339655a2c52f3e775166de7a21c...
==========

[commit-bot: I haz the power, 2017-02-25 08:03:07]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/1339655a2c52f3e775166de7a21c...