views:

978

answers:

4

I am looking at updating a program that currently uses DirectShow for video capture. While DirectShow seems to work well, I was wondering if there were any more powerful or up to date SDKs or APIs that I should look into. Some features that would be helpful would be ones that will:

  1. Provide a consistent framerate (33ms between frames for NTSC) during capture.
  2. Work with DirectShow compatible capture devices.
  3. Not require an extra license to be installed on the customer's PC.
  4. Allow for simultaneous preview and hardware encoding of video.
  5. Be able to be integrated into a C++/MFC application.

I've looked into LeadTools Multimedia Capture SDK and VisioForge Capture SDK and Microsoft Media Foundation, but just wanted to know what others have used successfully before I invest time or money into one of these alternatives. I don't care if this is a commercial or open source product.

EDIT: While I appreciate the attempts to solve my particular problem, this question was supposed to be about alternatives to DirectShow. So, I removed all of the references to my specific problem. Solving that will need to wait for another question.

A: 

The problem might just be the method you are using for timing. Are you using the high performance timer API?

jheriko
I'm familiar with the performance timers in Windows, but how do you suggest they be integrated into the DirectShow graph to improve framerate consistency?
bsruth
I currently use QueryPerformaceCounter to get a system wide timestamp that is saved with the video. It is actually this timestamp that is showing me the framerate is inconsistent.
bsruth
Well it was a bit of a stab in the dark. It could always be caused by something else. :)
jheriko
A: 

Quite all capture boards come with their own timers.

You may try to query you source filter for IReferenceClock and use its own timer that is usually more accurate than a PC's one.

If you use ISampleGrabber then the callback function is called microseconds from the moment Receive is called on the Sample Grabber's input pin, they're just few lines away in the source code.

It seems that your frame source timing is inaccurate (not the timing set in IMediaSample, but actial timing the frames are delivered in).

What is the source filter that produces the frames?

Quassnoi
I use the ISampleGrabber to grab the image and perform analysis on it. The frameready callback of the sample grabber is not called every 33ms, I am looking for something where I get an image every 33ms.
bsruth
A: 

VideoLan may be an option for you.

Chris Holmes
A: 

The DirectShow API is very good, I've never found better on the windows platform. DirectShow has been superseded by Media Foundation, which is Vista (and later) operating systems only.

We'll have to wait for XP to die before people will start mass development using Media Foundation...

May I ask why you're seeking an alternative to DirectShow - it's a very well supported API - well documented on MSDN and there's a very active and friendly forum on MSDN for DirectShow Development.

freefallr
I am having issues getting a consistent frame timing using DirectShow. The time between frames is between 10ms and 50ms. Which is fine for simple playback, but I'm trying to use it for scientific experiments where consistent timing is critical. However, the point of this question is just to come up with alternatives, not solve my particular problem.
bsruth
Can you tell us some more about your setup? What is your capture hardware? I normally use Osprey capture cards, but I've encountered other capture cards (Winnov etc), and they've always had a constant sample rate.
freefallr
I just did a bit of digging, and thought I'd pass on this link to IAMVideoControl::GetFrameRateList: http://msdn.microsoft.com/en-us/library/dd376026(v=VS.85).aspx
freefallr
I'd be v. interested to hear about your capture hardware. Please let me know about the hardware used. I'll even have a look at your source code if you send me a link to an SVN repository ;)
freefallr
I'm using the Hauppauge capture cards since hardware MPEG2 encoding is required. Thanks for the suggestion, I'll look into it once I'm able to get back to this project.
bsruth