Передача данных видеонаблюдения по IP-сетям

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

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

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

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

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

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

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

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

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

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

1. Один клиент получает видеопотоки с одного сервера.
2. Несколько клиентов получают одинаковые видеопотоки с одного сервера.
3. Несколько клиентов получают разные видеопотоки с одного сервера.
4. Несколько клиентов получают разные видеопотоки с разных серверов.

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

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

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

Ограничение скорости передачи в зависимости от скорости чтения

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

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

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

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

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

Рассмотрим упрощенную схему архитектуры программы-клиента (рис. 3). Для обработки видео с одной камеры запускается два потока, выполняющихся в параллель — TCP-клиент и декомпрессор. TCP-клиент читает данные из буфера, группирует их в кадры и передает декомпрессору. Декомпрессор осуществляет декомпрессию кадров и вывод их на экран. Для обработки видео с двух и более камер запускается по одному потоку декомпрессии на каждую из камер и общий поток чтения данных из всех сокетов соединений. Когда какой-либо поток декомпрессии не успевает обрабатывать все поставляемые ему кадры, поток чтения должен приостановить чтение из соответствующего сокета. Чтение можно приостановить после получения какой-то части следующего кадра, или по завершению приема кадра, передаваемого декомпрессору. В первом случае при возобновлении чтения придется вычитать остатки возможно уже устаревшего кадра (это может произойти при высокой скорости захвата кадров на сервере и низкой скорости обработки кадров на клиенте). Во втором случае кадр, полученный после возобновления чтения, также будет устаревшим, поскольку сервер по событию окончания передачи одного кадра автоматически начнет передачу следующего. В обоих случаях будет возникать задержка между событием и его отображением. Кроме того, вследствие неравномерности распределения вычислительных ресурсов компьютера-клиента между процессами, при высокой нагрузке на процессор скорость обработки кадров декомпрессором меняется в широких пределах, что приводит к «рывкам» выводимого на экран видеопотока.

Регулирование интервала между кадрами

Если сервер захватывает с какой-нибудь камеры RG кадров/c, но клиент, в силу недостаточности своих вычислительных ресурсов, может отобразить только RD кадров/с (RD

В реализованном нами методе определения клиентом величины RS считается, что RS должна указываться серверу в зависимости от скорости приема кадров TCP-клиентом (RC), скорости обработки кадров декомпрессором (RD) и средней суммарной загрузки процессора (L). Регулирование производится дискретно, с интервалом T (порядка нескольких секунд), при этом новое значение RS определяется исходя из значения RS, вычисленного на предыдущем шаге и текущей нагрузки процессора.

После определения RS вычисляется величина интервала между отправляемыми сервером кадрами: TS =1/ RS. Сервер, получив от клиента значение TS, начинает прореживать отправляемые клиенту кадры таким образом, чтобы разница между временами их создания превышала TS.

Заключение

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

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

Литература

1. et al. TCP-Friendly Internet Video Streaming Employing Variable Frame-Rate Encoding and Interpolation. IEEE Transactions on Circuits and Systems for Video Technology, vol. 10, no.7, October 2000.
2. Джамса К., Коуп К. Программирование для Internet в среде Windows. СПб., 1996.