Вы, возможно, удивитесь, но телевидение всё ещё живо. Да, аудитория поредела и «состарилась», а технологии приумножились и помолодели (IPTV, SmartTV, различные приставки), но всё-таки жизнь есть не только в YouTube и TikTok. Мало того, сейчас сделать свой телеканал можно при достаточно небольших инвестициях времени и финансов. В 2017 году мой брат (Ruler-ufa) попросил меня о помощи с технической реализацией нового музыкального телеканала на башкирском и татарском языках. О том, что у нас получилось, и пойдёт речь в этой статье. Сразу оговорюсь, что нюансов подбора контента, оформления эфира и подобных тем здесь не будет, т.к. я занимался исключительно технической частью. Кроме того, задача была сделать все максимально просто и дёшево, т.к. бюджет был ограничен, поэтому некоторые вещи можно было сделать по-другому — правильнее, но гораздо дороже.

DISCLAIMER! Все упомянутые решения, компании, партнеры и операторы — лишь отражение нашего личного опыта, а не реклама.

Создание картинки и генерация видеопотока

Что такое телеканал? По сути, это бесконечный аудиовидеопоток. И его необходимо как-то генерировать.

Сначала пара слов о том, как это происходит на «больших» телеканалах. Их сердцем можно назвать ЦА — центральную аппаратную (в телецентрах поменьше она называется КРА — коммутационно-распределительная аппаратная) — помещение с коммутатором, большим микшерным пультом и кучей мониторов. На коммутатор приходят сигналы с головной станции (если это региональный филиал), со всех аппаратно-студийных блоков (АСБ), с различных видеосерверов и с другого ПО — например, титровального.

Что такое АСБ? В общем случае — это другая аппаратная и студия, ответственные за производство конкретной программы в прямом эфире — например, новостей. Центральная аппаратная связывает воедино все АСБ и иные входы и решает, что пойдёт в эфир в конкретный момент времени. Ну а видеосерверы создают линейный эфир, т.е. эфир по расписанию — всё то, что не является «прямым эфиром». Кроме того, они могут генерировать, например, настроечную таблицу, сигнал часов и т.п. На выходе центральной аппаратной — аудиовидеопоток, который отправляется на передающее оборудование, спутник, сети распространения и т.д. Пример работы АСБ программы «Время» на Первом канале:



А теперь спустимся с небес на землю и сделаем всё чуть проще! Поскольку необходимости в прямых эфирах на нашем телеканале нет, всю аппаратную мы можем реализовать в качестве одного-единственного сервера. Так как кодирование видео — процесс затратный, а делать это нам придётся круглосуточно, железо должно соответствовать:

• Intel Core i7-7700K (с интегрированной Intel® HD Graphics 630),
• RAM 24 Gb,
• Windows 10 Pro,
• 3 сетевые карты — для интернета и отправки потока.

Сам сервер мы расположили в одном из дата-центров Уфы. Его выбор был не случаен — именно там располагается инфраструктура самых крупных в Уфе провайдеров телевидения и интернета. Благодаря такому размещению, доставка сигнала до этих операторов стала достаточно тривиальной задачей.

С железом разобрались, переходим к софту. В качестве ПО для генерации картинки мы выбрали Форвард ТС компании «СофтЛаб-НСК», поскольку уже имели опыт работы с ним. Этот комплекс предоставляет широкий спектр возможностей для организации цифрового вещания и используется большим количеством телеканалов стран бывшего СНГ и не только. Список фич, которые используем мы:

• подготовка эфира и составление расписания;
• оформление эфира (титрование);
• кодирование потока в H.264/MP3 и упаковка в MPEG-TS;
• передача потока по UDP Multicast.

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

Составление расписания эфира происходит в программе FDOnAir. Большую часть времени инженер эфира проводит именно в ней. Кроме того, здесь же происходит управление заранее подготовленными титрами при помощи команд в расписании и группы кнопок в верхней части интерфейса.

