Media Foundation crash under Windows 10 only with some ASF files

Pierre Chatelier 81 Reputation points
2020-09-17T11:22:56.417+00:00

Here is a minimal project that exhibits a bug of MSMF (Microsoft Media Foundation) when decoding some ASF files.
The code just opens an ASF, parse the samples to get the timestamps, then reparse the samples to decode them as RGB.
It runs flawlessly under Windows 7, but crashes under Windows 10.
The crash occurs on the first sourceReader->ReadSample() after reading the timestamps and rewinding the movie position.

I don't know if the ASF file is prefectly valid, it has been generated by some camera software. If I reencode it (with ffmpeg for instance), there is no more bug.
However, a crash is not really acceptable in this case (especially if Windows 7 does accept the file)

TestMFTASF.zip

[edit]
Is there any way to fix or circumvent the bug ? I really need to get random access on the frames of the movie, I won't just read them once from the beginning to the end.
[/edit]

[edit2]
pre-loading the whole movie in memory (parsing it just once) is not a solution, since the one given as example in the minimal project is very short, but I have others with thousands of frames.
[/edit2]

Windows API - Win32
Windows API - Win32
A core set of Windows application programming interfaces (APIs) for desktop and server applications. Previously known as Win32 API.
2,613 questions
0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Rita Han - MSFT 2,161 Reputation points
    2020-09-18T06:02:41.827+00:00

    Hello @Pierre Chatelier ,

    Your code sample generate "Access violation exception in mfreadwrite.dll" on Windows 10 for me at this line:

    25742-20200918-1.png

    Change MF_SOURCE_READER_ENABLE_VIDEO_PROCESSING to MF_SOURCE_READER_ENABLE_ADVANCED_VIDEO_PROCESSING at the following line solve this issue for me. Please have a try. 

    attributes->SetUINT32(MF_SOURCE_READER_ENABLE_VIDEO_PROCESSING, TRUE);

    Update:

    MF_SOURCE_READER_ENABLE_VIDEO_PROCESSING seems not support converting from MFVideoFormat_MP4S to MFVideoFormat_RGB32.

    Since MF_SOURCE_READER_ENABLE_VIDEO_PROCESSING supports limited video processing and these operations are performed in software. So it is suggested to use MF_SOURCE_READER_ENABLE_ADVANCED_VIDEO_PROCESSING for a greater range of format conversions and hardware support.

    Thank you!

    If the answer is helpful, please click "Accept Answer" and upvote it.

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

  2. Anthony Soto 81 Reputation points
    2020-10-22T19:32:46.303+00:00

    Hi @Pierre Chatelier ,

    From looking deeper into this issue, the source ASF appears to have corrupted content which is leading to a header attribute not matching that same attribute in the sample being processed by ReadSample. Ultimately, this issue is caused due to bad content on the ASF file.

    For the source file (wrong2.asf), is there anything about how this file was created that could possibly be related to the content being corrupted? Is it possible that this file is the result of two files being spliced together?

    It appears that re-encoding the file as you had stated resolves any issues with the file and therefore avoids any crashing behavior.
    Beyond that, @Rita Han - MSFT 's solution of using MF_SOURCE_READER_ENABLE_ADVANCED_VIDEO_PROCESSING is confirmed.

    Overall, issues with content should not be causing a crash. With that, we are looking to address this crashing issue and ideally look to fix it in a later version of Windows.

    Thank you very much for bringing this to our attention, and I hope my answer addresses any concerns you had.

    0 comments
  3. Pierre Chatelier 81 Reputation points
    2020-10-22T19:43:53.307+00:00

    Hello,
    I am happy to agree with you :
    -indeed, corrupted content removes any obligation on MSMF to be able to read the movie. It could just fail, it would be acceptable
    -the crash is an undesirable side effect that must be fixed, though, since it reveals weakness in error handling
    -if after your fix the movie can't be read, this will still be the fault of the corrupted content, not MSMF

    About that content :
    -The original movie was created by a camera software on a client machine. I don't know anything else. I doubt it has been edited, I just think the encoder used by the camera/the software is buggy
    -It was very difficult for me to create a small snippet of a few frames that still exhibited the bug, since reencoding would always fix the movie
    -I finally found an ffmpeg operation that was able to crop the movie AND keep the raw original samples, that's how I generated wrong2.asf.

    Thanks for your updates

    0 comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.