PDA

View Full Version : Error = filter could not be built from CLSID



Duduche
November 17, 2009, 17:55:47
Hello,

I am having a problem when trying to construct a Grabber ( m_pGrabberTop = new DShowLib::Grabber(); ), I get the following error:

Exception DEBUG: in d:\development\ic 3.0\core\tisudshl\grabber.cpp

Error = filter could not be built from CLSID
CLSID="{C1F400A4-3F08-11D3-9F0B-006008039E37}"

In file : "d:\development\ic 3.0\core\dshowlibgeneral\dshowfilter.cpp" at line : 58

From what I have looked around this CLSID corresponds to the NULL renderer. I checked that the CLSID is present in my registry, and the corresponding dll (qedit.dll) right where it should be (C:\Windows\system32).

Note that my code worked fine for some time before. It is also my first explicit call to the library after DShowLib::InitLibrary()...
Also note that video shows up correctly if I launch IC Capture 2.0. (so my devices, two DFG/USB2-lt converter are connected and functional.)

Any idea what could cause this?
Thanks

Stefan Geissler
November 18, 2009, 15:44:43
Hello,

It seems DShowLib::InitLibrary() was not called or it was called from a different thread. If so, then the CoInitialize() is not called in the thread, that holds the grabber object.

Duduche
November 25, 2009, 16:36:59
So basically, I have to call DShowLib::InitLibrary() in each Thread where I use the library to create a Grabber? Or can I pass a specific 'coinitmode' parameter to InitLibrary to avoid calling it again in every created Thread?

It might be a good idea to explain shortly that requirement in the InitLibrary reference page (http://www.imagingcontrol.com/en_US/support/documentation/class/meth_descreffunctions_InitLibrary.htm).

Stefan Geissler
November 25, 2009, 16:52:38
Well, Initlibrary() calls are a good idea.



It might be a good idea to explain shortly that requirement in the InitLibrary reference page (http://www.imagingcontrol.com/en_US/...nitLibrary.htm).

I will think about this when I work on the help files again.

Duduche
February 12, 2010, 10:12:20
I have a related question, if I call DShowLib::InitLibrary() in several threads, do I need to call DShowLib::ExitLibrary() for each additional thread too?

Stefan Geissler
February 12, 2010, 12:26:54
Hello,


I have a related question, if I call DShowLib::InitLibrary() in several threads, do I need to call DShowLib::ExitLibrary() for each additional thread too?

Yes. Exitlibrary() clears memory and avoids memory leaks.

Duduche
February 18, 2010, 13:18:39
Ok, thank you for the answer.

I am running into a strange memory issue though. I'll describe the situation in a few words: I have defined a class that is used to grab from two USB devices simulatenously, and that tries to synchronize input from both devices. This class is instantiated by a dialog-based Windows app.

Previously I was creating the 2 DShowlib::Grabber objects at the app's startup, because the grabbers are used in a different thread and I had the multiple Initlibrary() issue. It was a lazy fix but it was working.

Now I am trying to create the grabbers in my second thread but I have a strange seg fault due to the class member DShowLib::Grabber::m_pP of one of my grabbers pointing in invalid memory area (namely a member char array of my class).

Here is a extract of my class's header and body.

Header:


class Launcher
{

... // some members declaration here

DShowLib::Grabber* m_pGrabberTop;
DShowLib::Grabber* m_pGrabberBottom;

... // some members declaration here

char m_szFilename[ 1024 ];

.. // rest of class definition here
};


Body:


Launcher::Launcher()
{
DShowLib::InitLibrary( CallbackGrabber::ms_szICImagingKey );

m_pGrabberTop = new DShowLib::Grabber();

.. // rest of class definition here
}


Right after the grabber's creation, I can see that the DShowLib::Grabber::m_pP points in the middle of my m_szFilename member. The second grabber seems fine however.

I have a seg fault if calling m_pGrabberTop->getAvailableVideoCaptureDevices(); after I have copied something in m_szFilename using sprintf_s (as in Debug, sprintf_s writes '0xFD' values in all the rest of the char array after the trailing '\0').



strcpy_s( m_szFilename, 1024, szFilename );
DShowLib::Grabber::tVidCapDevListPtr spList = m_pGrabberTop->getAvailableVideoCaptureDevices(); // Crash


I have no issue if I call m_pGrabberTop->getAvailableVideoCaptureDevices(); before copying something in m_szFilename, or if I use sprintf that does not fill the rest of the char array...

To me it looks like for some reason the Grabber member points to an invalid location, do you have any idea what could cause this inside the DShowLib::Grabber constructor? As I don't see any problem in what I am doing...

Duduche
February 23, 2010, 16:24:10
Ok forget it, my problem had nothing to do with IC Imaging library: in short I had a duplicated and outdated file in a directory, causing a discrepancy between header of the class and actual code, resulting in new allocating the wrong size for my object, hence memory problems... unfortunately this happened at the same time that I changed my code to move the Grabber initialization.

Sorry for the false alarm!

Stefan Geissler
February 23, 2010, 17:14:54
Hi,

However, it was an interresting case :-)