Все началось с того что нам привезли несколько тюнеров PBI DCH-4000P-S42 Вот таких приблизительно:
По характеристикам сие чудо китайской промышленности приближается к профессиональным тюнерам, но при несопоставимо низкой цене. Изначально предполагалось использовать эти тюнера для замены зоопарка, который начинался Openbox-ами и Glob-ами и заканчивался Vantag-ами, а также для реализации DVB-C по HFC и некоего подобия DVB-S при помощи Митрис-а. Беглое изучение документации показало что кроме требуемых от него изначально (и не интересных) выходов ASI,SDI, A/V, RGB, CVBS, XRL оное еще умеет и IP input or output with UDP/RTP (optional) а также Multicast and Unicast on IP что уже намного интереснее и профильнее как бы. Есть такое профессиональное заболевание – обязательно потрогать ручками что-то, где есть хотя бы намек на сетевые возможности.
Первой мыслью было что-то типа «А давайте играть в IPTV, раз оно уже почти внутри»
Изначальные условия
1. Есть старая аналоговая КТВ сеть покрывающая где-то 90% всего города, в которой живет DOCSIS 2.0
2. Есть FTTB сеть покрывающая около 95% всех многоэтажных застроек города и во многих местах пересекающаяся с КТВ сетью
3. FTTB состоит из свитчей, в основном Zyxel GS-4012F, Zyxel GS-3012F, Zyxel ES-2108, Foxgate S-6024-S2L2, S-6008-S2L2, Foxgate S-6208-S1, Foxgate S-6024-S4L2 и прочего зверинца всего модельного ряда Foxgate.
4. У всех вышеуказанных дивайсов в мануалах было обозначено, что они умеют и igmp snooping и multicast support.
5. Неприятным фактом конечно было то, что на 90% всех этих железок к абонентам шли 100Mbit/s медные порты но для testing purposes все это годилось вполне (заменить несколько сотен свичей как-бы «для поиграться» не планировалось)
Черная магия
Первое что пришло в голову, это просто настроить тюнера на неких 6 открытых каналов на каком-то одном транспондере. А далее наклонцать, заявленный в мануале multicast и ткнуть это все в свитч стоящий в ядре FTTB сети. Что без длительных раздумий и было сделано с имеющимися под руками тестовыми тюнерами. Первые подозрения в несостоятельности подобной затеи закрались через 40 секунд после внезапно осуществившегося в саппорт шквала звонков. При беглом взгляде на самопальную мониторилку свитчей оказалось что в момент втыкания ресивера в ядерный свитч примерно одновременно отваливается около ¼ сети. Странно, но все же повторяем втыкание 1 ресивера в свич и по начавшейся практически сразу панике на саппорте понимаем что дело не чисто. Более детальное изучение проблемы показывает, что выпадают из сети две самых ранних модельки Foxgate, со старыми прошивками при виде любого даже 4 мегабитного (1 канал в SD) мультикаста. Если быть точным то самая ранняя и дешевая 6208 вообще уходит в астрал до прекращения вещания а 24 портовая модель при IP-зомбоящика начинала пингаться под 900мс и с адским пакетлозом (ну а что ж вы хотели за такие смешные деньги – тобишь при цене раза в 2 меньше аналогичных решений от Zyxel).
Вторым камешком в огород изначальной идеи оказалось то, что в имевшейся на то время последней прошивке для этих ресиверов максимальный TTL который можно было указать было 5 что как-бы не особо согласовалось с реалиями имеющейся к тому времени инфраструктуры. Кроме того вспомнились абоненты DOCSIS которые может тоже хотят видеть «зомбоящик через интернеты».
Последних два фактора отсекли желание вырезать избирательно на L3 не переносящие мультикастового вещания дивайсы, и подумать над другими вариантами. Юникастить на конкретных людей с ресивера тоже оказалось глупой идеей и мы ее отбросили сразу.
После непродолжительного гугления и раздумий самым простым и очевидным (а еще пионерско-кустарным) решением показалось просто ловить мультикаст на одну машинку с установленным VLC и оборачивать полученную картинку в HTTP.
Так как никто никакие железки покупать не собирался собрали из подножного корма нечто конфигурации P4 2.4GHz/1Gb RAM/Какой-то винт из ящика стола/2 сетевухи. Была установлена фря 7.1 и VLC 0.8.6i. Все это было собрано в следующую конструкцию:
Конфиг vlc.cfg выглядел следующим образом:
Собственно в нем все понятно и логично – ловим бродкаст 239.0.0.х с сетевухи fxp0 после чего отдаем его с сетевой fxp1 уже обернутый в http с портов 8011, 8012 итд. Никаких особенных нюансов во всем этом нет, если не забыть написать раут на бродкастную сеть сквозь нужный интерфейс (route_broad=«239.0.0.0/24 192.168.8.8»).
Далее можно запускать все это скриптом вида
и начинать радоваться жизни.
Следующим шагом было просто и непринужденно перекинуть все это на существующий медиасервер к которому у пользователей максимальная скорость. Для этого мы собираем portfwd с конфигом для тех же двух показанных для примера каналов вида:
Запускаем форвардилку командой portfwd –c /usr/local/etc/portfwd.cfg и тестим при помощи того же VLC. Далее идем в Википедию читать описание формата M3U и строим плейлист который и будем раздавать пользователям вместе с инструкцией как таки установить VLC и скормить ему плейлист.
Вот вроде и все работает, машинка вышеуказанной смешной конфигурации ретранслирует 20 каналов (80 Мбит потока с 4 ресиверов) хотя и скрипя зубами. Из неприятных ефектов можно отметить периодические падения VLC в связи с утекающей памятью, что лечиться периодическими рестартами VLC при помощи крона, а также изначальную пионерность и сырость решения по очевидным причинам – один пользователь 4-4.5Мбит, сто очевидно уже под полгигабита. Но для чисто ради интереса и отсутствии желания финансировать нечто более серьезное вполне сойдет. Кроме того пользователи подключенные при помощи технологии DOCSIS таки смогут это смотреть в отличии от других вариантов.
Естественно аналогичным макаром можно ловить каналы при помощи DVB карточки, либо просто показывать кино с файлопомойки – тут уже как фантазия работает/ресурсы позволяют.
Как дальнейшее развитие идеи можно рассматривать написание простенькой примочки к биллингу позволяющей формировать пользователю свой предоплаченный плейлист с нужными ему каналалами и разграничение банальным рассовыванием оных в таблички ipfw с allow/deny по соответствующим портам трансляции. Но об этом в следующий раз.
Хабраюзер miver подсказал воспользоваться в целях конвертации UDP Multicast -> HTTP продуктом по имени udpxy который является судя по его «документации» ничем иным чем «UDP-to-HTTP multicast traffic relay daemon». Всетаки мир не без добрых людей ибо все просто блещет скоростью и простотой.
Установка:
Использование исходя из нашего примера:
И пользовательский плейлист будет иметь соответственно вид:
Работает при нагрузке не сопоставимо ниже чем VLC на тех же задачах уже пол дня. Вроде без неожиданностей. Единственное что угнетает — продукт отлично документирован на Си. Собственно на тему правки опций рекомендую смотреть uopt.h.
Послесловие
1. Отдельную благодарность хотелось бы выразить хабрапользователю mkrentovskiy за неоценимую помощь с VLC. Собственно все знания по данному вопросу и теории поточного вещания в целом — почерпнуты от из его интереснейшего блога (очень рекомендую, одни статьи про wowza чего стоят) и при личном общении. Еще раз спасибо, что есть люди просто ради интереса готовые потратить личное время на помощь в вот таких вот развлечениях.
2. Как тестовая реализация, собранная за пол рабочего дня – вполне может быть. Но да – не для серьезного продакшена.
3. Да я не грамотен, я знаю. Язык не родной, в школе не учили, хотя догадываюсь это слабая отмазка. Если вы воспринимаете пропущенную запятую как личное оскорбление – приношу извинения заранее. Честно – я не хотел.
4. Прошивка с возможностью указать нормальный TTL и гламурным вебинтерфейсом появилась значительно позже.
5. Можно сделать проще и «концептуальнее» — засунуть ресивер одним концом в свич и мультикастнуть — правда не так весело получиться да и статья из 1 строчки вроде как не такая занимательная будет.
По характеристикам сие чудо китайской промышленности приближается к профессиональным тюнерам, но при несопоставимо низкой цене. Изначально предполагалось использовать эти тюнера для замены зоопарка, который начинался Openbox-ами и Glob-ами и заканчивался Vantag-ами, а также для реализации DVB-C по HFC и некоего подобия DVB-S при помощи Митрис-а. Беглое изучение документации показало что кроме требуемых от него изначально (и не интересных) выходов ASI,SDI, A/V, RGB, CVBS, XRL оное еще умеет и IP input or output with UDP/RTP (optional) а также Multicast and Unicast on IP что уже намного интереснее и профильнее как бы. Есть такое профессиональное заболевание – обязательно потрогать ручками что-то, где есть хотя бы намек на сетевые возможности.
Первой мыслью было что-то типа «А давайте играть в IPTV, раз оно уже почти внутри»
Изначальные условия
1. Есть старая аналоговая КТВ сеть покрывающая где-то 90% всего города, в которой живет DOCSIS 2.0
2. Есть FTTB сеть покрывающая около 95% всех многоэтажных застроек города и во многих местах пересекающаяся с КТВ сетью
3. FTTB состоит из свитчей, в основном Zyxel GS-4012F, Zyxel GS-3012F, Zyxel ES-2108, Foxgate S-6024-S2L2, S-6008-S2L2, Foxgate S-6208-S1, Foxgate S-6024-S4L2 и прочего зверинца всего модельного ряда Foxgate.
4. У всех вышеуказанных дивайсов в мануалах было обозначено, что они умеют и igmp snooping и multicast support.
5. Неприятным фактом конечно было то, что на 90% всех этих железок к абонентам шли 100Mbit/s медные порты но для testing purposes все это годилось вполне (заменить несколько сотен свичей как-бы «для поиграться» не планировалось)
Черная магия
Первое что пришло в голову, это просто настроить тюнера на неких 6 открытых каналов на каком-то одном транспондере. А далее наклонцать, заявленный в мануале multicast и ткнуть это все в свитч стоящий в ядре FTTB сети. Что без длительных раздумий и было сделано с имеющимися под руками тестовыми тюнерами. Первые подозрения в несостоятельности подобной затеи закрались через 40 секунд после внезапно осуществившегося в саппорт шквала звонков. При беглом взгляде на самопальную мониторилку свитчей оказалось что в момент втыкания ресивера в ядерный свитч примерно одновременно отваливается около ¼ сети. Странно, но все же повторяем втыкание 1 ресивера в свич и по начавшейся практически сразу панике на саппорте понимаем что дело не чисто. Более детальное изучение проблемы показывает, что выпадают из сети две самых ранних модельки Foxgate, со старыми прошивками при виде любого даже 4 мегабитного (1 канал в SD) мультикаста. Если быть точным то самая ранняя и дешевая 6208 вообще уходит в астрал до прекращения вещания а 24 портовая модель при IP-зомбоящика начинала пингаться под 900мс и с адским пакетлозом (ну а что ж вы хотели за такие смешные деньги – тобишь при цене раза в 2 меньше аналогичных решений от Zyxel).
Вторым камешком в огород изначальной идеи оказалось то, что в имевшейся на то время последней прошивке для этих ресиверов максимальный TTL который можно было указать было 5 что как-бы не особо согласовалось с реалиями имеющейся к тому времени инфраструктуры. Кроме того вспомнились абоненты DOCSIS которые может тоже хотят видеть «зомбоящик через интернеты».
Последних два фактора отсекли желание вырезать избирательно на L3 не переносящие мультикастового вещания дивайсы, и подумать над другими вариантами. Юникастить на конкретных людей с ресивера тоже оказалось глупой идеей и мы ее отбросили сразу.
После непродолжительного гугления и раздумий самым простым и очевидным (а еще пионерско-кустарным) решением показалось просто ловить мультикаст на одну машинку с установленным VLC и оборачивать полученную картинку в HTTP.
Так как никто никакие железки покупать не собирался собрали из подножного корма нечто конфигурации P4 2.4GHz/1Gb RAM/Какой-то винт из ящика стола/2 сетевухи. Была установлена фря 7.1 и VLC 0.8.6i. Все это было собрано в следующую конструкцию:
Конфиг vlc.cfg выглядел следующим образом:
new channel11 broadcast enabled
new channel12 broadcast enabled
….
setup channel11 input udp://@239.0.0.1:1234
setup channel11 output #standard{access=http,mux=ts,dst=my.hostname:8011}
setup channel12 input udp://@239.0.0.2:1234
setup channel12 output #standard{access=http,mux=ts,dst= my.hostname:8012}
….
control channel11 play
control channel12 play
Собственно в нем все понятно и логично – ловим бродкаст 239.0.0.х с сетевухи fxp0 после чего отдаем его с сетевой fxp1 уже обернутый в http с портов 8011, 8012 итд. Никаких особенных нюансов во всем этом нет, если не забыть написать раут на бродкастную сеть сквозь нужный интерфейс (route_broad=«239.0.0.0/24 192.168.8.8»).
Далее можно запускать все это скриптом вида
#!/bin/sh
/usr/local/bin/vlc --daemon --intf telnet --telnet-password gfhjkmnfrjqgfhjkm --vlm-conf /usr/local/etc/vlc.cfg
sleep 3
ps axv|grep vlc|awk '{print $1; exit;}' > /var/run/vlc.pid
и начинать радоваться жизни.
Следующим шагом было просто и непринужденно перекинуть все это на существующий медиасервер к которому у пользователей максимальная скорость. Для этого мы собираем portfwd с конфигом для тех же двух показанных для примера каналов вида:
tcp {
8011 {=>172.40.0.121:8011}
}
tcp {
8012 {=>172.40.0.121:8012}
}
Запускаем форвардилку командой portfwd –c /usr/local/etc/portfwd.cfg и тестим при помощи того же VLC. Далее идем в Википедию читать описание формата M3U и строим плейлист который и будем раздавать пользователям вместе с инструкцией как таки установить VLC и скормить ему плейлист.
#EXTM3U
#EXTINF:1,MTV
iptv.domain:8011
#EXTINF:1,QTV
iptv.domain:8012
Вот вроде и все работает, машинка вышеуказанной смешной конфигурации ретранслирует 20 каналов (80 Мбит потока с 4 ресиверов) хотя и скрипя зубами. Из неприятных ефектов можно отметить периодические падения VLC в связи с утекающей памятью, что лечиться периодическими рестартами VLC при помощи крона, а также изначальную пионерность и сырость решения по очевидным причинам – один пользователь 4-4.5Мбит, сто очевидно уже под полгигабита. Но для чисто ради интереса и отсутствии желания финансировать нечто более серьезное вполне сойдет. Кроме того пользователи подключенные при помощи технологии DOCSIS таки смогут это смотреть в отличии от других вариантов.
Естественно аналогичным макаром можно ловить каналы при помощи DVB карточки, либо просто показывать кино с файлопомойки – тут уже как фантазия работает/ресурсы позволяют.
Как дальнейшее развитие идеи можно рассматривать написание простенькой примочки к биллингу позволяющей формировать пользователю свой предоплаченный плейлист с нужными ему каналалами и разграничение банальным рассовыванием оных в таблички ipfw с allow/deny по соответствующим портам трансляции. Но об этом в следующий раз.
Хабраюзер miver подсказал воспользоваться в целях конвертации UDP Multicast -> HTTP продуктом по имени udpxy который является судя по его «документации» ничем иным чем «UDP-to-HTTP multicast traffic relay daemon». Всетаки мир не без добрых людей ибо все просто блещет скоростью и простотой.
Установка:
#wget downloads.sourceforge.net/project/udpxy/udpxy/Chipmunk-1.0/udpxy.1.0-Chipmunk-16.tgz
#tar zxvf udpxy.1.0-Chipmunk-16.tgz
#cd udpxy-1.0-Chipmunk-16/
# gmake && gmake install
Использование исходя из нашего примера:
#udpxy -p 8011 -M 30 -B 2Mb -a 8.8.8.8 -c 15
И пользовательский плейлист будет иметь соответственно вид:
#EXTM3U
#EXTINF:1,MTV
iptv.domain:8011/udp/239.0.0.1:1234
#EXTINF:1,QTV
iptv.domain:8011/udp/239.0.0.2:1234
....
Работает при нагрузке не сопоставимо ниже чем VLC на тех же задачах уже пол дня. Вроде без неожиданностей. Единственное что угнетает — продукт отлично документирован на Си. Собственно на тему правки опций рекомендую смотреть uopt.h.
Послесловие
1. Отдельную благодарность хотелось бы выразить хабрапользователю mkrentovskiy за неоценимую помощь с VLC. Собственно все знания по данному вопросу и теории поточного вещания в целом — почерпнуты от из его интереснейшего блога (очень рекомендую, одни статьи про wowza чего стоят) и при личном общении. Еще раз спасибо, что есть люди просто ради интереса готовые потратить личное время на помощь в вот таких вот развлечениях.
2. Как тестовая реализация, собранная за пол рабочего дня – вполне может быть. Но да – не для серьезного продакшена.
3. Да я не грамотен, я знаю. Язык не родной, в школе не учили, хотя догадываюсь это слабая отмазка. Если вы воспринимаете пропущенную запятую как личное оскорбление – приношу извинения заранее. Честно – я не хотел.
4. Прошивка с возможностью указать нормальный TTL и гламурным вебинтерфейсом появилась значительно позже.
5. Можно сделать проще и «концептуальнее» — засунуть ресивер одним концом в свич и мультикастнуть — правда не так весело получиться да и статья из 1 строчки вроде как не такая занимательная будет.