Standard Windows API for camera frame acquisition?

For .Net, take a look at this:

are likely to find other methods for other languages at the above site and codeguru.com I did a google on "directx video capture" (no quotes) and found zillions of references. If you are using VB6, there should be a control (Project, References) that will do this for you.

- Tim

Directx->DirectShow. Docs at msdn. DirectShow is supported by almost all video hardware that expects to be run under windows.

Do a google for capcreatecapturewindow avicap32.dll, this will show you a load of info about what I used.

This is actually the old VFW API -- you might want to avoid this one as it has been deprecated for some time now (and will, I assume, disappear in the near future). DirectShow has better support, and is a good deal more flexible.

Cheers -- m

The DirectShow thing for a lot of people is extreme overkill for just some simple frame grabbing. Using this method may be old but you can have it working very very simply and quickly.

The issue isn't so much that it's old, but that there may no longer be support in future MS OSes.

VFW is a bit simpler than directshow for simple frame capture, but only marginally (don't use the amcap source code as your guide -- that really

*is* overkill for what we're talking about).

Yeah but how often are you going to upgrade your robot's OS? You'd be insane to use anything other than vanilla windows 2000 install at the moment, and Longhorn is still about 3 years away apparently. Even if you keep windows 2000 forever, that functionality is ALWAYS going to remain on your existing install - it wont just stop working one day 2 years down the line.

For me to get the avicap code working took about 10-15 lines of code (excluding structures etc which were just copy pastes anyway), and I ended up with a nice byte array of the pixel data to play with. From what I've seen of the directX method, you have to spend a LOT of time pissing around with all sorts of dirctshow crap before you even start to get close to getting data. I want to spend less time jumping through hoops, and more time actually working on the software

You're assuming that the code that does the capture lives on the robot. In my case, it almost NEVER does. I don't think this was a given with the OP, either. Even where I've done the capture on the robot I used VFL under Linux for reasons of resource usage alone.

We're also not just talking possible OS issues -- there's also device vendor support to consider. VFW is often just barely supported with newer hardware. In particular I've run across vendor-supplied config dialogs are either partially broken or substantially less functional than the counterparts available under DirectX (this was actually one of the reasons I moved away from VFW).

In my case, I enclosed both APIs with a standard class that simply produces frames without distinguishing video sources (could be a capture source, could be an AVI file) and provides a number of other tweaks. It took me about the same amount of time to bring both up to the same level of functionality (but I'm doing a little more with the APIs than just capturing frames).

Basic capture under directshow really isn't that hard. The main problem with it was the documentation, and the fairly lame paradigm that the API is based on.

I have nothing against VFW, but the OP DOES need to be aware that it has been deprecated. If you're just experimenting and your hardware supports it well enough, then you're fine. But if you were, say, developing a commercial product, or any piece of software that you'd expect to have a decent lifetime, I personally would avoid basing it on any deprecated API.

In any case, this discussion is probably moot. I think the OP is looking for a Python solution, so he'll be using whatever the Python capture library is based on.

Cheers -- m

Hello again,

I am not necessarily looking for a Python solution, although I like the language. I also like Pascal (Borland Delphi) and Java (Borland JBuilder) too.

I've done VFW stuff in the past so I do have sample code. However, there's a good chance that I would want to distribute the solution to other people, so more modern support for a DirectShow API driven app might be the way to go. I must admit, I am nervous about using DirectShow because I have heard negative stories similar to Matt's about the complexities of DirectShow. I would be keen on finding a plug-in library for Pascal or Java. I really like Python, but for creating apps to be used by others, I still haven't seen anything nearly as easy to use for creating GUI interfaces as the Borland products; not even the latest versions of tools like BOA.

Thanks,