PDA

View Full Version : IC 2.0 vs. 1.41 - Frame Ready Callback



Kay
October 18, 2004, 21:39:17
I have a VC++ 7.0 application that works with IC 1.41 and DirectX 9b.

I have installed DirectX9.c and IC 2.0. Now, the same application does not run. That is, the "m_pGrabber->Startlive(FALSE) function returns 1, but the "frameReady" callback never gets to run.

The "DemoApp" application that comes with IC 2.0 runs fine.

Is there something in going from 1.41 to 2.0 that I should be doing differently? An answer here will save me the time of having to go through the IC 2.0 samples in detail.

Thanks,

Stefan Geissler
October 19, 2004, 10:51:43
Hello Kay,

The Demoapp does not use the GrabberListener::frameReady() method, therefore you can not compare it to the callback problem. Did you call m_pGrabber->AddListener() and pass a pointer to your GrabberListener derived object to it? If not, GrabberListener::frameReady() will not be called.
Also you must setup a membuffer collection. If you did not setup a membuffer collection, IC Imaging Control has no memory, where to copy the frames in, that are delivered to GrabberListener::frameReady(). Last you should set your framegrabbersink to DShowlib::eGrab. This advises the grabber to call GrabberListener::frameReady() for each incoming frame. DShowlib::eSNAP setting will advise the grabber to call GrabberListener::frameReady() only, if grabber->snapImages() is called.

I suggest to have a look on the callback sample.

Also IC Imaging Control 2.0 runs with .NET 7.1 2003. For .NET 7.0 we are not able to say, whether it is stable.

Kay
October 19, 2004, 15:41:38
Stefan,

Thanks for the reply.

1 - Yes, I'm running Visual Studio .NET 2003 version 7.1

2 - I did compare to the Callback sample. My application is unchanged from when it was running in IC 1.41. and DirectX9.b. Now that it was ported to IC2.0 and DirectX9.c, the frameReady callback does not happen.

3 - I do call 'setVideoFormat', then 'setSinkType', then 'newMemBufferCollection', then 'setActiveMemBufferCollection' and then 'addListerner', in that order, before I call 'startLive'.

The part that is perplexing is why would the same code work with the previous versions of IC and DirectX9 and not with IC2.0 and DirectX9.c.

I will try carrying the build from the XP machine to the Windows 2000 machine. I will install IC2.0 and DirectX9.c in the Windows 2000 machine to see what happens.

If you can think of what I may be doing wrong, please let me know. I appreciate the help.

Kay

Stefan Geissler
October 19, 2004, 16:15:35
Kay,

you may pack your project into a ZIP file and send it to support@imagingcontrol.com. So i can have a look on it.

Kay
October 19, 2004, 16:20:56
Stefan,

Myapplication is huge. What I'll do is strip out the code to the bare essentials. That is, the initialization of the IC module, just enough to get to the callback. I will then zip it to you.

Thanks,

Kay.

Kay
October 19, 2004, 23:03:39
Stefan,

After a long day of debugging, here is some interesting information.

Two programs. One works and the other doesn't.

1 - Working program.

- I select 640 x 480 RGB24 for the capture.
- I allocate 3 frame buffers for use by IC. Each buffer sized as (640 * 480 * 3) = 921600 bytes.
- I call
m_pBuffer = pGrabber->newMemBufferCollection(921600, m_pFrameBuffer, 3)

- The m_pData member of the m_pBuffer is NOT NULL.

2 - Program that does not work ... It does not call the frameReady callback.

- I select 640 x 480 RGB24 for the capture.
- I allocate 3 frame buffers for use by IC. This time, I allocate the size of the buffer to be a multiple of the disk sector size, in this case 4096 bytes. I do this for disk write performance reasons. In this case, the size of the frame buffers comes out to 925696 bytes.

- I call
m_pBuffer = pGrabber->newMemBufferCollection(925696, m_pFrameBuffer, 3)

- The m_pData member of the m_pBuffer is NULL.


Notes:
A - In IC 1.41, the size of the frame buffers did not have to be the same as required by the resolution and color space selected. That is, it did not have to be 640 x 480 X 3. Does this still apply to IC 2.0?

B - I'm using the following call inside a 'for-loop' to allocate each frame buffer.

m_pFrameBuffer[uCounter] =
VirtualAlloc(NULL, 925696,
MEM_COMMIT,
PAGE_READWRITE);


I hope you can figure it out from the above.

Thanks for any help that you can provide.

Kay

Stefan Geissler
October 20, 2004, 09:01:35
Hello Kay,

I suggest to use following code to initilize the grabber:


// start the grabber in single snap mode with a Colorformat corresponding to the videoformat.
grabber->setSinkType( FrameGrabberSink( FrameGrabberSink::tFrameGrabberMode::eGRAB, DShowLib::eRGB24) );
// Set a MemBufferCollection.
Grabber::tMemBufferCollectionPtr m_pBuffer = grabber->newMemBufferCollection( 3 );
grabber->setActiveMemBufferCollection( m_pBuffer );


With this you setup the sinktype for the frames first. Thus you do not need to calculate the size of your memory buffer on your own.
Also you have called "grabber->AddListener"?

Kay
October 20, 2004, 15:16:17
Stefan,

Thanks for the reply.

I don't understand. Are you saying that I can not set a memory frame buffer size that is different from that expected for the color format?

In other words, if I want to capture 640x480 RGB24, then that works out to a frame size of 921600 bytes. But, if I set the frame size to this, the speed of writing the frame to disk is relatively slow. On the other hand, if I make the frame size a mulitple of the disk sector size, the Win32 code that writes to disk writes a lot more bytes per second.

Setting the frame size larger than needed allows me to optimize the code that writes to disk. So the question is, is it possible to have my own custom size for the frame buffers?

Thanks,

Kay

Stefan Geissler
October 20, 2004, 15:30:51
Hello Kay,

This is an issue. You must pass a correct image buffer size to "newMemBufferCollection(size, m_pFrameBuffer, 3)".
But if you allocate the buffers on your own, you can use any size bigger than the size needed by the image. In this case, you would fake the newMemBufferCollection() function. The newMemBufferCollection() will not delete your previously created buffer.
We will fix this problem in the next version (2.1).

Kay
October 20, 2004, 15:40:31
Thanks Stefan,

How soon do you anticipate that you will have the fix in IC 2.1? I'm close to release and pressed for time.

Stefan Geissler
October 20, 2004, 15:42:07
Hello Kay,

I have no release date yet, but i think, with this work around in my last mail, you can aviod this problem.