none
Media Foundation and Windows Explorer reporting incorrect video resolution, 2560x1440 instead of 1920x1080 RRS feed

  • General discussion

  • Reproduce this issue using this video, and view frame size in explorer or use any app based on Media Foundation source reader. VLC, FFMPEG correctly report the file as 1920x1080.

    https://teleport.blob.core.windows.net/content/should_be_1080p.mp4

    The file was produced by an IP camera, may be non-standard, but MF should be able to deal with it given all other software does.

    Also vote here : https://aka.ms/AA4y7a2

    • Edited by _mms_ Sunday, April 28, 2019 1:18 AM
    Sunday, April 28, 2019 1:16 AM

All replies

  • I don't think it's MF problem. The file itself is inconsistent in its data. Resolution information can be derived from several sources (namely they are video track description, parameter sets of sample description box, resolution of effectively decoded first video frame) and it's up to software which one to present as "video file resolution". 

    This file has indeed 2560x1440 in track in its stsd, so it's the file to be fixed. Too early to blame the API.


    http://alax.info/blog/tag/directshow


    Sunday, April 28, 2019 6:50 AM
  • Didn't realize the file was so inconsistent. Which tool do you use to look at the file metadata? Any tool I try I guess must be doing a frame decode as it shows 1080p for this file.

    In the end have to work around this as the IP camera firmware can't be changed in the wild. Only option you think is to try and decode the first frame with MF? I'm using SourceReader other APIs may read other metadata?

    Specifically performance is a concern, don't want to decode the first frame unless there is inconsistent metadata. Possible to deduce this inconsistency from metadata alone?



    • Edited by _mms_ Sunday, April 28, 2019 5:17 PM
    Sunday, April 28, 2019 5:10 PM
  • Any tool that presents data derived from SPS from stsd box/atom would show you 2560 1440. I used code from one of my projects I had at hand.

    A side effect of this is that media type data obtained from MF has SPS different from the one attached (repeated) with first frame.

    With Source Reader API the easiest way is to read first decoded frame and check its properties. You can skip this step if SPS and PPS NAL units of first encoded frame match the ones you see in media type's MF_MT_MPEG_SEQUENCE_HEADER


    http://alax.info/blog/tag/directshow

    Sunday, April 28, 2019 8:08 PM
  • Can the Source Reader API provide SPS and PPS NAL unit information? Or must lower level MF APIs be used? Any info would be most welcome.
    Saturday, May 11, 2019 10:23 PM
  • DirectShow gives 1920 * 1080

    (with IBasicVideo::GetVideoSize)

    Sunday, May 12, 2019 6:09 AM
  • Yes you have them with a native media type reported for the video stream of the file.

    Input Path: should_be_1080p.mp4
    
    Video:
    MF_MT_VIDEO_PROFILE: eAVEncH264VProfile_High
    MF_MT_VIDEO_LEVEL: eAVEncH264VLevel5
    MF_MT_FRAME_SIZE: 2560 x 1440
    MF_MT_INTERLACE_MODE: MFVideoInterlace_MixedInterlaceOrProgressive
    MF_MT_FRAME_RATE: 5000000/333753 (14.981)
    
    Media Type Sequence Header:
    49 bytes: 00 00 01 67 64 00 32 AC 34 CC 02 80 0B 5F F0 16 A0 20 20 28 00 00 1F 68 EE 3C 30 87 43 00 13 F4 00 04 FC E5 DE 5C 68 60 02 7E 80 00 9F 9C BB CB...
    7 bytes: 00 00 01 68 EE 3C 30
    49 byes of SPS and 7 bytes of PPS.


    http://alax.info/blog/tag/directshow



    Sunday, May 12, 2019 6:53 AM