Kwert-soft.ru

IT Софт для ПК
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Передача видео по ip

Как транслировать (передавать) видео и музыку в сеть — делаем собственное вещание в локалку и интернет

Доброго дня!

Если у вас есть какая-нибудь камера или ТВ-тюнер, и вы хотите сделать свою трансляцию в локальной сети (или в интернет) — то эта заметка для вас.

Впрочем, никто не мешает с таким же успехом вещать и просто какие-нибудь фильмы/музыку, например, с ПК на ТВ или мобильные гаджеты.

Единственное, учитывайте, что ваш компьютер (который транслирует) должен быть достаточно производительным (чтобы избежать лагов и подвисаний). К тому же, нужно иметь хорошее и стабильное подключение к сети (не ниже 10 Мбит/с). В помощь: тест скорости интернета.

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

Ладно, ближе к теме.

Трансляция видео в сеть: пример настройки вещания

Запуск трансляции

ШАГ 1

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

VLC

Основные преимущества проигрывателя:

  1. «всеядность»: воспроизводит файлы, внешние диски, сетевые трансляции и т.д.;
  2. поддерживает все популярные форматы файлов: MPEG-2, MPEG-4, H.264, MKV, WebM, WMV, MP3 (даже, если у вас не установлены кодеки в системе);
  3. работает на Windows, Android, Linux, Mac OS X, iOS;
  4. программа бесплатна (и без рекламных вставок).

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

ШАГ 2

Теперь необходимо запустить VLC на том компьютере (устройстве), с которого будем вести трансляцию.

После перейти в меню «Медиа/Передать» (Ctrl+S). См. скриншот ниже.

ШАГ 3

Далее нужно выбрать, что мы будем транслировать:

  • файл;
  • диск;
  • ТВ-тюнер, камеру или др. устройства захвата.

В своем примере я просто добавил один из фильмов.

ШАГ 4

Затем нужно уточнить источник вещание: при выборе обычного файла (как в моем случае) можно сразу же нажать далее (т.е. следующий) .

ШАГ 5

Нужно выбрать в списке «HTTP» и нажать на кнопку «Добавить» . У вас появится вкладка с одноименным названием, в которой можно указать порт и путь трансляции (по умолчанию порт 8080). Рекомендую не менять эти значения и перейти к дальнейшей настройке.

Вывод потока (порт)

ШАГ 6

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

ШАГ 7

Здесь можно задать доп. параметры вещания. В большинстве случаев можно сразу же нажать «Поток» .

ШАГ 8

При первом запуске трансляции брандмауэр Windows попросит вас дать разрешение на работу VLC — просто согласитесь, нажав на «Разрешить доступ» .

ШАГ 9

Если трансляция запустилась вы увидите тикающий таймер времени (см. нижнюю часть окна программы). То есть с этого момента — вещание можно принять на другое устройство и посмотреть «что-там. «.

Как смотреть трансляцию

По локальной сети

Т.е. и компьютер (который вещает), и устройство (которое принимает трансляцию) находится в одной общей локальной сети. В своем примере ниже: трансляция ведется с ПК, а принимается на телефон под андроидом. Оба устройства подключены к одной Wi-Fi сети.

ШАГ 1

Для начала нам нужно узнать локальный IP-адрес компьютера, который ведет трансляцию. Сделать это можно через командную строку: введя в ней ipconfig и нажав Enter.

См. ниже скриншот — мой IP 192.168.0.106 (это нужно для дальнейшего подключения).

ipconfig / Командная строка

Кстати, узнать IP-адреса также можно в настройках роутера.

IP-адрес в настройках роутера

ШАГ 2

Теперь запускаем VLC на том устройстве, с которого будем принимать трансляцию (например, телефон). Далее переходим в меню программы и выбираем «Поток» (или «открыть URL-адрес трансляции») .

ШАГ 3

Далее нужно указать сетевой адрес — http://192.168.0.106:8080

Важно!

