Что такое DMX512?

Добавил(а) microsin

Аббревиатура DMX512 построена от слов Digital Multiplex, что означает в буквальном переводе "цифровое переключение" (далее перевод статьи Википедии [1]). Это стандарт для построения сети цифрового обмена данными, которая обычно используется для организации динамического освещения и цветовых эффектов. Изначально он предназначен как стандартизованный метод для управления световыми диммерами, которые до появления DMX512 имели для этого различные несовместимые друг с другом проприетарные протоколы. DMX512 скоро стал основным методом для подключения диммеров к контроллерам (таким как световая консоль), устройствам создания спецэффектов типа генераторов дыма и тумана, и к графическим экранам, состоящим из регулируемых источников света. DMX распространился до использования в нетеатральном внутреннем и архитектурном освещении, от создания рождественских гирлянд до световых рекламных щитов. На физическом уровне протокол DMX512 использует дифференциальную сигнальную пару EIA-485(он же RS-485 [2]) в соединении с протоколом, основанном на пакетах переменной длины. Протокол DMX512 однонаправленный, данные передаются только в одном направлении - от контроллера к управляемым устройствам. В протокол DMX512 не встроены автоматический контроль и коррекция ошибок, так что он не подойдет для управления потенциально опасных приложений, таких как пиротехника или перемещение театральных сооружений. Ошибочное срабатывание декодера протокола может быть вызвано электромагнитными помехами, электростатическими разрядами, неправильным терминированием кабеля, кабелем слишком большой длины или кабелями низкого качества. [История появления текущего стандарта DMX512-A] Стандарт DMX512 впервые был разработан в 1986 году инженерной комиссией USITT (United States Institute for Theatre Technology), и назывался "Digital Multiplex with 512 pieces of information" (цифровое мультиплексирование 512-ти порций информации), с последующей ревизией в 1990 году. В 1998 году организация ESTA (Entertainment Services and Technology Association) приступила к процедуре ревизии протокола, чтобы привести его к стандарту ANSI (American National Standards Institute). В результате переработанный стандарт, известный как "Entertainment Technology—USITT DMX512-A—Asynchronous Serial Digital Data Transmission Standard for Controlling Lighting Equipment and Accessories" был одобрен ANSI в ноябре 2004. Затем снова была ревизия в 2008 году, и текущий стандарт теперь называется "E1.11 - 2008, USITT DMX512-A", или просто DMX512-A. [Топология сети DMX512] В сети DMX512 применена многоточечная шинная топология Multidrop bus [3], узлы в которой расположены в одну цепочку, которую еще называют гирляндой (daisy chain). Сеть состоит из одного контроллера DMX512, который является мастером сети (master), и из одного или большего количества подчиненных устройств (slave devices). Например, световая консоль (lighting console, пульт управления освещением) часто оснащена контроллером для сети подчиненных устройств, таких как диммеры, генераторы тумана и интеллектуальные источники света. Каждое подчиненное устройство (slave device) имеет коннектор DMX512 "IN" и обычно также коннектор "OUT" (или "THRU"). Контроллер (мастер сети), который имеет только коннектор OUT, подключен кабелем DMX512 к коннектору IN первого подчиненного устройства в цепочке. Второй кабель соединяет коннектор OUT (или THRU) первого подчиненного устройства с коннектором IN следующего подчиненного устройства в цепочке, и так далее. Ниже в качестве примера показана блочная диаграмма простой сети из контроллера и трех подчиненных устройств. Стандарт также требует "терминатор" - нагрузочное сопротивление 120 Ом, подключенное к последнему в цепочке коннектору OUT (или THRU). Терминатор обычно представляет собой просто коннектор "папа", к которому припаян резистор 120 Ом, так чтобы он был подключен на сигнальную пару интерфейса. Номинал этого резистора соответствует волновому сопротивлению кабеля (characteristic impedance [4]). Если используется вторичная пара сигналов данных, то терминирующий резистор подключается также и на неё. Несмотря на то, что простые системы (например системы, у которых кабель короткий, и где в сети мало устройств) будут иногда нормально работать и без терминатора, стандарт все равно требует его использовать. Некоторые подчиненные устройства DMX уже имеют на борту встроенные терминаторы, которые могут быть активированы вручную (установкой перемычки или переключателя), или программно (под управлением внешней программы настройки), или автоматически, путем детектирования отсутствия подключенного кабеля. Сеть DMX512 иногда называют "DMX universe" (прим. переводчика: дословно переводится как "вселенная DMX", но я решил термин universe не переводить и оставить как есть). Каждый коннектор OUT на контроллере DMX512 может управлять одной universe. Небольшие контроллеры могут иметь один коннектор OUT connector, что позволяет им управлять только одной universe, в то время как большие пульты управления (консоли оператора) могут иметь возможность управлять несколькими universe, при этом для каждой universe имеется отдельный коннектор OUT. Контроллер DMX (master) Устройство DMX (slave) [Физический уровень DMX512, электрические цепи] Данные передаются по дифференциальной паре с использованием уровней напряжения стандарта EIA-485 [2]. Таким образом, электрические спецификации DMX512 идентичны указанным в стандарте EIA-485-A, кроме тех мест, где утверждено иначе (см. далее E1.11 про заземление). Шина DMX512 позволяет длину не более 1200 метров, и не более 32 нагружающих устройств на одной шине. Если нужно передавать данные с более чем 32 устройствами, то сеть может быть расширена параллельным подключением так называемых сплиттеров DMX. Провода данных прокладываются в экранированной витой паре с волновым сопротивлением 120 Ом, и с терминирующим резистором на противоположном от контроллера конце сети, чтобы устранить отражения сигнала. DMX512 имеет 2 канала передачи витой парой, хотя текущая спецификация определяет использование только одной из этих витых пар. Функционал второй пары не определен, однако она должна присутствовать по электрическим требованиям стандарта. Для коротких кабелей длиной примерно менее 45 метров, на котором присутствует небольшое количество устройств, иногда можно работать без терминатора. На коротких дистанциях можно использовать кабели с более высокой емкостью и различными волновыми параметрами, такие как например кабель от микрофона. Однако с увеличением длины кабеля и количества подключенных устройств становится все более важным наличие корректного кабельного волнового сопротивления и терминатора, соответствующих стандарту. Стандарт E1.11 (DMX512 2004) описывает электрические требования к соединению общего сигнала DMX512 с заземлением. В частности стандарт рекомендует, чтобы у портов передатчика (порт OUT контроллера DMX512) было соединение с низким сопротивлением между общим сигнальным проводом и землей; такие порты называются заземленными. Далее рекомендуется, чтобы приемники имели высокое сопротивление между общим сигнальным проводом и землей; такие порты называются изолированными. Стандарт также разрешает иметь изолированные порты передатчика, и неизолированные порты приемников. Стандарт рекомендует, чтобы заземление общего сигнального провода происходило только в одной точке, во избежание появления паразитных контуров заземления [5]. Строго не рекомендуется использовать заземленные приемники, у которых есть жесткое соединение между общим сигнальным проводом и землей, однако их использование разрешено. Несколько возможных конфигураций заземления, которые обычно используются с EIA485, специально запрещено для использования в E1.11. [Используемые коннекторы] DMX512 1990 года в плане коннекторов предусматривает для канала передачи данных применение 5-контактных коннекторов стиля XLR (XLR-5), где гнезда (female) стоят на стороне портов передачи (OUT), и штыри (male) на стороне принимающих портов (IN). Использование 3-выводного коннектора XLR специально запрещено. DMX512-A (ANSI E1.11-2008) позволяет использовать 8-контактные коннекторы (8P8C, или RJ-45) для фиксированных инсталляций, где не требуется частое подключение и отключение оборудования. Некоторые производители проигнорировали формальные правила топологии, и разработали свое оборудование для использования с нестандартными коннекторами 3-pin XLR, вместо того чтобы использовать по стандарту DMX коннекторы 5-pin XLR. Этим они устранили требование наличия неиспользуемой второй пары, и сделали возможным использования для шины DMX простых микрофонных аудиокабелей. Точно так же конечные пользователи могут создать свои собственные переходники, чтобы правильно конвертировать 5-pin XLR в микрофонный кабель 3-pin XLR. Некоторые производители оборудования DMX512 на заре эры DMX применяли несовместимые или проприетарные коннекторы и цоколевки; в конечно счете наиболее распространенным из них стал 3-pin XLR (в некоторых странах известный как cannon-джек), поскольку электрическая спецификация в настоящий момент определяет использование только одной сигнальной пары проводов. Есть некий риск повреждения оборудования, если случайно коннектор XLR 3-pin, передающий сигнал DMX, будет случайно подключен в тракт аудиосигнала (например, на вход микрофонного усилителя), однако тем не менее некоторые управляемые светильники и контроллеры все равно оснащены коннекторами 3-pin XLR точно такими же, какие используются в цепях аудиосигналов. Такие коннекторы иногда применяются в недорогих устройствах, и даже иногда эти нестандартные устройства имеют обратную полярность сигнала данных, что требует обратного переключения сигнальных проводов. Кроме того, устройства иногда оснащены 4-контактными коннекторами, через которые в одном общем кабеле передается как сигнал, так и питание. Имейте также в виду, что нетеатральное оборудование, использующее DMX512 для целей архитектурного освещения, часто использует нестандартные соединители. [XLR-5 pinout] 1 Signal Common, общий сигнальный провод 2 Data 1- (Primary Data Link, канал передачи данных) 3 Data 1+ (Primary Data Link, канал передачи данных) 4 Data 2- (Optional Secondary Data Link, не используется) 5 Data 2+ (Optional Secondary Data Link, не используется) [XLR-3 pinout] Внимание: этот коннектор запрещен секцией 7.1.2 стандарта ANSI E1.11. DMX+ и DMX- часто перепутаны. Наиболее распространенная цоколевка приведена ниже. 1 Ground, земля 2 Data 1- (Primary Data Link, канал передачи данных) 3 Data 1+ (Primary Data Link, канал передачи данных) [RJ-45 pinout] 1 Data 1+ 2 Data 1- 3 Data 2+ 4 пусто 5 пусто 6 Data 2- 7 Signal Common (0 V) для Data 1 8 Signal Common (0 V) для Data 2 Цоколевка модульного коннектора 8P8C совпадает со схемой пар кабелей патч-кордов Ethernet 5-й категории (Category 5, Cat5). Незадействованные контакты 4 и 5 помогают предотвратить повреждение оборудования, если кабель случайно подсоединен в телефонную линию PSTN (public switched telephone network) вместо телефонного джека. [Используемые кабели] Стандартные кабели в сети DMX512 оснащены коннекторами XLR5, где на одном конце штыри (male connector, папа), и на другом конце гнезда (female connector, мама). Коннектор male кабеля подключается к передающему разъему female jack (OUT), и коннектор female кабеля подключается к принимающему коннектору male jack (IN). Определение кабелей для DMX512 было удалено из стандарта, и в 2003 году отдельно был запущен отдельный проект стандарта для кабелей. Было разработано 2 стандарта кабелей, один для портативных, переносных кабелей DMX512 (ANSI E1.27-1 - 2006), и другой для постоянных инсталляций (макет стандарта BSR E1.27-2). Это решало вопросы, возникающие из-за различных требований для кабелей в применении для переезжающих шоу, и для применения в постоянной инфраструктуре управления освещением. Электрические характеристики кабеля DMX512 определены с точки зрения его сопротивления и емкости, несмотря на имеющиеся механические и другие соображение, которые также должны быть рассмотрены. У типов кабелей, которые подходят для DMX512, должно быть волновое сопротивление 120 Ом. Кабель Cat5, обычно используемый для сетей и телекоммуникаций, был протестирован организацией ESTA для использования в DMX512A. Также кабели, разработанные для EIA485, обычно удовлетворяют электрической спецификации DMX512. С другой стороны, микрофонные и аудиокабели не обладают достаточными электрическими параметрами, так что не подходят для соединений DMX512. У них волновое сопротивление значительно ниже, и емкость выше, что искажает форму цифрового сигнала DMX512, поэтому может быть неправильная работа и возникать случайные ошибки, которые трудно найти и исправить. [Протокол DMX512] На слое передачи данных контролер DMX512 передает асинхронные последовательные данные на скорости 250 kbaud. Формат данных жестко фиксирован: 1 стартовый бит, 8 бит данных, 2 стоповых бита, без бита четности. Таким образом, форма сигналов и их временнЫе параметры повторяют популярный формат сигнала RS-232. Пакет состоит их следующих частей: • Интервал Break condition. • Интервал Mark-After-Break (MAB). • Slot 0, содержащий однобайтный Start Code. • До 512 слотов данных канала, каждый содержит 1 байт. Начало пакета обозначено интервалом break (лог. 0), за которым идет "mark" (лог. 1), известный как "Mark After Break" (MAB). Код break обозначает сигнал окончания одного пакета и начало другого, что переводит приемники на запуск приема, и также служат фреймом (ссылкой на позицию) байт данных в пакете. Байты данных, помеченные фреймом, называют слотами. За break посылается до 513 слотов. Первый слот зарезервирован как "Start Code", который указывает тип данных в пакете. Start code 0x00 (шестнадцатеричный 0) является стандартным значением, используемым для всех совместимых с DMX512 устройств, которые включают большинство источников света и диммеров. Другие значения start code используются для пакетов текста (Text packets, 0x17), пакетов системной информации (System Information Packets, 0xCF), для RDM-расширения DMX (0xCC), и различных проприетарных систем. Plasa поддерживает базу данных альтернативных значений start code [7]. Все слоты, которые идут за start code, содержат управляющие установки для подчиненных устройств (slave devices). Позиция слота в пакете определяет устройство и функцию, которая будет управляться, в то время как значение слота определяет точку установки. [Диаграммы времени (timing parameters)] Параметры времени DMX512 могут меняться в широких пределах. Оригинальные авторы протокола указывают стандартные значения, которые обеспечивают самую лучшую гибкость для дизайна. Однако по этой причине было трудно разработать приемники, которые работали бы во всем диапазоне интервалов времени. В результате этих сложностей стандарт на параметры времени от 1986 года был изменен в 1990 году. В частности MAB, который изначально был фиксирован на 4 мкс, был изменен на минимальное значение 8 мкс. Стандартом E1.11 (2004) ослаблены требования к времени для передатчика и приемника. Это упростило требования времени для систем, использующих контроллеры, построенные для DMX512-A (E1.11); однако значительное количество обычных устройств все еще работают по принципу интервала времени, близкого к минимуму диапазона. Min длительность Break, мкс Min длительность MAB, мкс Для передатчика (master) 92 12 Может распознать приемник (slave) 88 8 Максимальные интервалы времени не определены, потому что как только пакет отправлен хотя бы 1 раз в секунду, интервалы времени BREAK, MAB, inter-slot time и mark между последним слотом пакета и break (MBB) уже могут быть достаточной длительности. Максимальный размер пакета, в котором передается 512 каналов (слоты, которые следуют за байтом start code), занимает по времени 23 мс на передачу, что соответствует максимальной частоте обновления около 44 Гц. Для того, чтобы получить более высокие скорости обновления, в пакете должно передаваться меньшее количество каналов, чем 512 - чем меньше передается каналов, тем быстрее будут передаваться пакеты, тем больше будет частота обновления. Стандарт не определяет минимальное количество слотов, которое должно быть передано в пакете. Однако требуется, чтобы пакеты были переданы так, чтобы передние фронты двух последовательных BREAK должны находиться друг от друга по времени не менее чем за must be separated by at least 1204 мкс, и приемники должны быть способны обработать пакеты с временем break-to-break 1196 мкс. Минимальное время break-to-break может быть достигнуто при передаче пакетов, которые содержат как минимум 24 слота (путем добавления дополнительных лишних байт, если это необходимо), или путем расширения параметров интервалов времени BREAK, MAB, Interslot, или Interpacket. [Адресация и кодирование данных DMX512] Большинство данных отправляется с кодом по умолчанию Null Start Code 00h. Цитата из стандарта, 8.5.1 NULL START code NULL START Code идентифицирует последующие слоты данных как блок нетипизированной последовательной 8-битной информации. Пакеты, идентифицированные через NULL START Code, являются пакетами по умолчанию, которые передаются в сетях DMX512. Более старые версии этого стандарта подразумевали, что только класс данных диммера будет отправляться с использованием пакетов с NULL START Code. На практике пакеты NULL START Code использовались большим количеством разных устройств; эта версия стандарта принимает это по факту. Каждый NULL START Code пакет не содержит формальных данных или структуры адресации. Устройство, использующее данные из пакета, должно знать позицию, где его данные находятся в теле пакета. Группы или стойки диммеров используют группу слотов, чтобы определить уровни для своих диммеров. Обычно диммер имеет начальный адрес, представленный диммером с наименьшим номером в этой группе, и адресация увеличивается от этого адреса до диммера с самым большим номером. Например, для двух групп из 6 диммеров каждая, первая группа адресуется начиная с адреса 1, и вторая группа с адреса 7. Каждый слот в пакете DMX512 соответствует одному диммеру. 8-bit или 16-bit? DMX не определяет метод 16-bit кодирования пакетов Null Start Code, однако многие параметры для организации бегущих огней используют кодирование величин с количеством разрядов больше 8. Чтобы более точно управлять этими параметрами, некоторые светильники имеют два канала для параметров, которые требуют повышенной точности. Первый из этих двух каналов грубо управляет параметром (256 шагов во всем диапазоне перемещения) и второй канал уточняет регулировку (256 шагов на каждой неточной позиции), что дает 16-битное значение, кодирующее диапазон из 65536 шагов, и позволяет повысить точность передачи для любого 16-bit управляющего параметра, такого как Pan или Tilt. [DMX на практике] Популярность DMX512 объясняется частично из-за его простоты и надежности. Кабелями в известной степени можно пренебречь без потери функциональности, можно использовать Ethernet или любые другие подходящие свободные кабели, пока не появляются проблемы наподобие неустойчивости и случайного срабатывания. Неожиданное поведение управляемого источника света может быть вызвано ошибками адресации, неисправным кабелем, или некорректными данными, приходящими от контроллера. Использованием дополнительного линка данных (Secondary data link). Стандарты 1986 и 1990 годов не определяют точно назначение второй пары линка данных. Эта пара описывается как "optional second data link" (необязательное вторичное соединение для передачи данных), предполагая использование её для передачи данных как в одном, так и в двух направлениях. Некоторое проприетарное оборудование задействует контакты для этого вторичного линка. Запрещены схемы, которые используют уровни напряжения вне диапазона EIA485. Руководство по допустимому применению дополнительного линка можно найти в Приложении B стандарта E1.11. Текущая практика стандарта - оставлять выводы для вторичного линка данных неиспользуемыми. Коннекторы. Стандарт DMX512-A предписывает, что должен использоваться коннектор 5-pin XLR. DMX512-A использует одну пару в коннекторах, что можно осуществить соединение с использованием дешевых коннекторов 3-pin XLR. Некоторые производители применяют в своем оборудовании коннекторы 3-pin XLR, потому что это снижает себестоимость. Однако поскольку 3-pin XLR обычно используются для подключения микрофонов и консолей микширования звука, есть риск ошибочного подключения оборудования DMX512 к микрофону или другому звуковому оборудованию. Напряжение питания +48V (phantom power), которое выдает микшерский пульт, может повредить оборудование DMX512, если его случайно подключить к коннектору звукового пульта. Также цифровые сигналы DMX512, выдаваемые панелями управления освещением, при ошибочном подключении могут повредить микрофоны и другое звуковое оборудование. Следовательно самой лучшей практикой будет использование для DMX512 исключительно коннекторов 5-pin XLR, это позволит избежать риска перепутать коннекторы DMX512 со звуковыми. Однако инспектирования онлайновых сервисов продаж, таких как Ebay или Amazon, показывает использование в подавляющем большинстве продаваемых кабелей DMX на коннекторах 3-pin XLR, и большинство дешевых осветителей и контроллеров на рынке также имеют коннекторы 3-pin XLR. Поэтому такие решения используются во многих инсталляциях, несмотря на нарушение стандарта. Терминирование и совместимость со стандартом. Как уже обсуждалось ранее, сигналы DMX512 требуют терминирования на самом дальнем конце сигнального кабеля. Однако в инструкциях недорогого оборудования редко упоминается терминирование. Поэтому с многими из этих продуктов может наблюдаться неправильное функционирование, как например мерцание или отсутствие управления в том случае, когда на конце кабеля установлен терминатор, в то время как без терминатора все работает нормально. В некоторых случаях только физическое исследование оборудование показывает, что сокет XLR не оборудован контактами переключения, который может автоматически устанавливать терминирование линии резистором, когда кабель не подключен в сокет, и внутренняя электроника не имеет распознаваемой маркировки. В этом случае можно только предположить, что в схеме применены твердотельные переключатели, которые подключают терминатор при необходимости, it can only be assumed that the internal circuit uses solid-state switches to insert the terminator when required. Не очевиден способ, каким образом устройство детектирует наличие или отсутствие подключения на линии передачи. Предусмотрительные пользователи/операторы всегда будут иметь при себе терминатор, чтобы при случае применить его с каким-то незнакомым устройством, который должен быть подключен в конце кабеля, если он по какой-то причине не предоставляет автоматическое терминирование. Можно сделать вывод, что значительная часть производителей отступают от опубликованных стандартов, что может привести к значительным трудностям из-за несовместимости, когда оборудование разных брендов нельзя использовать друг с другом, так что не решаются проблемы, ради чего стандарт и был создан. Благоразумный покупатель всегда должен задавать поставщику вопросы о степени соответствия стандарту - принцип Caveat emptor (на латинском означает "позвольте покупателю быть осторожным"). Беспроводный DMX512. Недавно стали популярными беспроводные адаптеры DMX512, удобные для использования в архитектурном освещении, когда длина кабелей становится чрезмерно большой. Такие сети обычно используют радиопередатчик в контроллере, и приемники в непосредственной близости от регулируемых источников освещения, чтобы преобразовать беспроводный сигнал обратно к обычному DMX512, передаваемому через проводную сеть. Несмотря на то, что беспроводные сети DMX512 в идеальных условиях могут работать на расстояниях более 910 метров, большинство беспроводных линков ограничены расстоянием 300..460 метров для гарантирования надежного функционирования. Первые коммерческие образцы беспроводных систем DMX512 были основаны на технологии расширенного спектра со скачкообразным изменением частоты FHSS (frequency-hopping spread spectrum), которая использовалась в коммерческих беспроводных модемах. Позднее вендоры начали использовать технологию WiFi/WLAN. Другие поздние системы продолжают использовать все ту же технологию FHSS, но с расширенной полосой частот. Системы FHSS имеют тенденцию мешать другим беспроводным системам связи, таким как WiFi/WLAN. Это было исправлено в более новых беспроводных системах DMX, использующих адаптивную перестройку частоты и опознавательное определение свободных частот, чтобы обнаружить и обойти частоты работающих неподалеку беспроводных систем, и не передавать на этих частотах. [См. также] • RDM: протокол управления освещением - общее описание протокола RDM. • Architecture for Control Networks site:en.wikipedia.org - архитектура сетей управления. • Lighting control console site:en.wikipedia.org - микшерский пульт оператора для управления освещением. • Lighting control system en.wikipedia.org - обзор систем управления освещением. • Art-Net en.wikipedia.org - описание протокола, позволяющий передавать данные DMX512 через сетевое соединение UDP. [Словарик] MAB специальный логический маркер протокола DMX512, интервал лог. 1, который сразу следует за BREAK. BREAK совместно с MAB позволяют приемнику надежно отследить начало пакета. BREAK специальный логический маркер протокола DMX512 (лог. 0 определенной длительности), который позволяет приемникам отделить друг от друга отдельные пакеты, т. е. определить начало пакета. RDM Remote Device Management, управление устройствами на расстоянии. SLOT слот, передаваемый байт в протоколе DMX512. UDP User Datagram Protocol, сетевой протокол, не гарантирующий доставку передаваемых сообщений. Диммер "затемнитель", регулятор яркости (иногда и цвета) освещения. [Ссылки] 1. DMX512 site:en.wikipedia.org. 2. RS-485 site:en.wikipedia.org. 3. Multidrop bus site:en.wikipedia.org. 4. Characteristic impedance site:en.wikipedia.org. 5. Ground loop (electricity) site:en.wikipedia.org. 6. ALTERNATE START CODES site:tsp.plasa.org.

