For future reference, and why not? the original chrome perfgrams are
https://chromeperf.appspot.com/report?sid=1714a1e26719c517812bfbc4ab42856effa400739d38dd0d41f7bc2db10b2e5f

but dcastagna@ has an encouraging lead to follow, stay tuned.

Repro'ed the problem with the bot by downloading [1] from [2]
and playing it back on a soraka simplechrome with hw deco off;
gpu process was crashing due to:

[11127:11127:1204/155509.518174:FATAL:gbm_buffer.cc(375)] Check failed: buffer_->GetFlags() & GBM_BO_USE_SCANOUT. 

[3773:3787:1204/162035.772883:ERROR:hardware_display_plane_manager.cc(274)] Failed to find a free plane for crtc 36
[3773:3787:1204/162035.773086:ERROR:crtc_controller.cc(96)] Failed to assign overlay planes for crtc 36: Invalid argument (22)
[3773:3773:1204/162035.773286:ERROR:gles2_cmd_decoder.cc(16041)] Context lost because SwapBuffers failed.
[3773:3773:1204/162035.805484:ERROR:gles2_cmd_decoder.cc(4447)]   GLES2DecoderImpl: Trying to make lost context current.
[3773:3787:1204/162035.773319:FATAL:drm_thread.cc(194)] Check failed: result. DrmThread::SchedulePageFlip failed.
#0 0x58e5cc8ba24c base::debug::StackTrace::StackTrace()
#1 0x58e5cc8d1cd3 logging::LogMessage::~LogMessage()
#2 0x58e5cac96fd9 ui::DrmThread::SchedulePageFlip()
#3 0x58e5caca05d3 _ZN4base8internal7InvokerINS0_9BindStateIMN2ui9DrmThreadEFviRKNSt3__16vectorINS3_12OverlayPlaneENS5_9allocatorIS7_EEEENS_12OnceCallbackIFvN3gfx10SwapResultEEEEEJNS0_17UnretainedWrapperIS4_EEiSA_SH_EEEFvvEE7RunOnceEPNS0_13BindStateBaseE
#4 0x58e5cc8baa59 base::debug::TaskAnnotator::RunTask()
#5 0x58e5cc8d68f7 base::MessageLoop::RunTask()
#6 0x58e5cc8d6e18 base::MessageLoop::DoWork()
#7 0x58e5cc8d80c9 base::MessagePumpLibevent::Run()
#8 0x58e5cc8f8b35 base::RunLoop::Run()
#9 0x58e5cc922449 base::Thread::ThreadMain()
#10 0x58e5cc91cbcd base::(anonymous namespace)::ThreadFunc()
#11 0x7c8999be02b8 <unknown>
#12 0x7c8998d20fad clone

Received signal 6
#0 0x58e5cc8ba24c base::debug::StackTrace::StackTrace()
#1 0x58e5cc8b9db1 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7c8999bea2e0 <unknown>
#3 0x7c8998c5ddd2 gsignal
#4 0x7c8998c5fbf6 abort
#5 0x58e5cc8b8965 base::debug::BreakDebugger()
#6 0x58e5cc8d212b logging::LogMessage::~LogMessage()
#7 0x58e5cac96fd9 ui::DrmThread::SchedulePageFlip()
#8 0x58e5caca05d3 _ZN4base8internal7InvokerINS0_9BindStateIMN2ui9DrmThreadEFviRKNSt3__16vectorINS3_12OverlayPlaneENS5_9allocatorIS7_EEEENS_12OnceCallbackIFvN3gfx10SwapResultEEEEEJNS0_17UnretainedWrapperIS4_EEiSA_SH_EEEFvvEE7RunOnceEPNS0_13BindStateBaseE
#9 0x58e5cc8baa59 base::debug::TaskAnnotator::RunTask()
#10 0x58e5cc8d68f7 base::MessageLoop::RunTask()
#11 0x58e5cc8d6e18 base::MessageLoop::DoWork()
#12 0x58e5cc8d80c9 base::MessagePumpLibevent::Run()
#13 0x58e5cc8f8b35 base::RunLoop::Run()
#14 0x58e5cc922449 base::Thread::ThreadMain()
#15 0x58e5cc91cbcd base::(anonymous namespace)::ThreadFunc()
#16 0x7c8999be02b8 <unknown>
#17 0x7c8998d20fad clone
  r8: 00007c89932ed3f0  r9: 0000000000000000 r10: 0000000000000008 r11: 0000000000000206
 r12: 00007c89932ed848 r13: 0000000000000071 r14: 00007c89932ed3f0 r15: 00007c89932ed840
  di: 0000000000000ebd  si: 0000000000000ecb  bp: 00007c89932ed380  bx: 00007c8998fcf7a0
  dx: 0000000000000006  ax: 0000000000000000  cx: 00007c8998c5ddd2  sp: 00007c89932ed258
  ip: 00007c8998c5ddd2 efl: 0000000000000206 cgf: 0000000000000033 erf: 0000000000000000
 trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.
