Территориально распределенные пользователи систематического видеонаблюдения

Одно из основных требований, предъявляемых к современным цифровым системам видеонаблюдения, — возможность передачи изображений по сети. В этой связи представляет интерес организация передачи видеопотоков в реальном времени по распределенной сети с использованием протокола TCP/IP при автоматическом регулировании скорости передачи в зависимости от пропускной способности сети и индивидуальных возможностей серверов и клиентов.

Современные цифровые системы видеонаблюдения позволяют получить значительный экономический эффект при обеспечении безопасности территориально распределенных объектов за счет передачи изображений по компьютерной сети. Видеосервер обычно представляет собой компьютер со специализированными платами видеоввода, к которым подключаются от одной до нескольких видеокамер. Программное обеспечение видеосервера организует: захват видеокадров; обработку видео (улучшение качества изображения, выявление движения, компрессию видеопотоков, запись в локальный архив); передачу по сети потоков сжатого видео клиентам.

В роли клиента может выступать любой компьютер, подключенный к сети и получающий потоки данных с видеосерверов, декомпрессирующий видеоизображения и выводящий изображения на монитор. В настоящее время широкое распространение начали получать IP-камеры, представляющие собой видеосервер, интегрированный с видеокамерой. В зависимости от функциональных возможностей IP-камеры клиент может получать потоки данных клиентом как напрямую с камеры (посредством протокола семейства IP), так и через специальный видеосервер.

Основные критерии оценки качества распределенной системы цифрового видеонаблюдения — величина временной задержки между каким-либо событием, произошедшим перед видеокамерой, и моментом его отображения на экране клиента, а также количество кадров, отображаемых в секунду на экране клиента. Оба параметра зависят от пропускной способности сети и производительности сервера и клиента. Следует подчеркнуть: помимо передачи видеопотоков по сети значительную роль играют процессы компрессии/декомпрессии видео, поэтому, если в глобальных сетях решающую роль играет пропускная способность канала, то в локальных сетях слабым звеном зачастую становятся ограниченные вычислительные мощности отдельных компьютеров.

Рисунок 4.1. Территориально распределенная многопользовательская система видеонаблюдения

Выбор протокола передачи данных

В системах видеонаблюдения общего пользования в качестве клиента может быть использован любой компьютер, поэтому вследствие ограниченности возможностей отдельных экземпляров реальная скорость вывода видео на экран может снижаться до 1-4 кадра/c на камеру при возможных 25 кадрах/c. В этом случае нет смысла передавать клиенту кадры, которые он не в состоянии обработать. Требуется механизм прореживания передаваемых кадров на уровне сервера.

Ethernet-коммутаторы способны отчасти решить проблемы коллизий, однако при высокой нагрузке на каждый порт коммутатора неизбежно накопление очередей в буферах коммутаторов и серверов, а значит, и задержки и потери даже в пределах локальной сети. Но даже замена концентраторов на коммутаторы не искореняет проблему потери сетевых пакетов в пределах локальной сети. Размер одного компрессированного видеокадра обычно составляет несколько килобайт и при передаче по сети происходит его разбиение на несколько пакетов. Потеря одного пакета, представляющего кусочек компрессированного кадра, приведет к несоизмеримым потерям в реальной картинке. Картинка не обязательно будет потеряна целиком (существуют механизмы восстановления растрового изображения из компрессированного), однако потери качества восстановленного изображения окажутся в процентном соотношении больше, чем потери данных в компрессированном изображении. В случае, если клиент успевает обрабатывать изображение с камеры со скоростью 25 кадров/c, можно просто отбросить «битый» кадр, однако на скорости 4 кадра/c его потеря будет весьма заметна. Следовательно, при низких скоростях вывода видео на экран необходимо предусмотреть механизм повторной посылки потерянных кадров.

Стандартные методы передачи видеопотоков по компьютерным сетям основываются на использовании протокола UDP, позволяющего организовывать одновременную передачу данных множеству клиентов (multicast), занимающего меньшую — по сравнению с протоколом TCP — часть пропускной способности, но не гарантирующего качество доставки и правильность порядка передачи данных. Правильность порядка передачи данных реализуется на уровне приложения за счет буферизации входящего трафика и его пересортировки. Потерянные пакеты обычно не пересылаются; вместо этого используются алгоритмы восстановления потерянной информации и механизмы регуляции скорости передачи данных.