Транслируем видеопоток с IP-камеры с помощью WebRTC

Решение задачи онлайн-вещания с IP-камеры, вообще говоря, не требует применения WebRTC. Камера сама является сервером, обладает IP-адресом и может быть подключена напрямую к маршрутизатору с целью раздачи видео-контента. Так зачем же применять технологию WebRTC?





На это есть как минимум две причины:

1. По мере увеличения числа зрителей Ethernet-трансляции все больше будет ощущаться сперва нехватка толщины канала, а затем и ресурсов самой камеры.

2. Как уже упоминалось выше, IP камера является сервером. Но по каким протоколам она сможет отдать видео браузеру десктопа? Мобильному устройству? Скорее всего это будет HTTP стриминг, где видео фреймы или JPEG картинки передаются через HTTP. HTTP стриминг, как известно не совсем подходит для потокового видео реального времени, хотя хорошо зарекомендовал себя в on-Demand видео, где интерактивность потока и задержка не особо важны. В самом деле, если вы смотрите фильм, задержка видео в несколько секунд не сделает его хуже, если только вы не смотрите этот фильм одновременно с кем то еще. “О нет! Джэк убил её! — пишет Элис в чате Бобу спойлер за 10 секунд до трагической развязки”.

Или же это будет RTSP/RTP и H.264, в этом случае в браузере должен быть установлен плагин видеоплеера, такой как VLC или QuickTime. Такой плагин будет забирать и проигрывать видео, как и сам плеер. Но нам то ведь нужен настоящий браузерный стриминг без установки дополнительных костылей/плагинов.

