Документация на 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. Группы каналов

Middleware в IPTV OTT

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

С переходом на IPTV технология настройки не сильно отличалась: в приставку при заливке прошивки добавляется плейлист, т.е. список каналов с их multicast UDP адресами. Контроль доступа осуществляется либо с помощью шифрования (CAS), либо с помощью сетевых методов, например авторизация IGMP запросов, которая возможна только в простой локальной сети.

При этом все функции реализуются на приставке. Например, такая услуга как PVR (personal video recorder) осуществляется на приставке: пользователь заранее заказывает запись передачи и в нужный момент приставка сама начинает на свой жесткий диск записывать нужную передачу.

С развитием IPTV пользователям начали предлагать такие новые сервисы, как:

  • EPG (electronic program guide), т.е. расписание передач.
  • Организация каналов по платным пакетам.
  • Каталогизация каналов (по жанрам).
  • Родительский контроль (не показывать детям эротику).
  • Просмотр записанных передач.
  • Сопутствующие сервисы типа прогноза погоды или курса валют.
  • Подписка на платный пакет с пульта.
  • Предоставление VOD, т.е. просмотр фильмов.

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

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

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

За этим страшным термином прячется обычный веб-сайт (отдающий HTML, javascript или отвечающий на HTTP API запросы), на который приставки заходят либо обычным веб-браузером, либо чем-то экзотическим типа SVG браузера. На приставке размещается доработанный веб-браузер (обычно Opera или webkit), который умеет проигрывать все варианты видео, доступных приставке (десктопные браузеры обычно не умеют и 5% от видео-возможностей приставки) и умеет работать с пультом, превращая нажатия кнопок пульта в Javascript-события.

Важный момент: на приставках не используется Java (за исключением андроидных приставок, которые по ряду причин очень непопулярны). Обычно люди путают Java и Javascript, не надо так делать.

До сих пор существует дискуссия среди специалистов, что лучше: веб-браузер или специализированное приложение на устройстве. Этот выбор совершенно аналогичен выбору технологии на мобильных устройствах: делать HTML приложение или писать на C.

Многие современные middleware предлагают оба варианта для покрытия максимального количества устройств. Так, например, для приставок Amino (с браузером opera), Mag250, tvip и т.п. (с браузером на базе webkit) будет отдаваться HTML с интерфейсом.

Обычно middleware практически не взаимодействует с видеопотоком, потому что лишь предоставляет приставкам урлы для просмотра каналов и фильмов: либо мультикаст урлы, либо уникаст. Иногда в Middleware реализован механизм мониторинга каналов, что бы не показывать клиентам канал или явно сообщать, что просмотр канала невозможен из-за аварии.

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

Авторизация пользователей Anchor Anchor x2

В IPTV ограничение доступа к видео используется для того, что бы:

  • управлять пакетами каналов. Не подписался на футбол — смотри что попало
  • усложнять задачу воровства контента неавторизованными пользователями
  • усложнять задачу несанкционированной записи передач

Тут смешиваются две системы: CAS и DRM. CAS (conditional access system) — это механизм технического ограничения доступа к контенту. DRM — механизм для запутывания пользователя, что бы он никак не добрался до расшифрованного видео.

CAS системы работают хорошо и исправно. DRM системы в силу своей природы ненадежны, глючат и создают массу проблем всем, кроме их продавцов.

В Flussonic Media Server реализована CAS с помощью авторизации доступа к потокам и файлам.

Интеграция с Middleware выглядит следующим образом:

  • Middleware при формировании HTML страницы или ответа на API, отдает ссылку на HLS (или HTTP MPEG-TS) поток с уникальным ключом.
  • Приставка получает этот уникальный урл для просмотра, обращается с ним к Flussonic Media Server.
  • Flussonic Media Server при первом запросе обращается обратно к Middleware с вопросом: можно ли этой приставке смотреть этот канал по этому адресу.
  • Middleware проверяет, не подсмотрен ли этот адрес (проверяется IP клиента, user agent, протокол и время) и разрешает или запрещает.

Если злоумышленник подсмотрит в сети адрес, то он им не сможет воспользоваться, потому что не совпадет какой-нибудь из параметров и Middleware скажет стримеру не отдавать ему видео.

Работа с EPG Anchor Anchor x2

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

Телеканалы не особо следят за точностью программы передач (погрешность до 15-20 минут) и постфактум точное время начала и конца передач не сообщают.

EPG можно получать со спутника в MPEG-TS потоке, но там информация достаточно ограничена, а можно забирать из интернета у поставщиков программы передач, таких как programma.tv или teleguide.info

Частый формат для программы передач — XMLTV.

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

Flussonic Media Server предлагает совершенно другой подход к записи передач. Не нужно издеваться над пользователем и заставлять его заранее вспоминать о нужной передаче. Middleware должна предоставлять возможность пользователю посмотреть передачи, которые уже прошли и сформировать правильную ссылку к Flussonic Media Server для просмотра уже записанной передачи.

Тут есть два механизма работы: для уже прошедшей передачи и для ещё идущей.

Если передача уже прошла и закончилась, то Middleware на основании EPG формирует ссылку для просмотра из архива (которая так же проходит через механизм авторизации). Пользователь получает возможность посмотреть записанную передачу, как обычный файл.

Например, если передача началась в 18:15 по Москве (14:15 UTC) 27 августа и длилась час, то Middleware должен при выборе передачи в списке прошедших сформировать урл вида http://streamer/ort/index-1409148900-3600.m3u8

Если передача сейчас всё ещё идет, то Middleware может сформировать специальный урл к архиву, позволяющий отматывать назад прямой эфир на начало передачи. Данная функциональность, к сожалению, поддерживается далеко не на всех устройствах и приставках, но тем не менее она существует.

Урл для такой незакончившейся передачи будет выглядеть http://streamer/ort/index-1409148900-now.m3u8

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

В документации более подробно описана работа с архивом DVR

В Flussonic Media Server есть поддержка и других вариантов доступа к записанным передачам. Это:

  • проигрывание архива по HTTP MPEG-TS с определенного момента: http://streamer/ort/timeshift_abs/1409148900
  • проигрывание архива в режиме потока по HLS с определенного момента: http://streamer/ort/timeshift_abs-1409148900.m3u8

Так же Middleware может обратиться к Flussonic Media Server к API о состоянии записи потока, чтобы показать в интерфейсе передачи, которые можно посмотреть и которые нельзя записать.

Таймшифт Anchor Anchor x2

Под термином таймшифт подразумевают две разных функции: возможность отмотки назад прямого эфира и постоянный сдвиг эфира в другую временную зону.

Эта услуга нужна, когда видео захватывается в одном часовом поясе, а показывать хочется в другом для того, что бы, например, пользователи в США видели утреннюю передачу в 9 утра, а не в час ночи.

Flussonic предлагает два варианта таймшифта: запуск постоянного потока, который отстает на фиксированное время от эфира и предоставление ссылок на просмотр архива в режиме потока.

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

Задача Middleware здесь — знать как настроен канал и выдавать ссылки либо к смещенному каналу, либо индивидуальные ссылки на просмотр архива вида:

  • http://streamer/ort/timeshift_rel/7200  — проигрывание архива по HTTP MPEG-TS с отставанием в 2 часа
  • http://streamer/ort/timeshift_rel-7200.m3u8  — проигрывание архива по HLS с отставанием в 2 часа

Интеграция Flussonic с Middleware Anchor Anchor x2

На сегодняшний день поддержка возможностей Flussonic Media Server есть в следующих Middleware:

С другими Middleware можно провести интеграцию по вашему запросу.

На стороне Flussonic Media Server реализованы всё, что нужно для интеграции с Middleware. Просите вашего поставщика Middleware проверить совместимость с Flussonic Media Server самостоятельно. Также вы можете протестировать следующие Middleware: