YUY2 video chroma problems on Surface Pro 4 only

The application I'm working on captures video in YUY2 format. It gets converted to I420 for compression, and later uses Direct3D to display the image.

On every laptop EXCEPT the Surface Pro 4, video might look like this:

However, on the Surface Pro 4, video looks like this:

(These are screenshots from different devices)

In this instance, both sides support the IMF2DBuffer interface. I get the scanLine0 and stride, along with the contiguous length with the following code:

BYTE *pSrc = NULL;
LONG stride = 0;
DWORD contigLength = 0;

m_p2DBuffer->Lock2D(&pSrc, &stride);
m_p2DBuffer->GetContiguousLength(&contigLength);

The code to unpack the YUY2 frame into planar I420 is as follows:

for (int h = 0; h < videoFrameHeight; h++)
{
	for (int doublePix= 0; doublePix < videoFrameWidth / 2; macroPix++)
	{
		// Grab both Y
		y_plane[yPix++] = pSrc[doublePix * 4];
		y_plane[yPix++] = pSrc[doublePix * 4 + 2];

		// On even-only rows, grab U and V component (vertical downsampling)
		if (h % 2 == 0){
			u_plane[uPix++] = pSrc[doublePix * 4 + 1];
			v_plane[vPix++] = pSrc[doublePix * 4 + 3];
		}
	}
	pSrc += stride;
}

The only difference I could find in the Surface Pro 4 is that the stride it returns is equivalent to 3 bytes per pixel times the image width, whereas the working systems return 2 bytes per pixel (as I would expect for YUY2).

For a 640x480 frame:

Working Laptops

• Format YUY2
• IMF2DBuffer?  Yes
• Contiguous? Yes
• Stride 1280
• Expected Size  614400 Bytes
• Contiguous Length 614400 Bytes

Surface Pro 4 

• Format YUY2
• IMF2DBuffer?  Yes
• Contiguous? Yes
• Stride 1920
• Expected Size  614400 Bytes
• Contiguous Length 3110400 Bytes

I'm struggling to make sense of this difference. Any guidance or thoughts would be appreciated.