Для начала поснифаем IP камеру чтобы узнать что именно отправляет этот девайс в сторону браузера. В качестве подопытного будет камера D-Link DCS 7010L:



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



Картинка открывается во всех браузерах и равномерно подлагивает, примерно раз в секунду. Учитывая что и камера и лаптоп, на котором мы смотрим поток подключены к одному маршрутизатору, все должно быть плавно и красиво, но это не так. Похоже на HTTP. Запускаем Wireshark чтобы подтвердить свои догадки:



Здесь видим последовательность TCP фрагментов длиной 1514 байт



и завершающий HTTP 200 OK с длиной принятого JPEG:



Далее заходим в Chrome / Developer Tools / Network и видим в реальном времени как мелькают GET Запросы и картинки, переданные по HTTP:



Такой стриминг нам не нужен. Не плавный, дергает HTTP запросы. Сколько таких запросов в секунду выдержит камера? Есть основания полагать что на 10 зрителях и раньше камера благополучно загнется или начнет страшно глючить и выдавать слайды.

Если заглянуть в HTML страницы админки камеры, увидим вот такой интересный код:

if(browser_IE)
  DW('<OBJECT CLASSID="CLSID:'+AxUuid+'" CODEBASE="/VDControl.CAB?'+AxVer+'#version='+AxVer+'" width="0" height="0" ></OBJECT>');
