Использование C # с C DLL для обратного вызова, не может быть лучше, чем частота смены кадров 16FPS, почему?

Question

У меня есть приложение на C #, которое взаимодействует с USB-камерой. Это работает просто отлично, за исключением того факта, что мне не удалось добиться лучшего, чем около 16 кадров в секунду. Я использую VFW и обратный вызов 'C' (обратный вызов является частью DLL) для сообщения WM_CAP_GRAB_FRAME_NOSTOP, и я обнаружил, что даже если я по существу ничего не делаю в обратном вызове, я не могу получить приличный частота кадров (16 кадров в секунду - это максимум).

Я думал , что использование этого интерфейса даст мне лучшую производительность, чем другие альтернативы (например, DirectShow), просто из-за его простоты и низкоуровневого подключения к драйверу; но теперь я начинаю задумываться, правда ли это.
У кого-нибудь есть понимание этого?

Answer 1

Я так и не узнал, почему VFW ограничивает мою частоту кадров; Тем не менее, я нашел VideoInput для C #, и теперь я использую это вместо. Дает мне гораздо больший контроль над камерой и гораздо более высокую частоту кадров.

Answer 2

Позвольте мне рискнуть догадаться ...

Вы случайно не используете System.Timers.Timer?Или часть C программы использует Windows Timer?Если вы это сделаете, причиной проблемы может быть его ограниченное разрешение.