How do I avoid being asked to provide a IMFTrustedInput interface in my ByteStreamHandler? RRS feed

  • Question

  • Hi,

    I'm trying to read in a file from a URL and extract video and audio streams from it. My problem is, when I do this, my ByteStreamHandler's QueryInterface function is called with an riid of IID_IMFTrustedInput. If it doesn't get one, it shuts the BSH down.

    Why does it ask me for this, and is there anything I can do to get around it ... or do I have to provide this interface and all the gubbins that is supposed to go with it, which looks like (yet another) can of worms? If I *do* have to provide this interface, can you give me any advice on what I will have to do, because the documentation is a bit vague.

    Although I'm really hoping there's something I can do to stop it asking me for this - some property or capability or manifest doohickey I can set somewhere ... ?

    What makes it quite difficult to see why this is happening is the fact that I don't have any source code for the code that's calling mine. If that's available anywhere, that would be very handy.

    Thank you for any advice.

    Wednesday, December 4, 2013 4:05 AM

All replies

  • Hello,

    If content is flagged in any way as protected you will need to implement the appropriate ITA for the content protection scheme that is being implemented. If the content is protected with PlayReady you may be able to request the built in ITA for PlayReady. However your MFT will need to be trusted by MFPMP. In order for your MFT to get full trust you must go through the licensing and signing process for MFPMP.

    I hope this helps,


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

    Wednesday, December 4, 2013 10:42 PM
  • Thanks. How would I know if my content is flagged as protected?
    Wednesday, December 4, 2013 10:50 PM
  • Hello,

    You need to query for "MF_SD_PROTECTED".

    MF_SD_PROTECTED attribute


    IMFMediaEngineEx::GetStreamAttribute method


    I hope this helps,


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

    Thursday, December 5, 2013 1:09 AM
  • Thank you!

    Thursday, December 5, 2013 1:22 AM
  • To clarify, is this an attribute of the output stream that I'm creating, rather than the byte stream that's coming in originally?

    Thursday, December 5, 2013 3:25 AM
  • This should be associated with the input stream.


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

    Friday, December 6, 2013 1:49 AM
  • Thanks, that would seem to make sense. In an effort to narrow down the problem I've removed the URL from the equation. I've found that even if I don't read the input file from a URL, but read it from disc, I'm still asked for the trusted input interface. The simplest arrangement I've come up with is to read a file like this:

            WinJS.Utilities.query("#byteStreamHandlerVideo")[0].src = "video/File.ts";

    register a ByteStreamHandler:

            this.extensions.registerByteStreamHandler("SmW8MediaPlayer.HLSByteStreamHandler", ".ts", "application/x-mpegURL");

    (I'm not sure what the MIME type should be, or if that matters)

    and then have a ByteStreamHandler which returns the input stream unchanged, with the output stream type set to

    spOutputType->SetGUID(MF_MT_MAJOR_TYPE, MFMediaType_Stream);
    spOutputType->SetGUID(MF_MT_SUBTYPE, MFStreamFormat_MPEG2Transport);

    So the input stream is created by the javascript engine, and the output stream is a type that I know can be displayed if played directly in javascript (if I don't register a byte stream handler).

    So I don't see why it would need me to provide the trusted input interface. But it does, even in this case!

    Friday, December 6, 2013 2:06 AM