1) Вместо 192.168.0.106 — у вас будет свой IP-адрес того компьютера, который ведет трансляцию (например, 192.168.10.102 или 192.168.0.103). Мы этот IP-адрес узнавали в ШАГЕ 1.

2) Вместо порта 8080 может использоваться другой (если при создании трансляции вы изменили его).

ШАГ 4

Если вы все указали правильно, то через 3-5 сек. устройство «прогрузит» кэш и VLC начнет показывать вещание.

Разумеется, к одной трансляции можно одновременно подключить несколько устройств.

По интернету

ШАГ 1

Всё отличие здесь будет сводится к тому, что нам нужно узнать не локальный IP-адрес (который «дал» нам роутер), а внешний/глобальный (у того ПК, который ведет трансляцию) . Сделать это можно по-разному, ссылку на инструкцию привожу ниже.

Например, мне импонирует утилита Speccy — достаточно открыть раздел Network и вы знаете и локальный IP, и внешний.

Speccy — просмотр IP-адресов, раздел Network

Разумеется, подобную информацию также можно узнать в настройках роутера. Скрин ниже в качестве примера.

ШАГ 2

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

Делается это обычно в настройках роутера в разделе «Перенаправление портов» (Port Forwarding). Вообще, у меня на блоге есть подробная заметка на эту тему (для начинающих), ссылка ниже.

В помощь! Как пробросить порты на роутере (открываем порты для игр, Skype, uTorrent и др. приложений) — https://ocomp.info/kak-probrosit-portyi-na-routere.html

ШАГ 3

Теперь запускаем VLC на том устройстве, где будем принимать трансляцию и открываем сетевой адрес вида: http://89.118.10.32:8080

Важно!

Вместо 89.118.10.32 — у вас будет свой внешний IP-адрес (который мы уточняли в ШАГЕ 1, см. чуть выше).

Вводим глобальный IP

ШАГ 4

Если вышеприведенные настройки были корректно заданы — то через несколько секунд начнется показ трансляции (см. скрин ниже). Задача выполнена?!

Передача видео по 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 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.

Передача аудио- и видеосигналов по IP: что это дает proAV?

Сигналы могут транслироваться и приниматься где угодно. «Источником может быть что угодно и их может быть сколько угодно: персональные компьютеры, видеокамеры, мультимедиа-проигрыватели, спутники, блок кабельного телевидения и т.д. — объясняет Самуэль Ресин (Samuel Recine) директор по продажам компании Matrox Graphics в Америке и Тихоокеанском регионе. — Приемником сигнала также может быть что угодно и их может быть сколько угодно: ресивер, подключенный напрямую к телевизору в зале для совещаний или в общественном месте, контроллер видеостены в центре мониторинга, ноутбук или персональный компьютер, декодирующий и отображающий принимаемые сигналы, или даже мобильные устройства с ПО, поддерживающим возможность декодирования и отображения получаемой информаци (смартфоны или планшеты, например)».

«Прелесть использования IP состоит в том, что эта технология позволяет добиться желаемого множеством разных способов, — говорит Пол Харрис (Paul Harris), генеральный директор компании Aurora Multimedia. — IP работает со стандартной инфраструктурой, но до недавнего времени методы передачи информации через эту инфраструктуру не могли удовлетворить всех потребностей наших клиентов». Однако теперь стало возможно определить допустимое качество изображения, пропускную способность и период ожидания. «Для работы в сети с низкой пропускной способностью можно использовать формат H.265, правда, при этом будет более долгий период ожидания, а высокая степень сжатия пагубно скажется на качестве изображения. Если же вы работаете с сетью с более высокой пропускной способностью, то и время ожидания меньше, и есть возможность использовать более качественные варианты сжатия — JPEG 2000, TICO, некоторое другие, позволяющие передавать изображение более высокого качества в более короткие сроки. Когда пропускная способность не имеет значения, и очень важно отсутствие задержки и сжатия (трансляции, видеоконференции, и тд.), передача данных вполне осуществима по сети 10G».

