Skip to main content

Converting audio using MFT was successful on windows 7 but failed on windows 10 RRS feed

  • Question

  • When we implement the conversion of  video with Audio sample rate from 16Khz to 44.1 Khz, there was a problem as follows:

    - On windows 7, the program worked successful.
    - On Windows 10, the program encountered a bug, the output audio is ran faster than the input audio.

    Program details as below:
    #include "stdafx.h"
    #include <windows.h>
    #include <windowsx.h>

    #include <comdef.h>
    #include <stdio.h>
    #include <mfapi.h>
    #include <mfidl.h>
    #include <mfreadwrite.h>
    #include <Mferror.h>
    #include <mfplay.h>
    #pragma comment(lib, "ole32")
    #pragma comment(lib, "mfplat")
    #pragma comment(lib, "mfreadwrite")
    #pragma comment(lib, "mfuuid")

    int main()
    hr = MFStartup(MF_VERSION);

    IMFMediaType *pMediaType;
    IMFMediaType *pMediaTypeOut;
    IMFSourceReader *pSourceReader;
    IMFAttributes *pAttributes;
    IMFSinkWriter *pSinkWriter;
    IMFMediaType *pCurrentMediaType;
    LONGLONG nDruration = 412800000;

    // Load souce file
    hr = MFCreateSourceReaderFromURL(
    pSourceReader->SetStreamSelection(MF_SOURCE_READER_FIRST_AUDIO_STREAM, TRUE);

    // Create a partial media type that specifies uncompressed audio
    IMFMediaType *pPartialType;
    hr = pPartialType->SetGUID(MF_MT_MAJOR_TYPE, MFMediaType_Audio);
    hr = pPartialType->SetGUID(MF_MT_SUBTYPE, MFAudioFormat_PCM);
    hr = pSourceReader->SetCurrentMediaType(MF_SOURCE_READER_FIRST_AUDIO_STREAM
    , nullptr
    , pPartialType);
    hr = pSourceReader->GetCurrentMediaType(MF_SOURCE_READER_FIRST_AUDIO_STREAM, &pPartialType);
    hr = pSourceReader->SetStreamSelection(MF_SOURCE_READER_FIRST_AUDIO_STREAM, TRUE);

    // set media type for output file
    hr = MFCreateMediaType(&pMediaTypeOut);

    // set major type for output file
    hr = pMediaTypeOut->SetGUID(

    // Set subtype for output file
    hr = pMediaTypeOut->SetGUID(

    hr = pMediaTypeOut->SetUINT32(

    // set audio number channal for output file
    hr = pMediaTypeOut->SetUINT32(

    // set audio bit depth for output file
    hr = pMediaTypeOut->SetUINT32(

    hr = pMediaTypeOut->SetUINT32(

    hr = pMediaTypeOut->SetUINT32(

    DWORD nWriterStreamIndex = -1;
    hr = MFCreateSinkWriterFromURL(
    hr = pSinkWriter->AddStream(pMediaTypeOut, &nWriterStreamIndex);
    hr = pSinkWriter->BeginWriting();

    _com_error err(hr);
    LPCTSTR errMsg = err.ErrorMessage();

    LONGLONG SampleDuration;
    //Sets the input format for a stream on the sink writer.
    hr = pSinkWriter->SetInputMediaType(nWriterStreamIndex, pPartialType, NULL);

    for (;;)
    DWORD nStreamIndex, nStreamFlags;
    LONGLONG nTime;
    IMFSample *pSample;

    hr = pSourceReader->ReadSample(
    printf("%d\n", nStreamFlags);
    printf("%d\n", nTime);

    //Update media type, when current media tye changed.
    , nullptr
    , pCurrentMediaType);
    pSourceReader->SetStreamSelection(MF_SOURCE_READER_FIRST_AUDIO_STREAM, TRUE);

    if (nTime >= nDruration)
    // Calculate new timestamp of sample when this sample is written on output file
    if (nTime + SampleDuration >= nDruration)
    SampleDuration = nDruration - nTime;

    if (FAILED(hr)) {
    printf("ReadSample Error...\n");
    return 0;

    //write sample
    if (pSample)
    OutputDebugString(L"Write sample...\n");
    hr = pSinkWriter->WriteSample(
    if (FAILED(hr)) {
    printf("WriteSample Error...\n");
    return 0;

    hr = pSinkWriter->Finalize();
    return 0;

    When debugging, we detected the following points:
    - After running through the IMFSourceReader::ReadSample funtion. On windows 7, the parameter "nStreamFlags" has resulted in 0.On windows 7, the "nStreamFlags" has resulted in "MF_SOURCE_READERF_CURRENTMEDIATYPECHANGED".
    - Bug only appear in the input audio format is AAC, with input  audio format is WMA, PCM ... it is not happen.
    - When input audio format is AAC, this bug only appear in cases with input audio sample rate is less than 32Khz and converting to 44.1kHz sample rate output.

    Q: Can you explain the problem, is there something wrong with the IMFSourceReader::ReadSample funtion?
    Saturday, October 19, 2019 8:44 AM

All replies

  • Would you mind sharing input.mp4 which exhibits the problem?

    Saturday, October 19, 2019 8:01 PM
  • Hi Roman Ryltsov,

    Any input video with audio format is AAC and audio sample rate is 16Khz, when converted into video with audio sample rate with 44.1Khz or 48 khz. It will get an bug in windows 10. Although it still works fine in windows 7. 
    You can refer to the input video at the following link: 

    Thank you!

    Sunday, October 20, 2019 3:17 PM
  • Hi,

    I will contact the relevant personnel for further testing to determine if it is a problem caused by the window version.

    Best regards,


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact

    Tuesday, October 22, 2019 2:50 AM
  • So you are ignoring MF_E_INVALIDMEDIATYPE in your pSinkWriter->SetInputMediaType call. How comes you are trying to set input format after you pSinkWriter->BeginWriting? This apparently needs a fix on your end.

    Tuesday, October 22, 2019 7:45 AM
  • Hi Jeffrey Shao, 

    Its very well when i hear that.
    Hope some news from you soon.

    Thanks and best regards,


    Friday, October 25, 2019 12:29 PM
  • Hi Roman Ryltsov, 

    I got it. However i think the missing of checking MF_E_INVALIDMEDIATYPE did not involve in wrong audio output. Isn' it?
    Especially this source code have been performing perfectly on windows7.

    Friday, October 25, 2019 12:31 PM
  • This error is directly related to the problem you are describing.

    It's a coincidence that you have this code running on Win 7, it does not excuse the problem.

    Friday, October 25, 2019 1:23 PM
  • On windows 7, function SetInputMediaType is returning S_OK.
    Is this a  bug of windows 7?
    Sunday, October 27, 2019 10:18 AM
  • Hi DinhChuyen,

    I am able to reproduce this issue as you described, and currently working with other colleague for this potential issue. Any progress of this issue, I will update here.

    Thanks for reporting for this issue.

    Regards & Fei

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact

    Monday, November 4, 2019 9:56 AM
  • Hi DinhChuyen,

    Thanks for reporting this issue. I was able to reproduce the problem using a known good sample. Because of this I don't believe that the issue is with your code. This appears to be a regression in the Media Foundation AAC encoder / decoder. I will continue to investigate and let you know if I find a workaround. 



    Windows SDK Technologies - Microsoft Developer Services -

    Tuesday, November 5, 2019 2:39 AM
  • Hi Fei Xue, 

    Thank you for your work.

    I wish can receive some news ASAP.

    Monday, November 11, 2019 3:39 AM
  • Hi James,

    Thank you for your work.

    I wish can receive some news ASAP.

    Best regards,


    Monday, November 11, 2019 3:41 AM
  • Hi DinhChuyen,

    This problem appears to be specific to the Source Reader and Sync Writer. I tested with the Transcode APIs and the issue does not occur. Please give the Transcode APIs a try and see it will work for your scenario. 

    Transcode API

    I hope this helps,


    Windows SDK Technologies - Microsoft Developer Services -

    Thursday, November 14, 2019 12:45 AM
  • Thank you for the information.
    I have been applying the APIs you mentioned and hope its OK.
    However i wonder the APIs in used of mine can be fix or improve from your side? It's will be perfect to me because using another APIs now may lead to several risk for my Whole Solution.

    Best Regards,


    Saturday, November 23, 2019 8:23 AM
  • Yes, I will report this issue as a code defect. We will investigate and consider a change for a future version of the OS.


    Windows SDK Technologies - Microsoft Developer Services -

    Monday, November 25, 2019 8:01 PM