Fixed status typo.

Still needs to be fixed...

Where are those YUVVideoDrawQuads coming from? When we have gmbs-video-frames enabled we usually end up with a TextureDrawQuad.

To take a look at the recent UMAs [1], we're now hitting the CA path 99.33% of the time on stable, with YUV draw quads having dropped down to 0.23% of our misses, and render pass sorting context ids accounting for 0.36% (this is in the 14 day aggregate, to avoid skew due to the recent holidays).

I'm still curious where these YUV videos come from, too.

[1]
https://uma.googleplex.com/p/chrome/histograms/?endDate=20180707&dayCount=1&histograms=Compositing.Renderer.CALayerResult&fixupData=true&showMax=true&filters=platform%2Ceq%2CM%2Cchannel%2Ceq%2C4%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

It could be the call to CreateAndAppendDrawQuad<viz::YUVVideoDrawQuad>() [1]
which is hit if we fall through CreateForSoftwarePlanes() [2]. This path is
hit in cases like VP8 with alpha video playback[3] , where the GMBVFPool is not
engaged.


[1] https://cs.chromium.org/chromium/src/media/renderers/video_resource_updater.cc?type=cs&sq=package:chromium&g=0&l=472
[2] https://cs.chromium.org/chromium/src/media/renderers/video_resource_updater.cc?type=cs&sq=package:chromium&g=0&l=1069
[3] https://cs.chromium.org/chromium/src/media/renderers/video_resource_updater.cc?type=cs&sq=package:chromium&g=0&l=1069

This site's creating a YUV draw quad on my Macbook:

https://simpl.info/videoalpha/

Looks like there exists a 4:2:2:4 YUVA IOSurface format -- perhaps we should add support to 

... to GMBVFPool? Haven't actually attempted it yet, but the documentation is promising.

https://developer.apple.com/documentation/corevideo/1563591-pixel_format_identifiers/kcvpixelformattype_422ypcbcr_4a_8biplanar?language=objc

First plane: Video-range Component Y'CbCr 8-bit 4:2:2, ordered Cb Y'0 Cr Y'1; second plane: alpha 8-bit 0-255.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dddc956881beb1618d5f672275ec0cf060a64e3e

commit dddc956881beb1618d5f672275ec0cf060a64e3e
Author: Miguel Casas <mcasas@chromium.org>
Date: Wed Jul 11 18:42:54 2018

GMBVideoFramePool: add UMA of unsupported VideoFrame formats

This CL adds a UMA for unsupported VideoFrame pixel formats in
GMBVideoFramePool; these VideoFrames are not processed in the said
GMVFPool and end up being handled in VideoResourceUpdater's
CreateForSoftwarePlanes() insteadm, which is a code path we would
like to avoid. This UMA will help track these situations.

Bug: 787122
Change-Id: I9c0a7e79c8784063b6dba577766d3fc504642400
Reviewed-on: https://chromium-review.googlesource.com/1132112
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#574260}
[modify] https://crrev.com/dddc956881beb1618d5f672275ec0cf060a64e3e/media/video/gpu_memory_buffer_video_frame_pool.cc
[modify] https://crrev.com/dddc956881beb1618d5f672275ec0cf060a64e3e/tools/metrics/histograms/histograms.xml

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cd37f90890183578fba64dd483432cb787178f1d

commit cd37f90890183578fba64dd483432cb787178f1d
Author: Miguel Casas <mcasas@chromium.org>
Date: Wed Jul 18 00:12:38 2018

GMBVideoFramePool UMA: only log non-texture VideoFrames

Follow up and correction to crrev.com/c/1132112: we should
only log those VideoFrames that are not supported _and_
that are not Textures/GMBs already. This CL adds the latter
part.

Bug: 787122
Change-Id: Ieb4e4fff0f2e14e9beb6949f1531507ac80733ce
Reviewed-on: https://chromium-review.googlesource.com/1140834
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575866}
[modify] https://crrev.com/cd37f90890183578fba64dd483432cb787178f1d/media/video/gpu_memory_buffer_video_frame_pool.cc