none
Is GMFBridge tool able to handle encoded media?

    Question

  • Hello,

    I have encountered a problem while trying to build a source graph containing GMFBridge Sinks. See the graphic below, please.

    I get the error message "No combination of intermediate filters could be found to make the connection"(VFW_E_CANNOT_CONNECT HRESULT)0x80040217L)), if I try to render stream between InfiniteTee filter and the BridgeSink. No matter, if there is a TransForm Filter inbetween or not.

    I use ffdshow->XVID as the coder and want to encode the video data from the source only once and then copy it to the different AVI files via GMFBridge. Furthermore, I would like to grab each sample within the SampleGrabber and process them in another way.

    I guess the reason for the failed connection is that the BridgeSink does not support all Media Subtypes? Is it right? 

    Could you give me a hint, how to achieve my goal? Thank you.

    best regards,

    Vitali

    Graph_image


    Friday, March 30, 2012 9:20 AM

Answers

  • Hello,

    I told in my last post that I did not have to modify the GMFBridge source code in order to be able to switch the media type. It is not true, indeed. If I work for the first time with my app, then it was sufficient as I told above. However, if the source and render graphs were bridged once, then I could not switch the media type anymore. Even, if I removed the render graphs with its BridgeSources. I discovered the reason is the fact that the stream is declared as "fixedType" during the bridging the graphs. I modified the source code, exactly only one line, and now I can switch the media type, even in "discard" mode.

    The location to modify is in "Bridge.h" header file, within the function "void TypeFixed()"

    void TypeFixed()
    {
            // get the input pin's current type
            m_pInputPin->CurrentType(&m_mt);
            //m_bTypeFixed = true;
    	m_bTypeFixed = false;
    }

    I let the media type to be not fixed. It does the work!

    As long as Geraint Davies does not offer another/ better solution, then it can be used as a workaround for me.

    best regards,

    Vitali


    • Edited by vanselm Tuesday, April 10, 2012 9:04 AM typo
    • Marked as answer by vanselm Thursday, May 03, 2012 1:13 PM
    Tuesday, April 10, 2012 9:03 AM

All replies

  • First, check what parameter you pass to AddStream. If you choose anything other than eAny, then there will be restrictions on what types it will accept. This is to help with automatic graph building. If you are building the graph fully manually, then you can use eAny and place the filters yourself.

    Then you will want to set breakpoints in BridgeSinkInput::CheckMediaType and BridgeStream::CanReceiveType.

    G

    Friday, March 30, 2012 2:38 PM
  • I use the automatic graph building by using the RenderStream() function... 

    I create a stream for video and discard mode because I want the source graph continue to run, although the bridge is not connected yet.

    // init to video-only, in discard mode (ie when source graph
    // is running but not connected, buffers are discarded at the bridge)
    
    hr = pBridgeController->AddStream(true, eMuxInputs, true);

    I also tried to set "eAny", but nothing changed.


    I have put breakpoints in BridgeSinkInput::CheckMediaType(), which returns S_OK, but the BridgeStream::CanReceiveType() returns "VFW_E_TYPE_NOT_CONNECTED" because I set the discard mode.

    if (DiscardMode())
    {
        hr = VFW_E_TYPE_NOT_ACCEPTED;
    } 

    Again the question how to solve this issue? Thank you.

    best regards,

    Vitali

    Friday, March 30, 2012 3:03 PM
  • Ah right. The problem is that the bridge is already connected with a different media type. To make this connection, you'd have to perform a dynamic media type to switch, and that's only possible if we are in discard mode, since only in discard mode do we own the allocator that we need to attach dynamic type changes to the samples returned from GetBuffer.

    The simplest fix is to ensure that you always use the same media type. If that's not possible, and you can't use discard mode, then it might be possible to rework the code a little. It's logically possible to support dynamic type changes in discard mode, but the code currently doesn't support it.

    G


    Friday, March 30, 2012 3:35 PM
  •  To make this connection, you'd have to perform a dynamic media type to switch, and that's only possible if we are in discard mode, since only in discard mode do we own the allocator that we need to attach dynamic type changes to the samples returned from GetBuffer.

    Hello,

    I guess, you mixed up the "discard" and "suspend" modes. Beacause, I use already the discard mode and I'm not able to switch the media type dynamically. Ok, I will try to modify your source code of the GMFBridge, to support the dynamic changes in discard mode. What can you estimate, is it much code to change for it? Or do I have to remove the if conditions for the discard mode only? I would appreciate it much, if you could give me the right direction, where to modify the code, in which class, for example. Thank you.

    best regards,

    Vitali

    Sunday, April 01, 2012 8:14 PM
  • Hello,

    the reason for the problem I have encountered is that I had already created the render graphs for each BridgeController. Therefore, I could not change the media type afterwards. If I create only the source graph with all the BridgeSinks and Controllers, then I'm still able to change the media types, as long as I don't have created the render graphs and its BridgeSources. In my scenario it is sufficient. This means, I did not have to modify the GMFBridge's source code. I had to implement a simple Transform Filter for offering its own buffer for each output pin of the InfTee filter only.

    best regards,

    Vitali

    Wednesday, April 04, 2012 8:25 AM
  • Hello,

    I told in my last post that I did not have to modify the GMFBridge source code in order to be able to switch the media type. It is not true, indeed. If I work for the first time with my app, then it was sufficient as I told above. However, if the source and render graphs were bridged once, then I could not switch the media type anymore. Even, if I removed the render graphs with its BridgeSources. I discovered the reason is the fact that the stream is declared as "fixedType" during the bridging the graphs. I modified the source code, exactly only one line, and now I can switch the media type, even in "discard" mode.

    The location to modify is in "Bridge.h" header file, within the function "void TypeFixed()"

    void TypeFixed()
    {
            // get the input pin's current type
            m_pInputPin->CurrentType(&m_mt);
            //m_bTypeFixed = true;
    	m_bTypeFixed = false;
    }

    I let the media type to be not fixed. It does the work!

    As long as Geraint Davies does not offer another/ better solution, then it can be used as a workaround for me.

    best regards,

    Vitali


    • Edited by vanselm Tuesday, April 10, 2012 9:04 AM typo
    • Marked as answer by vanselm Thursday, May 03, 2012 1:13 PM
    Tuesday, April 10, 2012 9:03 AM
  • Hello there;
    M_bTypeFixed = false;
    You can share the dll file you compiled as. 32bit if possible

    I have the same problem but I do not get 720p source but 1080p source in other resolution.
    Tuesday, November 29, 2016 1:37 PM