По сравнению с UDP, протокол TCP/IP обеспечивает регулирование скорости передачи данных в зависимости от загруженности канала связи, правильный порядок передачи данных и повторную посылку потерянных данных. Основным аргументом в пользу UDP выступает возможность организации многоадресной рассылки видео множеству клиентов. Для того чтобы оценить важность этого аргумента, рассмотрим основные случаи построения распределенной системы видеонаблюдения.

- Один клиент получает видеопотоки с одного сервера.

- Несколько клиентов получают одинаковые видеопотоки с одного сервера.

- Несколько клиентов получают разные видеопотоки с одного сервера.

- Несколько клиентов получают разные видеопотоки с разных серверов.

Использование многоадресной рассылки с точки зрения значительного уменьшения сетевого трафика выгодно только во втором случае, который по структуре соответствует принципам организации видеоконференций. В системах видеонаблюдения общего пользования наиболее распространены третий и четвертый варианты, поскольку выборки камер (из множества других, подключенных к серверу) для просмотра на компьютерах-клиентах делаются в зависимости от желаний пользователей, и, скорее всего, не по территориальному, а по тематическому признаку. Следовательно, в общем случае видеопотоки, адресованные различным клиентам, не будут совпадать друг с другом — как по содержанию, так и по скорости.

Регулирование скорости передачи данных

При готовности к обработке нового видеокадра клиент посылает запрос серверу, который в ответ посылает один кадр и переходит в состояние ожидания. Этот простой механизм хорошо работает на низких скоростях, что делает его привлекательным для Web-камер. Однако он не в состоянии эффективно использовать вычислительные ресурсы клиента на высоких скоростях; неизбежен простой процесса декомпрессии в течение ожидания нового кадра. Это приводит к большой задержке между реальным событием и его отображением, а также к заниженной скорости вывода на экран.

Ограничение скорости передачи в зависимости от скорости чтения. Избежать простоя процесса декомпрессии можно следующим образом. Так как используется протокол TCP/IP, то время окончания приема кадра клиентом примерно совпадает с моментом окончания передачи этого кадра на сервере, следовательно, можно избежать ожидания сервером нового запроса. При этом по событию окончания передачи предыдущего кадра сервер должен начать передачу нового. В этом случае клиент уже не посылает запрос на получение кадра, а вместо этого единожды «подписывается» на получение потока кадров. Чтобы пояснить, как происходит регуляция скорости в этом случае, рассмотрим одну из особенностей работы протокола TCP/IP (рис. 4.2).

С точки зрения программной реализации видеосервера процесс передачи данных по сети выглядит как запись этих данных в соответствующий сокет (дескриптор соединения). При этом данные помещаются в буфер передачи, расположенный на сервере, и, далее, средствами протокола в буфер приема, находящийся на клиенте

.

Рисунок 4.2. Передача данных от сервера клиенту (TX и RX — буферы передачи и чтения соответственно)

Клиент получает данные в процессе чтения из буфера приема, и если он будет читать медленнее, чем сервер будет записывать данные в свой буфер передачи, то буфер приема заполнится, вслед за этим заполнится буфер передачи, и попытка записи в него новых данных будет приводить к ошибке. Таким образом, уменьшение скорости чтения клиентом из буфера чтения приводит к уменьшению скорости передачи новых кадров сервером и наоборот, увеличение скорости чтения ведет к увеличению скорости передачи.

Основная трудность при реализации этого метода заключается в ограничении скорости чтения из буфера клиента.

Рассмотрим упрощенную схему архитектуры программы-клиента (рис. 4.3). Для обработки видео с одной камеры запускается два потока, выполняющихся в параллель — TCP-клиент и декомпрессор. TCP-клиент читает данные из буфера, группирует их в кадры и передает декомпрессору.

Рисунок 4.3. Просмотр видео с одной камеры