Настройка pipeline’а (по-русски это обычно называют «тракт») происходит в другой программе — SLStreamerPro.



Тут следует уточнить, что кроме Форвард ТС, Софтлаб имеет и более старую версию системы, которая работала, используя плату-расширение PCI. Итоговая картинка забиралась с платы при помощи физического соединения этой платы с остальным трактом, который преимущественно представлял из себя различные аппаратные компоненты. Сейчас большинство каналов вещает в цифре, но плата никуда не делась, просто теперь она — виртуальная.

На графе видно, что эта самая плата является источником сигнала, с неё в граф попадает несжатый аудиовидеопоток (RAW). Затем он кодируется в определённый формат, в нашем случае — H.264/MP3. Да, именно MP3, а не AAC, поскольку не все телевизоры могут воспроизвести AAC, а поток доходит до конечных телевизоров в неизменном виде — операторы просто доставляют его от телеканалов до зрителей, никак не изменяя.

Заключительная группа компонентов графа — получатели потока. Мы используем UDP Multicast и HLS segmenter. Первый нарезает MPEG-TS на UDP-дейтаграммы и отправляет на сетевую карту, а второй — на HLS-манифест и сегменты и складывает их на диск, чтобы мы могли опубликовать их с помощью IIS. Кстати, ffmpeg забирает сигнал тоже с помощью UDP Multicast, но не через реальную сетевую карту, а через loopback (об этом совсем скоро).

Доставка до кабельных операторов и медиасервисов

Теперь, зная, каким образом картинка рождается, остановимся чуть подробнее на том, как она попадает в конечные устройства зрителей. А происходит это, как правило, через посредников.

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

Но и тут возникают проблемы. Сам сервер расположен в каком-то определённом месте — да хоть на кухне, это не так важно (шутки шутками, но именно там он и стоял первые пару месяцев). Вещательный сервер один, а операторов много, и у каждого свои точки присутствия. Что же делать в таком случае? Как отдать картинку всем?

Тут есть два наиболее распространённых подхода. Первый — поднять сигнал на спутник. Практически все операторы имеют техническую возможность забрать его оттуда и распространить на своих абонентов. Минус один — это очень дорого. Примерная стоимость — сотни тысяч рублей в месяц.

Второй — доставлять сигнал по земле через специализированных посредников. Самый популярный — компания Медиалогистика, филиал MSK-IX. Что она делает: по локальной сети дата-центра (как правило, Останкино или M9) забирает ваш сигнал и по своей наземной инфраструктуре оптоволоконных сетей доставляет его до операторов по всей стране. Краткий ролик о том, как всё это работает:



Цена кусается уже не так сильно (десятки тысяч рублей в месяц), но всё ещё дорого для нашего случая. В этом смысле нам повезло — канал у нас на национальном языке, поэтому и большая часть аудитории расположена на вполне конкретной территории. Мы нашли дата-центр в Уфе с максимальным присутствием самых крупных кабельных операторов и разместили сервер там. Всё остальное — дело техники: с помощью выхода UDP Multicast отдать поток на сетевую карту и попросить сетевых инженеров направить этот поток по локальной сети на приёмный сервер оператора. Таким образом мы покрыли трёх самых крупных в Уфе операторов. Ещё один регион с большой аудиторией — Татарстан. Там мы сотрудничаем с другим крупным кабельным оператором; сигнал для них мы отправляем через магистральную сеть компании «ТрансТелеком».

Есть и такие операторы (на самом деле, их у нас большинство), которые готовы принять сигнал через «дикий» интернет. Как правило, забирают они его в формате HLS, для этого они получают ссылку вида streaming.matur-tv.ru/hls/h264_aac/stream.m3u8. В очень редких случаях партнёр (например, Яндекс.Эфир) не имеет технической возможности принять HLS, тогда мы можем отдать картинку по RTMP (pull) либо через HTTP-TS. Последний представляет собой HTTP-ссылку, которая, в отличие от сегментов HLS, является бесконечным виртуальным файлом с потоком MPEG-TS.

