locked
Get pointer to the IMFMediaSource from a IMFMediaEngine

    Question

  • I would like to get reference to the IMFMediaSource created by the IMFMediaEngine.

    Currently, I use the MediaExtensionManager::RegisterSchemeHandler to register a custom scheme, then have the IMFMediaEngine load up that scheme to instantiate the IMFMediaSource.  From there, I need to get a pointer to the IMFMediaSource so my application can feed to dynamically created media samples.

    I was hoping for a clean way to do this without using the RegisterSchemeHandler overload that has a IPropertySet overload, or doing nasty tricks by providing params in the scheme url.

    Thanks for any help you can provide!

    -Jer

    Friday, September 14, 2012 12:26 AM

Answers

  • Hi JMorrill...
    Unfortunately, what I have in mind is still a little involved and is based on the RegisterSchemeHandler using the IPropertySet overload. Here is the detail:

    • The app creates a property set, say props, to pass in configuration information when registering the scheme handler - 
               Props.add(“propKey”, onSourceCreated);
      Note: onSourceCreated is a callback function/delegate passed in by the application. This function will be called by the scheme handler implementation after your MF source object has been successfully created. The callback function will receive the reference to source object.
    • The app calls RegisterSchemeHandler on an instance of Windows.Media.MediaExtensionManager object passing in the config info. For example:
               mediaExtensionmgr.registerSchemeHandler(“Scheme handler ACID”, “source URL”, props);
    • Your scheme handler implements WinRT’s IMediaExtension interface to obtain a reference to the callback function via the SetProperties method
    • On successful creation of the source object in IMFSchemeHandler::EndCreateObject, the app supplied callback function (onSourceCreated) is called passing in a reference to MF source object - this could also be a reference to the corresponding WinRT representation for the COM MF source.

    Using this scheme, it’s even possible to handle multiple media elements with the same source URL. Apps can append a key-value expression that includes the unique element ID of the media element to the source URL. For example, vid1.source = scheme://sourceURL&ID=vid1. The WinRT source object returned to the app could then expose a property for this unique ID. Furthermore, this can be nicely wrapped into a declarative control object model (such as the one used in WinJS for JavaScript controls) to simplify the setup for developers.

    Of course the API surface will improve as time goes on.

    • Marked as answer by jmorrill Friday, September 14, 2012 2:34 AM
    Friday, September 14, 2012 1:43 AM

All replies

  • Hi JMorrill...
    Unfortunately, what I have in mind is still a little involved and is based on the RegisterSchemeHandler using the IPropertySet overload. Here is the detail:

    • The app creates a property set, say props, to pass in configuration information when registering the scheme handler - 
               Props.add(“propKey”, onSourceCreated);
      Note: onSourceCreated is a callback function/delegate passed in by the application. This function will be called by the scheme handler implementation after your MF source object has been successfully created. The callback function will receive the reference to source object.
    • The app calls RegisterSchemeHandler on an instance of Windows.Media.MediaExtensionManager object passing in the config info. For example:
               mediaExtensionmgr.registerSchemeHandler(“Scheme handler ACID”, “source URL”, props);
    • Your scheme handler implements WinRT’s IMediaExtension interface to obtain a reference to the callback function via the SetProperties method
    • On successful creation of the source object in IMFSchemeHandler::EndCreateObject, the app supplied callback function (onSourceCreated) is called passing in a reference to MF source object - this could also be a reference to the corresponding WinRT representation for the COM MF source.

    Using this scheme, it’s even possible to handle multiple media elements with the same source URL. Apps can append a key-value expression that includes the unique element ID of the media element to the source URL. For example, vid1.source = scheme://sourceURL&ID=vid1. The WinRT source object returned to the app could then expose a property for this unique ID. Furthermore, this can be nicely wrapped into a declarative control object model (such as the one used in WinJS for JavaScript controls) to simplify the setup for developers.

    Of course the API surface will improve as time goes on.

    • Marked as answer by jmorrill Friday, September 14, 2012 2:34 AM
    Friday, September 14, 2012 1:43 AM
  • Thank you for your detailed response Kenny!

    I think this solution will work out.  I'll probably get started on that now :).

    To further explain my use-case, is I have a custom audio mixer and video mixer.    Media samples from multiple file sources are read, decompressed and passed to the a/v mixers that apply effects, transitions between many inputs, etc.  Currently the output of the mixers is sent to a custom media writer (based on IMSinkWriter) for encoding.  This works great as an "encoding job", but it does little for "previewing" the mixer output, which would require I build all the infrastructure that IMFMediaEngine already supplies.  My idea is to have my "mixer output" plug into a IMFMediaSource to deliver the samples and act like a virtual media source, and lean on IMFMediaEngine to control audio rendering, playback controlling, a/v synchronization, etc.  So it is vital that I can get IMFMediaSource pointer.

    I'm unsure if I'm a common-case, or edge-case here, but would it be considered in the future for a less-friction method to do this?  Like an event - IMFMediaEngineNotify::EventNotify(MF_MEDIA_ENGINE_EVENT_NOTIFY_MEDIASOURCE_CREATED, (void)*mediaSource, nullptr)

    Thanks again for all the help!

    -Jer



    • Edited by jmorrill Friday, September 14, 2012 2:43 AM
    Friday, September 14, 2012 2:34 AM
  • No, having access to a reference to the source is not a corner case scenario. Your input feedback is very useful. Will make sure to pass along to the right channel.

    Thanks.

    -Kenny

    Friday, September 14, 2012 2:56 AM