Sometimes the source reader returns incorrect video size. It happens with some H265 video files.
This is the reference video: https://drive.google.com/file/d/12oH9x7MCW7YFZu1MDKGbOnIt4VvxrgtZ/view?usp=share_link 3840x2160 pixels
CComPtr<IMFSourceReader> r;
CComPtr<IMFMediaType> NativeMT;
MFCreateSourceReaderFromURL(L"file.mp4" 0, &r);
r->GetCurrentMediaType((DWORD)MF_SOURCE_READER_FIRST_VIDEO_STREAM, &NativeMT);
UINT wi = 0,he = 0;
MFGetAttributeSize(NativeMT, MF_MT_FRAME_SIZE, &wi,&he);
This returns 3840x2176. Why?
I will follow up with more problems because this format fails to be converted to another H264/H265 video with Media Foundation.
So you have this media type for the video track:
MF_MT_FRAME_SIZE
, 16492674418816 (TypeVT_UI8
, 3840x2176)MF_MT_MINIMUM_DISPLAY_APERTURE
, 00 00 00 00 00 00 00 00 00 0F 00 00 70 08 00 00 (TypeVT_VECTOR
|VT_UI1
)The latter quoted attribute reads as this:
You should take this into account and be ready to accept samples with 3840x2160 payload being carried in 3840x2176 buffers.
Related Q: Handling Image data from IMFSourceReader and IMFSample.
IMO this is still a bug since H.265 demultiplexer is aware that this is encoded video, and padding does not make sense. Decoder would apply this when it sets up textures or buffers with padding, it starts being important only there.
Also, this is a behavior different from H.264 codec AFAIR. And then, again, this side effect AFAIR causes a problem with property sheet handler which displays this wrong resolution for media files.