GetCurrentBuffer() error in qedit.dll under XP
I have a video frame grabber app that uses buffering, SetBufferSamples(TRUE). I get the frames that I want using GetCurrentBuffer(). It works fine under Windows 2000, but it crashes in qedit.dll with "0xC0000005: Access Violation" under Windows XP. Under Windows 2000 I was using DirectX 8.x and 9.0. Under Windows XP I am using DirectX 9.0c. In both cases Iam using MSVC++ 6.0.
In all the DirectShow example code buffering is set to OFF and the callback method is used to get samples. I would rather avoid using callbacks if possible, since I don't need them for any other purpose. The online documentation for ISampleGrabber does not indicate any OS dependencies. The only possible problem mentioned is a conflict between newer Direct3D header files and I am not using Direct3D in this case.
Any ideas?
If I were to use something other than the whole VFW and graph builder approach is there something that will work better under XP but also be backward compatible with Windows 2000? I need both.
[1041 byte] By [
KenFast] at [2008-1-4]
Ideas, thats what I get paid for, not actual mass*distance.
Check, the results of rendering through the grabber. or spy on the graph with graph edit to confirm it is in line.
Delay grabbing a frame from the problematic hardware while the graph gets itself into order.
The rendering operation works fine. I can render the graph and I see video. I checked in GraphEdit and everything looks fine. I even have separate graphs for live video and AVI stored video. Both work fine for rendering. It is when I try to grab a buffered image that the problem occurs. I call GetCurrentBuffer() the first time with a NULL in order to get the size of the image buffer. That works fine (I am stepping through in the debugger). I added some extra wait time after the initial call. After a 1000ms (1 sec) wait I call GetCurrentBuffer() again with the image buffer pointer. When I try to step into this method in the debugger it immediately errors out and sends me to qedit.dll (in assembly language). The buffer size returned in the first call is correct for this stream. The image structure is allocated to receive the buffered image. It used to work fine in W2K...
Does anybody else actually use this GetCurrentBuffer() call? Should I bite the bullet and go back to using a callback?
The first call to GetCurrentBuffer returns S_OK. The second call - to actually get the buffered sample - does not return at all. It goes into qedit.dll and stops with an access violation error. I am checking the return code on all of my graph setup calls and everything runs smoothly. The rendering works fine, it is just he sample grabbing that is giving me problems under XP. Are there version issues with qedit.dll? I am running DirectX9.0.c. Any problems with MS VC++ 6.0?
After a long tortuous journey I was able to get my application running on an up to date XP installation with the up to date VS2005. I will spare you the sad story. Actually it didn't run, it still broke on GetCurrentBuffer(), but that was OK.
Finally in the debugger I get a useful message saying that GetCurrentBuffer() is returning E_OUTOFMEMORY, meaning that my buffer size is too small for the image. Hmmm? This app used to work fine and the image size had not changed? After playing around with the call arguments I realized that instead of sending two (long *) args I was actually sending an (int *) for the buffer size with a cast to (long *). This used to work in Windows2000 with DirectX 8.x and 9.0. Now, in Windows XP with DirectX 9.0c this was gagging. I am using OpenCV and had allocated an image for the buffer result so I just passed the img->imageSize value. This happens to be an int value, and not a long. By declaring a long and setting the value to ing->imageSize and passing the long* everything is back to working.
Ken
