简体   繁体   中英

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.

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.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM