04 февраля 2004
С. Новиков. Передача видео в распределенных цифровых системах видеонаблюдения по протоколу TCP/IP.
С. Новиков
Открытые системы, #09/2003
Аннотация
В статье предлагаются принципы программной организации передачи видеопотоков реального времени по распределенной сети, состоящей из множества видеосерверов и компьютеров-клиентов, с использованием протокола TCP/IP.
ВВЕДЕНИЕ
Одним из основных требований, предъявляемых к современным цифровым системам видеонаблюдения, является возможность передачи изображений с видеокамер по компьютерной сети. Использование этой возможности дает значительный экономический эффект при организации видеонаблюдения на территориально распределенных объектах, а также в многопользовательских системах, когда изображение с одной камеры необходимо просматривать со значительно удаленных друг от друга рабочих мест (рис.1).
Рис.1. Территориально распределенная многопользовательская система видеонаблюдения.
Видеосервер обычно представляет собой компьютер со специализированными платами видеоввода, к которым подключаются от одной до нескольких видеокамер, и программным обеспечением. ПО видеосервера организует:
- захват видеокадров;
- обработку видео (улучшение качества изображения, детекцию движения, компрессию видеопотоков, запись в локальный архив);
- передачу по сети потоков сжатого видео клиентам.
В роли видеоклиента обычно может выступать любой компьютер, подключенный к компьютерной сети. Стандартными задачами ПО клиента являются:
- получение потоков данных с видеосерверов;
- декомпрессия видеоизображений;
- вывод изображений на монитор.
В последнее время широкое распространение начали получать IP-камеры, которые представляют собой видеосервер, интегрированный прямо в видеокамеру. При использовании таких камер получение потоков данных видеоклиентом может осуществляться как напрямую с камеры (посредством протокола семейства IP), так и через специальный видеосервер, в зависимости от функциональных возможностей IP-камеры.
Основными критериями оценки качества распределенной системы цифрового видеонаблюдения являются:
- Величина временной задержки между каким-либо событием, произошедшим перед видеокамерой, и моментом его отображения на экране клиента;
- Количество кадров/с, отображаемых на экране клиента.
Оба этих параметра зависят от пропускной способности сети и вычислительных ресурсов сервера и клиента. Следует подчеркнуть, что кроме передачи видеопотоков по сети, значительную роль играют процессы компрессии/декомпрессии видео. Поэтому, если в глобальных сетях (Интернет) решающую роль играет пропускная способность канала, то в ЛВС зачастую слабым звеном оказываются ограниченные вычислительные мощности отдельных компьютеров.
В данной работе предлагается возможный подход к программной организации передачи потоков данных в реальном времени между множеством серверов и клиентов, обеспечивающий регуляцию скорости передачи данных в зависимости от пропускной способности сети и вычислительных ресурсов серверов и клиентов.
1. ВЫБОР ПРОТОКОЛА ПЕРЕДАЧИ ДАННЫХ
При рассмотрении работы системы видеонаблюдения общего пользования мы опираемся на то, что в качестве компьютера-клиента может быть использован любой компьютер, находящийся в сети. Вследствие ограниченности его вычислительных ресурсов при получении видеопотоков со множества серверов, реальная скорость вывода видео на экран может снижаться до 1-4 кадра/c на камеру. Исходя из того, что нет необходимости передавать по сети клиенту те кадры, которые он не в состоянии обработать, вытекает необходимость в механизме прореживания передаваемых кадров на уровне сервера.
Ethernet-коммутаторы способны решить проблемы коллизий, однако при высокой нагрузке на каждый порт неизбежны накопления очередей в буферах коммутаторов и серверов, а значит задержки и потери даже в пределах ЛВС. Размер одного закомпрессированного видеокадра обычно составляет порядка нескольких Кбайт, т.е. при передаче по сети происходит его разбиение на несколько пакетов. Потеря одного пакета (кусочка закомпрессированного кадра) ведет к несоизмеримым потерям реальной картинки. В случае если мы успеваем обрабатывать на клиенте изображение с камеры со скоростью 25 кадров/c, можно просто отбросить «битый» кадр, однако потеря его на скорости порядка 4 кадра/c будет весьма заметна. Следовательно, на низких скоростях вывода видео на экран, необходимы механизмы перепосылки потерянных при передаче по сети данных.
Стандартные методы передачи видеопотоков по компьютерным сетям основываются на использовании протокола UDP [1]. Протокол UDP не гарантирует качество доставки и правильность порядка передачи данных, однако требует меньшей пропускной способности канала и позволяет организовывать одновременную передачу данных множеству клиентов (мультикаст) [2]. Правильность порядка передачи данных реализуется на уровне приложения за счет буферизации входящего трафика и его пересортировки. Потерянные пакеты обычно не пересылаются, вместо этого используются алгоритмы восстановления потерянной информации и механизмы регуляции скорости передачи данных.
Протокол TCP/IP по сравнению с UDP самостоятельно обеспечивает:
- регуляцию скорости передачи данных в зависимости от загруженности канала связи;
- правильный порядок передачи данных;
- перепосылку потерянных данных.
Основным аргументом за UDP выступает возможность организации мультикастовой рассылки видео множеству клиентов. Для того чтобы оценить его важность, рассмотрим следующие основные случаи построения распределенной системы видеонаблюдения:
- Один клиент получает видеопотоки с одного сервера;
- Несколько клиентов получают одинаковые видеопотоки с одного сервера;
- Несколько клиентов получают разные видеопотоки с одного сервера;
- Несколько клиентов получают разные видеопотоки с разных серверов.
Использование мультикаста с точки зрения значительного уменьшения сетевого трафика выгодно только во 2-м случае, который по структуре соответствует принципам организации видеоконференций. В системах видеонаблюдения общего пользования наиболее распространенными будут 3-й и 4-й варианты, т.к. выборки камер (из множества других, подключенных к серверу) для просмотра на компьютерах-клиентах делаются в зависимости от пожеланий пользователей, и, скорее всего, не по территориальному признаку, а тематическому. Следовательно, в общем случае видеопотоки до различных клиентов не будут совпадать друг с другом как по содержанию, так и скорости.
Принимая во внимание всё вышесказанное, мы отдали предпочтение TCP/IP. При этом на уровне приложения добавлен дополнительный механизм регуляции скорости передачи данных.
2. РЕГУЛИРОВАНИЕ СКОРОСТИ ПЕРЕДАЧИ ДАННЫХ
2.1 РЕГУЛИРОВАНИЕ ПО ПРИНЦИПУ "ЗАПРОС-ОТВЕТ"
Самый простой механизм регуляции скорости отправления кадров с сервера в зависимости от возможностей клиента выглядит следующим образом. Клиент, в случае готовности к обработке нового видеокадра, посылает серверу запрос. При получении запроса сервер отправляет клиенту один кадр и переходит в ожидание следующего запроса. Этот механизм очень прост и хорошо работает на низких скоростях, что делает его привлекательным для WEB-камер (т.е. просматриваемых с помощью WEB-браузера). К недостаткам метода можно отнести его неспособность эффективно использовать вычислительных ресурсы клиента на высоких скоростях, т.к. неизбежен простой процесса декомпрессии в течение ожидания нового кадра. Это приводит к большой задержке между реальным событием и его отображением, а также к заниженной скорости вывода на экран.
2.2 ОГРАНИЧЕНИЕ СКОРОСТИ ПЕРЕДАЧИ В ЗАВИСИМОСТИ ОТ СКОРОСТИ ЧТЕНИЯ
Избежать простоя процесса декомпрессии можно следующим образом. Так как мы используем протокол TCP/IP, то время окончания приема кадра клиентом примерно совпадает с моментом окончания передачи этого кадра на сервере. Следовательно, можно избежать ожидания сервером нового запроса. При этом по событию окончания передачи предыдущего кадра сервер должен начать передачу нового кадра. При использовании этого метода, клиент уже не посылает запрос на получение кадра, а вместо этого единожды «подписывается» на получение потока кадров. Чтобы пояснить, как происходит регуляция скорости в этом случае, рассмотрим одну из особенностей работы TCP/IP (рис 2).
Рис.2 Передача данных от сервера клиенту. TX, RX – буферы передачи и чтения соответственно.
С точки зрения программной реализации видеосервера процесс передачи данных по сети выглядит как запись этих данных в соответствующий сокет (дескриптор соединения). При этом данные помещаются в буфер передачи, расположенный на сервере, и, далее, средствами протокола перемещаются в буфер приема, находящийся на клиенте. Программа клиента получает данные в процессе чтения из буфера приема. Если программа клиента будет читать из буфера приема медленнее, чем сервер будет записывать данные в свой буфер передачи, буфер приема заполнится, вслед за этим заполнится буфер передачи, и попытка записи в него новых данных будет приводить к ошибке. Таким образом, уменьшение скорости чтения клиентом из буфера чтения приводит к уменьшению скорости передачи новых кадров сервером и наоборот, увеличение скорости чтения ведет к увеличению скорости передачи.
Основная трудность при реализации этого метода заключается в ограничении скорости чтения из буфера клиента. Рассмотрим упрощенную схему архитектуры программы-клиента (рис.3).
Рис.3 Архитектура программы-клиента. Просмотр видео с одной камеры. Два потока: чтения из буфера (TCP-клиент) и декомпрессии (Декомпрессор).
Для обработки видео с одной камеры мы запускаем два потока, выполняющихся параллельно: TCP-клиент и декомпрессор. TCP-клиент ведет чтение данных из буфера, группировку их в кадры и передачу кадров декомпрессору. Декомпрессор осуществляет декомпрессию кадров и вывод их на экран. Для обработки видео с двух и более камер запускается по одному потоку декомпрессии на каждую из камер и общий поток чтения данных из всех сокетов соединений. Когда какой-либо поток декомпрессии не успевает обрабатывать все поставляемые ему кадры, поток чтения должен приостановить чтение из соответствующего сокета. Чтение можно приостановить после получения какой-то части следующего кадра, или по окончании приема кадра, передаваемого декомпрессору. В первом случае, при возобновлении чтения нам придется вычитать остатки возможно уже устаревшего кадра (при высокой скорости захвата кадров на сервере и низкой скорости обработки кадров на клиенте). Во втором случае, кадр, полученный нами после возобновления чтения, также будет устаревшим, так как сервер по событию окончания передачи одного кадра автоматически начнет передачу следующего. В том и другом случае будет возникать задержка между событием и его отображением. Кроме того, вследствие неравномерности распределения вычислительных ресурсов компьютера-клиента между процессами, при высокой нагрузке на процессор скорость обработки кадров декомпрессором меняется в широких пределах, что приводит к «рывкам» выводимого на экран видеопотока.
2.3 РЕГУЛИРОВАНИЕ КЛИЕНТОМ ИНТЕРВАЛА МЕЖДУ КАДРАМИ, ОТПРАВЛЯЕМЫМИ СЕРВЕРОМ
Для того чтобы усреднить время задержки и по возможности уменьшить его, к механизму неявного регулирования клиентом скорости передачи с видеосервера, мы добавили возможность явного регулирования клиентом интервала между кадрами, отправляемыми сервером. В зависимости от суммарной нагрузки на процессор и от скоростей обработки кадров декомпрессорами клиент указывает серверу максимальную скорость передачи RS(в кадрах/c) для каждой из камер. Например, если сервер захватывает с какой-нибудь камеры RG кадров/c, но клиент, в силу недостаточности своих вычислительных ресурсов, может отобразить только RD кадров/с (RD<RG), серверу следует прореживать (по команде клиента) кадры, записываемые в сокет соединения этого клиента до RS кадров/c(RS<RG), вне зависимости от скорости чтения данных клиентом.
Предлагается следующий метод определения клиентом величины RS. Мы считаем, что RS должна указываться серверу в зависимости от скорости приема кадров TCP-клиентом (RC), скорости обработки кадров декомпрессором (RD) и средней суммарной загрузки процессора (L). Регулирование производится дискретно, с интервалом T, при этом новое значение RSопределяется исходя из значения RS, вычисленного на предыдущем шаге и текущей нагрузки процессора.
RS i = f (RS i-1 , RC i-1 , RD i-1 , Li)
Изменение RS в зависимости от нагрузки процессора определяется величиной RE:
Здесь LMAX – максимально допустимая нагрузка процессора, D -величина, задающая возможное отклонение нагрузки от максимальной, C – параметр, определяющий в конечном счете скорость изменения RS в зависимости от L. В случае, когда несколько потоков декомпрессии осуществляют регулирование, для обеспечения плавности изменения нагрузки C должна быть обратно пропорциональна числу таких потоков.
Далее, в зависимости от скорости обработки кадров декомпрессором выделяются два случая.
1) Декомпрессор успевает обрабатывать все кадры, принимаемые TCP-клиентом (RDi-1 = RCi-1).
При этом возможно, что какую-то часть времени декомпрессор простаивает в ожидании нового кадра от TCP-клиента, а следовательно можно увеличить RS.
Увеличение RS в зависимости от скорости работы декомпрессора определяется величиной RA:
– сумма интервалов времени (в пределах T), в течение которых декомпрессор простаивал в ожидании следующего кадра.
Если декомпрессор, по окончании обработки предыдущего кадра всегда имел на входе следующий кадр, RA = RDi-1.
В конечном счете, RS = max ( min(RA,RE,RMAX), RMIN )
Условие минимума предотвращает рост RS более RMAX, при нагрузке на процессор меньше допустимой включает регулирование в зависимости от возможностей декомпрессора (RA), в остальных случаях изменение RS задается величиной Li. Условие максимума предотвращает снижение Rs до нуля, которое может произойти если Li будет постоянно больше 
(такое возможно при заниженном значении LMAX или малой вычислительной мощности процессора).
2) Декомпрессор не успевает обработать все кадры, поставляемые ему TCP-клиентом (RD i-1<RС i-1).
В этом случае необходимо снизить RS до возможностей декомпрессора, или, при высокой нагрузке на процессор, еще ниже.
RS = max ( min(RE, RD i-1), RMIN)
После определения RS вычисляется величина интервала между отправляемыми сервером кадрами: TS =1/ RS. Сервер, получив от клиента значение TS, начинает прореживать отправляемые клиенту кадры таким образом, чтобы разница между временами их создания превышала TS.
ЗАКЛЮЧЕНИЕ
Описанные выше способы регулирования скорости передачи видео по TCP/IP реализованы в системе видеонаблюдения "PANDORA" (ЗАО НПО "Лаби"). Проведенные испытания и опытная эксплуатация показали, что система экономно и предсказуемо использует ресурсы ЛВС, обеспечивая выполнение задач видеонаблюдения с надлежащим качеством.
СПИСОК ЛИТЕРАТУРЫ
- Kim 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.
- Джамса К., Коуп К. Программирование для INTERNET в среде Windows. СПб., 1996.
Об авторе: Сергей Новиков , ведущий программист ЗАО НПО «Лаби», г. Пермь, e-mail info@labi.ru
Источник: сайт ЗАО НПО "Лаби"
