View Full Version : timeout problem using snapImages
April 24, 2008, 19:19:49
I own a commercial license together with a DFK 21AU04 camera, both recently bought from your company. Currently I run into following problem, here's my code snippet:
pSink = FrameHandlerSink::create( eRGB24, 1 );
pSink->setSnapMode( true );
pGrabber->setSinkType( pSink );
// the Sleep() does not help either....
// ::Sleep(250); // give device some time to setup...
// up to here everthing is alright, no errors so far
// now setup a timer to snap an image:
SetTimer(nID, 100, NULL);
// inside timer function:
pSink->snapImages( 1, 100 );
// the debugger output window notes:
// c:\csource\ic30\core\dshowlib\filtergraph.cpp(301) : Graph returned S_FALSE, so not yet started ...
// and I get an timeout error on snapImages()
Any idea what the issue could be?
My system is: Vista Ultimate, 4GB RAM, 2 x XEON 5130 (4 cores total)
Thanks for your help and best regards,
April 25, 2008, 11:35:04
I can not see an error, but in all IC versions before 3.0.6 was a timer error, thus the return value of snapImages was wrong.
Now you have to possibilities:
1.) Simply check with m_pSink->getLastAcqMemBuffer()->save( "test.bmp" ) whether the image is correct
2.) Send a request for a free update to IC 3.0.6 to email@example.com.
April 25, 2008, 12:02:33
Thanks for your reply.
1) the saved bitmap does not look like the one I'm getting with your DempApp, for instance. It's just a gray image.
2) I already installed the trial version 188.8.131.52 from your Website and set it up using my license number. Makes no difference.
Also: your debug message "c:\csource\ic30\core\dshowlib\filtergraph.cpp(301) : Graph returned S_FALSE, so not yet started ..." still comes up...
April 25, 2008, 12:09:27
I will test this on my own today and let you know the results.
April 25, 2008, 15:19:46
I created a similar project, at it works fine on my computer:
m_pSink = FrameHandlerSink::create(DShowLib::eRGB24,3);
m_pSink->setSnapMode( true );
m_cGrabber.setSinkType( m_pSink );
// The device is already setup.
SetTimer(1, 100,NULL );
void CPrepareLiveDlg::OnTimer(UINT_PTR nIDEvent)
if( m_pSink->snapImages(1,100) )
// Display the grabbed image
DShowLib::Grabber::tMemBufferPtr pBuffer = m_pSink->getLastAcqMemBuffer();
CDC *pDC = m_cStaticVideoWindow.GetDC();
smart_ptr<BITMAPINFOHEADER> pInf = pBuffer->getBitmapInfoHeader();
void* pBuf = pBuffer->getPtr();
int nLines = SetDIBitsToDevice(
pDC->GetSafeHdc(), // Handle to the device
pInf->biWidth, // Source rectangle width
pInf->biHeight, // Source rectangle height
0, // X-coordinate of lower-left corner of the source rect
0, // Y-coordinate of lower-left corner of the source rect
0, // First scan line in array
pInf->biHeight, // Number of scan lines
pBuffer->getPtr(), // Modified address of array with DIB bits
reinterpret_cast<LPBITMAPINFO>( &*pInf ), // Address of structure with bitmap info
DIB_RGB_COLORS // RGB or palette indices
m_cStaticVideoWindow.ReleaseDC( pDC );
The first image I see is the gray image you describe. I would like to test a longer time intervall in your timer.
On my 1.4 GHz single core AMD computer this works fine.
Also may be it is a good idea to kill the timer in your timer event and set it up after you have finished.
April 25, 2008, 16:10:17
I followed your suggestions and it does not make any difference at all. I used a longer timer period (500 ms), killed and restarted the time, no change. All I get is the gray image and the debug message I mentioned a couple of times. Please advise what to do, because I hang in a commercial project with this issue.
April 25, 2008, 16:31:41
It seems to be fixed. The problem is the code sequence
When I move the startLive() out of the loop and comment the suspendLive() call, it works:
However, and here comes the big but: this is not what your documenation says about startLive()/snapImages()/suspendLive() and I guess it's not what you were thinking of when you came up with this sequence, right? To me it sounds like a thread problem on fast machines...
April 25, 2008, 16:56:04
This is strange, but I agree with you, this could be an issue of fast computers. Unfortunately we can not test this, because we have no such fast computers right now.
As I wrote above, your code runs fine on my machine....
April 25, 2008, 17:26:06
Well, perhaps the community should spend some $$ so you guys can afford a faster PC from M*t....? ;) (for the US folks, that's a store here in Germany like BestBuy in the US...)
I'm going to check my code snippets on a slow poke Celeron and let you know next week, even though I hope you keep an eye on this issue.
Thanks for your help and best regards,
April 28, 2008, 09:35:00
Ich bin ganz zufrieden mit dem 1.9 GHz Dual Core Testcomputer und meinem 1.4 GHz AMD Arbeitsrechner. Allerdings werde ich mir mal die Programmierer vornehmen, die schnellere PCs als ich haben.
Den Hinweis auf den Elektronikmarkt mußte ich leider etwas entschärfen...
I am satisfied with my 1.9 GHz Dual Core test computer and my 1.4 GHz AMD work station. But I will have a word with my programmers, who have faster computers than me. :-)
Powered by vBulletin® Version 4.2.2 Copyright © 2014 vBulletin Solutions, Inc. All rights reserved.