简体   繁体   English

媒体基础错误的视频大小

[英]Media Foundation wrong video size

Sometimes the source reader returns incorrect video size.有时源阅读器会返回不正确的视频大小。 It happens with some H265 video files.某些 H265 视频文件会发生这种情况。

This is the reference video: https://drive.google.com/file/d/12oH9x7MCW7YFZu1MDKGbOnIt4VvxrgtZ/view?usp=share_link 3840x2160 pixels这是参考视频: https: //drive.google.com/file/d/12oH9x7MCW7YFZu1MDKGbOnIt4VvxrgtZ/view?usp=share_link 3840x2160 像素

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.这将返回 3840x2176。 Why?为什么?

I will follow up with more problems because this format fails to be converted to another H264/H265 video with Media Foundation.我会跟进更多问题,因为这种格式无法使用 Media Foundation 转换为另一种 H264/H265 视频。

So you have this media type for the video track:所以你有视频轨道的这种媒体类型:

  • MF_MT_FRAME_SIZE , 16492674418816 (Type VT_UI8 , 3840x2176) MF_MT_FRAME_SIZE ,16492674418816(类型VT_UI8
  • 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 ) MF_MT_MINIMUM_DISPLAY_APERTURE ,00 00 00 00 00 00 00 00 00 0F 00 00 70 08 00 00(类型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.您应该考虑到这一点,并准备好接受在 3840x2176 缓冲区中携带 3840x2160 负载的样本。

Related Q: Handling Image data from IMFSourceReader and IMFSample .相关问题: 处理来自 IMFSourceReader 和 IMFSample 的图像数据

IMO this is still a bug since H.265 demultiplexer is aware that this is encoded video, and padding does not make sense. IMO 这仍然是一个错误,因为 H.265 多路分解器知道这是编码视频,并且填充没有意义。 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.此外,这是与 H.264 编解码器 AFAIR 不同的行为。 And then, again, this side effect AFAIR causes a problem with property sheet handler which displays this wrong resolution for media files.然后,这种副作用 AFAIR 再次导致属性表处理程序出现问题,该处理程序显示媒体文件的错误分辨率。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

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