Michael Chourdakis
Michael Chourdakis

Reputation: 11158

Media Foundation wrong video size

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.

Upvotes: 1

Views: 362

Answers (1)

Roman Ryltsov
Roman Ryltsov

Reputation: 69662

So you have this media type for the video track:

  • MF_MT_FRAME_SIZE, 16492674418816 (Type VT_UI8, 3840x2176)
  • MF_MT_MINIMUM_DISPLAY_APERTURE, 00 00 00 00 00 00 00 00 00 0F 00 00 70 08 00 00 (Type VT_VECTOR | VT_UI1)

The latter quoted attribute reads as this:

{OffsetX={fract=0 value=0 } OffsetY={fract=0 value=0 } Area={cx=3840 cy=2160 } }
  {fract=0 value=0 }
  {fract=0 value=0 }
  {cx=3840 cy=2160 }

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.

Upvotes: 4

Related Questions