I am writing a program that reads from multiple audio and video devices and writes the data to suitable containers (such as mpeg). I have wrote the code in Linux, but now I have to write another version for windows as well. This is how I wrote it in Linux:
initialize the devices (audio: ALSA, video: V4L2)
get the file descriptors
mainloop
select on file descriptors
respond to the proper device
Unfortunately my expertise is only for Linux and I have never used windows SDK. I don't know what the right paradigm is. Do people do it the same way with the fds and select? In that case is there a way to get a fd from directshow? Oh and one last thing, I am bound to use only one thread for all of this. So the solution with multiple threads running at the same time and each handling one device is not admissible. The code in Linux currently runs on one thread as well. It is also preferred that the code should be written in c++. Thank you.
Second Thoughts There is only one question asked here and that is: How can one get the file descriptor of the video/audio device from DirectShow library. People who have worked with V4L2 and ALSA, I am looking for the same thing in DirectShow.
Roman is an expert in these topics and I don't think you'll find a better answer. To add to Roman's answer, you would do something like this in DirectShow:
Enumerate video/audio capture devices/select capture device
Construct DirectShow graph
Add video and audio capture source filters to graph
Add 2 sample grabbers to graph
Configure sample grabber callbacks
Connect capture source filters to samples grabbers
Add renderers to graph (This could be a null renderer or a video/audio renderer)
Connect sample grabbers to renderers
Play graph
Run the event loop
DirectShow will invoke the callbacks per media sample traversing the graph.
Your graph would typically look like this:
callback
|
Video capture -- sample grabber -- renderer
Audio capture -- sample grabber -- renderer
|
callback
As Roman said, there are many samples in the SDK showing how to
On the topic of threading, you'll be writing the code for the main application thread, and DirectShow will handle the internal thread management. However note that if your callback function is processing intensive, it may interfere with playback since (From MSDN):
The data processing thread blocks until the callback method returns. If the callback does not return quickly, it can interfere with playback.
This may or may not be important depending on your application requirements. If it is important you could e.g. pass the data to another thread for processing. The result of blocking the data processing thread is that you'll get lower framerates in the case of video.