Поскольку операторов становится уже слишком много, ПО «Форвард» не поддерживает протокол RTMP и является недостаточно гибким, а также нам нужно иметь публичный HLS-поток для сайта и мобильного приложения (в случае DDoS-атаки на сервер не хотелось бы, чтобы умер весь эфир), мы решили развернуть ещё два виртуальных сервера — только для ретрансляции потока. Один —для операторов и сервисов, второй — для публичного стриминга.



Основные инструменты, с помощью которых мы реализовали ретрансляцию — это ffmpeg и nginx rtmp module. Об ffmpeg, думаю, слышал хоть раз практически каждый. Это «швейцарский нож» в деле обработки и конвертирования аудио-видео. С помощью этой мощной утилиты мы вытаскиваем поток из pipeline’а «Форвард» и по RTMP отправляем на первый сервер ретрансляции. Там сигнал принимает nginx, который нарезает его на HLS и раздаёт всем операторам, у кого есть ссылка, а также отправляет его в YouTube, ВКонтакте и на второй сервер ретрансляции. Второй сервер практически ничем не отличается, только он не отправляет сигнал в YouTube и ВКонтакте и предназначен для раздачи потока для пользователей сайта и мобильного приложения.

Мониторинг

Отлично! Теперь у нас всё работает, и зрители могут наслаждаться музыкой! Но всегда есть «но». Чем сложнее система, тем чаще она ломается. А когда она частично или полностью является набором из бесплатных open-source-решений, соединённых воедино — это происходит ещё чаще. Не хотелось бы расстраивать зрителей отсутствием сигнала, и тут нам поможет мониторинг.



Велосипедов изобретать мы не стали, а развернули еще один сервер с Zabbix на борту и мониторингом всех трёх (четырёх вместе с Zabbix) серверов. Для удобства настроили оповещения в два чата в Telegram: один для незначительных проблем технического характера, второй для серьёзных аварий с полным или частичным отсутствием изображения. Теперь у нас есть мониторинг базовых метрик серверов. Но, как правило, с самими ОС всё хорошо, а нам ещё нужен мониторинг непосредственно медиапотока.

К сожалению, никаких готовых plugin‘ов «под ключ» мы не нашли. Взяв за основу этот template (спасибо, Diversantos!) и немного доработав, мы получили следующие метрики для каждого из наших HLS-потоков:

• существование сегмента;
• размер сегмента;
• время загрузки сегмента;
• продолжительность сегмента;
• громкость звука (добавили мы);
• индекс структурного сходства (добавили мы).

Используя всё это, плюс встроенные возможности Zabbix, мы создали несколько важных для нас триггеров:

• Битрейт нестабилен;
• Сегмент не найден;
• Загрузка сегмента заняла более 200 мс;
• Продолжительность сегмента менее 4 секунд;
• В потоке зафиксирована тишина;
• В потоке зафиксировано статичное изображение;
• Трансляция на сайте и в мобильном приложении недоступна;
• Трансляция в YouTube недоступна;
• Трансляция ВКонтакте недоступна.

Теперь, в любой момент дня и ночи, именно мы первыми узнаём о каких-то технических проблемах с эфиром, а не наши зрители.

Заключение

Как видите, усилиями нескольких человек, имея пару серверов и небольшой бюджет, можно создать настоящий телеканал. Конечно, SLA будет далеко не «пять девяток», но это всё равно будет настоящее телевидение! Наш канал проработал уже 3 года и не собирается на этом останавливаться.

Зачем нужны эти знания? Есть много примеров региональных, отраслевых, тематических телеканалов, а также телеканалов, принадлежащих отдельным информационным агентствам. А что мешает организовать корпоративный телеканал? В компании, где работает несколько сотен человек, внутренние коммуникации очень важны.

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



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