Attempt to fix a crash in the H.264 decoder on Windows in the GPU process.

Attempt to fix a crash in the H.264 decoder on Windows in the GPU process.

This crash occurs in the DXVAVideoDecodeAccelerator::Decode functions in a number of places.
1. While allocating an IMFSample interface for the packet coming in.
2. While copying the encoded data into the the sample.
3. While posting a task to the decoder thread.

It is unclear as to why these crashes occur. We have not been able to reproduce these in house.

The callstack in the dump for 1 above, indicates that we are trying to allocate a sample for the default
stream size of 0x1000, while the incoming packet is much lesser than that. I don't think that this crash
is due to OOM. However it seems better to allocate what is needed.

The other change is to set the current length on the media buffer before unlocking it as per msdn guidelines.

BUG=455390
Committed: https://crrev.com/fc09e24ec81ada1e5e462ff92d0eec1ecf38fe80
Cr-Commit-Position: refs/heads/master@{#373684}

[ananta, 2016-02-04 02:21:17]

ananta@chromium.org changed reviewers:
+ dalecurtis@chromium.org

[DaleCurtis, 2016-02-04 22:13:18]

https://codereview.chromium.org/1666043002/diff/1/content/common/gpu/media/dx...
File content/common/gpu/media/dxva_video_decode_accelerator_win.cc (right):

https://codereview.chromium.org/1666043002/diff/1/content/common/gpu/media/dx...
content/common/gpu/media/dxva_video_decode_accelerator_win.cc:258:
std::min<int>(bitstream_buffer.size(), stream_size),
seems this should be uint32_t or DWORD, not int? Ditto for the size type on
CreateInputSample.

[ananta, 2016-02-04 22:32:21]

https://codereview.chromium.org/1666043002/diff/1/content/common/gpu/media/dx...
File content/common/gpu/media/dxva_video_decode_accelerator_win.cc (right):

https://codereview.chromium.org/1666043002/diff/1/content/common/gpu/media/dx...
content/common/gpu/media/dxva_video_decode_accelerator_win.cc:258:
std::min<int>(bitstream_buffer.size(), stream_size),
On 2016/02/04 22:13:18, DaleCurtis wrote:
> seems this should be uint32_t or DWORD, not int? Ditto for the size type on
> CreateInputSample.

Done.

[DaleCurtis, 2016-02-04 22:41:23]

lgtm

[ananta, 2016-02-04 23:29:47]

The CQ bit was checked by ananta@chromium.org

[commit-bot: I haz the power, 2016-02-04 23:34:21]

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

[commit-bot: I haz the power, 2016-02-04 23:44:30]

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

[commit-bot: I haz the power, 2016-02-04 23:44:30]

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

[ananta, 2016-02-05 00:15:33]

The CQ bit was checked by ananta@chromium.org

[commit-bot: I haz the power, 2016-02-05 00:16:34]

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

[commit-bot: I haz the power, 2016-02-05 00:40:59]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-02-05 00:42:31]

Description was changed from

==========
Attempt to fix a crash in the H.264 decoder on Windows in the GPU process.

This crash occurs in the DXVAVideoDecodeAccelerator::Decode functions in a
number of places.
1. While allocating an IMFSample interface for the packet coming in.
2. While copying the encoded data into the the sample.
3. While posting a task to the decoder thread.

It is unclear as to why these crashes occur. We have not been able to reproduce
these in house.

The callstack in the dump for 1 above, indicates that we are trying to allocate
a sample for the default
stream size of 0x1000, while the incoming packet is much lesser than that. I
don't think that this crash
is due to OOM. However it seems better to allocate what is needed.

The other change is to set the current length on the media buffer before
unlocking it as per msdn guidelines.

BUG=455390
==========

to

==========
Attempt to fix a crash in the H.264 decoder on Windows in the GPU process.

This crash occurs in the DXVAVideoDecodeAccelerator::Decode functions in a
number of places.
1. While allocating an IMFSample interface for the packet coming in.
2. While copying the encoded data into the the sample.
3. While posting a task to the decoder thread.

It is unclear as to why these crashes occur. We have not been able to reproduce
these in house.

The callstack in the dump for 1 above, indicates that we are trying to allocate
a sample for the default
stream size of 0x1000, while the incoming packet is much lesser than that. I
don't think that this crash
is due to OOM. However it seems better to allocate what is needed.

The other change is to set the current length on the media buffer before
unlocking it as per msdn guidelines.

BUG=455390

Committed: https://crrev.com/fc09e24ec81ada1e5e462ff92d0eec1ecf38fe80
Cr-Commit-Position: refs/heads/master@{#373684}
==========

[commit-bot: I haz the power, 2016-02-05 00:42:32]

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