Skip to content

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 практически не взаимодействует с видеопотоком, потому что лишь предоставляет приставкам ссылки для просмотра каналов и фильмов: либо мультикаст url, либо уникаст. Иногда в Middleware реализован механизм мониторинга каналов, что бы не показывать клиентам канал или явно сообщать, что просмотр канала невозможен из-за аварии.

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

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

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

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

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

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

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

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

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

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

Работа с EPG

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таймшифт

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

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

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

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

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

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

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

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

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

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