else
{
  if(mpMode == 1)
    var RTSPName = g_RTSPName1;
  else if(mpMode == 2)
    var RTSPName = g_RTSPName2;
  else if(mpMode == 3)
    var RTSPName = g_RTSPName3;
 
  var o='';
  
    if(g_isIPv6)
    //because ipv6 not support rtsp.
        var host = g_netip;
    else
        var host = g_host;

  o+='<object id="qtrtsp_object" width="0" height="0" codebase="http://www.apple.com/qtactivex/qtplugin.cab" ';
        o+='classid="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B" type="video/quicktime">';
  o+='<param name="src" value="http://'+host+":"+g_Port+'/qt.mov" />';
  o+='<param name="autoplay" value="true" />';
  o+='<param name="controller" value="false" />';
  o+='<param name="qtsrc" value="rtsp://'+host+':'+g_RTSPPort+'/'+RTSPName+'"/>';
  o+='</object>';
  //alert(o);
  DW(o);
}

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.

Установка сервера

Итак, камера установлена, протестирована с десктопными плеерами и готова к вещанию через сервер. С помощью whatismyip.com определяем внешний IP-адрес камеры. В нашем случае это был 178.51.142.223. Осталось сказать роутеру, чтобы при обращении по RTSP на порт 554 входящие запросы передавались на IP-камеру.

Забиваем соответствующие настройки в маршрутизатор…



…и проверяем внешний 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 выше).

Настройка сервера на этом заканчивается, можно проверить его работу:

Открываем страницу web-клиента index.html в браузере(для этого на тот же сервер Амазон был установлен апач командой yum -y install httpd):

http://54.186.112.111/wcs_media_client/?id=rtsp://webrtc-ipcam.ddns.net/live1.sdp

Здесь webrtc-ipcam.ddns.net — это бесплатный домен, полученный через сервер динамического DNS noip.com, который ссылается на наш внешний IP адрес. Маршрутизатору мы сказали перенаправлять RTSP запросы на 192.168.1.34 в соответствии с правилами трансляции сетевых адресов NAT (также см. выше).
Параметр id=rtsp://webrtc-ipcam.ddns.net/live1.sdp задает URL потока для воспроизведения. WebRTC сервер запросит потоки с камеры, обработает их и отдаст браузеру на воспроизведение по WebRTC. Возможно ваш роутер поддерживает DDNS. Если нет, то такая поддержка есть у самой IP камеры:



А так поддержка DDNS выглядит в самом роутере:



Теперь можно приступить к тестированию и оценить результаты.

Тестирование

После открытия ссылки в браузере идет подключение к WebRTC серверу, который отсылает запрос к IP-камере на получение видеопотока. Весь процесс занимает несколько секунд.



В это время устанавливается соединение браузера с сервером по вебсокетам, далее сервер запрашивает IP камеру по RTSP, получает поток H.264 по RTP и транскодирует его в VP8 / SRTP — который в итоге воспроизводит WebRTC- браузер.



Далее после небольшого ожидания, отображается уже знакомая картинка.



В нижней части видео отображается URL видеопотока, который можно скопировать и открыть для просмотра из другого браузера или таба.

Убеждаемся что это действительно WebRTC.

Вдруг наc обманули, и видео с IP камеры снова идет по HTTP? Не будем праздно лицезреть картинку, а проверим, что за трафик мы получаем на самом деле. Конечно же снова запускаем Wireshark и консоль отладки в Chrome. В консоли Chrome браузера можем наблюдать следующее:



На этот раз ничего не мелькает и не видно никаких картинок, передающихся по HTTP. Все что мы видим на этот раз — это Websocket фреймы и большинство из них относятся к типам ping/pong для поддержания Websocket-сессии. Интересные фреймы: connect, prepareRtspSession и onReadyToPlay — именно в таком порядке осуществляется установка подключения к серверу: сначала коннект по Websocket, а потом запрос потока на воспроизведение.

А вот что показывает chrome://webrtc-internals



По показаниям графиков, мы имеем битрейт с IP камеры 1Mbps. Исходящий трафик тоже есть, скорее всего это RTCP и ICE пакеты. RTT до Amazon сервера составляет около 300 миллисекунд.

Теперь заглянем в Wireshark, там отчетливо видно UDP трафик с IP адреса сервера. На картинке ниже пакеты по 1468 байт. Это и есть WebRTC. Точнее SRTP пакеты несущие VP8 видео фреймы, которые мы можем наблюдать на экране браузера. Кроме это проскакивают STUN запросы(самый нижний пакет на картинке) — это WebRTC ICE заботливо проверяет соединение.



Стоит также отметить сравнительно малую задержку (пинг до дата-центра составил порядка 250 мс) воспроизведения видео. WebRTC работает по SRTP/UDP, а это как ни крути наиболее быстрый способ доставки пакетов, в отличии от HTTP, RTMP и других TCP-подобных методов стриминга. Т.е. задержка, видимая глазом должна составлять RTT + время буферизации, декодирования и воспроизведения браузером. Визуально в данном случае так и есть — глаз почти не видит задержку, она менее 500 миллисекунд.

Следующий тест — подключение других зрителей. Удалось открыть 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.

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

• WebRTC
• , ip camera
• , видео трансляция
• , онлайн трансляция
• , потоковое видео