I'm writing a program that is supposed to work with a variety of webcams via DirectShow.
To test with many different devices, I'm looking for (software) devices that provide test images in different resolutions and color formats.
I already found MayCam, but would like to have many more test devices, espcially some that support color formats other than BGR24 (for example YUV2).
There is no standard test device, you might possibly find a third party virtual video source capable of delivering video in multiple formats, however the reliably working but time consuming path is to take PushSource sample from Windows SDK and update it appropriately to convert it into a test source device.
Related
DirectShow supports many kinds of video input devices provided appropriate capture filters are available in a system. Is there a way in DirectShow to detect a type of a video input device? Say, I'm enumerating over video input devices and want to take cameras only...
If there is no such API in DirectShow specifically, can you suggest other ways for finding camera devices?
Parsing moniker display name you can get some leads, specifically you can typically sort out virtual cameras, which are not implemented via kernel mode driver (with a real hardware device on the back end you can get VID/PID identifiers to check, for instance, against your internal database of known devices). There is little you can do further, there is no other information attached there.
You will want to read David Miller's posts on this thread: How to identify a video device correctly?.
I've been experimenting with two cameras, one is a webcam and another is an evaluation-kit camera that comes with its own drivers, I can run AMCAP.exe (provided from Vimicro) and it will display live streaming from the connected camera (any of the two) although each one uses a different driver.
My question is: Is it safe to assume that AMCAP.exe is only running as a video-stream display program?
In which case, I assume that most camera vendors follow a common standard interface for camera drivers. Could anyone comment on such assumption or explain how AMCAP.exe is able to do that.
I've been able to use both cameras in my c++ based OpenCv applications, but I'm asking because a 3rd company is going to provide me with a usb board-based camera (for evaluation) and they are asking about driver specs. so I suggested that it should work with windows default driver similar to how a webcam would so as to avoid compatibility issues but I'm wondering if there is a better option that I might be missing.
Note I: I've been able to verify that different drivers are being used for each camera by: Start->Devices and Printers->USB 2.0 Camera->Hardware tabe->USB 2.0 camera->Driver->Driver Details. When the webcam is connected, it is using the microsoft provided driver files: ksthunk.sys and usbvideo.sys. When I disconnect the webcam and connect the evaluation camera, I am able to verify that it is using it's own (non-windows) driver.
Note II: Vimicro's AMCAP.exe can be downloaded from: VIMICRO USB PC Camera (VC0303) - CNET Download.com
Note III: Computer is core i7. OS is win7 64bit.
Any help or input on this is truly appreciated and immensely needed.
Best,
Hasan.
Camera drivers must implement the OS-defined interface which isn't different for various devices of the same category (in your case it's USB camera). Default drivers for some devices are bundled with Windows and it's ok to use them. However, they aren't necessary optimal for each and every device. E.g., for cameras they might support only a limited set of supported resolutions or might not be optimal with power saving (just an example, not necessary what really happens!). This is because MS implements only the basic and necessary functionality that must be present in every device and doesn't depend on proprietary HW of various vendors. Dedicated camera driver should provide all the additional functionality - you're the one to decide if it's important for you or not.
In Windows XP, you can configure your sound card properties via the preloaded windows software. In the recording properties, if "stereo mix" or "wave out" (or something similar) is selected as the recording device, programs that can record audio ("Sound Recorder" in windows for example) record a decent quality wave file of the audio stream. I usually use Goldwave from download.com to do this as an example of a third-party application that functions the same.
Well, I've had trouble getting this scenario to happen on Windows Vista or later in a direct no-bullsh*t manner as described above. It's more than just Vista+, it's also that some sound cards don't have that option at all.
I was just wondering if there is a way to run a windows-friendly program (VB?) that takes your audio output stream and converts it (in realtime, obviously) to a WAV file with the default sampling rate as other WAV files have.
Ideally, it would cool if it worked on any operating system, so is it possible to write a web service that "listens" to your audio card like that without making the computer think it's getting a virus attack or something?
Possibly related question:
How to save web audio streaming to file ( c++ / java )
I'm only aware of one manufacturer of sound cards that enabled that option (Creative). However Vista and beyond support a "loopback" mode which gives you effectively the same functionality. You need to use the low level WASAPI rendering stack but it should work just fine.
https://github.com/rdp/virtual-audio-output-sniffer provides a directshow input device to capture the sum of wave out for vista+
You could use low level waveOut API injection and capture what it receives.
I have SkypeMXrecorder, a software that does just that - inject into any exe and 'sniffs' what's going out from it and into the sound hardware. But, it seems rather complicated to implement...
I have this garden variety USB video camera, and it came with two mini-apps, one that just lets you see what the camera sees, and one that records to an .avi file.
But what's the API if I want to grab images from the camera in my own C program? I am making the assumptions that it's (1) possible and (2) desirable to make some call and have a 2D array of pixel information filled in.
What I really want to do is tinker with image processing algorithms, and for that I'd really like to get my code around some live data.
EDIT -
Having had a healthy exposure to Linux, I can grasp how (ideally/in theory) you could open() the device, use ioctl() to configure it, and read() the data. And I'm virtually certain that that's not how Windows is going to present the API. Not knowing what function names Windows might use for a video device API, or even if it has one, makes it difficult to look up, at least with the win32 api search capabilities that I have at my disposal.
You'll probably need the DirectShow API, provided that's how the camera operates. If the manufacturer created their own code path, you'll need their API.
Your first step, as pointed out by ChrisBD, is to check if Windows supports your device.
If that is the case you have three possible Windows APIs for capture:
DirectShow
VFW. Has more or less been replaced by DirectShow
MediaFoundation. Is the newest API that is intended to replace DirectShow. AFAIK not fully implemented yet and only available in Vista.
From the three DirectShow is the best choice. However, learning and using DirectShow is not a trivial task. An excellent example can be found here.
Another possibility is to use OpenCV. OpenCV is an image processing library, that you can also use for processing the images. OpenCV has an image capture API that provides a simpler abstraction and is easier to use than the Windows APIs.
The API is the way to go.
A good indication of whether the camera requires a bespoke one or not is to see if it is recognised by a PC without the manufacturer's applications installed. If windows has the drivers built in the you should be able to use the windows APIs to capture the images.
Alternatively if you know what compression codec has been used for the AVI file you could unpack it.
Ideally it would be good if you could capture the video in native (YUV, RGB15 or similar) format as then you can work on compression as well as manipulation.
I'd like to pull a stream of PCM samples from a Mac's line-in or built-in mic and do a little live analysis (the exact nature doesn't pertain to this question, but it could be an FFT every so often, or some basic statistics on the sample levels, or what have you).
What's a good fit for this? Writing an AudioUnit that just passes the sound through and incidentally hands it off somewhere for analysis? Writing a JACK-aware app and figuring out how to get it to play with the JACK server? Ecasound?
This is a cheesy proof-of-concept hobby project, so simplicity of API is the driving factor (followed by reasonable choice of programming language).
The principal framework for audio development in Mac OS X is Core Audio; it's the basis for all audio I/O. There are layers on top of it like Audio Toolbox, Audio Queue Services, QuickTime, and QTKit that you can use if you want a simplified API for common tasks.
To just pull a stream of samples, you'd probably want to use Audio Queue Services; the AudioQueueNewInput function will set up recording of PCM data and pass it to a callback you supply.
On your Mac there's a set of Core Audio examples in /Developer/Examples/CoreAudio/SimpleSDK that includes a use (AQRecord in AudioQueueTools) of the Audio Queue Services recording APIs.
I think portaudio is what you need.
Reading from the mike from a console app is a 10 line C file (see patests in the portaudio distrib).
Apple provides sample code for reading and writing audio data. Additionally there is a lot of good information in the Audio section of the Apple Developer site.