Question

I'm having a weird problem while developing my DirectShow application. I am using Delphi 6 with the DSPACK DirectShow component library. One of the IBaseFilter instances doesn't seem to recognize a pin that it owns when I try to find the pin in the filter using it's TPinInfo.achName property (_PinInfo). (Note, in this case it is the IBaseFilter created by the TSampleGrabber component that is exhibiting this weird behavior).

The sequence of events, encapsulated in the code sample below is this:

  1. Find the first available input pin in the IBaseFilter instance. In the code below this is the pin passed to testPinInfo().
  2. Execute QueryPinInfo() on the returned pin to get that information. The returned information shows the pin's achName as 'Input'.
  3. Try to find a pin named 'Input' in the very same IBaseFilter instance using IBaseFilter.findPin().
  4. Get NIL back indicating a pin could not be found with that name. This in my opinion is a really strange condition (error).

Does anyone know what kind of conditions could cause this scenario? I don't think it's a memory corruption problem because the data structures involved look fine when I inspect them in the debugger. Is it possible that some IBaseFilter implementations neglect to implement the FindPin() method properly?

Here's the code below:

procedure testPinInfo(intfInputPin: IPin);
var
    intfTestPin: IPin;
    pinInfo_input: TPinInfo;
begin
    intfTestPin := nil;

    // Get the pin information.
    ZeroMemory(@pinInfo_input, SizeOf(pinInfo_input));
    intfInputPin.QueryPinInfo(pinInfo_input);

    // Now immediately turn around and try to find the pin in the filter that
    //  owns it, using the name found in pinInfo_input
    pinInfo_input.pFilter.FindPin(pinInfo_input.achName, intfTestPin);

   // >>> intfTestPin is NIL (unassigned).  This is an error.
end;
Was it helpful?

Solution

Don't use FindPin, you always have better ways to do it. Look for unconnected pin of desired direction with the media type of interest. If you look for preview/capture pins specifically, you always have an option to use IKsPropertySet interface to unambiguously identify the pins you need.

OTHER TIPS

I had a similar issue to this so I made my own version of FindPin :-

HRESULT GraphControl::FindPinByName(IBaseFilter* pFilter,LPCWSTR pName,IPin** ppPin)
{
    HRESULT hr = E_FAIL;
    IEnumPins* pEnum = NULL;
    IPin* pPin = NULL;
    DWORD pFetched = 0;
    PIN_INFO pinInfo = {0};

    // Create a pin enumerator
    if(FAILED(pFilter->EnumPins(&pEnum)))
        return E_FAIL;


    // Get the first instance
    hr = pEnum->Next(1,&pPin,&pFetched);

    while( hr == S_OK )
    { 
    pPin->QueryPinInfo(&pinInfo);
    // Compare the names
    if (wcscmp(pName,pinInfo.achName) == 0 )
    {
        // pin names match so use this one and exit
        *ppPin = pPin;
        break;
    }
    SAFE_RELEASE(pinInfo.pFilter);
    SAFE_RELEASE(pPin);

    hr = pEnum->Next(1,&pPin,&pFetched);
    }

    SAFE_RELEASE(pinInfo.pFilter);
    SAFE_RELEASE(pEnum);

    // if the pPin address is null we didnt find a pin with the wanted name
    if(&*pPin == NULL)
        hr = VFW_E_NOT_FOUND;

    return hr;
}

For FindPin you need the corresponding Id, check QueryId(). For Input it's usually "In".

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top