This is a public version of bug 644293.

The basic problem is when chrome is launched with --disable-gpu-driver-bug-workarounds --disable-zero-copy-dxgi-video and you play an h.264 video (say from vimeo), it displays pink and green instead of the correct colors.

Here's what I've seen when investigating:
With zero copy dxgi video and NV12 video both enabled (--disable-gpu-driver-bug-workarounds)
1) The driver hangs. This seems to be because the decoder texture is created with MF_SA_D3D11_SHARED_WITHOUT_MUTEX, giving it a share handle. The driver tries to lock the texture DonotWait, but locking fails because you can't locked a shared texture, so it spins forever.
2) Removing the share handle, it kind of works, but it looks like there's no synchronization between decode into a texture and read from it. It's even possible that it reads the Y plane for one frame and the UV plane for a different frame in the same pixel shader invocation.

With zero copy dxgi video disabled and NV12 video enabled (--disable-gpu-driver-bug-workarounds --disable-zero-copy-dxgi-video):

It seems to be reading from the Y plane for the UV data. Based on the fact that zero-copy video mostly works, I'm inclined to think that it's the copying of the video that's incorrectly copying the Y data onto the UV plane. I also tried CopySubresourceRegion, but that had the same problem as using the video processor.