There is quite rare problem with the H264 decoder. I have camera with 4CIF resolution which produces H264 BP+ stream, wherein SPS describes the resolution as 704x288 and with pixel aspect ratio 6:11. This is because the camera is MPEG4 and has interlaced video, but it can also stream in H264 but only Baseline profile which is actually does not support field encoding. So the camera encodes each field as a frame. I feed this stream to the decoder filter (I use DirectShow) but the output is corrupt. Normally output consist of two planes: Y and UV. The size of the Y plane is width*height, so the UV plane has offset width*height. But in my case UV plane situated in the memory with the offset width*height/2, so that the Y plane is overwritten. With the input resolution of 704x288 it should be OK, but because the stream is "interlaced" it has twice less lines than it must have, decoder produces the output with following structure: decoded line, line with zeros, decoded line, line with zeros, etc., which correct in my opinion, so that the output Y plane has size width*height, but I think because, the input resolution has size 704x288, the UV plane has offset width*height/2, and the Y plane is overwritten by UV plane.
From your description it seems the H.264 stream generated by your camera is a somewhat custom stream type, and thus may not be supported by the Media SDK decoder without some manual restructuring in application layer.
It's hard to determine what the complications may be without more details about the stream.
Could you please extract the H.264 elementary stream from your camera and share it with us so that we can explore the layout and behavior when fed to the decoder?
Thanks for sharing the stream.
I do not see any issues related to resolution of color space planes in the file you shared.
But, I do see some odd color changes and slight artifacts at regular interval when decoding the stream using the Media SDK HW H.264 decoder. We are currently investigating the stream in more detail to determine to root cause. I'll respond back to this thread when I have more info to share.
May be you can share how you initialize CMediaType, may be I do initialize some values wrong when I pass them to the Intel decoder when it requests by calling GetMediaType?
After studying the content you provided further we do not find any issues with it. The reason for the observed color artifacts is likely related to an issue with the demuxer, which may be delivering incorrect content meta data or in wrong order.
To best understand how to initialize CMediaType I suggest you utilize the resources and samples on MSDN.