Дело не только в кабелях. Вам все еще приходится искать технологии, использующие CatX кабели для передачи аудио и видео информации через надлежащее оборудование и/или протокол (например, HDBaseT). У них есть свои ограничения, в то время как передача аудио- и видеосигналов по IP-сетям «не имеет ограничений в области одновременной передачи данных на множество адресов через беспроводную сеть, сеть Интернет, LAN, WAN и так далее», — подчеркивает Ресин.

При использовании стандартных IP-сред и стандартных протоколов передачи данных по IP, аудиовизуальная информация передается так же свободно, как и компьютерные данные — с теми же средствами управления, разрешениями для потокового доступа и протоколами безопасности. Но Ресин замечает, что «многие поставщики, используя среды передачи данных по протоколу IP, применяют некоторую форму сжатия для более эффективного использования сетей при передаче информации. Это позволяет передавать аудиовизуальную информации по беспроводной сети через Wi-Fi роутер на устройства типа смартфонов и планшетов».

Если вы не привязаны к сжатию и не хотите зависеть от ограничивающей пропускной способности выделенного сигнала, то решения в области передачи аудиовизуальной информации через IP, позволяющие передавать даже Full HD видео с минимальной задержкой, придутся вам по душе. «В отличие от традиционных методов, передача данных через IP позволяет динамично отправлять контент в реальном времени, привлекая покупателей своей ценой и сравнительно несложным процессом», — заявил Крис Банди (Chris Bundy), менеджер по продажам компании Core Brands, добавив, что подобное развитие событий позволяет смотреть в будущее с определенной долей уверенности. «IP является оптимальным решением для передачи сигналов в коммерческой среде и именно в этом направлении движется сфера AV-технологий».

Все зависит от того, согласны вы мириться с сжатием или нет. Вы можете использовать предназначенные для передачи видеоданных инфраструктуры типа HDBaseT или HDMI, которые разработаны специально для работы в сетях с высокой пропускной способностью и позволяют не сжимать видео. Или вы можете воспользоваться возможностью передавать аудиовизуальную информацию через IP — с меньшей задержкой. Но в этом случае, замечает Роб Картер (Rob Carter), менеджер технологического процесса производства цифровых средств коммуникации компании Crestron, «ясное понимание того, какие технологии сжатия можно использовать, а также знание их недостатков будут ключевыми факторами эффективной работы». Основными технологиями сжатия, используемыми в сфере AV, являются H.264 и JPEG 2000. При использовании каждой из этих технологий можно добиться высокого качества изображения, но H.264 лучше оптимизирован в плане пропускной способности, а JPEG 2000 — в плане задержки (т.е. периода задержки при обработке).

Низкая пропускная способность кодека H.264 позволяет без каких-либо сложностей передавать видео в этом стандарте через большинство сетевых сред. Также не стоит забывать про передачу сразу большого количества потоков через каждое соединение и возможность взаимодействия с корпоративной сетью. К примеру, многие видео, размещенные в сети интернет, сжаты именно при помощи H.264. Этот стандарт также достаточно часто используется в камерах, передающих потоковое видео, в мобильных устройствах, и proAV решения, в основе которых лежит H.264, могут весьма успешно взаимодействовать с упомянутыми девайсами. Проблема заключается в задержке, из-за которой передача видеопотока может запаздывать на доли секунды. Все это делает стандарт H.264 достаточно эффективным при передаче большого объема данных на дальние расстояния и между помещениями, но неподходящим для использования в локальных условиях, когда даже подтормаживание мыши или клавиатуры может разозлить.

Решения на базе стандарта JPEG 2000 применяются в сетях с высокой пропускной способностью, например, канала Ethernet, пропускная способность которого 1 гигабит. Для корректного функционирования данного стандарта требуются кабели, специально предназначенные для этой сети, подобные тем, что используются при работе с HDMI и HDBaseT. Выгодным отличием JPEG 2000 является меньшая по сравнению с H.264 задержка, однако степень ее все равно выше, чем у решений, не использующих сжатия, поэтому при работе с данным стандартом следует уделить особое внимание обеспечению положительного пользовательского опыта при использовании в локальных условиях.

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

