Поиск

10 января 2014

Исследование задержки разных средств видеозахвата.

В наземной станции, в наземке, будет использоватья устройство видеозахвата, для оцифровки и отображения в реальном времени полетного видео, и для ведения видеодневника полета.

Для удобного, и простого управления системой - нужно видео с минимальным уровнем задержки. Поясню на примере временной диаграммы:
Диаграмма нарисована для сигнала NTSC, с его 30 кадрами/с. У меня камера PAL, и соответственно на полный фрейм у меня 40мс.

Немного теории:
Итого, идеальный случай(для PAL): Фрейм камеры 40мс + фрейм оцифровки и отрисовками средствами OS - 80мс.

Проверяем теорию, используя прямое соединение "камера->аналоговый экран". Мы все понимаем, что камера не аналоговая, а цифровая, и строит картинку и "выплёвывает" ее в композит хоть и построчно, но уже после некого буфера кадров в ЦАПе самой камеры, и такая-же ситуация с "аналоговым" монитором, контроллер которого, пока не построит весь фрейм, не "выплюнет" картинку в свой LVDS самой ЖК панели.

Соответственно методика проста как камень: на одном экране мы отображаем таймер, на камеру снимаем, чтобы попадали одновременно монитор "А" с таймером и монитор "Б".

Проверка камера-"аналоговый"монитор, заодно неплохо видна методика измерения:
Итого, по результатам нескольких измерений: ~50мс. Т.е. время фрейма PAL пока он собирается в контроллере монитора + некое время для оцифровки DAC камеры, что в общем-то средний результат для специализированного устройства.


Дальнейшие проверки програмно-аппаратные. Стоят последние драйвера, и чистые OS, идеализировать не имеет смысла, т.к. некоторые драйвера имеют ограничения, и сама MS Windows вносит свои погрешности. Более того, вся моя базовая станция будет именно под MS Windows, что для меня удобнее и в итоге дешевле, чем что-то иное.
Проверка Pinnacle Dazzle AVC100, интерфейс USB2.0:
Итого: 201мс, что вполне объяснимо, время на полный захват фрейма, кодирование его в некий "Lossy или Lossless" формат чтобы запихать его в USB2 интерфейс, декодинг драйвером системы, вывод на экран... Трагично, и не используемо, слишком велика задержка для управления Real-Time, для видеожурналирования пойдет, но не более того. Качество захвата картинки приемлемое.

Проверка с помощью Canopus ADVC110, интерфейс FireWire 400:
Итого: 201мс. А вот это уже подозрительно, ведь совершенно другое устройство, совершенно(!) другой интерфейс.. А результат, фактически, идентичный.

Проверка с помощью Winnov Videum Quattro платы(устройство на порядок более дорогого для видеозахвата), интерфейс PCI:
Итого: 151мс, что уже лучше чем ранее, но начинают грести кошки сомнения, что "что-то не ладно в Датском королевстве". Videum Quattro - это профессиональная карта видеозахвата, стоящая, не много ни мало - $1500

Решаюсь проверить обычную вебкамеру, Microsoft Lifecam Cinema:
Итого: 103мс... Т.е. это виновата не OS, а механизм захвата и передачи данных предыдущих устройств.


Общий итог: работабщего решения у меня пока видимо нет :(. Прийдется брать специализированное устройство, расчитанное на видеозахват с наименьшей задержкой, например: Sensoray 2253 http://www.sensoray.com/products/2253.htm 





2 комментария:

  1. Анонимный01 апреля, 2014 12:42

    посмотрите тут чел решение предлагает на 130ms https://developer.oculusvr.com/forums/viewtopic.php?f=20&t=2358

    ОтветитьУдалить
  2. Да, спасибо - но, как это оказалось - я нашел решение с 100мс задержкой, не успел еще написать в блог.

    ОтветитьУдалить