device-enumerator: scan all dirs


[1] https://chromium.googlesource.com/chromiumos/third_party/autotest/+/385b8495af6d00864c60d34fa8439fce682fbd19/client/site_tests/video_PlaybackPerf/control.h264#23
[2]https://chromium.googlesource.com/chromiumos/third_party/autotest/+/385b8495af6d00864c60d34fa8439fce682fbd19/client/site_tests/video_PlaybackPerf/video_PlaybackPerf.py#21

(#4 included crrev.com/c/756217)

Actually the DCHECK() stack should be:

[7962:7962:1204/163212.955586:FATAL:gbm_buffer.cc(375)] Check failed: buffer_->GetFlags() & GBM_BO_USE_SCANOUT. 
#0 0x5d201096913c base::debug::StackTrace::StackTrace()
#1 0x5d2010987ec3 logging::LogMessage::~LogMessage()
#2 0x5d200e245cea ui::GbmPixmap::ScheduleOverlayPlane()
#3 0x5d2011842dca gl::GLImageNativePixmap::ScheduleOverlayPlane()
#4 0x5d2011839899 gl::GLSurfaceOverlay::ScheduleOverlayPlane()
#5 0x5d200e248fdb ui::GbmSurfaceless::SubmitFrame()
#6 0x5d200e248b90 ui::GbmSurfaceless::SwapBuffersAsync()
#7 0x5d20118378bb gl::GLSurfaceAdapter::PostSubBufferAsync()
#8 0x5d2011ce241c gpu::PassThroughImageTransportSurface::PostSubBufferAsync()
#9 0x5d20149d922c gpu::gles2::GLES2DecoderImpl::HandlePostSubBufferCHROMIUM()
#10 0x5d20149f5538 gpu::gles2::GLES2DecoderImpl::DoCommandsImpl<>()
#11 0x5d20149aed7f gpu::CommandBufferService::Flush()
#12 0x5d2014b7a7b9 gpu::GpuCommandBufferStub::OnAsyncFlush()
#13 0x5d2014b7a55c _ZN3IPC8MessageTI35GpuCommandBufferMsg_AsyncFlush_MetaNSt3__15tupleIJijbEEEvE8DispatchIN3gpu20GpuCommandBufferStubES8_vMS8_FvijbEEEbPKNS_7MessageEPT_PT0_PT1_T2_
#14 0x5d2014b78c8e gpu::GpuCommandBufferStub::OnMessageReceived()
#15 0x5d20149851cf IPC::MessageRouter::RouteMessage()
#16 0x5d2014b756ce gpu::GpuChannel::HandleMessageHelper()
#17 0x5d2014b731b7 gpu::GpuChannel::HandleMessage()
#18 0x5d2014b75f4b _ZN4base8internal7InvokerINS0_9BindStateIMN3gpu10GpuChannelEFvRKN3IPC7MessageEEJNS_7WeakPtrIS4_EENS5_8MessageTI35GpuCommandBufferMsg_AsyncFlush_MetaNSt3__15tupleIJijbEEEvEEEEEFvvEE7RunOnceEPNS0_13BindStateBaseE
#19 0x5d2014a74301 gpu::Scheduler::RunNextTask()
#20 0x5d200df75fb4 _ZN4base8internal7InvokerINS0_9BindStateIMN11google_apis19UrlFetchRequestBaseEFvvEJNS_7WeakPtrINS3_5drive30SingleBatchableDelegateRequestEEEEEEFvvEE3RunEPNS0_13BindStateBaseE
#21 0x5d2010969998 base::debug::TaskAnnotator::RunTask()
#22 0x5d2010a348c6 base::internal::IncomingTaskQueue::RunTask()
#23 0x5d201098f68d base::MessageLoop::RunTask()
#24 0x5d201098fa94 base::MessageLoop::DeferOrRunPendingTask()
#25 0x5d201098fd40 base::MessageLoop::DoWork()
#26 0x5d20109910f0 base::MessagePumpDefault::Run()
#27 0x5d201098eefc base::MessageLoop::Run()
#28 0x5d20109bd3a6 base::RunLoop::Run()
#29 0x5d20141262fa content::GpuMain()
#30 0x5d201056feb4 content::RunNamedProcessTypeMain()
#31 0x5d20105709c7 content::ContentMainRunnerImpl::Run()
#32 0x5d201057cf29 service_manager::Main()
#33 0x5d201056f241 content::ContentMain()
#34 0x5d200deb8293 ChromeMain
#35 0x7d6ef3a34736 __libc_start_main
#36 0x5d200deb7d89 _start

So the story, after some investigation, is that there seems to be a 
bit of a misuse inside VideoFrame of the pixel format to (potentially)
represent the storage format and the sampling format of the 
underlying GMBs represented by the mailboxes. IOW, a VideoFrame can
have |data_| [1] and/or |mailbox_holders_| [2] and, although those
two usually have the same pixel format, sometimes they won't; that
circumstance has been somehow worked around by e.g. [3,4].

[1] https://cs.chromium.org/chromium/src/media/base/video_frame.h?sq=package:chromium&dr=CSs&l=529
[2] https://cs.chromium.org/chromium/src/media/base/video_frame.h?sq=package:chromium&dr=CSs&l=532
[3] https://cs.chromium.org/chromium/src/media/video/gpu_memory_buffer_video_frame_pool.cc?sq=package:chromium&dr=CSs&l=277
[4] https://cs.chromium.org/chromium/src/cc/resources/video_resource_updater.cc?q=video_resource_update&sq=package:chromium&dr=C&l=40

So, what's needed to make crrev.com/c/756217 work is to correct those,
i.e. in a hackity hack way:

diff --git a/media/video/gpu_memory_buffer_video_frame_pool.cc b/media/video/gpu_memory_buffer_video_frame_pool.cc
index 10e7b458dd4f..f78fbb472302 100644
--- a/media/video/gpu_memory_buffer_video_frame_pool.cc
+++ b/media/video/gpu_memory_buffer_video_frame_pool.cc
@@ -274,14 +274,15 @@ VideoPixelFormat VideoFormat(
 VideoPixelFormat FinalVideoFormat(
     GpuVideoAcceleratorFactories::OutputFormat format) {
   // Consumers should sample from NV12 textures as if they're XRGB.
-  if (format == GpuVideoAcceleratorFactories::OutputFormat::NV12_SINGLE_GMB)
-    return PIXEL_FORMAT_XRGB;
+  //if (format == GpuVideoAcceleratorFactories::OutputFormat::NV12_SINGLE_GMB)
+  //  return PIXEL_FORMAT_XRGB;
   return VideoFormat(format);
 }
 
 // The number of output planes to be copied in each iteration.
 size_t NumGpuMemoryBuffers(GpuVideoAcceleratorFactories::OutputFormat format) {
-  return VideoFrame::NumPlanes(FinalVideoFormat(format));
+  return 1;
+  //return VideoFrame::NumPlanes(FinalVideoFormat(format));
 }

I'm confused, where is the misuse, and shouldn't we be fixing that instead?

One of the misuses comes from cases where the number of data 
planes is not equal to the number of buffers backing them, 
e.g. we can have an NV12 pixel format, which implies two data 
planes - one for luma and one for interleaved chromas, backed
by either two data buffers (up until recently the only option) 
or backed by one big buffer (possible a GMB).  

This situation is probably a legacy: VFrames used to be backed
by plain owned |data_| pointers, then they got the mailboxes 
when "backed by textures", then eventually the textures got a 
different format than |data_|, which is where we are now.

GpuMemoryBuffer (and GpuVideoAcceleratorFactories) work around 
this "limitation" in VideoFrames by describing the amount of 
planes together with the pixel format [0]; then said [1]
appropriates the pixel format to send the signal down the line 
that the data is backed by a single buffer (and to make sure 
that we fall down the path [2] and not [3])

[0] https://cs.chromium.org/chromium/src/media/video/gpu_video_accelerator_factories.h?sq=package:chromium&dr=CSs&l=70
[1] https://cs.chromium.org/chromium/src/media/video/gpu_memory_buffer_video_frame_pool.cc?sq=package:chromium&dr=CSs&l=277
[2] https://cs.chromium.org/chromium/src/cc/resources/video_resource_updater.cc?q=video_resource_update&sq=package:chromium&dr=C&l=55
[3] https://cs.chromium.org/chromium/src/cc/resources/video_resource_updater.cc?q=video_resource_update&sq=package:chromium&dr=C&l=73


Solutions: 

- short term, and for the purpose of this Issue, just make sure
the current code and the new needs reconcile.

- medium/long term, VideoFrame should get member(s) to carry 
the format of the |mailbox_holders_|, if any, separated from
the single |format_| of |data_|. All those formats may coincide.

I'm still confused. Once the data is placed into textures, the video frame only needs to know how to sample from those textures, it does not actually need to know the format.

NV12 is a specific memory layout, which really only makes sense when talking about memory-backed data. The GPU may also use NV12 internally, but once the data has been placed into such a texture, it looks like a standard RGB texture to the video frame and should be treated as such.

We need to know the format of the underlying buffer to schedule it as an overlay.

If we have a Quad with a resource that claims to be an RGB, but the data format is an NV12, we need to test the overlay configuration with NV12, not RGB.

What happened when we enabled NV12 on CrOS is that we ended up testing HW overlays with RGB (since the videoframe claimed to be RGB), then we scheduled the HW overlays, since the test succeed, and we failed to pageflip when we tried to schedule an NV12 that is not supported on KBL yet.

And it's not possible to just ask the GMB what format it actually is?
Or stick the relevant information in the mailbox perhaps?
The video frame format enum is already terrible in a lot of ways, using it less would be better than using it more.

We don't have GMBs when we're in the display compositor (where we generate the set of HW overlays to test), we have only textures.
We have no idea if the texture has an external image and the format of it. That information is in the GPU process, but we currently try to guess and create the configuration of overlays in the browser process.
Once we move to viz/mus world, we should be able to fix that.

We currently use NV12 videoframes for NV12 buffers coming from HW video decoding (at least on CrOS), even if you can bind them an RGB textures. crrev.com/c/807366 would make it more consistent with this behavior, while we figure out a better way of carrying along or surface data format and pixel format in the display compositor.

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

commit 43a94cb5e0b90beca79a80315baecadb474f2c5c
Author: Miguel Casas-Sanchez <mcasas@chromium.org>
Date: Wed Dec 06 04:15:30 2017

Use VideoFrame::NumTextures ISO NumPlanes where needed

This CL sorts out a few points to clear the way for
crrev.com/c/784330 to be landed again; these changes
are, in a nutshell using NumTextures() ISO NumPlanes()
where appropriate, and rewriting the service function
NumGpuMemoryBuffers() for clarity and to allow for
removing FinalVideoFormat().

TEST=all unittests working as before, Video playback
in all platforms and with/without video deco acceleration
running as on ToT.

Bug:  791676 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Ic8f0a646a7a0d9271d7233681cb0383e3f6f64ba
Reviewed-on: https://chromium-review.googlesource.com/807366
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Fredrik Hubinette <hubbe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#521999}
[modify] https://crrev.com/43a94cb5e0b90beca79a80315baecadb474f2c5c/cc/resources/video_resource_updater.cc
[modify] https://crrev.com/43a94cb5e0b90beca79a80315baecadb474f2c5c/cc/resources/video_resource_updater_unittest.cc
[modify] https://crrev.com/43a94cb5e0b90beca79a80315baecadb474f2c5c/media/renderers/paint_canvas_video_renderer.cc
[modify] https://crrev.com/43a94cb5e0b90beca79a80315baecadb474f2c5c/media/video/gpu_memory_buffer_video_frame_pool.cc
[modify] https://crrev.com/43a94cb5e0b90beca79a80315baecadb474f2c5c/media/video/gpu_memory_buffer_video_frame_pool_unittest.cc

+Drew since this is needed on Kahlee as well.

dcastagna@ knows what to do; I can verify on soraka and link.

Request to merge https://chromium-review.googlesource.com/807366 to M64 as it seems to be the fix for  crbug.com/787379 .

Removing the Merge-Request-64 since we requested it on  crbug.com/787379 

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

commit f6e6ee458bac39b21fcc6d4c95684bad2ab35c8e
Author: Daniele Castagna <dcastagna@chromium.org>
Date: Tue Dec 12 02:31:25 2017

Use VideoFrame::NumTextures ISO NumPlanes where needed

This CL sorts out a few points to clear the way for
crrev.com/c/784330 to be landed again; these changes
are, in a nutshell using NumTextures() ISO NumPlanes()
where appropriate, and rewriting the service function
NumGpuMemoryBuffers() for clarity and to allow for
removing FinalVideoFormat().

TEST=all unittests working as before, Video playback
in all platforms and with/without video deco acceleration
running as on ToT.

TBR=mcasas@chromium.org

(cherry picked from commit 43a94cb5e0b90beca79a80315baecadb474f2c5c)

Bug:  791676 ,  787379 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Ic8f0a646a7a0d9271d7233681cb0383e3f6f64ba
Reviewed-on: https://chromium-review.googlesource.com/807366
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Fredrik Hubinette <hubbe@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#521999}
Reviewed-on: https://chromium-review.googlesource.com/821151
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#163}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/f6e6ee458bac39b21fcc6d4c95684bad2ab35c8e/cc/resources/video_resource_updater.cc
[modify] https://crrev.com/f6e6ee458bac39b21fcc6d4c95684bad2ab35c8e/cc/resources/video_resource_updater_unittest.cc
[modify] https://crrev.com/f6e6ee458bac39b21fcc6d4c95684bad2ab35c8e/media/renderers/paint_canvas_video_renderer.cc
[modify] https://crrev.com/f6e6ee458bac39b21fcc6d4c95684bad2ab35c8e/media/video/gpu_memory_buffer_video_frame_pool.cc
[modify] https://crrev.com/f6e6ee458bac39b21fcc6d4c95684bad2ab35c8e/media/video/gpu_memory_buffer_video_frame_pool_unittest.cc

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

commit 0d58af6fc31ca16210c8a0c475fce91fff516ab2
Author: Miguel Casas-Sanchez <mcasas@chromium.org>
Date: Fri Dec 22 03:29:02 2017

Reland: Use NV12 VideoFrames for software decoder on x86

This CL relands crrev.com/c/756217 after fixing the issue with
previous generation boards by adding a new member to
GpuPreferences
  disable_biplanar_gpu_memory_buffers_for_video_frames
that is sent from Browser to GPU process, where it's connected
to a new gles2 decoder Capabilities member:
  image_ycbcr_420v_disabled_for_video_frames
which is then used in GpuVideoAcceleratorFactoriesImpl in the
Renderer process.

This flag and Feature indicates if biplanar VideoFrames (e.g.
NV12) may be stored in single GpuMemoryBuffers (also called here
biplanar for consistency) or not, for performance reasons.

Test: crosvideo.appspot.com?codec=vp9 on scarlet (no hw decoding
for VP9) and on Soraka (with hw decoding explicitly disabled).
Both use the best they can for video_resource_updater, i.e. scarlet
uses two buffers for upload (R_8 and RG_88), whereas soraka uses a
single YUV420_BIPLANAR one.

Bug:  791676 

Original CL description -------------------------------------------
Use NV12 VideoFrames for software decoder on x86.

NV12 has been supported on CrOS x86 mesa for a while.
Mapping an NV12 dmabuf has also been supported and test for a while.

This CL simply advertises that NV12 images can be used and that
NV12 dmabuffs buffers can be mmaped on the renderer side.

In this way, software decoded video frames will be converted to NV12.

Bug:  683347 
Test: youtube on eve with HW video decoder disabled.

--------------------------------------------------------------------

Reviewed-on: https://chromium-review.googlesource.com/756217
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: David Reveman <reveman@chromium.org>
Commit-Queue: Daniele Castagna <dcastagna@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#515855}
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I3b07cad358bd3219ad3ebdc45582e7b5213050e8
Reviewed-on: https://chromium-review.googlesource.com/838101
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#525919}
[modify] https://crrev.com/0d58af6fc31ca16210c8a0c475fce91fff516ab2/content/browser/gpu/gpu_data_manager_impl_private.cc
[modify] https://crrev.com/0d58af6fc31ca16210c8a0c475fce91fff516ab2/content/renderer/media/gpu/gpu_video_accelerator_factories_impl.cc
[modify] https://crrev.com/0d58af6fc31ca16210c8a0c475fce91fff516ab2/gpu/command_buffer/common/capabilities.h
[modify] https://crrev.com/0d58af6fc31ca16210c8a0c475fce91fff516ab2/gpu/command_buffer/service/feature_info.cc
[modify] https://crrev.com/0d58af6fc31ca16210c8a0c475fce91fff516ab2/gpu/command_buffer/service/gles2_cmd_decoder.cc
[modify] https://crrev.com/0d58af6fc31ca16210c8a0c475fce91fff516ab2/gpu/command_buffer/service/gles2_cmd_decoder_passthrough.cc
[modify] https://crrev.com/0d58af6fc31ca16210c8a0c475fce91fff516ab2/gpu/command_buffer/service/gpu_preferences.h
[modify] https://crrev.com/0d58af6fc31ca16210c8a0c475fce91fff516ab2/gpu/ipc/common/gpu_preferences.mojom
[modify] https://crrev.com/0d58af6fc31ca16210c8a0c475fce91fff516ab2/gpu/ipc/common/gpu_preferences_struct_traits.h
[modify] https://crrev.com/0d58af6fc31ca16210c8a0c475fce91fff516ab2/ui/gfx/linux/client_native_pixmap_factory_dmabuf.cc

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

commit 345fb82e391247fdcf72ebc3c9c667da7fd0d794
Author: Miguel Casas <mcasas@chromium.org>
Date: Thu Jan 04 23:58:41 2018

Add image_ycbcr_420v_disabled_for_video_frames to IPC traits

This CL is a follow up to crrev.com/c/838101, where the new Capability
  image_ycbcr_420v_disabled_for_video_frames
was added; I forgot to add it to the gpu_command_buffer_traits_multi.h
file [1], so here it is.

The functionality is not changing since this IPC route is not taken in
CrOs (using mojom instead: //gpu/ipc/common/capabilities.mojom), but
just for completion.

[1] https://cs.chromium.org/chromium/src/gpu/command_buffer/common/capabilities.h?type=cs&q=image_ycbcr_420v&sq=package:chromium&l=26

Bug:  791676 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I38ad09b944b9955f3044ab6a353e99551aae23ed
Reviewed-on: https://chromium-review.googlesource.com/850953
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527155}
[modify] https://crrev.com/345fb82e391247fdcf72ebc3c9c667da7fd0d794/gpu/ipc/common/gpu_command_buffer_traits_multi.h

Tnx Miguel.

Verified on 10448.0.0, 66.0.3357.0 by playing youtube video.