Лучшие статьи и кейсы стартапов
Включить уведомления
Дадим сигнал, когда появится
что-то суперстоящее.
Спасибо, не надо
Вопросы Проекты Вакансии
Light-weight streaming media server
Рекомендуем
Продвинуть свой проект
Лучшие проекты за неделю
45
Битрикс24

Битрикс24

www.bitrix24.ru

15
GIFTD

GIFTD

giftd.tech

13
Aword

Aword

Приложение для изучения английских слов

12
Логомашина

Логомашина

logomachine.ru

12
Convead

Convead

convead.ru

11
Devicerra

Devicerra

devicerra.com

11
Eczo.bike

Eczo.bike

www.eczo.bike

11
Flowlu

Flowlu

flowlu.ru

10
Отследить-посылку

Отследить-посылку

отследить-посылку.рф

10
KEPLER LEADS

KEPLER LEADS

keplerleads.com

Показать следующие
Рейтинг проектов
Подписывайтесь на Спарк в Facebook

Свой медиа-сервер

2 919 2 В избранное Сохранено
Авторизуйтесь
Вход с паролем
В предыдущей заметке я рассказал начало истории создания нашего первого продукта - WMSPanel, панели управления медиа-серверами Wowza. Рассказ остановился на осени 2012 года, когда мы получили статус Wowza Product Partner.

Функциональность росла, как на дрожжах. К началу 2013 года панель уже умела через установленного агента не только снимать статистику, но и защищать потоки от hotlinking-а, а так же управлять настройками сервера. Поскольку панель давала централизованный доступ ко всем серверам, то работа "больших парней" с большим числом серверов сильно упрощалась. Например, чтобы создать новое приложение с потоками для нового клиента на 20 серверах, нашему пользователю достаточно определить через конфигурацию приложения один раз и отметить галочками, на каких серверах потоки этого клиента будут обслуживаться.

В общем, клиентов на пробный период прибывало всё больше, многие после двух пробных недель оставались и подписывались. Устойчивая обратная связь давала пищу для планов на будущие фичи и даже позволяла грамотно расставлять приоритеты - чем больше что-то просят, тем выше стоит задача.

Однако стал заметен и другой процесс. Многие начали интересоваться поддержкой других продуктов, где есть работа с progressive download, также известный как псевдо-стриминг. К сожалению, при всей универсальности Wowza, она с этим протоколом не работает. Поэтому нас начали спрашивать - а не планируем ли мы поддержать эти продукты, также, как мы сделали поддержку Wowza и Windows Media? Самый популярный продукт из этой ниши - Nginx, у него есть соответствующие модули - как для MP4, так и для FLV. Также массово спрашивали и про работу с ShoutCast / IceCast - это протоколы вещания онлайн-радио, до сих пор весьма популярные во многих странах.
Со стороны расчёта статистики - многим нравится наш облачный подход, когда не надо ставить себе на сервер "ещё одну парсилку логов", а можно просто заплатить мелкую денежку и смотреть отличные графики через удобный интерфейс. Да и защита от ре-стриминга многим понравилась, не на всех платформах она есть, прямо скажем.

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

Мы к вопросу подошли более системно и обдумали, что же нужно будет типичному клиенту на самом деле. "Им ведь не nginx нужен" - подумали мы. А что же было нужно типичному клиенту, уходящего в сторону дешевого решения?
  1. Лёгковесный софт, поднимающийся на дешевом железе - хоть реальном, хоть виртуальном. В этом nginx силён, как никто другой.
  2. Софт, который сможет принимать и раздавать медиаданные по самым ходовым протоколам. Да, с правильными модулем nginx умеет процессить псевдостриминг, но не ShoutCast.
  3. Некое решение, которое позволит собирать статистику. Сейчас всё, что есть у пользователей nginx - это стандартные "парсилки логов", умеющие далеко не всё из того, что нужно рядовому стримеру. То есть потребовалось бы написать плагин для связи с нашим сервисом по аналогии с плагином для Wowza.
  4. Это некое решение должно ставиться на сервер легко и просто. Это проблема, т.к. установка плагина для nginx требует пересборки этого веб-сервера.
  5. Кроме того, от нас явно хотели поддержки нашей технологии защиты от ре-стриминга. А значит, опять таки, нужно сильно "допиливать" плагин nginx.
  6. Также шли другие запросы на функциональность, которые также требовали плотного ознакомления с кодовой базой сервера и серьёзной разработки в рамках его архитектуры. Например, раздача HLS потока из обычных MP4 медиа-файлов. Это есть и в Wowza, а в nginx это было реализовано только в рамках платной версии Nginx Plus.
