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:
- iptvportal (они же распространяют Flussonic Media Server в составе пакета)
- Stalker
- CloudWare
- Telebreeze
С другими Middleware можно провести интеграцию по вашему запросу.
На стороне Flussonic Media Server реализованы всё, что нужно для интеграции с Middleware. Просите вашего поставщика Middleware проверить совместимость с Flussonic Media Server самостоятельно. Также вы можете протестировать следующие Middleware: