View Full Version : startLive throws an exception

March 25, 2004, 20:24:25

I have build a test app and can't figure out why the 'startLive' call is throwing an exception. I have gone through your samples to try to figure it out but this has not helped.

Here is an ordered sequence of my calls to your api:


At this point, I construct my CListener object with FrameReady override



At this point, startLive throws an exception. Here is the message displayed:

"Exception DEBUG: in e:\daten\development\icimagingcontrol14\core\tisud shl\grabber.cpp at line 982.

CFilterGraph::startGraph() : failed to start the graph
COM Error Message: Insufficient system resources exist to complete the requested service.

In file: e:\daten\development\icimagingcontrol14\core\dshow lib\filtergraph.cpp at line: 595

Continue? (say "no" to rethrow catched exception or "yes" to continue without doing anything)"

I just started getting familiar with your API a few days ago. I figure it is probably some function called that I have forgotten to make. If you need more information on the parameters for some of the calls, please let me know.

I'm using MS VS 7.1 and your "_vc71" dlls.


Peter Davila

Stefan Geissler
March 26, 2004, 07:15:58

Please send your project as zipped file to support at imagingcontrol dot com, so i can have a look on it.

March 26, 2004, 13:54:03

Thanks for the reply.

Let me ask you.

1 - From the list of API calls that I sent you, I figured may be I'm missing some required call prior to starting the capture. Is everything there?

2 - I'm using your API for capturing to buffers in PC system memory. I then use Direct3D for presenting the frames to the VGA card and my own code to save each frame of video to disk. Will your DirectShow based API work alongside my Direct3D device creation. Any possible conflicts there?



Stefan Geissler
March 29, 2004, 08:16:20

To question 1:
I do not see anything missing, but without the parameters to the functions, it is hard to see what you have done. How big is your Membuffer Collection?
As i mentioned above, a small sample project that reproduces this problem sent as zip to support at imagingcontrol dot com would be a great help for me. This would be handled very confidential.
A small hint: You do not need the size of the video format if you use

m_pMemBuffColl = m_Grabber.newMemBufferCollection( 5 );

to create the MemBuffer Collection. The lines


are not needed to create the MemBuffer collection.

To question 2:
No, there is no problem with Direct 3D. I wrote sample, that displays a live images on a rotating 3D objects. I found no conflicts. Make sure, the textures and Membuffer use the same pixel formats or write a simple conversion.

March 31, 2004, 21:31:24
Thanks for the help Stefan.

Application is up and running. It seems the code was left in some weird state after pausing it with a breakpoint. A restart of the PC fixed it.

February 20, 2018, 16:11:14
Hi all,
Im having a similar problem with a DFK AFU420 camera.
My project consists on a three cameras system. Developing in Visual Studio 2010 and menus made on QT.

When I'm on DEBUG mode (using TIS_UDSHL11d.dll) the same exception as Kay is shown:
Exception DEBUG: in Grabber.cpp at line 863:
Error = Failed to start the graph. Due to: Error nos specified
In file: "FilterGraph.cpp" at line: 263
It appears always on the grabber.startLive(false) line.

Anyway, if I change fromDEBUG mode to RELEASE mode, the system apparetnly works fine.

Could you help me to debug properly my example?

Here is an extract of my example code:

bool initLibrary()
return DShowLib::InitLibrary();

bool get_snap(string camera_unique_name)

// Open camera 1
Grabber grabber1;

// Set sink types:
// FrameHandlerSink containing a 10-buffer MemBufferCollection of RGB24 images.
tFrameHandlerSinkPtr pSink1 = FrameHandlerSink::create(eRGB32, 1);

// Set the grabbers to 'prepared' state.
// Almost all necessary initializations are done then,
// and startLive() will be a fast operation.
if (!grabber1.prepareLive(false))
std::cerr << "grabber1.prepareLive failed: " << grabber1.getLastError() << std::endl;
return false;

// Snap one image from camera 1
bool a = grabber1.startLive(false);
Error el = pSink1->snapImages(1);

// Stop cameras

// Save the snapped images

return true;

Stefan Geissler
February 21, 2018, 09:06:44

please keep in mind, your cameras need *a lot of* memory, so consider either using a smaller video format or select 64bit platform.

February 21, 2018, 14:41:35
Hi Stefan,
changing to 64bit the app is able to snap from three cameras at the same time.

I don't figure out why the Grabber object is still taking lot of memory despite of being suspend...


Stefan Geissler
February 21, 2018, 16:54:00
Because if it is suspend, the filtergraph is still prepared and memory is allocated.

February 21, 2018, 20:44:00
Mmm ok. I understand now...
Thank you for the information and for the prompt reply!

February 23, 2018, 13:06:55
Last question Stefan,
Does the AFU 420 supports being directly programmed using DirectShow from the WindowsSDK?
Any standard protocol like USB3Vision or GeniCam...?

Stefan Geissler
February 26, 2018, 08:35:02

Yes, The driver is 100% DirectShow compatible. But the camera does not support USB3Vision.

February 26, 2018, 12:35:14
Hi Stefan,
I've been working with the camera and the ImagingSource C++
I'm monitoring the used memory and I'm doubting about a few concepts:

- I'm playing with malloc to know when my memory crashes. And the app crashes when consumes more than 800MB. That is caused by the filtergraph, that needs: 160MB per frame (7716x5360 RBG32) * 7.5 FPS -> 1200MB. 1200MB to buffering 7.5 image since startLive is executed.
800MB+1200MB -> 2GB limit.

- Then, I change the FPS to 2 with grabber.setFPS(2) . So in theory, the filtergraph needs less memory. But, the program still crashes and needs the same buffering memmory.
Is it possible that the filtergraph is always saving the maximum framerate?

Moreover, Have you got any DirectShow projects as template o example to do some tests?
Thanks in advance

Stefan Geissler
February 27, 2018, 08:16:10
You do not really know, how much memory is allocated by the filter graph, because if the color space is transformed, the image must be saved with old and new format in memory.
Also the camera driver allocates memory for some images.
The frame rate has no effect on the memory, that is allocated.
It is only the ringbuffersize property of IC Imaging Control, which you can lower to 2.

I am very sorry, but I do not have DirectShow code. That would be Microsoft's job. You could use e.g AMCAP or graphedit.

February 27, 2018, 08:22:17
Ok Stefan. Thanks for the information.

So, how could I set that ringbuffersize to 2?

Stefan Geissler
February 27, 2018, 08:39:01

with FrameHandlerSink::create()