Передать видео по ethernet
У любого пользователя может возникнуть задача передать видео от передатчик до приемника. Например, нужно передать видео с выхода камеры наблюдения на экран телевизора или передать видео с видео выхода компьютера на информационную панель. Если приемник находится на расстоянии больше 20 метров от передатчика, то даже при использовании фирменных кабелей передать видео не получится. В этом случае пользователю приходится использовать дополнительные устройства — устройства для передачи сигнала по витой паре. Все устройства применяемые для передачи видео по витой паре можно разделить на две группы :
1. устройства для передачи видео по витой паре
2.устройства для передачи видео в сети Ethernet
Устройства из первой группы могут передавать видео по витой паре, но они не будут работать если вы подключите их в вашу локальную сеть Ethernet, в худшем случае можно даже сломать коммутатор к которому будет подключено такое устройство. Однако устройства из первой группы обладают и преимуществом — меньшая задержка при передачи видео сигнала от передатчика к приемнику. Но фактически это единственное преимущество перед передатчиками из второй группы.
Передатчик из второй группы (кодер ITMS) обладает следующими характеристиками и возможностями:
- передача видео на большие расстояния в локальной сети — до 300м
- передача видео через Интернет
- передача видео по WIFI
- передача видео на неограниченное кол-во устройств одновременно в сети Ethernet ( поддержка мультикаст трансляции)
Описание работы системы передатчик( кодер ITMS) и премник ( Amino Aminet Image Encoder) поддерживающих стандарт Ethernet дано ниже.
Для передачи видео и аудио сигналов в локальной сети Ethernet или в сети Internet нужно всего три компонента:
- передатчик видео сигнала — устанавливается в точке приема видео и аудио сигналов
- услуги транспортной сети провайдера
- приемник видео сигнала— декодирующее оборудование в месте получения видео и аудио сигналов
Передатчик — оборудование, кодирующее видео сигнал, представляет собой аппаратный IP кодер/encoder, который осуществляет захват и кодирование аудио/видео сигналов и их трансляцию в виде H264 потока через сеть TCP/IP.
В качестве приемника видео сигнала можно использовать:
- ТВ приставку STB Amino Aminet Image Encoder . В зависимости от модели, у приставки могут быть разные видеовыходы: HDMI, композитный, компонентный, аудио выход.
- Компьютер с установленным ПО, например, VLC
Различие при передачи видео сигнала в Интернет и в Ethernet.
Сеть Интернет. При передачи сигнала в сети Интернет нужно учитывать следующие требования и возможности сети Интернет:
Сеть Ethernet. При передачи сигнала в сети Ethernet нужно учитывать следующие требования и возможности сети Ethernet:
При передачи видео в сети Интернет или Ethernet нужно учитывать что IP поток формируемый передатчиком будет занимать определенную часть пропускной возможности сети. В общем случае поток формируемый передатчиком зависит от разрешения передаваемого видео, однако некоторые некачественные передатчики формируют большой поток даже при передачи видео в низком разрешении.
Возможные области применения:
- передача видео при проведении конференций и собраний
- передача видео из театра и концертного зала
- передача видео из операционной или больницы
- передача видео внутри города от одного оператора кабельного телевидения к другому
- передача видео от студии до телепередающей станции
- передача видео из аудитории института
Трансляция видео в сеть: пример настройки вещания
Запуск трансляции
ШАГ 1
И так, для нашей задачи понадобится универсальный кросс-платформенный плеер VLC. Программа позволяет не только смотреть потоковое видео в сети, но и создавать трансляцию самостоятельно.
VLC
Основные преимущества проигрывателя:
- "всеядность": воспроизводит файлы, внешние диски, сетевые трансляции и т.д.;
- поддерживает все популярные форматы файлов: MPEG-2, MPEG-4, H.264, MKV, WebM, WMV, MP3 (даже, если у вас не установлены кодеки в системе);
- работает на Windows, Android, Linux, Mac OS X, iOS;
- программа бесплатна (и без рекламных вставок).
Примечание : очень желательно установить данный проигрыватель и на то устройство, с которого вы будете вещать, и на то - на котором будете принимать трансляцию. В своем примере ниже я так и сделал.
ШАГ 2
Теперь необходимо запустить VLC на том компьютере (устройстве), с которого будем вести трансляцию.
После перейти в меню "Медиа/Передать" (Ctrl+S). См. скриншот ниже.
ШАГ 3
Далее нужно выбрать, что мы будем транслировать:
- файл;
- диск;
- ТВ-тюнер, камеру или др. устройства захвата.
В своем примере я просто добавил один из фильмов.
ШАГ 4
Затем нужно уточнить источник вещание: при выборе обычного файла (как в моем случае) можно сразу же нажать далее (т.е. следующий) .
ШАГ 5
Нужно выбрать в списке "HTTP" и нажать на кнопку "Добавить" . У вас появится вкладка с одноименным названием, в которой можно указать порт и путь трансляции (по умолчанию порт 8080). Рекомендую не менять эти значения и перейти к дальнейшей настройке.
Вывод потока (порт)
ШАГ 6
В этом шаге нужно выбрать качество трансляции (подбирается экспериментально, в зависимости от ваших нужд). Например, я транслирую видео с ПК на телефон — поэтому выбрал видео для андроида ( прим. : на экране телефона почти незаметна разница между оригиналом и сжатым видео) .
ШАГ 7
Здесь можно задать доп. параметры вещания. В большинстве случаев можно сразу же нажать "Поток" .
ШАГ 8
При первом запуске трансляции брандмауэр Windows попросит вас дать разрешение на работу VLC — просто согласитесь, нажав на "Разрешить доступ" .
ШАГ 9
Если трансляция запустилась вы увидите тикающий таймер времени (см. нижнюю часть окна программы). То есть с этого момента - вещание можно принять на другое устройство и посмотреть "что-там. ". 👌
Возможности расширения системы
Для каждой из представленных групп оборудования, в случае необходимости внесения изменения в схему подключения, придется осуществить ряд действий, т.е. установить новое оборудование, заменить уже существующее и/или провести настройку существующей сети и оборудования.
Например, если нужно установить дополнительный приемник, то
- Для устройств передающих видео по витой паре понадобится проложить дополнительную витую пару до передатчика, заменить передатчик на новый с 2 выходами для передачи видео и установить новый приемник видео и настроить уровень сигнала во 2й точке приема видео.
- Для устройств передающих видео в локальной сети (например кодер ITMS — приставка) понадобится установить новый приемник( приставку) и протянуть витую пару от приемника до ближайшего коммутатора подключенного к локальной сети.
- Если передатчик приемник соединены с помощью кабеля HDMI, то понадобится установить делитель HDMI сигнала и протянуть новый HDMI кабель от делителя до нового приемника.
Если нужно перенести приемник в другое место, то
- Для устройств передающих видео по витой паре понадобится проложить новую или переложить старую витую пару до передатчика, настроить уровень сигнала если была проложена новая витая пара.
- Для устройств передающих видео в локальной сети (например кодер ITMS — приставка) понадобиться только проложить витую пару от нового места установки приемника до ближайшего коммутатора подключенного к локальной сети
- Если передатчик приемник соединены с помощью кабеля HDMI, то понадобится переложить HDMI кабель.
Если нужно подключить приемник к другому передатчику, то
Речь в сегодняшней заметке пойдет о принципиально новой технологии передачи профессионального цифрового AV — “Audio Video Bridging”.
В настоящее время все остальные технологии (CobraNET, EtherSound и др. ) являются проприетарными (читать- платными) или вообще связанными с Ethernet очень отдаленно.
AVB – это семейство протоколов разрабатываемых IEEE (тем же институтом что и стандартизовал сам Ethernet), т.е. не требующих никаких авторских отчислений.
Для тех кому лень читать, можно просто просмотреть презентацию, тем кому интересны детали и комментарии прошу под кат.
В современном мире ProAV до сих пор преобладают аналоговые подключения. Которые в свою очередь могут передать один поток по одному кабелю.
Такой подход приводит к тому что кабельная инфраструктура становиться избыточной и очень дорогостоящей, как на этапе инсталляции, так и в дальнейшем обслуживании.
А существующие проприетарные решения цифровизации (CobraNET, EtherSound и др.), не позволяют решить проблему кардинально (масштабирование, совместимость, …).
Но интерес рождает спрос, и такие гиганты ИТ индустрии как Broadcom, Cisco, Harman, Intel, Xilinx основали AVNU Alliance, в который уже сейчас входит 50 компаний.
Эта некоммерческая организация занимается развитием, продвижением, сертификацией на совместимость продуктов AVB.
Так как стандартизацией занимается IEEE 802.1, то неудивительно что принцип работы AVB, и DCB (Data Center Bridging) очень похож (разрабатывают соседние команды одной рабочей группы).
Семейство протоколов AVB включает в себя:
1. 802.1AS (Timing and Synchronization (gPTP) — Позволяет синхронизировать потоки с точностью до 0,5 мкс в пределах 7 хопов. Идея работы протокола взята из стандарта IEEE 1588v2
Для работы данного протокола необходима аппартная поддержка, так как на порту должны проставляться “time-stamp”,
Поэтому оборудование некоторых производителей использующих собственные ASICs не будут поддерживать AVBдаже после обновления софта.
2. 802.1Qav (Traffic Shaping) — Профилирование трафика, позволяет обеспечить работу в пределах максимальной задержки для пакетов “class А” (профи системы), и “class B” (пользовательские) — 2 и 50 мс соответственно, а также сглаживание трафика для устранения возможных потерь.
3. 802.1Qat (Stream Reservation Protocol (SRP) – Динамическое резервирование до 75 % ресурса линка для передачи потока. Используются два верхних профиля QoS
4. 802.1BA (Audio Video Bridging (AVB) Systems) — Определение устройств AVB и их идентификации в сети (скорость и дуплекс работы линка, поддержка 802.1 AS, вычисление задержки, подтверждение резервации ресурсов)
Остальные протоколы является не менее важными дополнениями для полноценной работы AVB систем
IEEE 1722, 1733 — Протоколы описывающие транспорт для сетей AVB
IEEE 1722.1* — Протокол для обнаружения, контроля, нумерации, устройств работающих по 1722
При этом только последний пока является Draft версией, остальные стандарты приняты.
Целостная система AVB состоит из следующий частей:
• Endpoint – являются по сути “AVB – gateway” которые осуществляют АЦП и ЦАП преобразования с необходимым форматированием, могут быть
a. Talker (микрофон, камера, микшер, …)
b. Listener (колонки, монитор, пульт, . )
c. Both (микшер, пульт, …)
• AVB Bridge – коммутатор поддерживающий AVB
• Controller – устройство или софт с помощью которого происходит обнаружение всех “Endpoint” и их потоков, отображение их оператору для принятия решения о их коммутации.
Ниже представлена блок-схема включений работающего стенда
Преимуществ от использования систем AVB очень много:
— никакого vendor-lock
— совместное использование AVB, и non-AVB устройств в одной сети
— увеличенная пропускная способность
— гибкое масштабирование
— стандартная СКС
— упрощенная инсталляция и траблшутинг
— использование РоЕ
— а также многое другое
В качестве обратной стороны медали, наверное стоит упомянуть то что для работы AVB-системы все потоки постоянно должны транслироваться в сеть.
Но учитывая низкую стоимость Ethernet транспорта, это не является большой проблемой. Особенно если учесть математику для пропускной способности одного линка:
– Each stereo / AES3 channel stream = ~8 MB / stream
1000 MB * 0.75 / ~8 MB
= ~94 streams (реально 97)
Так как актуальность данной темы не вызывает сомнения, то многие участники AVNU альянса уже выпустили коммерческие образцы AVB продуктов, количество реализованных проектов постоянно растет несмотря на молодость технологии.
Если коснутся сетевой части, то в данный момент на рынке доступны коммутаторы с поддержкой AVB от LABx, BSS/Netgear и Extreme Networks (наиболее полная линейка). Поэтому выбирая коммутаторы Extreme Networks вы инвестируете в будущее сети своей компании!
Решение задачи онлайн-вещания с IP-камеры, вообще говоря, не требует применения WebRTC. Камера сама является сервером, обладает IP-адресом и может быть подключена напрямую к маршрутизатору с целью раздачи видео-контента. Так зачем же применять технологию WebRTC?
На это есть как минимум две причины:
1. По мере увеличения числа зрителей Ethernet-трансляции все больше будет ощущаться сперва нехватка толщины канала, а затем и ресурсов самой камеры.
Или же это будет RTSP/RTP и H.264, в этом случае в браузере должен быть установлен плагин видеоплеера, такой как VLC или QuickTime. Такой плагин будет забирать и проигрывать видео, как и сам плеер. Но нам то ведь нужен настоящий браузерный стриминг без установки дополнительных костылей/плагинов.
Для начала поснифаем IP камеру чтобы узнать что именно отправляет этот девайс в сторону браузера. В качестве подопытного будет камера D-Link DCS 7010L:
Подробнее об установке и настройке камеры вы сможете прочесть ниже, а здесь мы просто посмотрим что она использует для видео стриминга. При попадании в админку камеры через web-интерфейс наблюдаем примерно такую картинку (пардоньте за пейзаж):
Здесь видим последовательность TCP фрагментов длиной 1514 байт
Если заглянуть в HTML страницы админки камеры, увидим вот такой интересный код:
RTSP/RTP — это как раз то что нужно для правильного воспроизведения видео. Но будет ли это работать в браузере? — Нет. А вот если установить плагин QuickTime — все будет работать. Но мы-то делаем чисто-браузерный стриминг.
Здесь можно упомянуть еще Flash Player, который может через подходящий сервер типа Wowza получать RTMP поток, сконвертированный из RTSP, RTP, H.264. Но Flash Player, как известно тоже браузерный плагин, хотя несравненно более популярный чем VLC или QuickTime.
В данном случае, мы протестируем тот же RTSP/RTP re-streaming, но в качестве проигрывающего устройства будет использоваться WebRTC-совместимый браузер без всяких дополнительных браузерных плагинов и других костылей. Мы настроим сервер-ретранслятор, который заберет поток у IP-камеры и отдаст его в Интернет произвольному числу пользователей, использующих браузеры с поддержкой WebRTC.
Подключение IP-камеры
Как уже упоминалось выше, для тестирования была выбрана простая IP-камера D-Link DCS-7010L. Ключевым критерием выбора здесь была поддержка устройством протокола RTSP, поскольку именно по нему наш сервер будет забирать видеопоток с камеры.
Камеру подключаем к маршрутизатору идущим в комплекте патч-кордом. После включения питания и подключения к маршрутизатору, камера взяла IP-адрес по DHCP, в нашем случае это был 192.168.1.34 (Если зайти в настройки маршрутизатора, вы увидите, что подключено устройство DCS 7010L — это она и есть). Самое время протестировать камеру.
Открываем указанный IP-адрес в браузере 192.168.1.34, чтобы попасть в веб-интерфейс администратора камеры. По умолчанию пароль отсутствует.
Как видно, в админской панели видео с камеры транслируется исправно. При этом заметны периодические подлагивания. Это мы и будем фиксить с помощью WebRTC.
Настройка камеры
Сначала в настройках камеры мы отключаем аутентификацию – в рамках тестирования будем отдавать поток всем, кто попросит. Для этого в веб-интерфейсе камеры заходим в настройки Setup – Network и выставляем значение опции Authentication в Disable.
Там же проверяем значение порта протокола RTSP, по умолчанию он равен 554. Формат отдаваемого видео определяется используемым профилем. В камере их можно задать до трех штук, мы воспользуемся первым, live1.sdp – по умолчанию он настроен на использование H.264 для видео и G.711 для аудио. Поменять настройки при необходимости можно в разделе Setup – Audio and Video.
Теперь можно проверить работу камеры через RTSP. Открываем VLC Player (можно любой другой, поддерживающий RTSP — QuickTime, Windows Media Player, RealPlayer и др.) и в диалоге Open URL задаем RTSP адрес камеры: rtsp://192.168.1.34/live1.sdp
Что ж, все работает, как и должно. Камера исправно воспроизводит видеопоток в плеере через протокол RTSP.
Кстати, поток воспроизводится достаточно плавно и без артефактов. Ждем того же и от WebRTC.
Установка сервера
Забиваем соответствующие настройки в маршрутизатор…
…и проверяем внешний IP адрес и RTSP порт с помощью telnet:
telnet 178.51.142.223 554
Убедившись, что по данному порту идет ответ, приступаем к установке WebRTC сервера.
За хостинг будет отвечать виртуальный сервер на Centos 64 bit на Amazon EC2.
Чтобы не иметь проблем с производительностью, выбрали m3.medium инстанс с одним VCPU:
Да, да, есть еще Linode и DigitalOcean, но в данном случае захотелось поамазонить.
Забегая вперед, напишу что в панели управления Amazon EC2 нужно добавить несколько правил(пробросить порты), без которых пример не будет работать. Это порты для WebRTC(SRTP, RTCP, ICE) трафика и порты для RTSP/RTP трафика. Если будете пробовать, в правилах Amazon должно быть нечто похожее для входящего трафика:
С DigitalOcean кстати все будет проще, достаточно открыть эти порты на firewall или заглушить последний. По последнему опыту эксплуатации инстансов DO, там пока еще выдают статический IP адрес и не заморачваются с NAT-ами, а значит и проброс портов, как в случае Амазона, не нужен.
В качестве серверного ПО, ретранслирующего RTSP/RTP поток в WebRTC будем использовать WebRTC Media & Broadcasting Server от Flashphoner. Стриминг сервер очень похож на Wowza, которая умеет отдавать RTSP/RTP поток на Flash. Единственное отличие в том, что этот поток будет отдан на WebRTC, а не на Flash. Т.е. между браузером и сервером пройдет честный DTLS, установится SRTP сессия и поток, закодированный в VP8 пойдет зрителю.
Для установки нам потребуется SSH-доступ.
По идее, вместо пункта 10 правильно было бы задать все необходимые порты и правила firewall, но для целей тестирования решили просто отключить брэндмауэр.
Настройка сервера
Напомним, что структура нашей WebRTC трансляции такова:
Установку основных элементов этой диаграммы мы уже произвели, осталось наладить «стрелочки» взаимодействий.
Связь между браузером и WebRTC сервером обеспечивает web-клиент, который есть на гитхабе:. Набор JS, CSS и HTML файлов просто закидывается в /var/www/html на этапе установки (см. выше под спойлером пункт 9).
Взаимодействие браузера и сервера настраивается в конфигурационном XML-файле flashphoner.xml. Туда нужно вписать IP-адрес сервера, чтобы web-клиент смог подключаться к WebRTC серверу по HTML5 Websockets (пункт 9 выше).
Настройка сервера на этом заканчивается, можно проверить его работу:
А так поддержка DDNS выглядит в самом роутере:
Теперь можно приступить к тестированию и оценить результаты.
Тестирование
После открытия ссылки в браузере идет подключение к WebRTC серверу, который отсылает запрос к IP-камере на получение видеопотока. Весь процесс занимает несколько секунд.
В это время устанавливается соединение браузера с сервером по вебсокетам, далее сервер запрашивает IP камеру по RTSP, получает поток H.264 по RTP и транскодирует его в VP8 / SRTP — который в итоге воспроизводит WebRTC- браузер.
Далее после небольшого ожидания, отображается уже знакомая картинка.
В нижней части видео отображается URL видеопотока, который можно скопировать и открыть для просмотра из другого браузера или таба.
Убеждаемся что это действительно WebRTC.
А вот что показывает chrome://webrtc-internals
По показаниям графиков, мы имеем битрейт с IP камеры 1Mbps. Исходящий трафик тоже есть, скорее всего это RTCP и ICE пакеты. RTT до Amazon сервера составляет около 300 миллисекунд.
Теперь заглянем в Wireshark, там отчетливо видно UDP трафик с IP адреса сервера. На картинке ниже пакеты по 1468 байт. Это и есть WebRTC. Точнее SRTP пакеты несущие VP8 видео фреймы, которые мы можем наблюдать на экране браузера. Кроме это проскакивают STUN запросы(самый нижний пакет на картинке) — это WebRTC ICE заботливо проверяет соединение.
Следующий тест — подключение других зрителей. Удалось открыть 10 окон Chrome, и каждое из них показывало картинку. При этом сам Chrome начал немного тупить. При открытии 11-го окна на другом компьютере, воспроизведение оставалось плавным.
Про WebRTC на мобильных устройствах
Как известно, WebRTC поддерживают Chrome и Firefox браузеры на платформе Android.
Проверим, будет ли там отображаться наша трансляция:
На картинке HTC телефон, в Firefox браузере отображается видео с камеры. Отличий в плавности воспроизведения от десктопа нет.
Заключение
В результате нам удалось запустить WebRTC онлайн-трансляцию с IP-камеры на несколько браузеров с минимальными усилиями. Не потребовалось ни плясок с бубном, ни rocket-science – только базовые знания Linux и SSH-консоли.
Качество трансляции было на приемлемом уровне, а задержка воспроизведения была незаметна на глаз.
Подводя итог, можно сказать что браузерные WebRTC трансляции имеют право на существование, т.к. в нашем случае WebRTC это уже не костыль или плагин, а реальная платформа для воспроизведения видео в браузере.
Почему же мы не видим повсеместного внедрения WebRTC?
Главный тормоз, пожалуй, недостаток кодеков. WebRTC сообществу и вендорам следовало бы сделать усилие и ввести в WebRTC кодек H.264. Против VP8 сказать нечего, но зачем отказываться от миллионов совместимых девайсов и ПО, которые работают с H.264? Патенты, такие патенты…
На втором месте, не полная поддержка в браузерах. C IE и Safari, например вопрос остается открытым и там придется переходить на другой тип стриминга или использовать плагин типа webrtc4all.
Так что в будущем, надеемся увидеть более интересные решения, в которых не нужен будет транскодинг и конвертация потоков и большинство браузеров смогут отыгривать потоки с различных устройств уже напрямую.
Уважаемый читатель, приветсвую тебя на просторах хабрахабра, этой уникальной площадки обмена опытом и мнениями. В этой заметке я хочу вернутся к теме беспроводной передачи высококачественного видео и звука без использования проводов, с применением различных технологий. При этом я буду рассматривать аспект беспроводной передачи шире, чем просто сетевое «расшаривание» фильмов и музыки. Необходимым и достаточным условием упоминания той или иной технологии будет возможность передачи экрана рабочего стола и работы любых программ, с поддержкой разрешения, не ниже 1280x720 (HD-ready/720p).
Поскольку с момента моих прошлых публикаций уже прошло довольно большое время (относительно этой, развивающейся взрывными темпами, индустрии), и появилось N-ое количество новшеств, то их описанием и хотелось бы поделиться.
Пару слов перед началом
Как бы это не казалось странным, но технологий передачи HD-видео и звука достаточно большое количество(здесь и далее под HD-видео и звуком подразумевается не просто файлы музыки и кино, но работа программ в реальном времени и высоком разрешении) и все они в текущей заметке не поместятся. А поскольку любому техническому уму, коих большинство на нашем ресурсе, требуется точность и категоричность, то если тема окажется интересной, в конце я подведу итог всех заметок общей табличкой, в которой сведу все беспроводные стандарты и их многочисленные характеристики. Как я уже заметил ранее, мозг читателя хоть и технический, но не резиновый как первопрестольная и, дабы ограничить явление многабукаф (Господи, хотя статья и так получилась огромной! ), начнём мы с самой доступной технологии беспроводной передачи видео и звука — передача по Wi-Fi.
Передача по Wi-Fi
Итак, переда началом рассмотрения конкретных технологий передачи видео и звука поверх Wi-Fi, мы должны понять общие достоинства и недостатки, обусловленные таким использованием Wi-Fi.
Достоинства
- Большинство компьютеров (и не только их) уже оснащено Wi-Fi — не нужен отдельный передатчик, всё, что нужно для трансляции уже имеется;
- Можно использовать не только для беспроводной передачи видео и звука но и для получения доступа к сети;
- Из за широкой распространённости обращает на себя внимание крупнейших участников IT-индустрии, таких как Intel, Apple, Qualcomm, Cavium Networks.
На этом немногочисленные, но значимые достоинства, заканчиваются.
Недостатки
- Беспроводная передача видео и звука забивает/отнимает часть эфира у прямого назначения вайфая — доступа в сеть;
- Работе вашей сети могут мешать окружающие Wi-Fi сети, коих с каждым годом становится всё больше;
- Для того, чтобы HD-видео и звук помещались в полосу пропускания Wi-Fi, требуется «упаковать» их соответствующим кодеком (в большинстве случаев — h.264), что даёт (вообще говоря, несущественную) потерю качества;
- Потребность в сжатии рождает потребность в софте, который может работать на одной, но не работать на другой ОС/платформе;
- Из за потребности в софте будет работать толко на ПК-образном железе — передача от игровых (Xbox360,PS3)/спутниковых(НТВ+)/телевизионных(БилайнТВ, Акадо) приставок отпадает (за некоторым исключением, где свет сошёлся клином и на приставке есть возможность запускать сторонний софт и сам подобный софт под неё написан, вероятность чему — 0,01%, а независимые от компьютера передатчики не очень-то торопятся выпускать);
- Работа кодека по сжатию контента требует аппаратных ресурсов, при том немалых;
- Из за работы кодека передача сигнала задерживается на дельту времени, уходящую на сжатие (от 20мс до 2 секунд, в зависимости от расстояния и мощности сжимающей аппаратуры).
Общие слова сказаны, теперь поехали по конкретным технологиям (отсортированы по доступности):
Это самый простой способ и, наверное, самая распространенная на сегодняшний день технология передачи фильмов и музыки по LAN/Wi-Fi. Многие удивятся: сам же, мол, говорил, что «расшариваемые» технологии с файлами отметаем? — Спокойно, коллеги, сейчас всё объясню.
Сам принцип DLNA заключается в том, что на компьютере запускается серевер, в котором прописана открытая для просмотра папка с кино и музыкой. Сам (умный)ТВ, или некий «околотвшный» посредник, типа SetTop box'а или тюнера или игровой приставки, подключается (под вашим чутким руководством) по Wi-Fi к расшаренной папке и выводит из неё контент на HDTV.
Теперь вопрос для страждущих: как передать по DLNA рабочий стол? Ответ: кэпчурить(capture) экран в реальном времени в файл(например VLC'шкой), который расшарен и открыт телевизором/приставкой по DLNA. Примечание: поскольку сжатие и передача будут настроены «кустарным» способом, ничего хорошего от этого не ждите — 12 секундная задержка, не видно курсора и нет звука (проверено лично и найдено в гугле по запросу «рабочий стол по DLNA»).
Да и вообще, в нашем быстроменяющемся IT-мире содержать сервер на своём ПК и заставлять дополнительными, лишними движениями подключатся к нему устройства-клиенты, совсем не кошерно. Беспроводная передача должна выглядеть так: на компьютере кнопочку нажали — «подключить ТВ», на ТВ картинка появилась. Без муторных настроек и выбора файлов посредством пульта или джойстиков или прочих нехороших.
Итак, главная, выведенная мною и опорная, для беспроводной передачи видео/звука парадигма — передающий должен являтся клиентом к принимающему, но не наоборот!
Достоинства
- Встроен в большинство современной околоТВ'шной техники.
Недостатки
- Низкая производительность при передаче рабочего стола/программ;
- Сложность в настройке из за обмена ролями клиентсервер.
Налицо нарушение выведенной выше парадигмы: для получения видео и звука с вашего компьютера на нём должен быть запущен сервер одного из протоколов удаленного рабочего стола, а около телевизора должен находится клиент (читай — ещё один грёбанный, жрущий электричество ящик), который должен инициировать подключение к вашему компьютеру не без помощи мутных манипуляций (даже если это запуск скрипта беспроводной мышкой/клавиатурой). Да ещё и производительность тут будет от невысокой до очень низкой из за «кустарности» метода.
С другой стороны, это выход для малобюджетных решений, когда у телевизора достаточно поставить только старый компьютер и оптимально его настроить.
Достоинства
- Для работы достаточно любого старого ПК или даже смартфона с выводом на ТВ.
Недостатки
- Те же, что и у DLNA, хотя производительность рабочего стола и выше.
Беспроводные серверы презентаций (wireless presentation gateway)
Интересный класс железок, весьма мало распространенный, однако существующий. Представьте себе такую картину: к Wi-Fi точке доступа, помимо интернета, можно подключить телевизор или монитор с колонками, и с помощью небольшой утилиты выводить картинку и звук с ПК на эти ТВ/монитор/колонки. Это и есть схема работы беспроводного сервера презентации. Грубо говоря, это точка доступа/wi-fi роутер, который помимо интернета предоставляет вашему ПК/смартфону устройство вывода изображения и звука.
В большинстве случаев, когда вы хотите передать через сервер презентаций уже не рабочий стол и программы, а кино и музыку, в передающую утилиту встроен плеер, открывая которым ваши медиафайлы они передаются на точку доступа уже по протоколу DLNA, тоесть в оконном режиме вы кино не посмотрите, только на полный экран. Когда фильм/музыка заканчивается, приложение автоматически переключается обратно, в режим передачи изображения рабочего стола.
В разное время подобные точки доступа выпускали Dlink, Planet, Edimax, ViewSonic и другие, мене известные авторы. Но наилучшего результата по качеству передачи и снижению задержки достигла фирма Awind со своим продуктом McTivia: это небольшая точка доступа 802.11n, имеющая HDMI выход (максимальное разрешение — 1280x720, звук — стерео). Также есть вход ethernet для предоставления общего доступа к сети (кстати, связь утилиты и точки доступа работает и по LAN); а также имеется USB-вход для клавиатуры/мыши, чтобы можно было управлять компьютером, на котором запущена утилита, удаленно. Поскольку протокол передачи заметно оптимизирован по сравнению с предшественниками, удалось убрать DLNA'шную часть и запускать видео и звук напрямую, через любой проигрыватель. При этом у утилиты есть несколько режимов качества: при наименьшем качестве, соответственно, самая низкая задержка — это для презентаций и прочего интерактива; при наивысшем качестве задержка почти секунда, но это для кино, где в хорошем качестве запустили и не трогаете, так что задержка не напрягает.
Удивляет обилие клиентов к McTivia для разных платформ: есть клиенты и для MacOS и для разных версий Windows, и даже клиенты (правда, пока без звука) для iOS и Android. К сожалению Linux, по моему мнению — незаслуженно, обделили.
Самое интересное, что Awind сотрудничает с фирмой mirrorop, которая и пишет софт для смартфонов и коммуникаторов. Так вот mirrorop также пишет софтверные версии серверов презентации для разных платформ: вместо McTivia можно передавать картинку на планшет и смартфон, который также можно подключить к телевизору. Но тут, увы, уже не будет такой производительности, как у железа.
Коллеги сняли русскоязычное видео про McTivia:
Достоинства
- Работает практически на любой платформе, в том числе и на мобильных ОС;
- Оптимизированное качество, приемлемое при среднестатистическом компьютере;
- Софт частично использует GPU для ускорения сжатия;
- Есть возможность управлять удаленным компьтером прямо с точки доступа (USB-клавиатурой/мышью);
- Можно использовать одновременно ещё и как точку доступа для раздачи сети.
Недостатки
- Чем слабее компьютер — тем хуже производительность;
- Видео ограничено разрешением 1280х720, про 3D речи нет, звук — только стерео;
- Довольно большая задержка, могут возникнуть проблемы с играми;
- Необходимо тратить средства на покупку WPG-оборудования.
Intel WiDi
Ител (пока)является ключевым производителем чипов на рынке процессоров для ПК и ноутбуков, и, как любой, уважающий себя индустриальный гигант, имеет ряд своих тузов в рукаве, подсунутых туда огромными research-центрами и исследовательскими лабораториями, которые он содержит по всему миру. Есть неплохая рекламная статейка на хабре про WiDi, которая, кстати, и побудила меня разрадиться сим манифестом.
Вкратце, посколку Intel всё теснее соединяет все компоненты современного компьютера, такие как CPU, GPU и Wi-Fi адаптер, в рамках своей единой платформы, то они могут позволить себе выпускать софт, сильно заточенный под эту платформу, так как она — массова.
WiDi работает только на процессорах Core второго поколения и только с интеловским вай-фай чипом. Сжатию потока для передачи помогает встроенный в кристал процессора графический адаптер.
Для приёма сигнала на телевизоре используется специальная приставка WiDi, качество FullHD 1080p, но пока только 30fps. Звук — многоканальный. Задержка — от 20мс и более (обычно — более). Для соединения с WiDi-приёмником используется специальная технология от Intel, на подобии множественного Wi-Fi p2p, тоесть ваш ПК может быть присоединён к WiDi-адаптеру одновременно вместе с соединением с интернетом через точку доступа.
В качестве альтернативы приёмнику Intel обещает встраивать технологию в современные телевизоры (несколько прототипов, в том числе и от Samsung уже были показаны в начале года). Или же, что ещё более интересно: предлагают как то хитро отправлять/принимать контент по DLNA (в качестве подтверждения на CES2012 показывали PS3 и Xbox360, принимающие сигнал от ноутбука с WiDi). Только не понятно, нужно ли будет устанавливать какой-нибудь софт от Intel на приставку. Скорее всего — да, но это не очень-то проблемно.
Достоинства
- Работает на всех ПК с современной платформой Intel;
- Софт оптимизирован под платформу, активно используется мощь GPU;
- Постоянные обновления, высокое качество сигнала (FullHD+5.1), понижение задержки;
- Появление встроенных в ТВ и Sat/IPTV-приставки приёмников и передача через повсеместный DLNA.
Недостатки
- Только железо от Intel — CPU Core, работает на встроенной видеокарте, нужен Wi-Fi чип Intel;
- Работает только под Windows;
- На мобильной платформе только в стадии прототипа на платформе Intel (Cedar Trail), на ARM отсутствует;
- Пока ещё ощутимая задержка передачи сигнала;
- Пока ещё требуется покупать отдельный приёмник WiDi.
Apple AirPlay
У яблочной компании началось всё давным давно с точки доступа, к которой можно подключить колонки (AirPort Express) и крутить музыку из монструозного iTunes денно-нощно, при том, iTunes из Windows тоже мог слать. Потом это перерасло ещё и в трансляции на AppleTV (вся технология основывалась на DLNA в «яблочной» обёртке, ничего сложного). Потом появились i'гаджеты и технология AirPlay: теперь из встроенного плеера i'гаджетов стало возможно слать как видео так и музыку на AppleTV и только музыку на AirPort Express. Намётанный глаз заметит, что пока это всё ещё смахивает на старый добрый DLNA в яблочной кожице (хотя есть софт от фирмы rogueamoeba, называется — airfoil, который может выводить звук любого приложения в приёмники от Apple, да и самим компьютерам превращаться в AirPlay приёмники).
Но с появлением двухъядерных АйФонов и АйПэдов всё изменилось. Теперь мощности стало достаточно и одно ядро процессора может отвечать за основные задачи, полностью соответствуя характеристикам предыдущего поколения, а второе ядро может сжимать всё, что происходит на экране и в динамиках, и отправлять это на AppleTV. Так что AirPlay вырос до полноценной передачи рабочего стола мобильных устройств на телевизор (правда пока только в разрешении 1280х720, но всё впереди).
А что же с обычными маками? Неужели Apple бросила свои компьютеры в угоду смартфонам и планшетам? Как оказалось — совсем нет, в грядущей обновленной Mac OS — Mountain Lion, выход которой намечен на лето'12, появилась такая долгожданная функция AirPlay, которая глубоко интегрированна в систему и распознаёт телевизор, подключенный к AppleTV, просто как второй экран. С ним можно делать любые настройки, как и с монитором, подключенным по проводу, это очень удобно.
Поговаривают, что в скором времени должна выйти и обновленная версия AppleTV, скорее всего в ней появится возможность принимать не только HD-Ready (720p), но и FullHD(1080p).
Поскольку устройства от Apple нынче достигли невероятного подъёма своей популярности, то огромное число производителей аксессуаров стали встраивать в свои аккустические системы поддержку AirPlay для звука. Скорее всего нечто подобное начнёт скоро происходить и для видео.
Достоинства
- Работает практически на всех современных устройствах от Apple, в том числе и мобильных, и через iTunes на Windows;
- Софт оптимизирован под платформу, активно используются аппаратные особенности;
- Сигнал имеет гарантированне качество и отсутствие градаций: гарант Apple;
- Совершенно точно будет развиваться дальше;
- AirPlay встраивается в множество аксессуаров для Apple-устройств.
Недостатки
- Только железо от Apple, Linux'ы и Android'ы отдыхают;
- Работает только под MacOS/iOS, за исключением DLNA функций через iTunes на Windows (или Airfoil)
- Качество пока только 720p и задержка, всё же имеется, хоть и малозаметная;
- Неизвестно, будет ли возможность встраивать AirPlay приёмники HD-видео и звука в иную технику, кроме существующей AppleTV.
Заключение
Обобщая, все стараются сделать решение встроенным, использующим уже существующую аппаратную платформу и Wi-Fi адаптер, но, как видно, даже самые последние реализации пока не достигли абсоютного HD-качества и очень низкой задержки. Они будут развиваться и улучшаться по мере выхода нового, более мощного оборудования.
Если это будет интересно, то дальше мы поговорим о специализированных стандартах с отдельными передатчиками, по всем параметрам обеспечивающими имитацию HDMI-кабеля.
P.S.: Как ни старался сжать материал ребята, но, как говорится, по другому никак не скажешь. Напишите, стоит ли писать продолжение про другие технологии. Также рад буду ответить на любые вопросы в комментариях.
Доброго дня!
Если у вас есть какая-нибудь камера или ТВ-тюнер, и вы хотите сделать свою трансляцию в локальной сети (или в интернет) — то эта заметка для вас. 👌
Впрочем, никто не мешает с таким же успехом вещать и просто какие-нибудь фильмы/музыку, например, с ПК на ТВ или мобильные гаджеты.
Единственное, учитывайте, что ваш компьютер (который транслирует) должен быть достаточно производительным (чтобы избежать лагов и подвисаний). К тому же, нужно иметь хорошее и стабильное подключение к сети (не ниже 10 Мбит/с). В помощь: тест скорости интернета.
В этой заметке я по шагам рассмотрю все необходимые действия как для вещания по локальной сети, так и по интернету. Разумеется, в вашем случае могут быть небольшие отличия (например, при выборе устройства захвата. ).
Ладно, ближе к теме.
Как смотреть трансляцию
По локальной сети
Примечание!
Т.е. и компьютер (который вещает), и устройство (которое принимает трансляцию) находится в одной общей локальной сети. В своем примере ниже: трансляция ведется с ПК, а принимается на телефон под андроидом. Оба устройства подключены к одной Wi-Fi сети.
ШАГ 1
Для начала нам нужно узнать локальный IP-адрес компьютера, который ведет трансляцию. Сделать это можно через командную строку: введя в ней ipconfig и нажав Enter.
См. ниже скриншот - мой IP 192.168.0.106 (это нужно для дальнейшего подключения).
ipconfig / Командная строка
Кстати, узнать IP-адреса также можно в настройках роутера.
IP-адрес в настройках роутера
ШАГ 2
Теперь запускаем VLC на том устройстве, с которого будем принимать трансляцию (например, телефон). Далее переходим в меню программы и выбираем "Поток" (или "открыть URL-адрес трансляции") .
ШАГ 3
Важно!
1) Вместо 192.168.0.106 - у вас будет свой IP-адрес того компьютера, который ведет трансляцию (например, 192.168.10.102 или 192.168.0.103). Мы этот IP-адрес узнавали в ШАГЕ 1.
2) Вместо порта 8080 может использоваться другой (если при создании трансляции вы изменили его).
VLC для андроид
ШАГ 4
Если вы все указали правильно, то через 3-5 сек. устройство "прогрузит" кэш и VLC начнет показывать вещание.
Разумеется, к одной трансляции можно одновременно подключить несколько устройств.
По интернету
ШАГ 1
Всё отличие здесь будет сводится к тому, что нам нужно узнать не локальный IP-адрес (который "дал" нам роутер), а внешний/глобальный (у того ПК, который ведет трансляцию) . Сделать это можно по-разному, ссылку на инструкцию привожу ниже.
Например, мне импонирует утилита Speccy — достаточно открыть раздел Network и вы знаете и локальный IP, и внешний.
Speccy - просмотр IP-адресов, раздел Network
Разумеется, подобную информацию также можно узнать в настройках роутера. Скрин ниже в качестве примера.
ШАГ 2
Чтобы к вашей трансляции могли подключиться из интернета — необходимо открыть (пробросить) нужный порт (в нашем случае 8080). По умолчанию, в целях безопасности, роутер не позволяет подключаться из вне.
Делается это обычно в настройках роутера в разделе "Перенаправление портов" (Port Forwarding). Вообще, у меня на блоге есть подробная заметка на эту тему (для начинающих), ссылка ниже.
ШАГ 3
Важно!
Вместо 89.118.10.32 - у вас будет свой внешний IP-адрес (который мы уточняли в ШАГЕ 1, см. чуть выше).
Вводим глобальный IP
ШАГ 4
Если вышеприведенные настройки были корректно заданы — то через несколько секунд начнется показ трансляции (см. скрин ниже). Задача выполнена?!
Возможности расширения системы
Для каждой из представленных групп оборудования, в случае необходимости внесения изменения в схему подключения, придется осуществить ряд действий, т.е. установить новое оборудование, заменить уже существующее и/или провести настройку существующей сети и оборудования.
Например, если нужно установить дополнительный приемник, то
- Для устройств передающих видео по витой паре понадобится проложить дополнительную витую пару до передатчика, заменить передатчик на новый с 2 выходами для передачи видео и установить новый приемник видео и настроить уровень сигнала во 2й точке приема видео.
- Для устройств передающих видео в локальной сети (например кодер ITMS — приставка) понадобится установить новый приемник( приставку) и протянуть витую пару от приемника до ближайшего коммутатора подключенного к локальной сети.
- Если передатчик приемник соединены с помощью кабеля HDMI, то понадобится установить делитель HDMI сигнала и протянуть новый HDMI кабель от делителя до нового приемника.
Если нужно перенести приемник в другое место, то
- Для устройств передающих видео по витой паре понадобится проложить новую или переложить старую витую пару до передатчика, настроить уровень сигнала если была проложена новая витая пара.
- Для устройств передающих видео в локальной сети (например кодер ITMS — приставка) понадобиться только проложить витую пару от нового места установки приемника до ближайшего коммутатора подключенного к локальной сети
- Если передатчик приемник соединены с помощью кабеля HDMI, то понадобится переложить HDMI кабель.
Если нужно подключить приемник к другому передатчику, то
Речь в сегодняшней заметке пойдет о принципиально новой технологии передачи профессионального цифрового AV — “Audio Video Bridging”.
В настоящее время все остальные технологии (CobraNET, EtherSound и др. ) являются проприетарными (читать- платными) или вообще связанными с Ethernet очень отдаленно.
AVB – это семейство протоколов разрабатываемых IEEE (тем же институтом что и стандартизовал сам Ethernet), т.е. не требующих никаких авторских отчислений.
Для тех кому лень читать, можно просто просмотреть презентацию, тем кому интересны детали и комментарии прошу под кат.
В современном мире ProAV до сих пор преобладают аналоговые подключения. Которые в свою очередь могут передать один поток по одному кабелю.
Такой подход приводит к тому что кабельная инфраструктура становиться избыточной и очень дорогостоящей, как на этапе инсталляции, так и в дальнейшем обслуживании.
А существующие проприетарные решения цифровизации (CobraNET, EtherSound и др.), не позволяют решить проблему кардинально (масштабирование, совместимость, …).
Но интерес рождает спрос, и такие гиганты ИТ индустрии как Broadcom, Cisco, Harman, Intel, Xilinx основали AVNU Alliance, в который уже сейчас входит 50 компаний.
Эта некоммерческая организация занимается развитием, продвижением, сертификацией на совместимость продуктов AVB.
Так как стандартизацией занимается IEEE 802.1, то неудивительно что принцип работы AVB, и DCB (Data Center Bridging) очень похож (разрабатывают соседние команды одной рабочей группы).
Семейство протоколов AVB включает в себя:
1. 802.1AS (Timing and Synchronization (gPTP) — Позволяет синхронизировать потоки с точностью до 0,5 мкс в пределах 7 хопов. Идея работы протокола взята из стандарта IEEE 1588v2
Для работы данного протокола необходима аппартная поддержка, так как на порту должны проставляться “time-stamp”,
Поэтому оборудование некоторых производителей использующих собственные ASICs не будут поддерживать AVBдаже после обновления софта.
2. 802.1Qav (Traffic Shaping) — Профилирование трафика, позволяет обеспечить работу в пределах максимальной задержки для пакетов “class А” (профи системы), и “class B” (пользовательские) — 2 и 50 мс соответственно, а также сглаживание трафика для устранения возможных потерь.
3. 802.1Qat (Stream Reservation Protocol (SRP) – Динамическое резервирование до 75 % ресурса линка для передачи потока. Используются два верхних профиля QoS
4. 802.1BA (Audio Video Bridging (AVB) Systems) — Определение устройств AVB и их идентификации в сети (скорость и дуплекс работы линка, поддержка 802.1 AS, вычисление задержки, подтверждение резервации ресурсов)
Остальные протоколы является не менее важными дополнениями для полноценной работы AVB систем
IEEE 1722, 1733 — Протоколы описывающие транспорт для сетей AVB
IEEE 1722.1* — Протокол для обнаружения, контроля, нумерации, устройств работающих по 1722
При этом только последний пока является Draft версией, остальные стандарты приняты.
Целостная система AVB состоит из следующий частей:
• Endpoint – являются по сути “AVB – gateway” которые осуществляют АЦП и ЦАП преобразования с необходимым форматированием, могут быть
a. Talker (микрофон, камера, микшер, …)
b. Listener (колонки, монитор, пульт, . )
c. Both (микшер, пульт, …)
• AVB Bridge – коммутатор поддерживающий AVB
• Controller – устройство или софт с помощью которого происходит обнаружение всех “Endpoint” и их потоков, отображение их оператору для принятия решения о их коммутации.
Ниже представлена блок-схема включений работающего стенда
Преимуществ от использования систем AVB очень много:
— никакого vendor-lock
— совместное использование AVB, и non-AVB устройств в одной сети
— увеличенная пропускная способность
— гибкое масштабирование
— стандартная СКС
— упрощенная инсталляция и траблшутинг
— использование РоЕ
— а также многое другое
В качестве обратной стороны медали, наверное стоит упомянуть то что для работы AVB-системы все потоки постоянно должны транслироваться в сеть.
Но учитывая низкую стоимость Ethernet транспорта, это не является большой проблемой. Особенно если учесть математику для пропускной способности одного линка:
– Each stereo / AES3 channel stream = ~8 MB / stream
1000 MB * 0.75 / ~8 MB
= ~94 streams (реально 97)
Так как актуальность данной темы не вызывает сомнения, то многие участники AVNU альянса уже выпустили коммерческие образцы AVB продуктов, количество реализованных проектов постоянно растет несмотря на молодость технологии.
Если коснутся сетевой части, то в данный момент на рынке доступны коммутаторы с поддержкой AVB от LABx, BSS/Netgear и Extreme Networks (наиболее полная линейка). Поэтому выбирая коммутаторы Extreme Networks вы инвестируете в будущее сети своей компании!
Решение задачи онлайн-вещания с IP-камеры, вообще говоря, не требует применения WebRTC. Камера сама является сервером, обладает IP-адресом и может быть подключена напрямую к маршрутизатору с целью раздачи видео-контента. Так зачем же применять технологию WebRTC?
На это есть как минимум две причины:
1. По мере увеличения числа зрителей Ethernet-трансляции все больше будет ощущаться сперва нехватка толщины канала, а затем и ресурсов самой камеры.
Или же это будет RTSP/RTP и H.264, в этом случае в браузере должен быть установлен плагин видеоплеера, такой как VLC или QuickTime. Такой плагин будет забирать и проигрывать видео, как и сам плеер. Но нам то ведь нужен настоящий браузерный стриминг без установки дополнительных костылей/плагинов.
Для начала поснифаем IP камеру чтобы узнать что именно отправляет этот девайс в сторону браузера. В качестве подопытного будет камера D-Link DCS 7010L:
Подробнее об установке и настройке камеры вы сможете прочесть ниже, а здесь мы просто посмотрим что она использует для видео стриминга. При попадании в админку камеры через web-интерфейс наблюдаем примерно такую картинку (пардоньте за пейзаж):
Здесь видим последовательность TCP фрагментов длиной 1514 байт
Если заглянуть в HTML страницы админки камеры, увидим вот такой интересный код:
RTSP/RTP — это как раз то что нужно для правильного воспроизведения видео. Но будет ли это работать в браузере? — Нет. А вот если установить плагин QuickTime — все будет работать. Но мы-то делаем чисто-браузерный стриминг.
Здесь можно упомянуть еще Flash Player, который может через подходящий сервер типа Wowza получать RTMP поток, сконвертированный из RTSP, RTP, H.264. Но Flash Player, как известно тоже браузерный плагин, хотя несравненно более популярный чем VLC или QuickTime.
В данном случае, мы протестируем тот же RTSP/RTP re-streaming, но в качестве проигрывающего устройства будет использоваться WebRTC-совместимый браузер без всяких дополнительных браузерных плагинов и других костылей. Мы настроим сервер-ретранслятор, который заберет поток у IP-камеры и отдаст его в Интернет произвольному числу пользователей, использующих браузеры с поддержкой WebRTC.
Подключение IP-камеры
Как уже упоминалось выше, для тестирования была выбрана простая IP-камера D-Link DCS-7010L. Ключевым критерием выбора здесь была поддержка устройством протокола RTSP, поскольку именно по нему наш сервер будет забирать видеопоток с камеры.
Камеру подключаем к маршрутизатору идущим в комплекте патч-кордом. После включения питания и подключения к маршрутизатору, камера взяла IP-адрес по DHCP, в нашем случае это был 192.168.1.34 (Если зайти в настройки маршрутизатора, вы увидите, что подключено устройство DCS 7010L — это она и есть). Самое время протестировать камеру.
Открываем указанный IP-адрес в браузере 192.168.1.34, чтобы попасть в веб-интерфейс администратора камеры. По умолчанию пароль отсутствует.
Как видно, в админской панели видео с камеры транслируется исправно. При этом заметны периодические подлагивания. Это мы и будем фиксить с помощью WebRTC.
Настройка камеры
Сначала в настройках камеры мы отключаем аутентификацию – в рамках тестирования будем отдавать поток всем, кто попросит. Для этого в веб-интерфейсе камеры заходим в настройки Setup – Network и выставляем значение опции Authentication в Disable.
Там же проверяем значение порта протокола RTSP, по умолчанию он равен 554. Формат отдаваемого видео определяется используемым профилем. В камере их можно задать до трех штук, мы воспользуемся первым, live1.sdp – по умолчанию он настроен на использование H.264 для видео и G.711 для аудио. Поменять настройки при необходимости можно в разделе Setup – Audio and Video.
Теперь можно проверить работу камеры через RTSP. Открываем VLC Player (можно любой другой, поддерживающий RTSP — QuickTime, Windows Media Player, RealPlayer и др.) и в диалоге Open URL задаем RTSP адрес камеры: rtsp://192.168.1.34/live1.sdp
Что ж, все работает, как и должно. Камера исправно воспроизводит видеопоток в плеере через протокол RTSP.
Кстати, поток воспроизводится достаточно плавно и без артефактов. Ждем того же и от WebRTC.
Установка сервера
Забиваем соответствующие настройки в маршрутизатор…
…и проверяем внешний IP адрес и RTSP порт с помощью telnet:
telnet 178.51.142.223 554
Убедившись, что по данному порту идет ответ, приступаем к установке WebRTC сервера.
За хостинг будет отвечать виртуальный сервер на Centos 64 bit на Amazon EC2.
Чтобы не иметь проблем с производительностью, выбрали m3.medium инстанс с одним VCPU:
Да, да, есть еще Linode и DigitalOcean, но в данном случае захотелось поамазонить.
Забегая вперед, напишу что в панели управления Amazon EC2 нужно добавить несколько правил(пробросить порты), без которых пример не будет работать. Это порты для WebRTC(SRTP, RTCP, ICE) трафика и порты для RTSP/RTP трафика. Если будете пробовать, в правилах Amazon должно быть нечто похожее для входящего трафика:
С DigitalOcean кстати все будет проще, достаточно открыть эти порты на firewall или заглушить последний. По последнему опыту эксплуатации инстансов DO, там пока еще выдают статический IP адрес и не заморачваются с NAT-ами, а значит и проброс портов, как в случае Амазона, не нужен.
В качестве серверного ПО, ретранслирующего RTSP/RTP поток в WebRTC будем использовать WebRTC Media & Broadcasting Server от Flashphoner. Стриминг сервер очень похож на Wowza, которая умеет отдавать RTSP/RTP поток на Flash. Единственное отличие в том, что этот поток будет отдан на WebRTC, а не на Flash. Т.е. между браузером и сервером пройдет честный DTLS, установится SRTP сессия и поток, закодированный в VP8 пойдет зрителю.
Для установки нам потребуется SSH-доступ.
По идее, вместо пункта 10 правильно было бы задать все необходимые порты и правила firewall, но для целей тестирования решили просто отключить брэндмауэр.
Настройка сервера
Напомним, что структура нашей WebRTC трансляции такова:
Установку основных элементов этой диаграммы мы уже произвели, осталось наладить «стрелочки» взаимодействий.
Связь между браузером и WebRTC сервером обеспечивает web-клиент, который есть на гитхабе:. Набор JS, CSS и HTML файлов просто закидывается в /var/www/html на этапе установки (см. выше под спойлером пункт 9).
Взаимодействие браузера и сервера настраивается в конфигурационном XML-файле flashphoner.xml. Туда нужно вписать IP-адрес сервера, чтобы web-клиент смог подключаться к WebRTC серверу по HTML5 Websockets (пункт 9 выше).
Настройка сервера на этом заканчивается, можно проверить его работу:
А так поддержка DDNS выглядит в самом роутере:
Теперь можно приступить к тестированию и оценить результаты.
Тестирование
После открытия ссылки в браузере идет подключение к WebRTC серверу, который отсылает запрос к IP-камере на получение видеопотока. Весь процесс занимает несколько секунд.
В это время устанавливается соединение браузера с сервером по вебсокетам, далее сервер запрашивает IP камеру по RTSP, получает поток H.264 по RTP и транскодирует его в VP8 / SRTP — который в итоге воспроизводит WebRTC- браузер.
Далее после небольшого ожидания, отображается уже знакомая картинка.
В нижней части видео отображается URL видеопотока, который можно скопировать и открыть для просмотра из другого браузера или таба.
Убеждаемся что это действительно WebRTC.
А вот что показывает chrome://webrtc-internals
По показаниям графиков, мы имеем битрейт с IP камеры 1Mbps. Исходящий трафик тоже есть, скорее всего это RTCP и ICE пакеты. RTT до Amazon сервера составляет около 300 миллисекунд.
Теперь заглянем в Wireshark, там отчетливо видно UDP трафик с IP адреса сервера. На картинке ниже пакеты по 1468 байт. Это и есть WebRTC. Точнее SRTP пакеты несущие VP8 видео фреймы, которые мы можем наблюдать на экране браузера. Кроме это проскакивают STUN запросы(самый нижний пакет на картинке) — это WebRTC ICE заботливо проверяет соединение.
Следующий тест — подключение других зрителей. Удалось открыть 10 окон Chrome, и каждое из них показывало картинку. При этом сам Chrome начал немного тупить. При открытии 11-го окна на другом компьютере, воспроизведение оставалось плавным.
Про WebRTC на мобильных устройствах
Как известно, WebRTC поддерживают Chrome и Firefox браузеры на платформе Android.
Проверим, будет ли там отображаться наша трансляция:
На картинке HTC телефон, в Firefox браузере отображается видео с камеры. Отличий в плавности воспроизведения от десктопа нет.
Заключение
В результате нам удалось запустить WebRTC онлайн-трансляцию с IP-камеры на несколько браузеров с минимальными усилиями. Не потребовалось ни плясок с бубном, ни rocket-science – только базовые знания Linux и SSH-консоли.
Качество трансляции было на приемлемом уровне, а задержка воспроизведения была незаметна на глаз.
Подводя итог, можно сказать что браузерные WebRTC трансляции имеют право на существование, т.к. в нашем случае WebRTC это уже не костыль или плагин, а реальная платформа для воспроизведения видео в браузере.
Почему же мы не видим повсеместного внедрения WebRTC?
Главный тормоз, пожалуй, недостаток кодеков. WebRTC сообществу и вендорам следовало бы сделать усилие и ввести в WebRTC кодек H.264. Против VP8 сказать нечего, но зачем отказываться от миллионов совместимых девайсов и ПО, которые работают с H.264? Патенты, такие патенты…
На втором месте, не полная поддержка в браузерах. C IE и Safari, например вопрос остается открытым и там придется переходить на другой тип стриминга или использовать плагин типа webrtc4all.
Так что в будущем, надеемся увидеть более интересные решения, в которых не нужен будет транскодинг и конвертация потоков и большинство браузеров смогут отыгривать потоки с различных устройств уже напрямую.
Уважаемый читатель, приветсвую тебя на просторах хабрахабра, этой уникальной площадки обмена опытом и мнениями. В этой заметке я хочу вернутся к теме беспроводной передачи высококачественного видео и звука без использования проводов, с применением различных технологий. При этом я буду рассматривать аспект беспроводной передачи шире, чем просто сетевое «расшаривание» фильмов и музыки. Необходимым и достаточным условием упоминания той или иной технологии будет возможность передачи экрана рабочего стола и работы любых программ, с поддержкой разрешения, не ниже 1280x720 (HD-ready/720p).
Поскольку с момента моих прошлых публикаций уже прошло довольно большое время (относительно этой, развивающейся взрывными темпами, индустрии), и появилось N-ое количество новшеств, то их описанием и хотелось бы поделиться.
Пару слов перед началом
Как бы это не казалось странным, но технологий передачи HD-видео и звука достаточно большое количество(здесь и далее под HD-видео и звуком подразумевается не просто файлы музыки и кино, но работа программ в реальном времени и высоком разрешении) и все они в текущей заметке не поместятся. А поскольку любому техническому уму, коих большинство на нашем ресурсе, требуется точность и категоричность, то если тема окажется интересной, в конце я подведу итог всех заметок общей табличкой, в которой сведу все беспроводные стандарты и их многочисленные характеристики. Как я уже заметил ранее, мозг читателя хоть и технический, но не резиновый как первопрестольная и, дабы ограничить явление многабукаф (Господи, хотя статья и так получилась огромной! ), начнём мы с самой доступной технологии беспроводной передачи видео и звука — передача по Wi-Fi.
Передача по Wi-Fi
Итак, переда началом рассмотрения конкретных технологий передачи видео и звука поверх Wi-Fi, мы должны понять общие достоинства и недостатки, обусловленные таким использованием Wi-Fi.
Достоинства
- Большинство компьютеров (и не только их) уже оснащено Wi-Fi — не нужен отдельный передатчик, всё, что нужно для трансляции уже имеется;
- Можно использовать не только для беспроводной передачи видео и звука но и для получения доступа к сети;
- Из за широкой распространённости обращает на себя внимание крупнейших участников IT-индустрии, таких как Intel, Apple, Qualcomm, Cavium Networks.
На этом немногочисленные, но значимые достоинства, заканчиваются.
Недостатки
- Беспроводная передача видео и звука забивает/отнимает часть эфира у прямого назначения вайфая — доступа в сеть;
- Работе вашей сети могут мешать окружающие Wi-Fi сети, коих с каждым годом становится всё больше;
- Для того, чтобы HD-видео и звук помещались в полосу пропускания Wi-Fi, требуется «упаковать» их соответствующим кодеком (в большинстве случаев — h.264), что даёт (вообще говоря, несущественную) потерю качества;
- Потребность в сжатии рождает потребность в софте, который может работать на одной, но не работать на другой ОС/платформе;
- Из за потребности в софте будет работать толко на ПК-образном железе — передача от игровых (Xbox360,PS3)/спутниковых(НТВ+)/телевизионных(БилайнТВ, Акадо) приставок отпадает (за некоторым исключением, где свет сошёлся клином и на приставке есть возможность запускать сторонний софт и сам подобный софт под неё написан, вероятность чему — 0,01%, а независимые от компьютера передатчики не очень-то торопятся выпускать);
- Работа кодека по сжатию контента требует аппаратных ресурсов, при том немалых;
- Из за работы кодека передача сигнала задерживается на дельту времени, уходящую на сжатие (от 20мс до 2 секунд, в зависимости от расстояния и мощности сжимающей аппаратуры).
Общие слова сказаны, теперь поехали по конкретным технологиям (отсортированы по доступности):
Это самый простой способ и, наверное, самая распространенная на сегодняшний день технология передачи фильмов и музыки по LAN/Wi-Fi. Многие удивятся: сам же, мол, говорил, что «расшариваемые» технологии с файлами отметаем? — Спокойно, коллеги, сейчас всё объясню.
Сам принцип DLNA заключается в том, что на компьютере запускается серевер, в котором прописана открытая для просмотра папка с кино и музыкой. Сам (умный)ТВ, или некий «околотвшный» посредник, типа SetTop box'а или тюнера или игровой приставки, подключается (под вашим чутким руководством) по Wi-Fi к расшаренной папке и выводит из неё контент на HDTV.
Теперь вопрос для страждущих: как передать по DLNA рабочий стол? Ответ: кэпчурить(capture) экран в реальном времени в файл(например VLC'шкой), который расшарен и открыт телевизором/приставкой по DLNA. Примечание: поскольку сжатие и передача будут настроены «кустарным» способом, ничего хорошего от этого не ждите — 12 секундная задержка, не видно курсора и нет звука (проверено лично и найдено в гугле по запросу «рабочий стол по DLNA»).
Да и вообще, в нашем быстроменяющемся IT-мире содержать сервер на своём ПК и заставлять дополнительными, лишними движениями подключатся к нему устройства-клиенты, совсем не кошерно. Беспроводная передача должна выглядеть так: на компьютере кнопочку нажали — «подключить ТВ», на ТВ картинка появилась. Без муторных настроек и выбора файлов посредством пульта или джойстиков или прочих нехороших.
Итак, главная, выведенная мною и опорная, для беспроводной передачи видео/звука парадигма — передающий должен являтся клиентом к принимающему, но не наоборот!
Достоинства
- Встроен в большинство современной околоТВ'шной техники.
Недостатки
- Низкая производительность при передаче рабочего стола/программ;
- Сложность в настройке из за обмена ролями клиентсервер.
Налицо нарушение выведенной выше парадигмы: для получения видео и звука с вашего компьютера на нём должен быть запущен сервер одного из протоколов удаленного рабочего стола, а около телевизора должен находится клиент (читай — ещё один грёбанный, жрущий электричество ящик), который должен инициировать подключение к вашему компьютеру не без помощи мутных манипуляций (даже если это запуск скрипта беспроводной мышкой/клавиатурой). Да ещё и производительность тут будет от невысокой до очень низкой из за «кустарности» метода.
С другой стороны, это выход для малобюджетных решений, когда у телевизора достаточно поставить только старый компьютер и оптимально его настроить.
Достоинства
- Для работы достаточно любого старого ПК или даже смартфона с выводом на ТВ.
Недостатки
- Те же, что и у DLNA, хотя производительность рабочего стола и выше.
Беспроводные серверы презентаций (wireless presentation gateway)
Интересный класс железок, весьма мало распространенный, однако существующий. Представьте себе такую картину: к Wi-Fi точке доступа, помимо интернета, можно подключить телевизор или монитор с колонками, и с помощью небольшой утилиты выводить картинку и звук с ПК на эти ТВ/монитор/колонки. Это и есть схема работы беспроводного сервера презентации. Грубо говоря, это точка доступа/wi-fi роутер, который помимо интернета предоставляет вашему ПК/смартфону устройство вывода изображения и звука.
В большинстве случаев, когда вы хотите передать через сервер презентаций уже не рабочий стол и программы, а кино и музыку, в передающую утилиту встроен плеер, открывая которым ваши медиафайлы они передаются на точку доступа уже по протоколу DLNA, тоесть в оконном режиме вы кино не посмотрите, только на полный экран. Когда фильм/музыка заканчивается, приложение автоматически переключается обратно, в режим передачи изображения рабочего стола.
В разное время подобные точки доступа выпускали Dlink, Planet, Edimax, ViewSonic и другие, мене известные авторы. Но наилучшего результата по качеству передачи и снижению задержки достигла фирма Awind со своим продуктом McTivia: это небольшая точка доступа 802.11n, имеющая HDMI выход (максимальное разрешение — 1280x720, звук — стерео). Также есть вход ethernet для предоставления общего доступа к сети (кстати, связь утилиты и точки доступа работает и по LAN); а также имеется USB-вход для клавиатуры/мыши, чтобы можно было управлять компьютером, на котором запущена утилита, удаленно. Поскольку протокол передачи заметно оптимизирован по сравнению с предшественниками, удалось убрать DLNA'шную часть и запускать видео и звук напрямую, через любой проигрыватель. При этом у утилиты есть несколько режимов качества: при наименьшем качестве, соответственно, самая низкая задержка — это для презентаций и прочего интерактива; при наивысшем качестве задержка почти секунда, но это для кино, где в хорошем качестве запустили и не трогаете, так что задержка не напрягает.
Удивляет обилие клиентов к McTivia для разных платформ: есть клиенты и для MacOS и для разных версий Windows, и даже клиенты (правда, пока без звука) для iOS и Android. К сожалению Linux, по моему мнению — незаслуженно, обделили.
Самое интересное, что Awind сотрудничает с фирмой mirrorop, которая и пишет софт для смартфонов и коммуникаторов. Так вот mirrorop также пишет софтверные версии серверов презентации для разных платформ: вместо McTivia можно передавать картинку на планшет и смартфон, который также можно подключить к телевизору. Но тут, увы, уже не будет такой производительности, как у железа.
Коллеги сняли русскоязычное видео про McTivia:
Достоинства
- Работает практически на любой платформе, в том числе и на мобильных ОС;
- Оптимизированное качество, приемлемое при среднестатистическом компьютере;
- Софт частично использует GPU для ускорения сжатия;
- Есть возможность управлять удаленным компьтером прямо с точки доступа (USB-клавиатурой/мышью);
- Можно использовать одновременно ещё и как точку доступа для раздачи сети.
Недостатки
- Чем слабее компьютер — тем хуже производительность;
- Видео ограничено разрешением 1280х720, про 3D речи нет, звук — только стерео;
- Довольно большая задержка, могут возникнуть проблемы с играми;
- Необходимо тратить средства на покупку WPG-оборудования.
Intel WiDi
Ител (пока)является ключевым производителем чипов на рынке процессоров для ПК и ноутбуков, и, как любой, уважающий себя индустриальный гигант, имеет ряд своих тузов в рукаве, подсунутых туда огромными research-центрами и исследовательскими лабораториями, которые он содержит по всему миру. Есть неплохая рекламная статейка на хабре про WiDi, которая, кстати, и побудила меня разрадиться сим манифестом.
Вкратце, посколку Intel всё теснее соединяет все компоненты современного компьютера, такие как CPU, GPU и Wi-Fi адаптер, в рамках своей единой платформы, то они могут позволить себе выпускать софт, сильно заточенный под эту платформу, так как она — массова.
WiDi работает только на процессорах Core второго поколения и только с интеловским вай-фай чипом. Сжатию потока для передачи помогает встроенный в кристал процессора графический адаптер.
Для приёма сигнала на телевизоре используется специальная приставка WiDi, качество FullHD 1080p, но пока только 30fps. Звук — многоканальный. Задержка — от 20мс и более (обычно — более). Для соединения с WiDi-приёмником используется специальная технология от Intel, на подобии множественного Wi-Fi p2p, тоесть ваш ПК может быть присоединён к WiDi-адаптеру одновременно вместе с соединением с интернетом через точку доступа.
В качестве альтернативы приёмнику Intel обещает встраивать технологию в современные телевизоры (несколько прототипов, в том числе и от Samsung уже были показаны в начале года). Или же, что ещё более интересно: предлагают как то хитро отправлять/принимать контент по DLNA (в качестве подтверждения на CES2012 показывали PS3 и Xbox360, принимающие сигнал от ноутбука с WiDi). Только не понятно, нужно ли будет устанавливать какой-нибудь софт от Intel на приставку. Скорее всего — да, но это не очень-то проблемно.
Достоинства
- Работает на всех ПК с современной платформой Intel;
- Софт оптимизирован под платформу, активно используется мощь GPU;
- Постоянные обновления, высокое качество сигнала (FullHD+5.1), понижение задержки;
- Появление встроенных в ТВ и Sat/IPTV-приставки приёмников и передача через повсеместный DLNA.
Недостатки
- Только железо от Intel — CPU Core, работает на встроенной видеокарте, нужен Wi-Fi чип Intel;
- Работает только под Windows;
- На мобильной платформе только в стадии прототипа на платформе Intel (Cedar Trail), на ARM отсутствует;
- Пока ещё ощутимая задержка передачи сигнала;
- Пока ещё требуется покупать отдельный приёмник WiDi.
Apple AirPlay
У яблочной компании началось всё давным давно с точки доступа, к которой можно подключить колонки (AirPort Express) и крутить музыку из монструозного iTunes денно-нощно, при том, iTunes из Windows тоже мог слать. Потом это перерасло ещё и в трансляции на AppleTV (вся технология основывалась на DLNA в «яблочной» обёртке, ничего сложного). Потом появились i'гаджеты и технология AirPlay: теперь из встроенного плеера i'гаджетов стало возможно слать как видео так и музыку на AppleTV и только музыку на AirPort Express. Намётанный глаз заметит, что пока это всё ещё смахивает на старый добрый DLNA в яблочной кожице (хотя есть софт от фирмы rogueamoeba, называется — airfoil, который может выводить звук любого приложения в приёмники от Apple, да и самим компьютерам превращаться в AirPlay приёмники).
Но с появлением двухъядерных АйФонов и АйПэдов всё изменилось. Теперь мощности стало достаточно и одно ядро процессора может отвечать за основные задачи, полностью соответствуя характеристикам предыдущего поколения, а второе ядро может сжимать всё, что происходит на экране и в динамиках, и отправлять это на AppleTV. Так что AirPlay вырос до полноценной передачи рабочего стола мобильных устройств на телевизор (правда пока только в разрешении 1280х720, но всё впереди).
А что же с обычными маками? Неужели Apple бросила свои компьютеры в угоду смартфонам и планшетам? Как оказалось — совсем нет, в грядущей обновленной Mac OS — Mountain Lion, выход которой намечен на лето'12, появилась такая долгожданная функция AirPlay, которая глубоко интегрированна в систему и распознаёт телевизор, подключенный к AppleTV, просто как второй экран. С ним можно делать любые настройки, как и с монитором, подключенным по проводу, это очень удобно.
Поговаривают, что в скором времени должна выйти и обновленная версия AppleTV, скорее всего в ней появится возможность принимать не только HD-Ready (720p), но и FullHD(1080p).
Поскольку устройства от Apple нынче достигли невероятного подъёма своей популярности, то огромное число производителей аксессуаров стали встраивать в свои аккустические системы поддержку AirPlay для звука. Скорее всего нечто подобное начнёт скоро происходить и для видео.
Достоинства
- Работает практически на всех современных устройствах от Apple, в том числе и мобильных, и через iTunes на Windows;
- Софт оптимизирован под платформу, активно используются аппаратные особенности;
- Сигнал имеет гарантированне качество и отсутствие градаций: гарант Apple;
- Совершенно точно будет развиваться дальше;
- AirPlay встраивается в множество аксессуаров для Apple-устройств.
Недостатки
- Только железо от Apple, Linux'ы и Android'ы отдыхают;
- Работает только под MacOS/iOS, за исключением DLNA функций через iTunes на Windows (или Airfoil)
- Качество пока только 720p и задержка, всё же имеется, хоть и малозаметная;
- Неизвестно, будет ли возможность встраивать AirPlay приёмники HD-видео и звука в иную технику, кроме существующей AppleTV.
Заключение
Обобщая, все стараются сделать решение встроенным, использующим уже существующую аппаратную платформу и Wi-Fi адаптер, но, как видно, даже самые последние реализации пока не достигли абсоютного HD-качества и очень низкой задержки. Они будут развиваться и улучшаться по мере выхода нового, более мощного оборудования.
Если это будет интересно, то дальше мы поговорим о специализированных стандартах с отдельными передатчиками, по всем параметрам обеспечивающими имитацию HDMI-кабеля.
P.S.: Как ни старался сжать материал ребята, но, как говорится, по другому никак не скажешь. Напишите, стоит ли писать продолжение про другие технологии. Также рад буду ответить на любые вопросы в комментариях.
Доброго дня!
Если у вас есть какая-нибудь камера или ТВ-тюнер, и вы хотите сделать свою трансляцию в локальной сети (или в интернет) — то эта заметка для вас. 👌
Впрочем, никто не мешает с таким же успехом вещать и просто какие-нибудь фильмы/музыку, например, с ПК на ТВ или мобильные гаджеты.
Единственное, учитывайте, что ваш компьютер (который транслирует) должен быть достаточно производительным (чтобы избежать лагов и подвисаний). К тому же, нужно иметь хорошее и стабильное подключение к сети (не ниже 10 Мбит/с). В помощь: тест скорости интернета.
В этой заметке я по шагам рассмотрю все необходимые действия как для вещания по локальной сети, так и по интернету. Разумеется, в вашем случае могут быть небольшие отличия (например, при выборе устройства захвата. ).
Ладно, ближе к теме.
Читайте также: