Документация на Flussonic Media Server

  1. Быстрый старт
  2. How To
  3. Потоковое вещание
    1. Публикация
    2. Прием мультикаста
    3. Варианты источников
    4. Переключение источников
    5. Плейлисты
    6. Наложение логотипа
    7. Миксер
    8. WebRTC публикация
    9. SDI
    10. Отправка на другие сервера
    11. Распознавание DVB субтитров
  4. Транскодер
    1. Логотип
    2. Hardware
    3. Скриншоты
    4. Мозаика
  5. DRM
    1. Simple CAS
    2. Conax DRM
    3. BuyDRM (KeyOS)
  6. Авторизация
    1. Конструктор бэкендов
    2. Сервис сбора статистики
    3. Domain lock
    4. Middleware
    5. Secure links
    6. Ограничение сессий
    7. Мультиавторизация
    8. Бан IP адресов
    9. DVR
    10. Aliaser
  7. API
    1. HTTP API
    2. Events API
    3. MySQL API
    4. SQL API для кластеров
    5. SNMP
  8. Кластер
    1. Ретрансляция
    2. Кластерный захват
    3. Балансировщик нагрузки
    4. Пиринг
    5. Организация CDN
  9. VOD
    1. Кэш
    2. Облако
    3. Транскодирование файлов
  10. DVR
    1. Настройка
    2. Timeshift
    3. Catchup
    4. Проигрывание
    5. Экспорт в MP4
    6. Доступ по протоколам
    7. Timelapse
    8. API
    9. Кластеризация DVR
    10. Репликация
    11. Облако
  11. Воспроизведение
    1. HLS
    2. embed.html
    3. HTML5 с низкой задержкой
    4. Плеер HTML5 с низкой задержкой
    5. MPEG-TS
    6. RTMP
    7. DASH
    8. HDS
    9. RTSP
    10. multicast, CBR UDP
    11. WebRTC проигрывание
    12. H.265
  12. Администрирование
    1. Установка
    2. Обновление

    3. Конфигурация
    4. Мониторинг
    5. Производительность
    6. Лицензия
    7. LUA скрипты
    8. Безопасность
    9. Let's Encrypt
    10. Миграция
  13. IPTV
    1. Захват спутникового видео
    2. Транскодирование
    3. Middleware в IPTV OTT
    4. Экспорт EPG со спутника
    5. Группы каналов

Организация CDN

Если одного сервера для раздачи видео перестает хватать, небходимо организовывать сеть доставки контента (CDN).

Flussonic Media Server обладает рядом возможностей, позволяющих упростить эту задачу. В данной статье будем рассматривать небольшую сеть на 3-10 серверов, вещающих прямые эфиры.

Терминология Anchor Anchor x2

CDN — Content Delivery Network — сеть доставки контента. Это множество серверов с специализированным ПО, которые ускоряют доставку и отдачу контента конечному пользователю. Сервера расположены по всему миру таким образом, чтобы время ответа посетителям сайта было минимальным. Под «контентом» обычно подразумевают видео и статические элементы веб-сайтов (не требующие выполнения кода на сервере или запросов в базу данных, такие как css/js).

Региональное распределение Anchor Anchor x2

Будем рассматривать ситуацию, когда видео захватывается со спутника в России/Европе и потом передается в Европу/Америку для ретрансляции.

Передавать видео прийдется на большое расстояние по публичному интернету, а следовательно гарантировать качество канала не получится.

Схема организации:

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

На такой схеме продемонстрируем возможности Flussonic Media Server.

Захват Anchor Anchor x2

Можно сделать разные конфигурации захвата потоков в сеть доставки и их конфигурации зависят от того: можно ли брать из источника видео несколько раз или нет.

В самом простом варианте, если у вас видео приходит мультикастом по UDP, можно просто на разных серверах захвата (далее grabber1.cdn.tv и grabber2.cdn.tv) настроить захват одного и того же видео:

http 80;
cluster_key mysecretkey;

stream ort {
  url udp://239.0.0.1:1234;
  dvr /storage 3d;
}

Здесь и далее мы подразумеваем, что у серверов хостнеймы правильные и они все резолвятся.

Также важный момент с единым ключом кластера на всех серверах. Здесь мы выбрали mysecretkey, но его можно поменять.

В таком режиме сервера захвата работают абсолютно независимо, архив пишется на обоих серверах и оба сервера постоянно доступны. Но такая схема требует захвата из источника несколько раз, а это не всегда бывает удобно или возможно. Например, если пакет каналов, получаемый по HTTP, укладывается в 500-800 мегабит, то двойной захват может потребовать серьезного расширения входного канала выше гигабита.

Если вы не хотите брать видео из источника несколько раз, то можно настроить кластерный захват.

На серверах захвата добавляется одинаковый конфиг со стримами:

http 80;
cluster_key mysecretkey;

stream ort {
  url tshttp://origin/ort/mpegts;
  cluster_ingest capture_at=grabber1.cdn.tv;
  dvr /storage 3d;
}

С таким конфигом на обоих серверах захвата всё видео будет захватываться на одном сервере, второй будет работать в режиме горячего резерва. Опция capture_at указывает серверам, что grabber1 является более приоритетным для захвата. Если её не указать, то стримы равномерно распределятся между серверами, что тоже может быть неплохой идеей.

Если grabber1.cdn.tv упадет, то grabber2.cdn.tv отреагирует на это и автоматически добавит стримы себе.

При такой настройке второй сервер простаивает, архив на нём не пишется и появится на нем только при падении первого сервера.

Если хочется полностью срезервировать и архив, то нужна другая конфигурация.

Если хочется сохранить одну точку захвата видео, но резервировать архив, тогда надо на втором сервере постоянно забирать потоки и писать их. Для этого прийдется сделать разный конфиг на разных серверах.

На grabber1.cdn.tv будет такой конфиг:

http 80;
cluster_key mysecretkey;

stream ort {
  url tshttp://origin/ort/mpegts;
  dvr /storage 3d;
}

Видео захватывается из источника и пишется на диск.

На grabber2.cdn.tv будет немного другой конфиг:

http 80;
cluster_key mysecretkey;

stream ort {
  url hls://grabber1.cdn.tv/ort/mono.m3u8;
  url tshttp://origin/ort/mpegts;
  dvr /storage 3d;
}

grabber2 будет стараться забрать видео с первого сервера, но в случае его падения пойдет к источнику напрямую.

Транзит от захвата к стримингу Anchor Anchor x2

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

Однако нет необходимости прописывать все каналы руками и следить за ними, можно воспользоваться механизмом Flussonic для этого.

На сервере streamer1.cdn.tv, который занимается приёмом видео с захвата достаточно прописать в конфигурационный файл:

http 80;
cluster_key mysecretkey;

source grabber1.cdn.tv grabber2.cdn.tv {
  dvr /storage 7d replicate;
}

При такой конфигурации Flussonic Media Server будет забирать каналы с одного или с второго сервера, писать их локально в архив и при необходимости докачивать те данные, которые есть удаленно, но отсутствуют локально.

Если какие-то каналы не требуются для постоянной работы, можно пометить их как каналы по запросу:

http 80;
cluster_key mysecretkey;

source grabber1.cdn.tv grabber2.cdn.tv {
  except ort 2x2;
  dvr /storage 7d replicate;
}

Раздача Anchor Anchor x2

При раздаче большого количества видео надо решать вопрос с распределением нагрузки.

Оптимально, когда распределением занимается Middleware, это самая надежная схема с точки зрения клиентов (не все поддерживают редиректы), но можно воспользоваться и другими вариантами.

Сами стримеры имеет смысл организовывать также, как и транзит. Но только забирать с локальных серверов:

http 80;
cluster_key mysecretkey;

source streamer1.cdn.tv streamer2.cdn.tv {
  cache /cache 2d;
}

В этом случае мы включили не DVR, а сегментный кеш. Flussonic Media Server будет складывать сегменты в кеш и при необходимости отдавать их оттуда. Кеш, понятно, размещать на шпиндельных дисках не имеет никакого смысла, это только SSD.

Прямой эфир при этом всё равно обслуживается из памяти и без проблем забивает 10 гигабит, а вот кеш с одного SATA SSD упрется в 6 гигабит SATA шины. Можно это решить сборкой RAID 0 из нескольких SSD.

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