В первой части я исследовал зависимость задержки, и общую латентность системы при использовании средств видеозахвата. Вынес один урок - средства видуозахвата оказались слабым звеном при проектировании наземной станции, т.к. не удовлетворяли требованию минимальной задержки захваченного сигнала.
Я не списывал со счетов средство видеозахвата, и, при оказазии - купил чуть более чем за 1т.р. IconBIT TV-Hunter Studio. Достаточно интересная железка, сделанная на относительно свежем чипсете - Китайском Empia 2980
Я не списывал со счетов средство видеозахвата, и, при оказазии - купил чуть более чем за 1т.р. IconBIT TV-Hunter Studio. Достаточно интересная железка, сделанная на относительно свежем чипсете - Китайском Empia 2980
Стоит отметить - для нужд нормального "интегратора" материнская плата данного устройства обладает очень полезным свойтсвом - отверстиями для монтажа.
Подключив, убедившись в полной совместимости с Windows 8.1 x64 (!), что было отдельным приятным сюрпризом, и посмотрев на коробочку в действии - решено было сделать замеры скорости по методике описываемой в первой части.
103мс!!! Каково мое было удвиление! Я был просто приятно, нет, ПРИЯТНО поражен! 103мс при захвате и выводе аналогового сигнала формата PAL, т.е. общий лаг чуть более 2х полных кадров(напонимаю - PAL, 40мс/кадр перед оцифровкой).
Я фактически УВЕРЕН, что 100мс это определенный "предел" практически реализуемый для аналогового захвата(в силу сканирующей природы образования "полного" кадра). Я в курсе low-latency решений, использующих цифровую передачу данных между узлами, где латентность держится порядка 60мс, но это удел будущего, и экспериментов с адаптивным "HD" для использования в FPV.
Я еще проведу ряд оптимизаций со стороны операционной системы, и надеюсь выиграть еще 20-25мс на задержках, но и этот результат меня устраивает - я готов его использовать. Считаю - для ФПВ целей - оптимальное устройство видеозахвата.
Комментариев нет:
Отправить комментарий