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.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
bsruth
  • 5,372
  • 6
  • 35
  • 44
  • have you found a solution to this problem yet? I'm in a similar situation.. – Mike Dinescu Sep 25 '10 at 00:00
  • Nope, got pulled off the project and haven't had a chance to get back to it yet. I'll update here if I find anything though. – bsruth Sep 28 '10 at 14:52
  • http://stackoverflow.com/questions/2940592/how-to-capture-data-from-camera-not-using-directshow may be related, and have more info. – rogerdpack Sep 25 '11 at 01:47

6 Answers6

1

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.

  • 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 Oct 13 '10 at 16:40
  • 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. –  Oct 13 '10 at 17:22
  • 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 –  Oct 13 '10 at 17:33
  • 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 ;) –  Oct 13 '10 at 17:43
  • 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 Oct 14 '10 at 15:26
  • Every capture device includes a hardware clock which triggers frame captures at the rate you specify (in DirectShow use IAMStreamConfig::SetFormat). Frames will always be captured at this rate unless the capture filter is starved for buffers to fill (in DirectShow, use IAMBufferNegotiation::SuggestAllocatorProperties to control the number of frames to allocate on the capture filter). When your application actually gets the captured frames is a completely different issue, controlled by latencies in the graph. – Jay Borseth Jan 04 '12 at 13:43
1

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
  • 413,100
  • 91
  • 616
  • 614
  • 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 Feb 12 '09 at 19:24
0

LeadTools and VisioForge SDKs are just wrappers for DirectShow + some custom filters from them! There is no real alternativ to DirectShow for capturing on a Windows PC. Maybe on Win8 with MediaFoundation? Some Hardware Vendors have there own capture programms, but most of them just use DirectShow.

I think your problem is not DirectShow. How long is your callback working? Because if your doing some analysis on the image, then you need to do this fast. Not the time in your callback is importent, but the presentation time in the mediasample you get! This should be +33ms from the previews sample.

CPlusSharp
  • 881
  • 5
  • 15
0

FFmpeg can receive directshow input and manipulate it, and it's free. AviSynth maybe too...

rogerdpack
  • 62,887
  • 36
  • 269
  • 388
0

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

jheriko
  • 3,043
  • 1
  • 21
  • 28
  • 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 Feb 12 '09 at 19:21
  • 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 Feb 12 '09 at 19:23
  • Well it was a bit of a stab in the dark. It could always be caused by something else. :) – jheriko Feb 12 '09 at 19:24
0

VideoLan may be an option for you.

Chris Holmes
  • 11,444
  • 12
  • 50
  • 64