Ensure that the code in the DXVA DX11 decoder which can potentially access the DX11 device context …

Merging to M48

Ensure that the code in the DXVA DX11 decoder which can potentially access the DX11 device context on the decoder thread is locked with the ID3D10Multithread interface.

The ProcessInput call on the color converter does access the DX11 device context on the decoder thread to check states.
This currently executes outside the lock. Moving it inside the lock. With this change the color converter ProcessInput
and ProcessOutput calls are in the lock. Added a class AutoDX11DeviceLock to make the locking more seamless.

The other change is to get rid of the begin streaming calls for the converter and the Flush calls on the context.
These are not necessary now with the single device

If this does not fix the Win8 bot flakiness the last step to try would be to move the copy texture call to the main thread.
Failing that we need to go back to the two device model. All symptoms here point to an NVIDIA driver quirk.

BUG=548383
TBR=dalecurtis

Committed: https://chromium.googlesource.com/chromium/src/+/60f74b113dfe62404e80e0899beda85e4f7c538f

[ananta, 2016-01-30 02:18:05]

Description was changed from

==========
Merging to M48

Ensure that the code in the DXVA DX11 decoder which can potentially access the
DX11 device context on the decoder thread is locked with the ID3D10Multithread
interface.

The ProcessInput call on the color converter does access the DX11 device context
on the decoder thread to check states.
This currently executes outside the lock. Moving it inside the lock. With this
change the color converter ProcessInput
and ProcessOutput calls are in the lock. Added a class AutoDX11DeviceLock to
make the locking more seamless.

The other change is to get rid of the begin streaming calls for the converter
and the Flush calls on the context.
These are not necessary now with the single device

If this does not fix the Win8 bot flakiness the last step to try would be to
move the copy texture call to the main thread.
Failing that we need to go back to the two device model. All symptoms here point
to an NVIDIA driver quirk.

BUG=548383
TBR=dalecurtis

Committed: https://crrev.com/fc9a5766e318f7d331961c87bbeb515df1d5b0f6

Cr-Commit-Position: refs/heads/master@{#363611}
==========

to

==========
Merging to M48

Ensure that the code in the DXVA DX11 decoder which can potentially access the
DX11 device context on the decoder thread is locked with the ID3D10Multithread
interface.

The ProcessInput call on the color converter does access the DX11 device context
on the decoder thread to check states.
This currently executes outside the lock. Moving it inside the lock. With this
change the color converter ProcessInput
and ProcessOutput calls are in the lock. Added a class AutoDX11DeviceLock to
make the locking more seamless.

The other change is to get rid of the begin streaming calls for the converter
and the Flush calls on the context.
These are not necessary now with the single device

If this does not fix the Win8 bot flakiness the last step to try would be to
move the copy texture call to the main thread.
Failing that we need to go back to the two device model. All symptoms here point
to an NVIDIA driver quirk.

BUG=548383
TBR=dalecurtis

Committed: https://crrev.com/fc9a5766e318f7d331961c87bbeb515df1d5b0f6

Cr-Commit-Position: refs/heads/master@{#363611}
==========

[ananta, 2016-01-30 02:21:35]

Description was changed from

==========
Merging to M48

Ensure that the code in the DXVA DX11 decoder which can potentially access the
DX11 device context on the decoder thread is locked with the ID3D10Multithread
interface.

The ProcessInput call on the color converter does access the DX11 device context
on the decoder thread to check states.
This currently executes outside the lock. Moving it inside the lock. With this
change the color converter ProcessInput
and ProcessOutput calls are in the lock. Added a class AutoDX11DeviceLock to
make the locking more seamless.

The other change is to get rid of the begin streaming calls for the converter
and the Flush calls on the context.
These are not necessary now with the single device

If this does not fix the Win8 bot flakiness the last step to try would be to
move the copy texture call to the main thread.
Failing that we need to go back to the two device model. All symptoms here point
to an NVIDIA driver quirk.

BUG=548383
TBR=dalecurtis

Committed: https://crrev.com/fc9a5766e318f7d331961c87bbeb515df1d5b0f6

Cr-Commit-Position: refs/heads/master@{#363611}
==========

to

==========
Merging to M48

Ensure that the code in the DXVA DX11 decoder which can potentially access the
DX11 device context on the decoder thread is locked with the ID3D10Multithread
interface.

The ProcessInput call on the color converter does access the DX11 device context
on the decoder thread to check states.
This currently executes outside the lock. Moving it inside the lock. With this
change the color converter ProcessInput
and ProcessOutput calls are in the lock. Added a class AutoDX11DeviceLock to
make the locking more seamless.

The other change is to get rid of the begin streaming calls for the converter
and the Flush calls on the context.
These are not necessary now with the single device

If this does not fix the Win8 bot flakiness the last step to try would be to
move the copy texture call to the main thread.
Failing that we need to go back to the two device model. All symptoms here point
to an NVIDIA driver quirk.

BUG=548383
TBR=dalecurtis
==========

[ananta, 2016-01-30 02:28:02]

Description was changed from

==========
Merging to M48

Ensure that the code in the DXVA DX11 decoder which can potentially access the
DX11 device context on the decoder thread is locked with the ID3D10Multithread
interface.

The ProcessInput call on the color converter does access the DX11 device context
on the decoder thread to check states.
This currently executes outside the lock. Moving it inside the lock. With this
change the color converter ProcessInput
and ProcessOutput calls are in the lock. Added a class AutoDX11DeviceLock to
make the locking more seamless.

The other change is to get rid of the begin streaming calls for the converter
and the Flush calls on the context.
These are not necessary now with the single device

If this does not fix the Win8 bot flakiness the last step to try would be to
move the copy texture call to the main thread.
Failing that we need to go back to the two device model. All symptoms here point
to an NVIDIA driver quirk.

BUG=548383
TBR=dalecurtis
==========

to

==========
Merging to M48

Ensure that the code in the DXVA DX11 decoder which can potentially access the
DX11 device context on the decoder thread is locked with the ID3D10Multithread
interface.

The ProcessInput call on the color converter does access the DX11 device context
on the decoder thread to check states.
This currently executes outside the lock. Moving it inside the lock. With this
change the color converter ProcessInput
and ProcessOutput calls are in the lock. Added a class AutoDX11DeviceLock to
make the locking more seamless.

The other change is to get rid of the begin streaming calls for the converter
and the Flush calls on the context.
These are not necessary now with the single device

If this does not fix the Win8 bot flakiness the last step to try would be to
move the copy texture call to the main thread.
Failing that we need to go back to the two device model. All symptoms here point
to an NVIDIA driver quirk.

BUG=548383
TBR=dalecurtis

Committed:
https://chromium.googlesource.com/chromium/src/+/60f74b113dfe62404e80e0899bed...
==========

[ananta, 2016-01-30 02:28:03]

Committed patchset #1 (id:1) manually as
60f74b113dfe62404e80e0899beda85e4f7c538f (presubmit successful).