Делаем свой телеканал



    Вы, возможно, удивитесь, но телевидение всё ещё живо. Да, аудитория поредела и «состарилась», а технологии приумножились и помолодели (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 востребовано, и мы будем развивать его дальше.



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

    Похожие публикации

    Комментарии 15

      +4
      Теперь фраза «Мама, я в телевизоре» стала для меня буквальной)
        0
        Спасибо, очень интересно. Однако я ничего не нашел про часть от генерации видеопотока до доставки его на сервер в датацентре, простым и бюджетным путем. Как устроена студия, камеры, коммутаторы и т.п.
          0
          В нашем случае генерация происходит непосредственно на сервере в дата-центре. От нашего сервера до серверов кабельных операторов сигнал идет по локальной сети ДЦ по UDP Muticast, в MPEG-TS. За пересылку сигнала по локалке денег не берут, так что, решение вполне бюджетное.

          Доставка между Уфой и Казанью, как я уже упомянул, идет по магистрали ТрансТелеком, мы арендуем канал в несколько мегабит. Ничего специально для этого настраивать не пришлось, отдаем MPEG-TS средствами SLStreamerPro на одну из сетевых карт, говорим сетевику ДЦ мультикаст-группу и порт и все, он отдает сигнал на магистраль :) Стоит это удовольствие несколько т.р.

          На счет студии, камер и коммутатора — у нас все это не используется, есть студия, но она не участвует непосредственно в эфире, там происходит запись программ по расписанию.
          Если будет какое-то количество желающих, могу написать об этой кухне в общем. Как говорится, ставим пальцы вверх :)
            0
            Забыл упомянуть. Между вещательным сервером и серверами ретрансляции поток идет по «дикому» интернету. Пока полет нормальный, проблем с этим не было.
              0
              Потом напишите, как будете бороться с потерями UDP поверх «дикого» интернета.
                0
                UDP мы используем только в пределах дата-центра и выделенной магистрали, для интернета — RTMP.

                Были мысли попробовать SRT, но, к сожалению, nginx пока не поддерживает.
                  0

                  А Red 5 не пробовали использовать для рестриминга? У них SRT вроде есть, но только в про версии.

                    0
                    Нет, не пробовали, изучу, спасибо! Какое-то время сидели на Wowza, где платили за количество одновременных зрителей, в какой-то момент стало рентабельней сделать свое решение :)
              0
              Азат, доброго времени суток.
              Не совсем понятно, у Вас продакшн-студия в Казани, транслятор в ДЦ в Уфе, между ними L2VPN от ТТК для доставки контента? Тогда сколько этот несжатый контент заливается через «несколько мегабит»?
              А если у ТТК падает связь — зрители остаются без свежих программ? Или есть резерв на такой случай? Или через «дикий» интернет просто подпихиваете в эфир уже существующий на сервере вещания контент?
              Кстати, а как хранение организовано? RAID на самом сервере? Или по сети смонтирована хранилка?

              Спасибо.
                +1
                Здравствуйте!

                Не совсем так. «Транслятор» и студия у нас в Уфе, но, поскольку, прямых эфиров нет, между студией и вещательным сервером никакой выделенной линии не требуется. Весь эфир — линейный и материалы заливаются заранее через обычный интернет.

                Из Уфы в Казань сигнал идет уже сжатым в H.264/MP3 для кабельного оператора Татарстана, причем, даже не в FullHD, а в SD 720x576 (требование оператора). Если у ТТК падает связь — без картинки остаются абоненты только одного оператора (резерва нет), но пока такого, к счастью, не было.

                Единственный кейс, когда все зрители оставались без эфира — во время профилактики после установки обновлений на Windows сервер не поднялся, пришлось ехать в ДЦ. После этого на всякий случай подключили удаленную консоль. Но все это было ночью в течение 1-2 часов.

                По поводу хранения — на сервере установлено 3 физических диска без RAID, один под систему и два — под контент. Резервирование обеспечивается сторонним облачным сервисом. В случае сбоя, запустим аварийный плейлист и за несколько часов восстановим все материалы из облака.
                  0
                  Спасибо!!!
            +2

            Спасибо за статью!


            Про мониторинг интересно очень! Можете чуть подробнее рассказать про триггеры? Как и что анализировали, и чем? Скармливали куски ffprobe? В каких точках мониторили? Только у себя на выходе или в других местах тоже? Ну и, конечно, интересно про громкость звука и SSIM.

              +2
              Спасибо за отзыв!

              Завтра сяду и напишу развернутый комментарий :)
                +1
                Первые 4 триггера идут из коробки использованного template'а.
                Для определения громкости и SSIM используем такую команду ffmpeg:

                ffmpeg \
                    -y \
                    -t 3 \
                    -i http://streaming.matur-tv.ru/hls/h264_aac/stream.m3u8 \
                    -filter_complex "split[int1][out2]; [0:a]volumedetect, anullsink; [int1]drawtext=fontfile=monofonto.ttf:fontsize=96:box=1:boxcolor=black@0.75:boxborderw=5:fontcolor=white:x=(w-text_w)/2:y=((h-text_h)/2)+((h-text_h)/4):text='%{gmtime\:%H\\\\\:%M\\\\\:%S}'[bg]; [0:a]showvolume=o=v:w=1080:h=40:f=0:p=0.5:dm=3[fg]; [bg][fg]overlay=x=W-81:y=0[out1]" \
                    -map '[out1]' \
                    -ss 2.9 \
                    -vframes 1 \
                    -f image2 /var/www/video_streams_preview/preview.jpg \
                    -map '[out2]' \
                    -ss 2.9 \
                    -vframes 1 \
                    -f image2 /var/www/video_streams_preview/diff_3.jpg \
                    2>&1 >/dev/null | grep -oP "(?<=mean_volume: ).*(?= dB)"

                Что она делает: подгружает первые 3 секунды потока, с помощью фильтров накладывает «телеметрию», замеряет звук с помощью фильтра volumedetect, сохраняет два кадра в виде картинок: с телеметрией для отображения в Zabbix и без для последующего сравнения с кадрами несколько секунд назад и определения SSIM. В консоль команда выводит значение звука в dB:



                Команда вызывается из незначительно доработанного Python скрипта использованного template'а (сорри за неаккуратность, делали для себя): pastebin.com/7jjw5wrC

                Ну а дальше просто вручную создаем нужные элементы данных и триггеры, данные для которых возвращает py-скрипт:



                Из тех картинок с телеметрией делаем вот такой красивый dashboard в Zabbix:



                Насчет точек мониторинга — мониторим ту ссылку, которую раздаем операторам и сервисам, поток для сайта/приложения и финальный HLS-поток Яндекс.Эфира, который нам любезно предоставили :) Потоки, которые уходят по UDP Multicast мониторим только по количеству трафика. Если он падает ниже определенного значения — срабатывает триггер.
                  0

                  огонь! спасибо!!!

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

              Самое читаемое