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

В предыдущей заметке я рассказал начало истории создания нашего первого продукта - 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. Это разнообразные "ютюбоподобные" сервисы, которые зарабатывают на подписке для доступа к контенту.
Также появились ряд "побочных" юзкейсов, которые немедленно или были реализованы, или поставлены в очередь задач.

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

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

Но об этом в следующей заметке.