locked
Debug Media Foundation

    Question

  • Hey,

    I'm currently trying to write a ByteStreamHandler and an audio decoder to add support for an unsupported codec.
    I followed the MPEG1 sample and adjusted it for my needs.
    However I'm not sure if it is loaded correctly since I always get the error MF_MEDIA_ENGINE_ERR_SRC_NOT_SUPPORTED with the HRESULT E_FAIL.
    I've added values to all E_FAIL results I use in my code to figure out where it happens unfortunately it doesnt seem to happen in my code.
    Now I'd like to know if there's any way to find out if the dll containing the ActivatableClasses was loaded correctly and how I could debug the code in the dll.

    More Info:
    I added the dll to the project by adding this to my package.appxmanifest

    <Extensions>
        <Extension Category="windows.activatableClass.inProcessServer">
            <InProcessServer>
                <Path>MyDecoder.Windows.dll</Path>
                <ActivatableClass ActivatableClassId="MyDecoder.MyDecoder" ThreadingModel="both"/>
            </InProcessServer>
        </Extension>
        <Extension Category="windows.activatableClass.inProcessServer">
            <InProcessServer>
                <Path>MyDecoder.Windows.dll</Path>
                <ActivatableClass ActivatableClassId="MyDecoder.MyByteStreamHandler" ThreadingModel="both"/>
            </InProcessServer>
        </Extension>
    </Extensions>

    I created the MediaExtensionManager in the MainPage as private class variable

    MediaExtensionManager mediaExtensionManager = new MediaExtensionManager();

    I registered the handler and the decoder in the OnNavigatedTo

    protected override void OnNavigatedTo(NavigationEventArgs e)
    {
        base.OnNavigatedTo(e);
    
        mediaExtensionManager.RegisterByteStreamHandler("MyDecoder.MyByteStreamHandler", FILE_TYPE, MIME_TYPE);
        mediaExtensionManager.RegisterAudioDecoder("MyDecoder.MyDecoder", MF_SUBTYPE, Guid.Empty);
        mediaElement.MediaFailed += mediaElement_MediaFailed;
     }

    The ByteStreamHandler and the Decoder are in one project.

    Tuesday, January 06, 2015 10:21 PM

All replies

  • Hello,

    Make sure your MFT project is included with the test app project in the same solution. You then need to enable mixed mode debugging to allow you to debug both managed and unmanaged code. You can then set breakpoints in the MediaType negotiation code in your MFT to see how you MFT is being considered for the topology. If your functions never get called then you have a registration problem.

    I hope this helps,

    James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Wednesday, January 07, 2015 9:13 PM
    Moderator
  • Hey,

    thanks for your answer.

    I followed your steps but since the dll code said that it wouldnt break because no symbols were loaded, I googled and found out about Debug > Windows > Modules.
    However I couldn't find the dll in the list of Modules.
    Does that mean it's not loaded correctly?
    Where does the dll have to be in order to get loaded correctly?
    I set the dll build directory to the main folder of the windows store test application and let it copy the dll to the output folder.

    Edit: Also added the windows version of the decoder and bytestreamhandler project to the references still not showing up as a module.
    Wednesday, January 07, 2015 11:12 PM
  • Found out that it's probably normal that it doesn't show up since in the sample the dlls don't show up either.

    Still don't know how to fix the missing symbols.

    Thursday, January 08, 2015 4:59 PM
  • Hello,

    To get the symbol information to match up you must have the .pdb file in the same directory as the .dll. The .pdb must have the same MD5 as the .dll or the symbols will not match up.

    I hope this helps,

    James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Thursday, January 08, 2015 7:32 PM
    Moderator
  • Hey,

    Unfortunately it doesn't. I had all the projects compile into the same directory. Meaning the dll and the pdbs were in the same directoy as the exe.
    Still it didn't work. Dunno about the MD5 part but since the pdb was generated by the build process just like the dll I'd assume that they match.
    I changed it now that they build into different directories and added the Source and Decoder (which I separated now) as References to the test app.

    Still not working :/

    Thursday, January 08, 2015 7:50 PM
  • Hello,

    Did you enable mixed mode debugging for the start-up project?

    I-James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Monday, January 12, 2015 10:22 PM
    Moderator
  • Hey,

    of course I did enable mixed mode debugging. That was the first thing you told me to do.
    Sorry for the late answer, was pretty busy last week :/

    Tuesday, January 20, 2015 1:15 AM
  • Hello,

    I guess without seeing your project I'm not sure that I can provide any additional assistance. If you can create a VS project that represents a small subset of your app that directly reproduces the problem, upload it to your OneDrive account and post a link here I can take a look and let you know what I find.

    -James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Thursday, January 29, 2015 9:33 PM
    Moderator
  • You will not hit a breakpoint until you actually start to use the decoder as part of a media element source.

    Your construction will be hit when the media elements source is set.  Using something like the following code:

            <MediaElement x:Name="mediaElement"
                          Width="320"
                          Height="240"
                          HorizontalAlignment="Center"
                          VerticalAlignment="Top"
                          AreTransportControlsEnabled="True"
                          AutoPlay="False" />

    And to set the source:

            private async void OnSetFile(object sender, RoutedEventArgs e)
            {
                mediaElement.RemoveAllEffects();
                mediaElement.AddAudioEffect("SimpleAudioEffect.EchoEffect", false, null);

                var audioFiles = await KnownFolders.MusicLibrary.GetFilesAsync();

                var audioFile = audioFiles.FirstOrDefault();

                if (audioFile != null)
                {
                    var fileStream = await audioFile.OpenReadAsync();
                    mediaElement.SetSource(fileStream, fileStream.ContentType);
                }
                else
                {
                    await new MessageDialog("No audio files where found. Use the emulator to mount a directory with audio files", "Error").ShowAsync();
                }
            }

    The above code will use the first audio file found in your music folder.  Once the source is set, at a minimum, your constructors breakpoint should be hit.

    Wednesday, February 25, 2015 3:58 AM
  • Sorry for the late reply, was rather busy the past month.
    Anyway of course I've set a test file as source. Wouldn't have gotten an exception if I didn't, would I?
    And VS itself says the breakpoints will not be hit so I'm pretty sure that they will not be hit.
    Friday, March 13, 2015 2:50 PM
  • Hello,

    You said that you added the dll to the project by adding it to you package.appxmanifest. If you are simply referencing the MFT DLL and do not have the code as part of your solution file you will need to make sure that the PDB generated when you compiled the DLL can be located by VS. Usuarlly you should have the PDB in the same folder as the DLL. When the app starts you will see the symbols being loaded in the output window. Check to make sure that the symbols are properly loaded for your DLL by looking for it in the output window once the DLL has been referenced in your app.

    I hope this helps,

    James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Friday, March 13, 2015 8:04 PM
    Moderator