Итого получается, что собственно nginx упрощал нам решение задач 1 и 2, то есть он давал бы нам базис для обработки большого числа входящих соединений и вообще грамотную работу с ресурсами системы. Однако сверх этого нам всё равно нужно было бы много написать самим. Надо сказать, что члены нашей команды обладают опытом промышленной разработки программных систем самой разнообразной сложности, и у всех был опыт сопровождения и активной разработки в рамках существующих систем и архитектур. А значит, мы прекрасно представляли, что это такое - влезть с многомегабайтную кодовую базу и начать что-то на её основе делать. Как обычно бывает в этих случаях, немало сил ушло был на то, чтобы грамотно вписать наши идеи в существующее мироустройство внутри nginx-а.

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

Для начала реализации выбрали несколько сценариев, которые хотелось бы покрыть в первую очередь.
  1. Progressive download.
  2. ShoutCast и IceCast.
  3. Стриминг предварительно подготовленных статических файлов MP4 в HLS.
  4. Ре-стриминг HLS с уже работающих медиа-серверов вроде Wowza.
  5. Стриминг в HLS из входящего потока RTMP.
  6. Работа с прочими протоколами на базе HTTP, в первую очередь SmoothStreaming и MPEG-DASH.
Пункты 4 - 6 появлялись по ходу общения с клиентами, у которых аппетит приходил во время еды. Ведь если мы сможем сделать один HTTP-based протокол, то почему бы не зацепить и статистику с другого, чем-то похожего? Сразу стало понятно, что делать серьёзный упор на бинарные протоколы RTMP и RTSP смысла нет. Даже ре-стриминг из RTMP предполагалось делать в HLS. Здесь всё просто - протоколы на базе HTTP очень активно завоёвывают рынок вследствие своей простоты и относительно малых накладных расходов на транспортировку. Здесь как раз выделяются протоколы HTTP Live Streaming (HLS) от Apple и набирающий обороты MPEG-DASH от одноимённого индустриального консорциума. Не будем вдаваться в подробности - почему именно они, скажу только, что HLS стал негласным лидером в передаче данных на различные устройства, а DASH - универсальный стандарт, идущий на смену HLS.

Итак, было принято решение "писать своё". Именно этим и занялись. В январе 2013 была начата работа, а уже в апреле был выложен первый релиз, умевший не только очень хорошо работать с большим числом входящих соединений, но и производить полезную работу - ре-стримить HLS и раздавать контент через псевдостриминг. Надо ли говорить, что с первого дня этот сервер умел выдавать статистику для WMSPanel с последующим её показом в контрольной панели? Там же, в панели, можно было задавать основные настройки работы. Первая версия ставилась только на Ubuntu в силу её популярности и удобства пакетной установки. Именно так сразу и была сделана установка - пара команд в консоли для менеджера пакетов, запуск сервиса - и всё, он уже ждёт поступающих запросов. Итого, меньше 4 месяцев - и у нас есть базис для дальнейшей работы.

После определённых раздумий было принято название Nimble Streamer. Nimble - значит шустрый, юркий, быстрый. Тот, кто решает вопросы быстро, но без лишней суеты - в общем, "сращивает", как говорят у нас во Владивостоке.

Так что "шустрый стример" начать жить и активно двигаться вперёд. К настоящему моменту панель даёт всю статистику, доступную для Wowza Media Server. Сам Нимбл предоставляет защиту от ре-стриминга и фреймворк для построения систем pay-per-view - аналогичная функциональность уже была создана для Wowza, мы реализовали её на новой платформе, заодно несколько улучшив.

Наиболее популярны сценарии, связанные с HLS.

В первую очередь, это создание своих сетей доставки контента, где Wowza выступает в качестве центра подготовки стримов, а Nimble ставится между этим центром и конечными пользователями для равномерного распределения нагрузки и увеличения отказоустойчивости. Этот сценарий популярен среди компаний, занимабщихся живыми трансляциями. В этом случае и управление Вовзой, и снятие статистики с Нимбл-серверов производится в одной и той же панели.

Второй популярный сценарий - раздача VOD-контента из файлов MP4 в поток HLS. Это разнообразные "ютюбоподобные" сервисы, которые зарабатывают на подписке для доступа к контенту.
Также появились ряд "побочных" юзкейсов, которые немедленно или были реализованы, или поставлены в очередь задач.

Аппетиты клиентов, конечно же, не уменьшаются - новые идеи приходят регулярно. Ну и хорошо. Хуже всего в работе над новым продуктом - отсутствие обратной связи. Если её нет - что-то явно идёт не так. Ну а раз она есть и не ослабевает - мы на правильном пути.

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

Но об этом в следующей заметке.
0
Добавить в избранное Сохранено
Авторизуйтесь
Вход с паролем
Первые Новые Популярные
Dmitry
это ведь не оригинальная статья? где оригинальный источник?
Ответить
Nimble Streamer
Light-weight streaming media server
Yury Udovichenko
Эта заметка написана специально для данного блога.
Ответить
Выбрать файл
Читайте далее
Загружаем…
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать