IPTV

Статус документа

Оглавление

Общая информация

IPTV сервис предоставляет ссылку на список источников вещания каналов в формате M3U или XSPF.

Рекомендуемый формат — M3U.

Ввиду возможности изменения списка каналов политика кэширования может быть задана средствами транспортного протокола, например, в случае протокола HTTP на стороне сервера при помощи заголовков Expires, Last-Modified, ETag и т.д.

При обращении за списком каналов рекомендуется устанавливать HTTP заголовок User-Agent. Данный заголовок может быть использован системой при генерации списка каналов. Значение заголовка должно однозначно определять платформу и класс устройства.

Пример задания HTTP–заголовка User-Agent:

Peers.TV/3.2.1 (iOS/7.1.0; iPhone/6,2; build 484) Darwin/14.0.0

Аутентификация пользователя и авторизация доступа

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

Для аутентификации пользователя клиент может при обращении к сервису передать полученные ранее данные аутентификации — пару логин/пароль посредством HTTP Basic Auth или токен доступа, выданные Auth API контрагента, по схеме авторизации в соответствии с типом токена.

Для авторизации по типу токена «Bearer» рекомендуется использовать HTTP заголовок Authorization, пример:

Authorization: Bearer 18dasd81230dah12032

Cross-origin resource sharing

Для корректной работы приложений на основе браузера, например, виджет в SmartTV, необходима настройка специальных HTTP заголовков на стороне сервера. Наиболее простой способ — установить заголовок Access-Control-Allow-Origin, разрешающий доступ с любого адреса:

Access-Control-Allow-Origin: *

Более подробно с механизмом CORS можно ознакомиться в документации MDN.

Стандартные коды ответов

При получении списка источников каналов допустимы стандартные коды ответов (RFC2616), ниже описана интерпретация некоторых кодов:

Если аутентификация возможна, то для кодов 401, 403 должен быть передан HTTP заголовок WWW-Authenticate с указанием ожидаемой схемы аутентификации и дополнительнной информации (если применимо). Например, для схемы «Bearer» может быть указан дополнительный атрибут error со значением:

Cписок каналов

При построении списка доступных каналов у приложения имеются несколько списков источников вещания каналов операторов связи, каждый из которых содержит:

Замечания:

  1. Признак наличия архива не гарантирует доступность записей для конечного пользователя;
  2. Пропорции изображения могут быть рассчитаны на основе разрешения изображения, но иногда может потребоваться явно указать пропорции изображения, например, в случае анаморфного изображения;
  3. Признак наличия поддержки технологии Timeshift носит вспомогательный характер и не гарантирует поддержку сервером вещания.

Логотип канала может быть получен при помощи Media Guide API.

Архив записей телепередач предоставляется при помощи Media Guide API и MediaLocator API.

Рекомендации по реализации клиента

В случае поддержки директив клиентом рекомендуется:

Фильтрация источников вещания

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

По поддерживаемым функциям

Клиент может передать список поддерживаемых функций при помощи HTTP заголовка Client-Capabilities. Возможные значения:

HTTP заголовок Client-Capabilities задается грамматикой в форме ABNF (см. RFC2616):

Client-Capabilities = "Client-Capabilities" ":" 1#feature
feature = token

Замечание:

Пример задания заголовка

Client-Capabilities: paid_content,adult_content

Характеристики источников вещания каналов

Схемы URI

Каждый источник вещания должен иметь определенную схему URI (RFC2396), например: http, https, udp, rtp, magnet и другие. При построении списка каналов клиент должен учитывать источники вещания канала только с поддерживаемыми схемами URI.

Список поддерживаемых схем зависит от возможностей платформы и установленных ограничений на клиенте.

Рекомендации по протоколу доставки и способу кодирования

  1. Для мобильных устройств:
  2. Для устройств с подключением по кабелю (STB, SmartTV):

Замечание: поддержка различных протоколов доставки и способов кодирования зависит от возможностей платформы.

Технология Timeshift

Источники вещания, использующие в качестве транспорт протокол HTTP(s), могут поддерживать технологию Timeshift, позволяющую просматривать эфирное вещание со смещением.

Взаимодействие с автоматизированной системой расчетов оператора связи

Список каналов, поставляемый оператором связи может содержать дополнительные признаки доступности каналов абоненту (см. документы по расширению M3U или XSPF). Для этого служат специальные атрибуты источников вещания каналов access, allowed-till и pending-till. С их помощью оператор может указать, какие из каналов доступны абоненту, имеются ли временные ограничения по доступности.

Интерпретация приложением данных атрибутов перечислены в таблице ниже:

access allowed-till pending-till интерпретация
denied не указан игнорируется Доступ к вещанию канала запрещен. Для операторов–партнеров приложение может предложить купить подписку на канал в «Личном кабинете» абонента
denied число игнорируется Доступ на постоянной основе к вещанию канала у абонента отсутствует, но доступен режим пробного ознакомления с вещанием канала в течение времени, указанного в параметре allowed-till, в данном случае значение указывается в секундах.
pending игнорируется число Канал оплачен, но вещание еще не доступно абоненту в силу ряда причин (ожидание подтверждения оплаты, применение конфигурации на оборудовании и т.п.). Планируемое время появления доступа к вещанию каналу указывается в параметре pending-till, в формате GMT UNIX time. При наступлении этого времени приложение перечитает список каналов.
allowed,purchased не указан игнорируется Канал доступен без ограничений по времени.
allowed,purchased число игнорируется Канал доступен абоненту с ограниченным временем подписки. Время, когда оканчивается подписка, указывается в параметре allowed-till, в формате GMT UNIX time.

Значение purchased в отличие от allowed несет дополнительную информацию о факте оплаты доступа к каналу, что может быть использовано клиентом при ранжировании источников вещания.

При наличии доступа (полноценного, с ограничением по времени или пробного режима) ожидается, что по указанному в списке каналов URI для HTTP запросов будет возвращаться ответ с кодом 200. HTTP ответ с кодом 401 должен интерпретироваться как завершение подписки на вещание канала.

При интерпретации времени, указанное сервером производится с учетом текущего времени сервера, переданного им в ответе в заголовке Date. Тем самым приложение может переводить абсолютное время в относительное для отображения обратного отсчета до событий (например, появления доступа до вещания канала) в графическом интерфейсе или выставления таймеров.

Кадрирование и изменение пропорций изображений каналов стандартной четкости

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

Параметр crop, отвечающий за кадрирование, состоит из двух положительных целых чисел от 0 до 100, разделенные двоеточием: X:Y (в форматах M3U, XSPF).

При обрезании картинки результирующий прямоугольник должен находиться по центру исходного изображения.

Для примера рассмотрим канал, иногда передающий большую часть времени «полезную» картинку в формате 16:9, вписанную в полный кадр 768x576. Если не применить кадрирование, на широкоформатном экране она будет иметь поля со всех сторон. Применив кадрирование приложение вырезает прямоугольник с заданными шириной и высотой, а затем вписывает ее в область отображения видео:

Оригинальное изображение размером 768x576 с помощью указанного оператором IPTV параметра crop=100:75 обрезается до размера 768x432, а затем масштабируется до размеров экрана (в случае FullHD — в 2,5 раза).
Оригинальное изображение размером 768x576 с помощью указанного оператором IPTV параметра crop=100:75 обрезается до размера 768x432, а затем масштабируется до размеров экрана (в случае FullHD — в 2,5 раза).

Кадрирование применяется только на устройствах с широкоформатным экраном.

Изменение пропорций изображения может понадобиться каналам с неквадратными пикселями. Для видеопроигрывателей, не понимающих анаморфное вещание, оператор может дополнительно указать параметр aspect-ratio, указывающий истинные пропорции вещаемого эфира. Например:

Оригинальное SDTV изображение размером 768x576 с помощью параметра aspect-ratio=16:9 растягивается до размеров 1024x576, а затем масштабируется (в случае FullHD — в 1,875 раз), при этом можно наблюдать исправление пропорций в изображении.
Оригинальное SDTV изображение размером 768x576 с помощью параметра aspect-ratio=16:9 растягивается до размеров 1024x576, а затем масштабируется (в случае FullHD — в 1,875 раз), при этом можно наблюдать исправление пропорций в изображении.

Таргетирование рекламных вставок

Для некоторых источников вещания может быть доступно таргетирование рекламных вставок. О наличии таргетирования у источника вещания канала сообщает специальный атрибут ad-targeting (см. описание формата M3U).

Параметры таргетирования

Список возможных параметров:

Передача параметров таргетирования

Параметры таргетирования передаются при помощи query части запроса в формате «ключ=значение» (см. RFC3986). В качестве ключа параметра таргетирования необходимо использовать название параметра, а значение экранировать в соответствии с правилами кодирования URI.

Установка параметров таргетирования клиентом должна осуществляется непосредственно перед началом воспроизведения источника

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

Пример

Предположим, имеется источник вещания:

http://example.com/streaming/1292837123/16/playlist.m3u8?token=a83fg17de1aa

Чтобы передать параметры рекламного таргетирования, необходимо добавить в запрос известные параметры:

http://example.com/streaming/1292837123/16/playlist.m3u8?token=a83fg17de1aa&idfa=6EB2771C-8E79-4815-B831-9263EEF999FD

Соглашения

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

Рекламный идентификатор вида «00000000–0000–0000–0000–000000000000» стоит рассматривать как отсутствие возможности получить доступ к рекламному идентификатору.

Изменения по версиям

Изменения в версии 1.0.1

Изменения в версии 1.0.2

Изменения в версии 1.1.0

Изменения в версии 1.2.0

Изменения в версии 1.2.1

Изменения в версии 1.3.0

Изменения в версии 1.3.1

Изменения в версии 1.3.2

Изменения в версии 1.4.0

Изменения в версии 1.5.0

Изменения в версии 1.5.1

Изменения в версии 1.6.0

Изменения в версии 2.0

Изменения в версии 2.0.1

Изменения в версии 2.1.0 (TVREC–341)

Изменения в версии 2.1.1

Изменения в версии 2.2.0 (TVREC–364)

Изменения в версии 2.2.1

Изменения в версии 2.2.2

Изменения в версии 2.3.0 (TVREC–378)

Изменения в версии 2.3.1

Изменения в версии 2.3.2

Изменения в версии 2.3.3 (TVREC–392)

Изменения в версии 2.4.0 (TVREC–402)

Изменения в версии 2.4.1 (TVREC–425)

Изменения в версии 2.4.2

Изменения в версии 2.4.3

Изменения в версии 2.4.4

Изменения в версии 2.4.5

Изменения в версии 2.4.6 (TVREC–591)

Изменения в версии 2.5.0 (TVREC–629)

Изменения в версии 2.5.1 (TVREC–639)

Изменения в версии 2.5.2 (TVREC–639)

Изменения в версии 2.6.0 (TVREC–666)

Изменения в версии 2.7.0 (TVREC–673)

Изменения в версии 2.8.0 (TVREC–688)

Изменения в версии 2.8.1

Изменения в версии 2.9.0 (TVREC–982)

Изменения в версии 2.9.1