cc: Don't apply YUV color conversion to non-YUV draw quads

cc: Don't apply YUV color conversion to non-YUV draw quads

Some video frames are passed as RGBA textures to the compositor. RGBA
conversion is done beforehand in various ways (for 422 textures, this
can be done in hardware at texture fetch time, for 420 textures, this
has to be done manually in the command buffer bowels).

The root problem is that, despite the fact that YUV to RGB conversion
has been applied, these textures are tagged with a YUV color space.

The full fix is to audit all of the places where TextureMailboxes are
populated by media code, and ensure that the ColorSpace attached to the
mailbox is the ColorSpace that we will get from texturing out of the
resource we create from the TextureMailbox.

For the moment, fix this regression by ensuring that no color conversion
be applied to any DrawQuads except for YUV video draw quads.

BUG=699123
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2734223002
Cr-Commit-Position: refs/heads/master@{#455265}
Committed: https://chromium.googlesource.com/chromium/src/+/7100c1b09f742260b741c1cd717b8f449e0f8eb2

[ccameron, 2017-03-07 21:07:31]

Description was changed from

==========
cc: Don't apply YUV color conversion to non-YUV draw quads

Some video frames are passed as RGBA textures to the compositor. RGBA
conversion is done beforehand in various ways (for 422 textures, this
can be done in hardware at texture fetch time, for 420 textures, this
has to be done manually in the command buffer bowels).

The root problem is that, despite the fact that YUV to RGB conversion
has been applied, these textures are tagged with a YUV color space.

The full fix is to audit all of the places where TextureMailboxes are
populated by media code, and ensure that the ColorSpace attached to the
mailbox is the ColorSpace that we will get from texturing out of the
resource we create from the TextureMailbox.

For the moment, fix this regression by ensuring that no color conversion
be applied to any DrawQuads except for YUV video draw quads.

BUG=699123
==========

to

==========
cc: Don't apply YUV color conversion to non-YUV draw quads

Some video frames are passed as RGBA textures to the compositor. RGBA
conversion is done beforehand in various ways (for 422 textures, this
can be done in hardware at texture fetch time, for 420 textures, this
has to be done manually in the command buffer bowels).

The root problem is that, despite the fact that YUV to RGB conversion
has been applied, these textures are tagged with a YUV color space.

The full fix is to audit all of the places where TextureMailboxes are
populated by media code, and ensure that the ColorSpace attached to the
mailbox is the ColorSpace that we will get from texturing out of the
resource we create from the TextureMailbox.

For the moment, fix this regression by ensuring that no color conversion
be applied to any DrawQuads except for YUV video draw quads.

BUG=699123
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

[ccameron, 2017-03-07 21:16:00]

ccameron@chromium.org changed reviewers:
+ hubbe@chromium.org

[ccameron, 2017-03-07 21:16:01]

This works around the bug, to ensure that we don't ship anything broken.

I'm going to update the video resource updater code (among other things) in a
separate patch, and change these things to DCHECKs.

[ccameron, 2017-03-07 21:16:15]

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

[commit-bot: I haz the power, 2017-03-07 21:17:32]

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

[hubbe, 2017-03-07 21:55:08]

lgtm

[ccameron, 2017-03-07 21:55:49]

The CQ bit was unchecked by ccameron@chromium.org

[ccameron, 2017-03-07 21:55:52]

The CQ bit was checked by ccameron@chromium.org

[commit-bot: I haz the power, 2017-03-07 21:56:28]

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-07 22:46:31]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1488923752453210,
"parent_rev": "4c5dedc05add1990762f67a148118fedc78db487", "commit_rev":
"7100c1b09f742260b741c1cd717b8f449e0f8eb2"}

[commit-bot: I haz the power, 2017-03-07 22:47:22]

Description was changed from

==========
cc: Don't apply YUV color conversion to non-YUV draw quads

Some video frames are passed as RGBA textures to the compositor. RGBA
conversion is done beforehand in various ways (for 422 textures, this
can be done in hardware at texture fetch time, for 420 textures, this
has to be done manually in the command buffer bowels).

The root problem is that, despite the fact that YUV to RGB conversion
has been applied, these textures are tagged with a YUV color space.

The full fix is to audit all of the places where TextureMailboxes are
populated by media code, and ensure that the ColorSpace attached to the
mailbox is the ColorSpace that we will get from texturing out of the
resource we create from the TextureMailbox.

For the moment, fix this regression by ensuring that no color conversion
be applied to any DrawQuads except for YUV video draw quads.

BUG=699123
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

to

==========
cc: Don't apply YUV color conversion to non-YUV draw quads

Some video frames are passed as RGBA textures to the compositor. RGBA
conversion is done beforehand in various ways (for 422 textures, this
can be done in hardware at texture fetch time, for 420 textures, this
has to be done manually in the command buffer bowels).

The root problem is that, despite the fact that YUV to RGB conversion
has been applied, these textures are tagged with a YUV color space.

The full fix is to audit all of the places where TextureMailboxes are
populated by media code, and ensure that the ColorSpace attached to the
mailbox is the ColorSpace that we will get from texturing out of the
resource we create from the TextureMailbox.

For the moment, fix this regression by ensuring that no color conversion
be applied to any DrawQuads except for YUV video draw quads.

BUG=699123
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2734223002
Cr-Commit-Position: refs/heads/master@{#455265}
Committed:
https://chromium.googlesource.com/chromium/src/+/7100c1b09f742260b741c1cd717b...
==========

[commit-bot: I haz the power, 2017-03-07 22:47:23]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/7100c1b09f742260b741c1cd717b...