Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

23.04.2017

Google
WWW CITForum.ru
С Новым годом!
2003 г

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

Сергей Новиков
18.09.2003
Открытые системы, #09/2003

Одно из основных требований, предъявляемых к современным цифровым системам видеонаблюдения, — возможность передачи изображений по сети. В этой связи представляет интерес организация передачи видеопотоков в реальном времени по распределенной сети с использованием протокола 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<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 вычисляется величина интервала между отправляемыми сервером кадрами: 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.

Сергей Новиков (info@labi.ru) — ведущий программист НПО «Лаби» (Пермь).

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...