Говоря об аудио, необходимо давать точные определения. «Между понятиями «передача аудио через IP» (AoIP)» и «передача аудио через сеть Ethernet» (AoE)» существует весьма значительная разница, но зачастую люди употребляют их как синонимы», — говорит Аманда Ро (Amanda Roe), менеджер по исследованиям и связям с общественностью компании Biamp, и достаточно точно раскрывает основные различия данных понятий. Технология AoIP позволяет передавать сжатую аудиоинформацию по сети Интернет, и она достаточно часто используется вещательными компаниями и сервисами типа Spotify и Pandora. Она не слишком практична для применения в сфере proAV, поскольку в ней используются специализированные кодеки для сжатия данных, значительно увеличивающих время задержки из-за большого количества транзитных шлюзов. AoE — это технология передачи несжатой аудио информации по сети Ethernet. И с задержкой тут никаких проблем, так как данная технология преимущественно применяется в сетях LAN. Приятный плюс технологии AoE: «поскольку аудиосигналы передаются так же, как и любой другой сетевой трафик, они не чувствительны к воздействию кабелей питания или других высокочастотных кабелей, — добавляет Аманда Ро. — Без установки специальных кабелей и оборудования эти сигналы можно посылать в любую часть здания — всюду, где есть данная сеть».

При наличии стольких возможностей, какие вопросы следует задать перед переходом на данную технологию? «Прежде чем выбрать продукт, следует определиться с масштабом, возможностями и ожиданиями заказчика, — говорит Джо да Сильва (Joe da Silva), начальник отдела продаж продукции компании Extron. — Знание этих деталей поможет реселлерам и консультантам выбрать продукт, исходя из поставленной задачи: будет ли он использоваться в одном, в нескольких помещениях, или по всему предприятию. Знание требований к пропускной способности, качеству изображения и допустимому уровню задержки поможет определить, какой продукт или серию продуктов следует выбрать для достижения желаемых результатов».

Перейдем к практическим вопросам. Эрик Индресовд (Erik Indresovde), начальник отдела по AV продуктам компании Black Box составил список вопросов, которыми следует руководствоваться при выборе оборудования. Как осуществляется работа и управление системой? Поддерживается ли возможность дистанционного управления? Проста ли система в установке? Понадобится ли помощь специалистов для ее настройки? Система предназначена для использования в локальной сети или осуществляет передачу видео через Интернет? Каков уровень задержки? Замечу ли я разницу между этой и традиционной системой прямого подключения? Поддерживает ли продукт разрешение 4K? Какие типы периферийного подключения поддерживаются (н-р, HDMI, аналоговое аудио, RS-232, USB)? Поддерживает ли система подключение к видеостене?

Теперь вы готовы к будущему. «Интернет это не пейджер — он никуда не пропадет, — заметил Марк Армон (Mark Armon), менеджер по продукции, компании tvONE. — Все больше и больше пользователей становятся специалистами в определенных аспектах IT-технологий, ожидая от AV-оборудования таких вещей как оперативная совместимость, возможность совместной работы и немедленный доступ к данным. Предложение «переместиться в специальный зал для проведения совещания» начинает терять свою актуальность. Почему мы не можем провести совещание прямо здесь? Почему я не могу поделиться изображением с моего экрана? Почему я не могу подключиться? AV-продукция неотступно следует за развитием IT технологий. Несомненно, на данный момент между тем, что предлагают сетевые технологии и тем, что нужно сфере AV, существует пробел. Но это только пока. Через 10 лет «поколение смартфонов» сможет добиться такой высокой степени сетевого взаимодействия, что сейчас это трудно себе представить, но это неизбежно случится».

Передача видео по 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 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.

Ссылка на основную публикацию
Adblock
detector