ГОСТ Р 56950-2016 Телевидение вещательное цифровое. Расширенная спецификация общего интерфейса в системах ограничения доступа CI Plus™. Основные параметры

ГОСТ Р 56950-2016

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ТЕЛЕВИДЕНИЕ ВЕЩАТЕЛЬНОЕ ЦИФРОВОЕ

РАСШИРЕННАЯ СПЕЦИФИКАЦИЯ ОБЩЕГО ИНТЕРФЕЙСА В СИСТЕМАХ ОГРАНИЧЕНИЯ ДОСТУПА CI PLUS

Основные параметры

Digital Video Broadcasting. Extensions to the CI Plus Specification. Basic parameters

ОКС 33.170

ОКП 657400

Дата введения 2017-06-01

Предисловие

1 РАЗРАБОТАН Федеральным государственным унитарным предприятием Ордена Трудового Красного Знамени научно-исследовательским институтом радио, Самарский филиал "Самарское отделение научно-исследовательского института радио" (филиал ФГУП НИИР - СОНИИР)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 480 "Связь"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 7 июня 2016 г. N 543-ст

4 Настоящий стандарт разработан с учетом основных нормативных положений стандарта Европейского института по стандартизации в области телекоммуникаций (ETSI) ЕТСИ ТС 103 205 V1.1.1 (2014-03)* "Расширенная спецификация общего интерфейса в системах ограничения доступа CI Plus" [ETSI TS 103 205 V1.1.1 "Digital Video Broadcasting (DVB); Extensions to the CI Plus Specification", NEQ]

________________

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

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомления и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

1 Область применения

Настоящий стандарт содержит расширенные характеристики общего интерфейса в системах ограничения доступа CI Plus, определенного в [1]. Стандарт распространяется на оборудование защиты информации, передаваемой по каналам вещания и по каналам интернет-протокола (Internet Protocol; IP).

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ Р 52210-2004 Телевидение вещательное цифровое. Термины и определения

ГОСТ Р 52591-2006 Система передачи данных пользователя в цифровом телевизионном формате. Основные параметры

ГОСТ Р 53528-2009 Телевидение вещательное цифровое. Требования к реализации протокола высокоскоростной передачи информации DSM-CC. Основные параметры

Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

3 Термины, определения, сокращения и символы

3.1 В настоящем стандарте применены термины по ГОСТ Р 52210, ГОСТ Р 52591, ГОСТ Р 53528, а также следующие термины с соответствующими определениями:

3.1.1 виртуальный канал (Virtual Channel): Канал, формируемый из совокупности каналов Хоста и запускаемый из меню CICAM как элемент перечня каналов Хоста.

3.1.2 дескриптор (descriptor): Ключевое слово, определяющее тип передаваемых данных.

3.1.3 идентификатор локального транспортного потока (transport stream; TS) (Local TS identifier; LTS): Уникальный номер, присвоенный локальному (местному) TS; замещает байт синхронизации в каждом заголовке пакета TS.

3.1.4 интерфейс сети IP (IP network interface): Проводной или беспроводной интерфейс интегрированного приемника-декодера (Integrated Receiver Decoder; IRD), поддерживающего базовые соединения IP.

3.1.5 контент IP (IP-delivered content): Аудиовидеоконтент, принятый через сетевой интерфейс IP IRD.

3.1.6 листинг (listing): Список, составление списка.

3.1.7 локальный (местный) TS (Local TS): Последовательность пакетов TS, в которой каждый пакет TS имеет идентификатор локального TS.

3.1.8 настройка приоритетная (foreground tune): Операция настройки в многопоточном режиме для приема службы, которая будет представляться пользователю.

3.1.9 настройка фоновая (background tune): Операция настройки в многопоточном режиме для приема службы, не предназначенной для представления пользователю.

3.1.10 общий интерфейс (Common Interface; CI): Метод обеспечения доступа к скремблированному сигналу, при котором все узлы Хоста, имеющие отношение к защите информации, устанавливаются в модуле защиты.

3.1.11 орган (trust authority): Объект (организация), который регламентирует соответствие и надежность реализаций CICAM и Хоста в соответствии с настоящим стандартом.

3.1.12 платформа координации приложений (application coordination framework): Совокупность конкретных правил CI Plus координации приложений вещания и приложений CICAM.

Примечание - В соответствии с 12.4 настоящего стандарта.

3.1.13 приложение вещания (broadcast application): Приложение, сигнализируемое в службе вещания, или приложение, запускающее приложение вещания, даже если оно само не сигнализируется в службе DVB.

3.1.14 приложение вещания CICAM (CICAM broadcast application): Приложение вещания, загруженное от системы вспомогательных файлов.

3.1.15 приложение, сигнализированное вещанием (broadcast signalled application): Приложение, сигнализированное в службе DVB, которое может переноситься во внутриполосной службе (например, с каруселью объектов DSM-CC) или во внеполосной службе [например, с помощью протокола передачи гипертекста (HyperText Transfer Protocol; HTTP) или системы вспомогательных файлов CICAM].

3.1.16 приложение AppMMI CICAM (CICAM AppMMI application): Приложение, использующее ресурсы приложения MMI CI Plus и запущенное CICAM.

3.1.17 приложение CICAM (CICAM application): Приложение, предоставленное CICAM с помощью системы вспомогательных файлов или использования ресурса приложения MMI.

3.1.18 профиль пользователя (consumer profile): Данные, представляющие интересы и предпочтения пользователя.

3.1.19 режим ввода (Input Mode): Режим работы интерфейса TS, в котором CICAM генерирует для Хоста новые TS.

3.1.20 режим доставки контента IP Хосту в режиме проигрывателя (IP delivery Host player mode): Режим обработки контента IP, в процессе которого Хост обрабатывает протоколы доставки и формат инкапсуляции контента.

3.1.21 режим доставки контента IP CICAM в режиме проигрывателя (IP delivery CICAM player mode): Режим обработки доставленного контента IP, в процессе которого CICAM обрабатывает протоколы и формат инкапсуляции контента.

3.1.22 режим многопоточный (Multi-stream Mode): Режим работы, обеспечивающий перенос нескольких TS через интерфейс TS.

3.1.23 режим нормальный (Normal Mode): Режим работы локального TS, переносящего обычный TS.

3.1.24 режим обработки одиночного потока (single-stream mode): Режим работы интерфейса TS, соответствующего [2].

3.1.25 режим семпла (Sample Mode): Режим работы локального TS при переносе семпла.

3.1.26 режим спецэффектов (trick mode): Режим, позволяющий устанавливать начало проигрывания контента, ускоренную перемотку вперед или назад, ускоренное (относительно реального времени) считывание, запрос и считывание блоков контента, например I-кадров, в пределах элемента контента.

3.1.27 ресурс приложения MMI (application MMI resource): Ресурс, обеспечивающий обмен файлами и данными в обоих направлениях и обеспечивающий возможность возвращать информацию о статусе от домена приложения к модулю (CICAM).

3.1.28 сеанс проигрывателя (player session): Интервал времени, на котором выполняется проигрывание контента.

3.1.29 сеанс CICAM в режиме проигрывателя (CICAM player mode session): Интервал времени, на котором CICAM выполняет проигрывание контента.

3.1.30 семпл (Sample): Логический сегмент данных.

Примечание - Контент семпла содержит сегмент данных, скремблированных постоянным набором параметров скремблирования.

3.1.31 синтаксис (syntax): Часть языка программирования, которая описывает структуру программ как набор символов.

3.1.32 служба DVB (DVB service): Служба, которая сигнализирована или объявлена в соответствии со спецификациями DVB, включая [3], [4] и OSDT, приведенный в разделе 15 и приложении А настоящего стандарта.

3.1.33 транспортный поток (transport stream; TS): Набор из нескольких программных потоков данных цифрового телевизионного вещания, сформированный из программных пакетов постоянной длины с коррекцией ошибок и независимым тактированием от своих источников синхронизации.

3.1.34 трек (Track): Последовательность связанных семплов в файле контента IP, доставляемая Хосту в режиме проигрывателя.

3.1.35 тюнер (tuner): IRD, имеющий функциональную возможность доставки TS, содержащего не менее одной службы DVB.

3.1.36 формат преобразования юникода (Unicode Transformation Format, 8-bit; UTF-8): Восьмибитный набор символов для протоколов, выходящих за рамки кодировки ASCII.

3.1.37 Хост (Host): IRD, включающий в себя CI PХus™ со слотом CICAM.

3.1.38 элемент контента (content item): Объект, который может быть приобретен как единое целое, например, файл аудио/видео, аудиопоток.

В настоящем стандарте применены следующие сокращения:

ADQ - запрос домена приложения (Application Domain Query);

AIT - таблица информации приложения (Application Information Table);

AKH - аутентификация (проверка подлинности) ключа Хоста (Authentication Key Host);

AKM - аутентификация (проверка подлинности) ключа модуля (CICAM) [Authentication Key Module (CICAM)];

APDU - модуль данных протокола приложения (Application Protocol Data Unit);

API - интерфейс прикладных программ (Application Programming Interface);

ASCII - американский 8-битный стандартный код для обмена информацией (American Standart Code for Information Interchange);

ASN.1 - абстрактная синтаксическая нотация, версия 1 (Abstract Syntax Notation One);

AV - аудио/видео (Audio-Video);

BCG - путеводитель по широкополосному контенту (Broadband Content Guide);

BER - базовые правила кодирования (Basic Encoding Rules);

BLT - таблица уровня буфера (Buffer Level Table);

bslbf - строка битов, левый бит первый (bit string, left bit first);

CA - условный доступ (Conditional Access);

CA_PMT - таблица состава программ CA (Conditional Access Program Map Table);

CAS - система условного доступа (CA System);

CASD - дескриптор CAS (Content Access Streamings Descriptior);

CAT - таблица условного доступа (Conditional Access Table);

CC - управление контентом (Content Control);

CCK - ключ управления контентом (Content Control Key);

CENC - общее скремблирование (Common Encryption);

CI - общий интерфейс (Common Interface);

CICAM - модуль CI СА (CI СА Module);

CIS - передача сообщения CI (CI Send Message);

CIV - вектор инициализации контента (Content Initialisation Vector);

DASH - динамическая адаптивная потоковая передача по HTTP (Dynamic Adaptive Streaming over HTTP);

DH - криптографический протокол Диффи-Хеллмана (Diffie Hellman);

DHCP - протокол динамического конфигурирования Хоста (Dynamic Host Configuration Protocol);

DHPH - открытый ключ DH Хоста (DH Public key Host);

DHPM - открытый ключ DH модуля CICAM (DH Public key CICAM Module);

DNS - служба доменных имен (Domain Name Service);

DRM - цифровое управление правами (Digital Rights Management);

DSD - дескриптор системы доставки (Delivery System Descriptor);

DSM-CC - система команд и управления для средств цифровой записи (Digital Storage Media - Command and Control);

DTCP - защита контента при цифровой передаче (Digital Transmission Content Protection);

DVB - цифровое телевизионное вещание (Digital Video Broadcasting);

DVB-C - стандарт цифрового телевизионного вещания по кабелю первого поколения (DVB Cable);

DVB-C2 - стандарт цифрового телевизионного вещания по кабелю второго поколения (Digital Video Broadcasting-Cable 2);

DVB-S - стандарт спутникового цифрового телевизионного вещания первого поколения (DVB Satellite);

DVB-S2 - стандарт спутникового цифрового телевизионного вещания второго поколения (Digital Video Broadcasting-Satellite 2);

DVB-T - стандарт наземного цифрового телевизионного вещания первого поколения (DVB Terrestrial);

DVB-T2 - стандарт наземного цифрового телевизионного вещания второго поколения (Digital Video Broadcasting-Terrestrial 2);

EBU - Европейский вещательный союз (European Broadcasting Union);

ECM - сообщение управления доступом (Entitlement Control Message);

EMM - сообщение разрешения доступа (Entitlement Management Message);

EPG - электронный путеводитель по программам (Electronic Programme Guide);

ES - элементарный поток MPEG-2 (MPEG-2 Elementary Stream);

ETSI - Европейский институт по стандартизации в области телекоммуникаций (European Telecommunications Standards Institute);

FEC - прямая коррекция ошибок (Forward Error Correction);

FLT - таблица сброса (очистки) (Flush Table);

HbbTV - гибридное широкополосное телевизионное вещание (Hybrid Broadcast Broadband Television);

HD - высокая четкость (High Definition);

HDCP - система защиты широкополосного цифрового контента (High-bandwidth Digital Content Protection system);

HTTP - протокол передачи гипертекста (HyperText Transfer Protocol);

ID - идентификатор (Identifier);

IEC - Международная электротехническая комиссия; МЭК (International Electrotechnical Commission);

IETF - Комитет по инженерным вопросам Интернета (Internet Engineering Task Force);

IGMP - протокол управления группами Интернета (Internet Group Management Protocol);

IP - Интернет-протокол (Internet Protocol);

IPTV - телевидение IP (IP Television);

IRD - интегрированный приемник-декодер (Integrated Receiver Decoder);

ISO - Международная организация по стандартизации (International Standards Organizations);

ISOBMFF - базовый формат медиафайла ISO (ISO Base Media File Format);

ITU-T - сектор стандартизации электросвязи МСЭ (International Telecommunications Union-Telecommunication Standardization Sector);

IV - вектор инициализации (Initialisation Vector);

KID - идентификатор ключа (kеу identifier);

LCN - номер логического канала (Logical Channel Number);

LSC - низкоскоростное соединение (Low Speed Communication);

LTS - локальный транспортный поток (Local Transport Stream);

MAC - управление доступом медиа (Media Access Control);

MHEG - группа экспертов по мультимедиа и гипермедиа (Multimedia and Hypermedia Experts Group);

МНР, МНР - мультимедийная домашняя платформа (Multimedia Home Platform);

MMI - интерфейс человек-машина (Man-Machine Interface);

MPD - дескриптор представления медиа (Media Presentation Description);

MPEG - 1 Группа экспертов ISO по вопросам стандартизации, обработки и записи движущихся объектов; 2 Набор стандартов кодирования и сжатия цифрового изображения и звука (Motion Pictures Expert Group);

MSB - старший значащий бит (Most Significant Bit);

NIT - таблица сетевой информации (Network Information Table);

OSDT - онлайн SDT (Online SDT);

PAT - таблица объединения программ (Program Association Table);

PES - пакетизированный элементарный поток (Packetised Elementary Stream);

PID - идентификатор пакета (Packet Identifier);

PIN - персональный идентификационный номер (Personal Identification Number);

PMT - таблица состава программы (Program Map Table);

ROT- полномочный орган [Root of Trust (i.e. Trust Authority)];

RTP - транспортный протокол реального времени (Real Time Transport Protocol);

RTSP - протокол потоковой передачи в реальном времени (Real Time Streaming Protocol);

SAC - безопасный канал с проверкой аутентификации (Secure Authenticated Channel);

SAS - поддержка специфического приложения (Specific Application Support);

SD - стандартная четкость (Standard Definition);

SDT - таблица описания служб (Service Description Table);

SET - таблица окончания семпла (Sample End Table);

SI - информация о службах (Service Information);

SPTS - однопрограммный транспортный поток (Single Programme Transport Stream);

SRM - сообщение реабилитации системы (System Renewability Message);

SSM - режим набора субтитров (Set Subtitle Mode);

SST - таблица старта (начала) семпла (Sample start table);

tcimsbf - мнемоническое условное обозначение: целое число в дополнительном коде, старший бит следует первым (twos complement integer, most significant bit first);

TCP - протокол управления передачей (Transmission Control Protocol);

TS - транспортный поток (transport stream);

TSC - транспорт управления скремблированием (Transport Scrambling Control);

UDP - протокол дейтаграмм пользователя (User Datagram Protocol);

uimsbf - целое число без знака, сначала старший значащий бит (unsigned integer most significant bit first);

URI - информация о правилах использования (Usage Rules Information);

URL - унифицированный указатель (определитель расположения) ресурса (Uniform Resource Locator);

URN - унифицированное имя ресурса (Uniform Resource Name);

UTF-8 - формат преобразования юникода, 8-битный (Unicode Transformation Format, 8-bit);

UUID - универсальный уникальный идентификатор (Universally Unique Identifier);

VOD - видео по запросу (Video on Demand);

XML - расширяемый язык разметки (Extensible Markup Language).

3.2 В настоящем стандарте применены следующие символы:

0х - префикс шестнадцатеричного числа;

0b - префикс двоичного числа.

4 Общие сведения о расширенной спецификации общего интерфейса CI Plus

4.1 Введение

Настоящий стандарт устанавливает параметры расширенной спецификации общего интерфейса системы условного доступа, определенного в [1].

Спецификация CI Plus [1] в рамках настоящего стандарта расширяется дополнением следующих функций и возможностей:

- функцией обработки нескольких локальных транспортных потоков, переносимых через интерфейс TS;

- функцией обработки контента, доставляемого по каналам IP;

- расширением функций браузера CI Plus;

- функцией активизации приложения CICAM;

- расширением URI при обработке режима спецэффектов;

- функциями маркирования дескремблированных служб водяными знаками;

- функциями транскодирования служб.

На рисунке 1 представлена структурная схема расширенной системы CI Plus, которая включает новые функции и возможности обработки потоков, определенные в настоящем стандарте.

Рисунок 1 - Структурная схема расширенной системы CI Plus

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

При обработке нескольких потоков Хост маршрутизирует контент, полученный от интерфейса IP, к CICAM или направляет контент непосредственно к CICAM, если Хост поддерживает маршрутизацию к CICAM только одной службы. Хост форматирует контент, доставленный через интерфейс IP, для передачи через интерфейс транспортного потока. В 4.3 настоящего стандарта содержатся вводные сведения о доставке контента средствами IP. Параметры детализированных функций доставки контента представлены в разделах 7 и 8 настоящего стандарта.

На рисунке 2 показана совокупность схем защиты контента, представляющая расширенную версию схем защиты, в соответствии с [1] (рисунок 5.1). Эта область включает схему защиты системы цифрового управления правами (Digital Rights Management; DRM) для контента, поставляемого средствами IP.

Рисунок 2 - Совокупность схем защиты контента

Настоящий стандарт расширяет спецификацию [1] (приложение Н) новым идентификатором типа данных datatype_id и расширяет [1] (Приложение L) новыми ресурсами и APDU, определенными в настоящем стандарте. Другие приложения [1] в настоящем стандарте не изменены.

Раздел 5 настоящего стандарта содержит общие требования к реализациям Хоста и CICAM.

Разделы 6-16 настоящего стандарта содержат параметры новых функций, а также изменения и ограничения параметров интерфейса CI Plus.

4.2 Расширенные возможности приема нескольких потоков

Настоящий стандарт определяет расширение для CI Plus, которое позволяет выполнять передачу через интерфейс TS с одним CICAM различных служб от нескольких вещательных тюнеров и/или интерфейсов IP. Эти службы могут быть защищены системами CAS или DRM при доступе к службам с помощью одного CICAM. На рисунке 1 Хост содержит три вещательных тюнера, создающих несколько потоков. Обработка этих потоков должна выполняться интерфейсом TS в многопоточном режиме.

Параметры процессов в многопоточном режиме работы нормированы в разделе 6 настоящего стандарта.

4.3 Доставка контента через каналы с IP

4.3.1 Общие положения

Многие провайдеры вещательных служб и операторы сетей доставляют контент по каналам с IP (контент IP). Современные Хосты в дополнение к традиционной доставке контента средствами вещания могут подключаться к широкополосной сети IP и имеют возможности обработки гибридного широкополосного вещания. Предыдущие версии спецификации CI предусматривали обработку контента IP через интерфейс TS, защищенного CAS. Доступ пользователя к контенту IP, защищаемому DRM, определял необходимость наличия в Хосте отдельного агента DRM. В настоящем стандарте процессы маршрутизации и дескремблирования защищенного контента IP на сетевом интерфейсе Хоста расширены при размещении в CICAM агента DRM. Это позволяет провайдерам служб и операторам сетей иметь единый CICAM, который может принимать и дескремблировать как контент вещания, так и контент IP.

Характеристики форматов контейнеров и протоколов доставки контента IP, используемых для передачи контента между сервером и Хостом, настоящий стандарт не нормирует, за исключением случаев, когда они влияют на поведение контента, передаваемого через CI. Предоставление защищенного контента IP с помощью Хоста на CICAM обеспечивается для всех форматов, применяемых до марта 2014 г. включительно.

Настоящий стандарт определяет параметры поддержки контента IP как для случая TS, так и для контента IP, инкапсулированного в формате ISOBMFF. Контент IP в формате TS не требует повторной инкапсуляции для переноса через интерфейс TS. Контейнер контента IP ISOBMFF [5] или MP4FF [6] инкапсулируется в специфичный контейнер базового формата TS для доставки IP CI Plus. Этот контейнер применен для передачи от Хоста к CICAM и от CICAM к Хосту. При переносе контента в контейнере, отличающемся от контейнера TS, интерфейс TS работает в режиме семпла. В случае переноса в стандартных контейнерах TS он работает в нормальном режиме.

В режиме семпла метаданные DRM и информация управления, относящиеся к IP-элементам контента, перед запуском проигрывания передаются от Хоста на CICAM через интерфейс команд. Метаданные DRM, которые изменяются между семплами, переносятся с данными семпла через интерфейс TS.

В режиме семпла данные, входящие от Хоста к CICAM, как правило, хранятся в буфере до тех пор, пока они не будут готовы к дескремблированию семплов. Настоящий стандарт предусматривает два режима доставки контента IP, различающиеся уровнем взаимодействия Хоста с IP протоколами и форматами доставки. Они вводятся в 4.3.2 настоящего стандарта.

4.3.2 Режимы доставки IP

4.3.2.1 Хост в режиме проигрывателя

При работе в режиме проигрывателя Хост подключен к широкополосной сети и обрабатывает протоколы, доставляющие контент. Кроме того, Хост обрабатывает контейнеры с инкапсулированным контентом. Хост передает контент в CICAM на дескремблер DRM. CICAM возвращает дескремблированный контент, который он может скремблировать вновь с использованием системы управления контентом, определенной в спецификации Хоста CI Plus. Последовательность обмена APDU данных между Хостом и CICAM при подготовке к дескремблированию и в процессе дескремблирования контента представлена в 7.4 настоящего стандарта.

Аналогичным образом Хост и CICAM обрабатывают контент вещания, когда для безопасной поставки CICAM предоставляет клиенту собственную защиту дескремблированного контента и может безопасно предоставить Хосту дескремблированный контент, используя систему управления контентом CI Plus.

Параметры доставки IP Хосту в режиме проигрывателя определены в разделе 7 настоящего стандарта.

4.3.2.2 CICAM в режиме проигрывателя

При работе CICAM в режиме проигрывателя Хост подключен к широкополосной сети, но не обрабатывает протоколы UDP или TCP, с помощью которых доставляется контент, и не обрабатывает форматы инкапсуляции контента и коды, а передает полезную нагрузку пакетов IP в CICAM. CICAM деинкапсулирует контент, управляет протоколами доставки и переводит их в случае необходимости в формат, поддерживаемый Хостом. Контент возвращается из CICAM в Хост в виде SPTS, который Хост способен обрабатывать самостоятельно.

Параметры CICAM в режиме проигрывателя при доставке контента IP представлены в разделе 8 настоящего стандарта.

4.3.3 Методы использования контента IP

4.3.3.1 Общие положения

Три метода использования контента IP описаны в 4.3.3.2-4.3.3.4 настоящего стандарта.

4.3.3.2 Передача видео по запросу в потоке "вытягиванием"

При передаче видео по запросу в потоке "вытягиванием" контент от сервера передается в потоке, используя протокол для VOD, аналогичный HTTP. Хост может обеспечить проигрывание контента в режиме спецэффектов.

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

Защищенный контент дескремблируется CAS или клиентом DRM в CICAM, позволяя Хосту представить контент пользователю.

4.3.3.3 Передача видео по запросу в потоке "проталкиванием"

При передаче видео по запросу в потоке с протоколами "проталкивания" контент передается от сервера при использовании протоколов RTSP/RTP. Хост выполняет проигрывание контента в режиме спецэффектов в границах элемента контента при передаче соответствующих команд.

Защищенный контент дескремблирован CAS или клиентом DRM в CICAM, позволяя Хосту представить контент пользователю.

4.3.3.4 Использование загруженного контента

Использование загруженного контента возможно только в случае, когда Хост работает в режиме проигрывателя контента IP. Контент был загружен ранее для локального хранения и защищен скремблированием DRM. Контент считывается Хостом. Хост может обеспечить обработку контента в режиме спецэффектов.

Защищенный контент дескремблирован клиентом DRM в CICAM, что позволяет Хосту представить контент пользователю.

Проигрывание контента возможно только при наличии соединения с сервером о DRM.

4.4 Расширенные функции браузера CI Plus

Браузер CI Plus с расширенными функциями выполняет поиск и извлечение контента, используя соединение IP приложения браузера CI Plus и используя профиль интерактивного канала MHEG профиля вещания MHEG-5 [7]. Параметры браузера с расширенными функциями определены в 12.2 настоящего стандарта.

Настоящий стандарт устанавливает обязательной поддержку браузером CI Plus масштабируемого видео. Параметры процесса обработки масштабируемого видео браузером CI Plus определены в 12.2.4 настоящего стандарта.

Расширения для CI Plus, предусмотренные настоящим стандартом, позволяют браузеру CI Plus использовать гибридное широкополосное вещание и облегчают пользователю доступ к приложениям оператора, например, для работы VOD и EPG.

4.5 Запуск приложений CICAM

Реализации Хоста для поддержки вещания и онлайн интерактивных приложений включают в себя промежуточное программное обеспечение (ПО), например, HbbTV или МНР. Настоящий стандарт определяет механизмы CICAM, позволяющие установить возможность Хоста поддерживать системы промежуточного ПО и возможность запуска на Хосте промежуточного ПО приложений. Настоящий стандарт определяет только платформу, в рамках которой могут быть запущены из CICAM приложения для Хоста, поддерживающие среды, отличные от среды браузера CI Plus. Параметры идентификаторов, необходимых для использования этой платформы, устанавливаются конкретной средой.

Платформа координации приложений, возникающих между приложениями CICAM и приложениями вещания, определена в разделе 12 настоящего стандарта. Настоящий стандарт определяет механизм формирования CICAM виртуального канала, который при запуске выбранного приложения CICAM добавляется к совокупности каналов Хоста. Пользователь получает доступ к виртуальному каналу с помощью обычных методов выбора канала, доступных интерфейсу пользователя. Параметры механизма формирования виртуального канала CICAM должны быть в соответствии с разделом 14 настоящего стандарта.

4.6 Извлечение файла из CICAM

Настоящий стандарт определяет механизм, с помощью которого приложение Хоста, например HbbTV или МНР, может получать файлы, которые хранятся в CICAM. Целью использования этого механизма является извлечение файла для приложений, работающих в Хосте для считывания активов (цифровых объектов) интерфейса пользователя (иконок, графики) CICAM, а не от сервера через соединение IP Хоста. Предполагается, что приложению заранее известны доступные активы файла CICAM. Запрос файла или успешно выполнится, или перестанет работать, если файл недоступен. Параметры процесса поиска файла в CICAM должны быть в соответствии с разделом 9 настоящего стандарта.

4.7 Расширенная информация URI о правилах использования

Расширение параметров сигнализации URI управления контентом позволяет поддерживать ограничение операций в режиме спецэффектов, которые будут включены или отключены для соответствующих элементов управляемого контента. Это расширение параметров сигнализации применяется к управляемому контенту со статусом управления копией только одной генерации. Правила интерпретации URI замедления режима перемотки в Хосте настоящий стандарт не определяет.

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

4.8 Водяные знаки и транскодирование

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

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

В соответствии с настоящим стандартом CICAM создает водяные знаки на компрессированном видео на стороне получателя.

Транскодирование применяется в случае доставки IP CICAM в режиме проигрывателя, когда Хост не поддерживает кодек, используемый для доставленных компонентов службы. CICAM транскодирует каждый соответствующий поток компонентов в формат, поддерживаемый Хостом.

При доставке IP Хосту в режиме проигрывателя выполнение водяных знаков и транскодирование операций с контентом ограничивается в случаях, рассмотренных в 5.2 настоящего стандарта.

Настоящий стандарт позволяет CICAM создавать водяные знаки и транскодировать операции на контенте или службах, которые дескремблируются. Методы создания водяных знаков или форматы перекодирования стандарт не устанавливает. Нормативные положения, касающиеся создания водяных знаков и транскодирования операций, выполняемых в CICAM, должны быть в соответствии с 5.2 настоящего стандарта.

5 Общие требования

5.1 Требования обратной совместимости

Хосты, соответствующие настоящему стандарту, должны работать с CICAM, удовлетворяющим требованиям предыдущих версий CI Plus, т.е. [1], и с CICAM, соответствующим требованиям общего интерфейса и требованиям технологий DVB [2], [8].

Конкретные вопросы, касающиеся работы с несколькими потоками нескольких CICAM, рассматриваются в 6.2.7 настоящего стандарта.

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

5.2 Водяные знаки и транскодирование

Как отмечалось в 4.8 настоящего стандарта, интерфейсы CICAM CI Plus, выполняющие дескремблирование защищенных служб или компонентов потока, могут выполнять добавление водяных знаков и транскодирование компонентов потоков.

Независимо от функции обработки контента, выполняемой CICAM, для Хоста должен предоставляться совместимый с ним TS.

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

Операции транскодирования в формате ISOBMFF при доставке IP контента сопровождаются изменением размера семпла между входом и выходом CICAM, поэтому они могут выполняться CICAM только при работе в режиме проигрывателя.

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

При добавлении водяных знаков или при перекодировании CICAM может вставлять новые пакеты TS, удалять часть входных пакетов и/или изменять контент входных пакетов TS.

5.3 Скремблирование на уровне PES

Спецификация [1] предусматривает защиту контента, поставляемого скремблированным на уровне PES, и выполнение повторного скремблирования CICAM на уровне TS при доставке на Хост. Настоящий стандарт не допускает повторного скремблирования в CICAM контента на уровне TS. Это объясняется повышением уязвимости системы безопасности при повторном скремблировании.

6 Многопоточный режим работы

6.1 Общие замечания

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

На рисунке 3 в качестве примера показана схема расширенной архитектуры CI Plus, обеспечивающей поддержку многопоточного режима реализации Хоста с тремя тюнерами вещания и с возможностью доставки IP.

В контексте настоящего стандарта тюнер обеспечивает доставку TS MPEG-2 на физическом уровне наземных DVB, спутниковых и кабельных каналов и интерфейса сетей IP. При использования тюнера IP он может принимать обычные TS, защищенные СА. Контент может быть доставлен в формате ISOBMFF или в активах MPEG DASH. Общие вопросы процесса обработки IP контента CI Plus кратко описаны в 4.3 настоящего стандарта. Параметры обработки IP контента установлены в разделе 7 (Хост в режиме проигрывателя) и в разделе 8 (CICAM в режиме проигрывателя) настоящего стандарта.

В расширенной архитектуре каждая служба для дескремблирования в CICAM извлекается из поступающего TS при выборе PID этой службы с последующим формированием локального TS. Локальные TS мультиплексируются перед отправкой в CICAM, который дескремблирует каждую службу независимо. Когда мультиплексированные дескремблированные локальные TS возвращаются к Хосту, они демультиплексируются на отдельные SPTS, которые Хост может декодировать. Совокупность потоков, совместимых с Хостом, должна обрабатываться в соответствии с [2] до тех пор, пока CICAM не завершит инициализацию многопоточного ресурса, определенного в 6.4.2 настоящего стандарта, передав APDU CICAM_multistream_capability.

После создания сеанса многопоточного ресурса CICAM должен передать APDU CICAM_multistream_capability и ожидать приема одного или нескольких локальных TS в многопоточном режиме.

Настоящий стандарт предусматривает расширение ряда ресурсов CI [2] и [1] добавлением возможностей обработки многопоточного ресурса. Многопоточный Хост должен предлагать CICAM как многопоточные типы ресурса, так и стандартные типы ресурса единого потока. Это позволяет CI V1.3 Plus и более ранним версиям, совместимым с CICAM, нормально функционировать в режиме одиночного потока.

При поддержке Хостом многопоточного ресурса многопоточный CICAM может запросить сеанс или к ресурсам многопоточного типа, или к ресурсам типа одиночного потока. Если будет открыт какой-либо ресурс многопоточного типа, то CICAM должен продолжать работать в многопоточном режиме и должен запрашивать сеансы только к ресурсу многопоточного типа до тех пор, пока не будут закрыты все ресурсы многопоточного типа.

Если CICAM затребует ресурсы одиночного потока, то Хост должен работать в режиме одиночного потока в соответствии с [2].

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

Рисунок 3 - Схема расширенной архитектуры CI Plus, обеспечивающей поддержку многопоточного режима реализации Хоста с тремя тюнерами вещания и с возможностью доставки IP

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

Количество служб, которые могут быть реализованы через интерфейс TS в многопоточном режиме, ограничивает только общая пропускная способность интерфейса TS (96 Мбит/с) и возможности Хоста и CICAM. Максимальная скорость передачи службы вещания, пропускная способность, выделяемая для каждой службы в многопоточном режиме, и критерии возможности мультиплексирования Хостом дополнительных потоков определяются при оценке параметров реализации Хоста и характеристик доступных сетей вещания.

Дополнительные правила для работы в многопоточном режиме, когда в многопоточном Хосте устанавливаются многопоточный CICAM и однопоточный CICAM, определены в 6.2.7 настоящего стандарта.

Спецификации многопоточного ресурса представлены в 6.4 настоящего стандарта.

При необходимости использования ресурсов многопоточности типы ресурсов, указанные в [2] и [1], были обновлены с добавлением параметра LTS_id, идентифицирующего локальные TS, и определены в 6.4 настоящего стандарта.

Состав ресурса (идентификатор ресурса 00 90 00 41), необходимого для поддержки многопоточной функциональности, представлен в приложении Б настоящего стандарта.

6.2 Интерфейс транспортного потока и мультиплексирование локальных TS

6.2.1 Идентификатор локального TS

Каждому локальному TS Хост должен присваивать уникальный идентификатор локального TS (LTS_id). LTS_id заменяет фиксированное значение 0x47 в поле синхронизации байтов заголовка пакета TS каждого пакета TS, передаваемого от Хоста на CICAM. Хост устанавливает поле синхронизации байтов в заголовке TS пакетов LTS_id каждого соответствующего пакета TS, отправленного на CICAM. Значение LTS_id должно быть уникальным для каждого локального TS и не должно изменяться при выборе локального TS для дескремблирования и для передачи по интерфейсу TS. Рекомендуется, чтобы значения, присвоенные LTS_id, начинались от 0x47, т.е. LTS_id первого локального TS устанавливается на 0x47, LTS_id второго локального TS устанавливается на 0x48 и т.д.

Так как байт синхронизации локального TS может отличаться от фиксированного стандартного значения 0x47, это значение байта не должно использоваться для обнаружения первого байта каждого пакета транспортного потока.

CICAM не должен вносить изменения в поля LTS_id входящих локальных TS.

LTS_id используется демультиплексорами Хоста и CICAM для идентификации пакетов TS, связанных с каждым локальным TS. Хост может регенерировать каждый локальный TS из совместимого TS, заменяя LTS_id синхронизирующим байтом фиксированного стандартного значения 0x47. Хост не должен выполнять регенерацию TS до выполнения операций декодирования или хранения, если результирующий TS не будет использоваться устройствами или приложениями, требующими полностью совместимого TS.

Если интерфейс TS эксплуатируется в режиме одиночного потока, то LTS_id должен иметь значение 0x47.

6.2.2 Мультиплексирование вещательного контента и контента IP

Обмен контентом IP между Хостом и CICAM должен выполняться в формате TS. В режиме одиночного потока контент IP через интерфейс TS переносится как одиночный TS. В многопоточном режиме контент IP поставляется или как одиночный локальный TS, или как мультиплексированный с локальными TS вещания или потоками IP.

6.2.3 Параметры задержки мультиплексированных пакетов транспортного потока

Требования к параметрам задержки пакетов, вносимых CICAM для отдельных TS, проходящих через CICAM в Хост и из Хоста в CICAM, устанавливает [2]. В таблице 1 определены требования к порядку следования пакетов TS, к задержке пакетов TS и к изменениям задержки байтов TS на входе CICAM для различных вариантов использования. Первый вариант использования в случае вещания расширяет требования, содержащиеся в [2] для многопоточного режима. Следующие два варианта использования относятся к режиму доставки IP Хосту в режиме проигрывателя, указанному в разделе 7 настоящего стандарта, и к режиму IP доставки CICAM в режиме проигрывателя, указанному в разделе 8 настоящего стандарта. Четвертый вариант использования применяется в случае переноса через интерфейс TS контента вещания и контента IP.

Таблица 1 - Требования к порядку следования пакетов TS, к задержке пакетов TS и к изменениям задержки байтов TS на входе CICAM для различных вариантов использования

6.2.4 Правила применения шифра скремблирования и ключа управления контентом

Хост и CICAM должны применять одинаковые правила выбора шифра скремблирования в соответствии с [1] (таблица 5.6). Такой же шифр должен быть использован для всех локальных TS.

6.2.5 Услуга игнорирования, предоставляемая Хостом

В соответствии с [1] Хост предоставляет услугу игнорирования службы, позволяющую предотвратить отображение контента в случае использования пользователем CICAM, не совместимого с интерфейсом CI Plus.

По требованию оператора Хост не должен предоставлять игнорируемую службу в CICAM для дескремблирования. Услуга игнорирования службы, предоставляемая Хостом, активизируется в соответствии с [1] (раздел 10). В многопоточном режиме Хост не должен выполнять мультиплексирование локальных TS, содержащих игнорируемые службы в многопоточном TS, отправляемом на CICAM, т.е. услуга игнорирования применяется только к той службе, о которой сообщил оператор службы.

Услуга игнорирования, выполняемая Хостом, не распространяется на виды доставки IP, описанные в разделах 7 и 8 настоящего стандарта.

6.2.6 Тактовая частота транспортного потока

Вследствие того, что тактовая частота мультиплексируемых локальных TS может постоянно изменяться, может изменяться и скорость передачи по интерфейсу TS, поэтому Хост и CICAM должны функционировать в условиях переменных тактовых частот входного и выходного сигналов MPEG.

6.2.7 Обработка нескольких транспортных потоков несколькими CICAM

В настоящем стандарте многопоточный Хост должен работать с несколькими CICAM, соответствующими предыдущим версиям спецификации CI Plus [2]. В случае, когда в многопоточный Хост устанавливаются несколько CICAM, допускаются следующие варианты использования многопоточного Хоста:

- при работе Хоста только с многопоточными CICAM допускается обработка Хостом мультиплекса локальных TS в гирлянде последовательно соединенных CICAM;

- при работе Хоста только с однопоточными CICAM допускается работа Хоста в режиме одиночного потока при работе одиночных TS в гирлянде последовательно соединенных однопоточных CICAM;

- при работе Хоста с многопоточными и с однопоточными CICAM допускается работа Хоста:

- в многопоточном режиме при обработке мультиплекса локальных TS в гирлянде последовательно соединенных многопоточных CICAM с обходом однопоточных CICAM;

- в однопоточном режиме при обработке одиночных TS в гирлянде последовательно соединенных CICAM.

6.3 Выбор PID

6.3.1 Общие замечания

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

Для каждой выбранной службы Хост должен поддерживать список выбранных PID. Первоначальное содержание этого списка определяется Хостом и включает в себя минимальный набор PID "по умолчанию", как указано в 6.3.2 или 6.3.3 настоящего стандарта, в зависимости от обстоятельств. Список может также включать в себя и любые другие PID, которые Хост может выбрать для своих собственных потребностей.

Список выбранных PID может обновляться в следующих случаях:

- пользователь инициирует изменение в выбранном элементарном потоке, например, изменением активного аудиотрека;

- CICAM инициирует изменение списка для добавления или удаления PID. Запрос состоит из списка PID, перечисленных в порядке уменьшения очередности;

- любое иное событие, требующее изменения Хостом списка выбранных PID.

6.3.2 Выбор Хостом РID по умолчанию

После выбора службы по умолчанию Хост должен отобрать следующие PID и направить соответствующие пакеты TS через интерфейс TS:

- ES (PID Elementary_PID), объявленные в соответствующем APDU са_pmt;

- СА_PID, объявленные в CA_descriptor, присутствующие в соответствующем APDU ca_pmt;

- PID РМТ, содержащую выбранную службу;

- EIT PID в соответствии с [3];

- SDT PID в соответствии с [3].

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

Хост в частичных TS может включать дополнительные PID.

6.3.3 Выбор PID частоты настройки тюнера по умолчанию

В частном случае, когда CICAM выдает частоту настройки при помощи APDU tune_broadcast_req без ссылки на конкретную службу, устанавливая в поле APDU service_id значение 0x0000, тогда выбранные по умолчанию значения в списке PID должны содержать:

- PID PAT в соответствии с [9];

- PID CAT в соответствии с [9];

- PID EIT в соответствии с [3];

- PID SDT в соответствии с [3];

- список PID NIT в соответствии с [3].

В локальный TS Хост может включать дополнительные PID.

6.3.4 Приоритет выбора PID

CICAM предоставляет список PID, которые он хочет получить для выбранной службы (в порядке убывания приоритета). Наиболее приоритетными должны быть PID, необходимые для дескремблирования. Это атрибут, который может быть установлен для каждого запрашиваемого PID в APDU PID_select_req. Хост должен выбирать PID в соответствии с приоритетом списка PID. Если Хост не может включать в себя PID, которые CICAM обозначает приоритетными для дескремблирования (в APDU PID_select_req), то CICAM может неправильно дескремблировать службу.

6.3.5 Инициация обновления CICAM

CICAM может потребовать обновления списка PID, выбранного Хостом. Для изменения списка PID по запросу CICAM должны использоваться APDU PID_select_req. Этот список может включать в себя PID, на которые нет ссылок в РМТ выбранной службы. Хост должен ответить на такой запрос передачей APDU PID_select_reply. Совокупность PID ES для служб, перечисленных в са_pmt, не может быть изменена с помощью CICAM.

Результирующий список PID содержит следующие группы:

- PID ES (Elementary_PID), объявленные в последнем появлении APDU са_pmt для службы;

- PID, объявленные CICAM в APDU PID_select_req APDU;

- любые дополнительные PID, выбранные Хостом для собственных нужд.

Если Хост не может выбрать все вышеуказанные PID, то он должен выбрать PID в следующем порядке:

- PID ES (PID Elementary_PID), декларированные в последнем событии са_pmt, связанном со службой, и поэтому имеющие высший приоритет;

- PID, запрошенные CICAM по списку в порядке очередности, и дополнительные PID, выбранные Хостом для собственных нужд. Выбор приоритетов собственного набора необходимых PID из перечня дополнительных PID, выбранных CICAM, определяется реализацией Хоста.

6.3.6 Изменение выбранных ES

Всякий раз когда Хост посылает обновление APDU са_pmt для выбранной службы (са_pmt_list_management = 0x05), Хост должен вернуться к набору PID "по умолчанию", как определено в 6.3.2 настоящего стандарта.

6.3.7 Корректировка списка PID по инициативе Хоста

Хост может корректировать список PID с добавлением или удалением PID в соответствии с собственными потребностями. В случае изменения списка PID, запрошенных CICAM, Хост должен информировать об этом CICAM отправлением APDU PID_select_reply.

PID, запрошенные CICAM, в том числе и не критические для дескремблирования, должны быть предоставлены и должны оставаться в локальном TS в соответствии с возможностями Хоста.

Хост может повторно выбрать один из PID, запрошенных CICAM, и должен соответственно информировать CICAM об этом, отправив APDU PID_select_reply. Хост не должен информировать CICAM, если он добавляет или удаляет PID, которые не были в списке PID, запрошенных CICAM.

Удаление или повторный выбор PID выполняются Хостом в соответствии с приоритетом, установленным CICAM.

6.3.8 Службы, выбираемые из одного транспортного потока

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

6.4 Ресурсы для обработки нескольких потоков

6.4.1 Общие замечания

Ресурсы обработки нескольких потоков являются модифицированными видами следующих ресурсов управления контентом:

- управления Хостом;

- поддержки системы условного доступа;

- MMI;

- приложения MMI.

Ресурсы обработки нескольких потоков специфицированы в 6.4.2 настоящего стандарта.

Перечень идентификаторов типов данных многопоточной функциональности должен быть в соответствии с приложением Б.

6.4.2 Многопоточный ресурс

6.4.2.1 Общие замечания

Многопоточный ресурс содержит APDU, показывающие возможности для CICAM, связанные с многопоточностью, и APDU для управления выбором PID в локальном TS. Ресурс многопоточности реализуют Хосты и CICAM. Параметры APDU многопоточного ресурса должны быть в соответствии с таблицей 2.

6.4.2.2 APDU от CICAM к Хосту о возможностях работы CICAM в многопоточном режиме

При открытом сеансе многопоточного ресурса CICAM должен направить Хосту APDU CICAM_multistream_capability с сообщением о максимальном количестве TS и ES, которые CICAM способен дескремблировать одновременно.

Учитывая возможности CICAM, Хост должен ограничить количество локальных TS, которые он одновременно мультиплексирует, и количество ES, которые запрашивает CICAM для дескремблирования.

Синтаксис APDU CICAM_multistream_capability должен быть в соответствии с таблицей 3.

Таблица 2 - Параметры APDU многопоточного ресурса

Таблица 3 - Синтаксис APDU CICAM_multistream_capability

Семантика полей APDU CICAM_multistream_capability:

- CICAM_multistream_capability_tag: поле 24 бита является тегом со значением 0x9F9200;

- length_field: поле указывает значение длины полезной нагрузки APDU в формате BER ASN.1 в соответствии с [2] (8.3.1);

- max_local_TS: поле 8 битов указывает максимальное количество локальных TS, которые CICAM может получить одновременно;

- max_descramblers: поле 16 битов указывает общее количество дескремблеров, которые CICAM может предоставить одновременно для всех локальных TS.

6.4.2.3 APDU от CICAM к Хосту запроса выбора PID

CICAM посылает Хосту APDU PID_select_req с запросом на конкретный набор PID для включения в принятый локальный TS.

CICAM должен предоставить список PID в порядке приоритета списка. Каждый PID в списке должен сопровождаться флагом critical_for_descrambling_flag, который CICAM устанавливает для PID, необходимых для дескремблирования контента. Список PID не должен содержать PID с critical_for_descrambling_flag, установленным в 0b1 после первого PID, который имеет critical_for_descrambling_flag, установленный в 0b0.

Если Хост не может включить PID с установленным флагом critical_for_descrambling_flag, то CICAM не может корректно дескремблировать службу.

В любой момент времени Хост может отменить или повторно выбрать один из PID, выбранных CICAM ранее. Об этом случае Хост должен информировать CICAM, отправив APDU PID_select_reply об обновленном состоянии тех PID, которые не были выбраны или были выбраны повторно.

В случае отмены Хостом PID он должен отменять PID с самым низким приоритетом из списка PID, представленного CICAM первоначально при отборе PID.

При повторном выборе Хостом PID из списка ранее выбранных он должен выбирать PID с высшим приоритетом.

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

Синтаксис APDU PID_select_req должен быть в соответствии с таблицей 4.

Таблица 4 - Синтаксис APDU PID_select_req

Семантика полей APDU PID_select_req:

- PID_select_req_tag: поле 24 бита является тегом со значением 0x9F9201;

- length_field: длина полезной нагрузки APDU в формате BER ASN.1 в соответствии с [2] (8.3.1);

- LTS_id: поле 8 битов содержит идентификатор локального TS;

- num_PID: поле 8 битов указывает количество PID, содержащихся в передаваемом цикле;

- critical_for_descrambling_flag: при флаге, установленном на 0b1, связанный с ним PID имеет решающее значение для дескремблирования. При установке на 0b0 связанный с ним PID не имеет решающего значения для дескремблирования;

- PID: поле 13 битов содержит запрашиваемое значение PID. Хост должен игнорировать любые запросы при значении PID 0x1FFF.

6.4.2.4 APDU ответа Хоста на запрос набора PID

Когда Хост получает запрос на PID от CICAM, он должен подтвердить способность обеспечивать выделение запрошенных PID, используя APDU PID_select_reply. Хост должен указать статус для всех PID, которые были запрошены для выбора в предыдущем APDU PID_select_req, установив соответствующим образом флаг PID_selected_flag.

CICAM будет ожидать приема APDU PID_select_reply до выдачи следующего APDU PID_select_req для того же LTS_id.

Всякий раз когда Хост отменяет выбор PID или выбирает PID повторно из числа запрошенных CICAM, Хост должен сообщить CICAM об изменениях и послать APDU PID_select_reply. APDU PID_select_reply указывает статус всех PID, которые присутствовали в предыдущем APDU PID_select_req.

Синтаксис АРDU PID_select_reply должен быть в соответствии с таблицей 5.

Таблица 5 - Синтаксис АРDU PID_select_reply

Семантика полей APDU PID_select_reply:

- PID_select_reply_tag: поле 24 бита является тегом со значением 0x9F9202;

- length_field: поле содержит длину полезной нагрузки APDU в формате BER ASN.1 в соответствии с [2] (8.3.1);

- LTS_id: поле 8 битов содержит идентификатор локального TS;

- PID_selection_flag: флаг указывает статус PID, он должен быть установлен в 0b0, если весь TS передается как локальный TS, а в поле num_PID должно быть установлено 0x0. Если будет применена селекция PID, то флаг должен быть установлен в 0b1 и Хост должен информировать CICAM о выбранных PID, используя поле num_PID и список выбранных PID.

- num_PID: поле 8 битов указывает количество PID, содержащихся в передаваемом цикле;

- PID_selected_flag: статус соответствующего запрашиваемого PID. PID, который выбран успешно, должен иметь этот флаг, установленный в 0b1. Если PID не может быть выбран Хостом, то его значение должно быть 0b0.

- PID: поле 13 битов содержит PID, для которого установлен флаг PID_selected_flag.

6.4.3 Ресурсы управления контентом

6.4.3.1 Общие замечания

Поддержка приема нескольких потоков должна обеспечиваться дополнением контента ресурса управления новым типом ресурсов (0х008С1041).

Контент ресурса управления в обобщенной форме должен быть в соответствии с таблицей 6.

Таблица 6 - Контент ресурса управления в обобщенной форме

Пункт 6.4.3.2 настоящего стандарта определяет APDU, предназначенные для расширения ресурса управления контентом в многопоточном режиме. Упомянутое расширение ресурса выполняется включением поля идентификатора локального TS (LTS_id). Остальные APDU этого типа ресурсов соответствуют синтаксису, приведенному в [1] (11.3.1 и 11.3.2).

В 6.4.3.3 настоящего стандарта определены расширенные протоколы управления контентом, специфицированным в [1].

6.4.3.2 APDU расширенного ресурса управления контентом в многопоточном режиме

6.4.3.2.1 APDU cc_PIN_reply

Хост должен использовать APDU cc_PIN_reply для протокола начала записи. В случае активности многопоточного режима APDU должен дополняться включением LTS_id.

Синтаксис этого расширенного APDU должен быть в соответствии с таблицей 7.

Таблица 7 - Синтаксис APDU cc_PIN_reply

Семантика полей APDU cc_PIN_reply:

- PID_select_reply_tag: поле 24 бита является тегом со значением 0x9F9202;

- length_field: поле содержит длину полезной нагрузки APDU в формате BER ASN.1 в соответствии с [2] (8.3.1);

- LTS_bound_flag: при установке на 0b1 флаг показывает, что APDU cc_PIN_reply связан с конкретным легальным TS. При установке на 0b0 показывает, что APDU cc_PIN_reply не связан с LTS_id, например, когда передается в ответ на cc_PIN_cmd, APDU cc_PIN_playback или cc_PIN_MMI_req;

- LTS_id: поле 8 битов содержит идентификатор локального ТS;

- PINcode_status_field: поле 8 битов, семантика этого поля должна быть в соответствии с [1] (11.3.2.3).

6.4.3.2.2 APDU cc_PIN_event

APDU cc_PIN_event используется для протокола начала записи. В случае активности многопоточного режима он расширяется включением LTS_id. Синтаксис APDU cc_PIN_event должен быть в соответствии с таблицей 8.

Таблица 8 - Синтаксис APDU cc_PIN_event

Семантика полей APDU cc_PIN_event:

- cc_PIN_event_tag: поле 24 бита является тегом со значением 0x9F9015;

- length_field: поле содержит длину полезной нагрузки APDU в формате BER ASN.1 в соответствии с [2] (8.3.1);

- LTS_id: поле 8 битов содержит идентификатор локального TS.

Семантика других полей должна быть в соответствии с [1] (11.3.2.4).

6.4.3.3 Расширенные протоколы управления

6.4.3.3.1 Протокол передачи и подтверждения URI

В случае активности многопоточного режима URI передается от CICAM к Хосту в составе APDU cc_sac_data_req. Хост должен ответить CICAM передачей APDU cc_sac_data_cnf.

Параметры модифицированного протокола передачи и подтверждения URI должны быть в соответствии с таблицей 9.

Таблица 9 - Параметры модифицированного протокола передачи и подтверждения URI

CICAM должен получить от Хоста APDU cc_sac_data_cnf перед отправлением следующего сообщения протокола передачи и подтверждения URI.

6.4.3.3.2 Протокол начала записи

В случае активности многопоточного режима Хост, информируя CICAM о начале записи, передает APDU cc_sac_data_req, на который CICAM должен ответить Хосту подтверждением о приеме и передать APDU cc_sac_data_cnf.

Параметры модифицированного протокола начала записи, расширенного при использовании многопоточного режима, должны быть в соответствии с таблицей 10. Хост должен дождаться от CICAM подтверждения APDU cc_sac_data_cnf перед отправлением следующего сообщения протокола начала записи.

Таблица 10 - Параметры модифицированного протокола начала записи

При выполнении протокола начала записи Хост указывает, поддерживается выбранная программа пользователем или не поддерживается. Если выбранная программа пользователем не поддерживается, то CICAM должен воздержаться от использования MMI высокого уровня или приложения MMI для диалога с пользователем по поводу выбранной программы. CICAM должен рассматривать выбранную программу как необслуживаемую, когда operating_mode будет установлен равным или 0x01 (Timeshift), или 0x02 (Unattended_Recording).

6.4.3.3.3 Расширение протокола остановки записи

В случае активности многопоточного режима остановка записи выполняется передачей от Хоста на CICAM APDU cc_sac_data_req. CICAM должен ответить Хосту передачей APDU cc_sac_data_cnf.

Параметры модифицированного протокола остановки записи, расширенного при обслуживании нескольких потоков, должны быть в соответствии с таблицей 11.

Таблица 11 - Параметры модифицированного протокола остановки записи

Хост должен дождаться от CICAM подтверждения перед отправлением следующего сообщения протокола остановки записи.

6.4.3.3.4 Расширение протокола изменения режима работы

В случае активности многопоточного режима Хост информирует CICAM об изменении режима работы и посылает APDU cc_sac_data_req. CICAM должен ответить Хосту передачей APDU cc_sac_data_cnf.

Параметры модифицированного протокола изменения режима работы должны быть в соответствии с таблицей 12.

Таблица 12 - Параметры модифицированного протокола изменения режима работы

Перед отправлением следующего сообщения протокола изменения режима работы Хост должен дождаться подтверждения от CICAM.

6.4.3.3.5 Расширение протокола замены лицензии между CICAM и Хостом

В случае активности многопоточного режима расширение протокола замены лицензии между CICAM и Хостом выполняется передачей от CICAM на Хост APDU cc_sac_data_req с контентом лицензии. Хост должен ответить CICAM APDU cc_sac_data_cnf с подтверждением получения.

Параметры протокола замены лицензии между CICAM и Хостом, расширенного для работы в многопоточном режиме, должны быть в соответствии с таблицей 13.

Таблица 13 - Параметры протокола замены лицензии между CICAM и Хостом, расширенного для работы в многопоточном режиме

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

6.4.4 Ресурсы поддержки условного доступа

6.4.4.1 Общие замечания

Для поддержки многопоточного режима ресурс поддержки условного доступа должен обеспечиваться новым resource_type, определенным как (resource_type=2, версия 1), в котором APDU са_pmt и са_pmt_reply расширены добавлением к синтаксису APDU идентификатора локального TS (LTS_id). APDU ca_pmt расширяется также включением поля PMT_PID с целью экономии ресурсов CICAM для выполнения задачи синтаксического анализа локального TS при его получении.

Хост и CICAM должны использовать эти расширенные APDU в многопоточном режиме.

6.4.4.2 APDU са_pmt

APDU са_pmt расширяется включением идентификатора локального TS и поля PMT_PID. Синтаксис APDU ca_pmt должен быть в соответствии с таблицей 14.

Таблица 14 - Синтаксис APDU ca_pmt

Семантика полей APDU ca_pmt:

- LTS_id: поле 8 битов содержит идентификатор локального TS;

- ca_pmt_list_management: поле 8 битов в режиме одиночного потока указывает, что пользователь выбрал одну программу (состоит из одного или нескольких ES) или несколько программ. В многопоточном режиме каждая программа должна соответствовать отдельному локальному TS, в этом случае могут быть использованы значения, приведенные в таблице 15. Это подмножество определено в [2] (8.4.3.4).

Таблица 15 - Значения поля ca_pmt_list_management для отдельного локального TS в многопоточном режиме

В многопоточном режиме "Only (только)" используется для запуска новой программы в связанном локальном TS. Эта операция не влияет на другие локальные работающие TS:

- PMT_PID: поле 13 битов содержит PID РМТ выбранной службы. Всякий раз когда PID РМТ выбранной службы изменяется, Хост должен отправить APDU ca_pmt с полем ca_pmt_list_management, содержащим 0x05 (обновление);

- другие поля должны быть в соответствии с [2] (таблица 25).

6.4.4.3 APDU ca_pmt_reply

В случае активности многопоточного режима APDU са_pmt_reply расширяется добавлением поля идентификатора локального TS (LTS_id). Синтаксис расширенного APDU ca_pmt_reply должен быть в соответствии с таблицей 16.

Таблица 16 - Синтаксис расширенного APDU ca_pmt_reply

Семантика полей APDU са_pmt_reply:

- LTS_id: поле 8 битов содержит идентификатор локального TS;

- семантика других полей должна быть в соответствии с [2] (таблица 26).

6.4.5 Ресурсы Хоста управления несколькими потоками

6.4.5.1 Общие замечания

Многопоточный ресурс управления Хоста (с ID ресурса 0x00200081) базируется на версии 3 управления Хоста DVB. Эта версия ресурса позволяет CICAM запрашивать Хост о необходимом типе настройки или для презентации (представления), или фоновой. Хост должен ответить на запрос информацией о типе настройки с LTS_id потока.

Если Хост предоставит CICAM фоновую настройку, то CICAM должен ответить на APDU ask_release в течение одной секунды "Release_OK" в APDU ask_release_reply и должен выделить этот ресурс, не используя приложения MMI или MMI высокого уровня. Эти операции не должны оказывать влияние на поток презентации.

Перечень APDU, поддерживающих многопоточный тип ресурса управления Хоста, должен быть в соответствии с таблицей 17. Все другие APDU ресурса управления Хоста DVB (версия 3) не должны поддерживаться.

Таблица 17 - Перечень APDU, поддерживающих многопоточный тип ресурса управления Хоста

CICAM не должен на интервале одного сеанса запрашивать настройку для презентации и фоновую настройку. При необходимости выполнения двух видов настроек (для презентации и фоновой настройки) CICAM должен запрашивать другой сеанс к ресурсу управления Хостом. Многопоточный Хост должен поддерживать не менее двух сеансов многопоточного ресурса управления Хоста DVB.

На интервале многопоточного сеанса управления Хоста любой запрос настройки отменяет и заменяет предыдущий запрос в этом сеансе.

В многопоточном режиме может потребоваться фильтрация PID для сохранения пропускной способности интерфейса TS на уровне ниже максимальной. После подтверждения успешного запроса настройки APDU tune_reply Хост должен обеспечить минимально необходимое подмножество PID в зависимости от типа запроса настройки. Если целью запроса настройки от CICAM является служба, то Хост должен обеспечить необходимые PID в соответствии с 6.3.2 настоящего стандарта. CICAM может запрашивать дополнительные PID, используя APDU pid_select_req.

Если целью запроса настройки от CICAM является не служба, а частота настройки, то Хост должен предоставить совокупность PID в соответствии с 6.3.3 настоящего стандарта. CICAM может запрашивать дополнительные PID, используя APDU pid_select_req. Синтаксис APDU tune_broadcast_req, tune_triplet_req, tune_lcn_req, tune_ip_req и tune_reply изменен в их многопоточных версиях, чтобы позволить CICAM запрашивать настройку для презентации пользователю или фоновую настройку, означающую, что поток не предназначен для презентации. Все другие APDU сохраняют синтаксис ресурса версии 3 управления Хостом DVB, определенный в разделе 13 настоящего стандарта. В 6.4.5.2-6.4.5.6 настоящего стандарта определены измененные синтаксисы соответствующих APDU для многопоточных операций.

6.4.5.2 APDU tune_broadcast_req

Версия APDU tune_broadcast_request в многопоточном режиме позволяет CICAM указать, необходимо или нет представлять запрос настройки пользователю. Хост должен ответить APDU tune_reply, информируя CICAM, с каким LTS_id будет отправлен требуемый поток. Синтаксис APDU tune_broadcast_req представлен в таблице 18.

Таблица 18 - Синтаксис APDU tune_broadcast_req

Семантика полей APDU tune_broadcast_request:

- background_tune_flag: флаг указывает режим, в котором должна быть выполнена настройка: в фоновом режиме или для презентации пользователю. Значение 0b0 указывает, что настройка должна быть в режиме презентации; значение 0b1 указывает, что настройка должна быть выполнена в фоновом режиме. В случае запроса фоновой настройки флаги tune_quietly_flag и keep_app_running_flag должны игнорироваться;

- семантика других полей должна быть в соответствии с 13.2.1 настоящего стандарта.

6.4.5.3 APDU tune_triplet_req

Версия APDU tune_triplet_req в многопоточном режиме добавляет возможность, позволяющую CICAM указать, должен быть запрос настройки представлен пользователю или нет. Хост должен ответить APDU tune_reply, сообщая CICAM, с каким LTS_id будет отправлен запрошенный поток настройки.

Синтаксис АРDU tune_triplet_req представлен в таблице 19.

Таблица 19 - Синтаксис APDU tune_triplet_req

Семантика полей APDU tune_triplet_req:

- background_tune_flag: в соответствии с 6.4.5.2 настоящего стандарта;

- семантика других полей: в соответствии с 13.2.2 настоящего стандарта.

6.4.5.4 APDU tune_Icn_req

Версия APDU tune_Icn_req в многопоточном режиме добавляет возможность CICAM указывать, должен представляться пользователю запрос настройки или нет. Хост должен ответить APDU tune_reply, информируя CICAM, на который LTS_id будет отправлен запрошенный поток настройки.

Синтаксис APDU tune_lcn_req представлен в таблице 20.

Таблица 20 - Синтаксис APDU tune_lcn_req

Семантика полей APDU tune_Icn_req:

- background_tune_flag: в соответствии с 6.4.5.2 настоящего стандарта;

- семантика других полей: в соответствии с 13.2.3 настоящего стандарта.

6.4.5.5 APDU tune_ip_req

Версия APDU tune_ip_req в многопоточном режиме добавляет средство, позволяющее CICAM указать, должен представляться пользователю запрос настройки или нет. Хост должен ответить APDU tune_reply, информируя CICAM, на который LTS_id будет отправлен запрошенный поток настройки.

Синтаксис APDU tune_ip_req представлен в таблице 21.

Таблица 21 - Синтаксис APDU tune_ip_req

Семантика полей APDU tune_ip_req:

- background_tune_flag: в соответствии с 6.4.5.2 настоящего стандарта;

- семантика других полей: в соответствии с 13.2.4 настоящего стандарта.

6.4.5.6 APDU tune_reply

APDU tune_reply отправляет Хост в ответ на каждый из трех предыдущих типов запроса настройки, определенных для многопоточного ресурса управления Хоста DVB. Он используется для того, чтобы сообщить CICAM об успешной настройке и LTS_id, с которым требуемый поток будет отправлен.

Синтаксис APDU tune_reply представлен в таблице 22.

Таблица 22 - Синтаксис APDU tune_reply

Семантика полей APDU tune_reply:

- LTS_id: поле 8 битов содержит идентификатор локального TS, который может быть найден по запросу настройки локального TS. LTS_id должен игнорироваться, если запрос настройки будет неудачным;

- все другие поля должны быть в соответствии с [1] (таблица 14.30).

6.4.6 Ресурс приложения MMI

6.4.6.1 Общие замечания

Поддержка функций многопоточного режима должна обеспечиваться новым типом ресурса приложения MMI (resource_type 2, версия 1), в котором APDU RequestStart расширен добавлением к синтаксису APDU LTS_id. Хост может использовать дополнительный LTS_id для того, чтобы связать запрос с ситуацией, когда Хост отображает одновременно более одной программы (например, картина в картине, мозаика или предоставляет функцию двойного дисплея).

Многопоточный ресурс приложения MMI базируется на ресурсе приложения MMI версия 3, тип 1, специфицированного в 12.3 настоящего стандарта, и опционально включает ADQ.

6.4.6.2 APDU RequestStart

Синтаксис расширенного APDU RequestStart, содержащего идентификатор локального TS, должен быть в соответствии с таблицей 23.

Таблица 23 - Синтаксис расширенного APDU RequestStart, содержащего идентификатор локального TS

Семантика полей APDU RequestStart:

- LTS_bound_flag: флаг, установленный на 0b1, указывает, что запрос связан с определенным локальным TS. Когда этот флаг установлен на 0b0, это означает, что запрос не связан с определенным локальным TS, например, в ответ на отправленный Хостом APDU enter_menu;

- LTS_id: поле 8 битов содержит идентификатор локального TS, используется CICAM для того, чтобы ассоциировать объект RequestStart с локальным TS, когда LTS_bound_flag установлен в 0b1. Хост может использовать значение LTS_id для того, чтобы ассоциировать запрос с областью отображения, где в настоящее время отображается соответствующая программа, если дескремблируется более одной программы;

- семантика других полей должна быть в соответствии с [8] (таблица 62).

6.4.6.3 APDU RequestStartAck

APDU RequestStartAck определен в [8] (6.5.3). Семантика поля AckCode в расширенной версии при значении AckCode = 0x05 соответствует случаю "не обслуживается пользователем", когда конечный пользователь отсутствует.

После приема APDU RequestStartAck с AckCode = 0x05 CICAM не должен передавать еще один APDU RequestStart для этого LTS_id до тех пор, пока:

- Хост не укажет, что пользователь передал протокол начала записи или протокол остановки записи;

- Хост не укажет, что LTS_id предназначен для другой программы, передачей APDU ca_pmt или APDU sd_start.

6.4.6.4 APDU FileRequest

APDU FileRequest должен быть в соответствии с [8] (6.5.4).

6.4.6.5 APDU FileAck

APDU FileAck должен быть в соответствии с [8] (6.5.5).

6.4.6.6 APDU AppAbortRequest

APDU AppAbortRequest должен быть в соответствии с [8] (6.5.6).

6.4.6.7 APDU AppAbortAck

APDU AppAbortAck должен быть в соответствии с [8] (6.5.7).

6.4.7 Ресурсы MMI высокого уровня

6.4.7.1 Общие замечания

Поддержка многопоточного режима ресурсом MMI высокого уровня обеспечивается применением нового типа ресурса (resource_type = 2, версия = 1), в котором APDU enq, menu и list расширены добавлением к синтаксису APDU идентификатора LTS_id. Хост может использовать дополнительный LTS_id для того, чтобы связать запрос с отображением Хостом более одной программы одновременно (например, картинка в картинке, мозаика или сдвоенный дисплей).

Хост и CICAM должны использовать расширенный APDU в случае активности многопоточного режима.

6.4.7.2 APDU enq

Расширенный APDU enq включает в себя идентификатор локального TS. Синтаксис APDU enq должен быть в соответствии с таблицей 24.

Таблица 24 - Синтаксис APDU enq

Семантика полей APDU enq:

- LTS_bound_flag: флаг при установке на 0b1 указывает, что запрос связан с определенным локальным TS. Когда этот флаг установлен на 0b0, это означает, что запрос не связан с определенным локальным TS, например, в ответ на отправленный Хостом APDU enter_menu;

- LTS_id: идентификатор локального TS используется CICAM для того, чтобы связать объект запроса с локальными TS, когда LTS_bound_flag установлен в 0b1. Хост может использовать значение LTS_id для того, чтобы связать объект запроса с зоной отображения, в которой отображается соответствующая программа, когда дескремблируется более одной программы;

семантика полей blind_answer, answer_text_length, text_char должна быть в соответствии с [2] (таблица 47).

6.4.7.3 APDU answ

APDU answ определяется в соответствии с [2] (8.6.5.3). Кодирование поля answ_id должно быть в соответствии с таблицей 25.

Таблица 25 - Кодирование поля answ_id

Значение Unattended (не обслуживается) означает, что LTS_id соответствует программе, которая в настоящий момент не обслуживается конечным пользователем (например, Хост в настоящий момент записывает необслуживаемую программу), и Хост не может вывести на экран требуемый объект запроса. После приема APDU answ с answ_id "не обслуживается пользователем" CICAM должен воздерживаться от отправки другого объекта MMI высокого уровня для того же LTS_id до тех пор, пока:

- Хост не укажет, что программа снова обслуживается пользователем или при запуске протокола начала записи, или при запуске протокола остановки записи;

- Хост не укажет, что LTS_id выделяется для другой программы при помощи APDU ca_pmt или APDU sd_start.

6.4.7.4 APDU menu

APDU menu определяется в соответствии с [2] (8.6.5.4). Семантика APDU menu расширяется включением полей локального TS. Синтаксис APDU menu в соответствии с таблицей 26.

Таблица 26 - Синтаксис APDU menu

Семантика полей APDU menu:

- LTS_bound_flag: флаг, когда он установлен в 0b1, указывает, что объект запроса связывается с определенным локальным TS. Когда этот бит устанавливается в 0b0, это указывает, что запрос не связан с определенным локальным TS, например, он может быть ответом Хосту на APDU enter_menu;

- LTS_id: поле 8 битов, идентификатор локального TS используется CICAM для связывания объекта меню с локальным TS, когда LTS_bound_flag установлен в положение 0b1. Хост может использовать значение LTS_id для связывания объекта меню с областью отображения, в которой отображается соответствующая программа, при дескремблировании более одной программы.

6.4.7.5 APDU menu_answ

APDU menu_answ определен в [2] (8.6.5.5). Семантика поля choice_ref расширяется в соответствии с таблицей 27.

Таблица 27 - Кодирование поля choice_ref

Значение Unattended (не обслуживается) означает, что LTS_id соответствует программе, которая в настоящий момент не обслуживается конечным пользователем (например, Хост в настоящий момент записывает необслуживаемую программу), и Хост не может вывести на экран требуемый объект запроса. После приема APDU answ с answ_id Unattended (не обслуживается), CICAM должен воздерживаться от отправки другого объекта МMI высокого уровня для того же LTS_id до тех пор, пока:

- Хост не укажет, что программа снова обслуживается или при запуске протокола начала записи, или при запуске протокола остановки записи;

- Хост не укажет, что LTS_id выделяется для другой программы при помощи APDU ca_pmt или APDU sd_start.

6.4.7.6 APDU list

APDU list определен в [2] (8.6.5.5). Синтаксис расширенного APDU list представлен в таблице 28.

Таблица 28 - Синтаксис расширенного APDU list

Семантика APDU list расширяется включением полей локального TS:

- LTS_bound_flag: флаг указывает, что объект запроса связывается с определенным локальным TS, когда он установлен в 0b1. Когда флаг устанавливается в 0b0, это указывает, что запрос не связан с определенным локальным TS, например, он может быть ответом Хосту на APDU enter_menu;

- LTS_id: поле 8 битов содержит идентификатор локального TS и используется СICАМ для связывания объекта меню с локальным TS, когда LTS_bound_flag установлен в положение 0b1. Хост может использовать значение LTS_id для связывания объекта меню с областью отображения, в которой отображается соответствующая программа, при дескремблировании более одной программы.

6.4.7.7 APDU close_mmi

APDU close_mmi должен быть в соответствии с [2] (8.6.2.1).

6.4.7.8 APDU display_control

APDU display control должен быть в соответствии с [2] (8.6.2.2).

6.4.7.9 APDU display_reply

APDU display_reply должен быть в соответствии с [2] (8.6.2.3).

7 Хост в режиме проигрывателя контента IP

7.1 Общие замечания

В разделе 7 настоящего стандарта нормируются параметры обработки контента IP, представленного в форматах: TS, ISOBMFF, MPEG DASH, содержащего контент или в формате TS, или в формате ISOBMFF.

Контент IP может поставляться в любом формате контейнера TS, или ISOBMFF, или в любом формате файла, встроенного в объект DASH. Если контент поставляется не в формате TS, Хост управляет деинкапсуляцией семплов контента в специфический базовый формат контейнера TS CI Plus IP контента. Этот формат применяется при обмене между Хостом и СICАМ.

При работе Хоста в режиме проигрывателя CICAM может применить скремблирование управления контента CI Plus для защиты созданных элементарных потоков.

При переносе IP контента в контейнере формата TS или в контейнере какого-либо другого формата, исключая формат стандартных TS, защищенных СА, интерфейс TS работает в режиме семпла, а в случаях обычного TS он работает в нормальном режиме.

В режиме семпла метаданные DRM и управляющая информация, связанная с поставленным IP-элементом контента, передаются от Хоста на CICAM через интерфейс команд прежде, чем проигрывание может быть запущено. Метаданные DRM, изменяющиеся между семплами, например IV, переносят с данными семпла внутри полосы через интерфейс TS.

В режиме семпла CICAM накапливает в буфере входящие данные для дескремблирования. По этой причине, как правило, дескремблирование обычных TS с постоянной задержкой пакетов через CICAM в режиме семпла не применяется.

Если информация о дате и времени от тюнера вещания недоступна, то Хост и CICAM могут получить информацию о дате и времени через сетевой интерфейс IP. Настоящий стандарт не определяет правила получения информации о дате и времени через сетевой интерфейс IP.

Возможности выполнения Хостом услуги игнорирования, определенные в [1] (раздел 10), применяемые к вещательным службам, не должны использоваться для служб, доставленных IP через Хост в режиме проигрывателя.

7.2 Режимы интерфейса транспортного потока

При дескремблировании семпла CICAM может буферизировать принимаемый семпл перед его дескремблированием с последующей передачей обратно на Хост через интерфейс TS. Буферизация семпла в CICAM позволяет дескремблировать семпл, который будет создан, как правило, с новым IV. Метод буферизации в CICAM и количество дескремблеров, доступных в CICAM, настоящим стандартом не определяются.

Хост сообщает CICAM о формате передаваемого контента, устанавливая интерфейс TS (или локальный TS в контексте многопоточного режима) в режим семпла или в нормальный режим.

Хост управляет конфигурацией интерфейса TS с помощью APDU sd_start и ca_pmt. APDU sd_start является составной частью ресурса дескремблирования семпла, который определен в 7.4 настоящего стандарта.

При изменении режима интерфейса TS данные, относящиеся к предыдущему режиму в Хосте или CICAM, должны быть отброшены.

7.3 Интерфейс команд

7.3.1 Общие замечания

При работе интерфейса TS в режиме семпла Хост должен координировать доставку данных мультимедийных файлов в CICAM для обеспечения правильного дескремблирования контента. С этой целью CICAM также должен получать конкретную информацию о метаданных в медиафайле.

7.3.2 Инициирование проигрывания

Хост управляет конфигурацией интерфейса TS, который по умолчанию находится в нормальном режиме. Хост должен использовать APDU sd_start, чтобы переключить интерфейс TS или локальный TS из мультипотокового режима в режим семпла.

При приеме от Хоста APDU sd_start CICAM должен завершить дескремблирование любого контента нормального режима, ожидать контент, инициируемый APDU са_pmt, и подтвердить конфигурацию TS, отправляя APDU sd_start_reply. После передачи APDU sd_start интерфейс TS или локальный TS должны считаться находящимися в режиме семпла.

С помощью APDU sd_start Хост может запрашивать дескремблирование семплов, поступающих из разных треков. Эти треки, находящиеся или в одном и том же медиафайле или в разных медиафайлах, обозначаются как треки семплов и могут иметь свои собственные метаданные DRM.

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

После того как CICAM будет готов к получению семплов, он должен подтвердить готовность отправкой APDU sd_start_reply. После получения этого подтверждения Хост может начать передачу первых семплов. Если CICAM не может дескремблировать семпл, например, пока он находится в процессе получения лицензии от сервера DRM, то это состояние должно быть указано в подтверждении готовности. Когда CICAM будет способен дескремблировать семплы, он должен послать Хосту второе подтверждение, используя APDU sd_start_reply с обновленным статусом. Теперь CICAM должен запустить дескремблирование семплов и отослать дескремблированные семплы назад к Хосту через обратный интерфейс TS. Хост не должен отправлять данные семпла в количестве, превышающем возможности буфера CICAM, до получения второго подтверждения от CICAM и подтверждения уведомления от буферного механизма об уровне заполнения буфера в обратном TS о том, что буфер CICAM очищен. Информация о размере буфера CICAM для LTS сообщается CICAM в APDU sd_start_reply.

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

7.3.3 Выполнение проигрывания

Хост может начать передачу семплов через интерфейс TS при получении первого APDU sd_start_reply. В этом случае TS соответствует структуре, определенной в 7.5 настоящего стандарта. Хост должен соблюдать ограничения буфера CICAM, как определено в 7.5.4 настоящего стандарта.

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

В процессе проигрывания Хост может обновлять метаданные DRM, связанные со списком треков семплов с помощью APDU sd_update.

В процессе проигрывания Хост может полностью изменить список используемых треков семплов с помощью другого APDU sd_start, как правило, при выборе пользователем другого элемента контента, который требует работы в режиме семпла. После приема APDU sd_start CICAM, работающий в режиме семпла, должен прекратить какое-либо дескремблирование, очистить буфер и приготовиться к дескремблированию семплов, соответствующих новому списку файлов. CICAM направляет Хосту не менее одного подтверждения готовности к проигрыванию.

7.3.4 Прекращение проигрывания

Когда Хост заканчивает передачу мультимедийных семплов для CICAM или в связи с окончанием медиафайла, или потому, что пользователь решил остановить его просмотр, Хост может передать APDU са_pmt. Этот APDU переводит интерфейс TS или локального TS в нормальный режим и находится в состоянии готовности начать дескремблирование потока вещания.

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

7.4.1 Последовательность использования ресурса

Ресурс дескремблирования семпла обеспечивает управление дескремблированием CICAM последовательности медиасемплов, упакованных в TS системы MPEG-2 [9].

При необходимости дескремблирования семплов Хост посылает APDU sd_info_req, запрашивая список систем DRM, внедренных в CICAM и поддерживающих дескремблирование семплов. CICAM должен ответить APDU sd_info_reply со списком поддерживаемых drm_system_id и UUID систем защиты контента.

Хост должен декларировать треки семплов, передаваемые через интерфейс TS, для дескремблирования в CICAM с помощью APDU sd_start. Когда CICAM будет готов получить семплы, он должен ответить первым APDU sd_start_reply, а когда он будет готов дескремблировать семплы, он должен ответить вторым APDU sd_start_reply. Если CICAM обладает высоким быстродействием, то он может возвратить только один APDU sd_start_reply, содержащий обе области, соответствующие обновленным полям состояния.

Хост может обновлять список треков семплов, участвующих в процессе дескремблирования семплов, использованием APDU sd_update. Хост может добавить в список новые треки семплов или может удалить из списка несколько треков семплов, которые больше не используются. CICAM должны подтверждать обновления с помощью APDU sd_update_reply.

Хост может обновлять метаданные DRM, связанные с действующими треками семплов, применяя APDU sd_update. Трек семпла определяется по track_PID, выделенным Хостом в APDU sd_start.

Параметры ресурса дескремблирования семплa должны быть в соответствии с таблицей 29.

Таблица 29 - Параметры ресурса дескремблирования семпла

7.4.2 APDU sd_info_req

Запрос списка систем DRM, встроенных в CICAM и поддерживающих дескремблирование семплов, Хост выполняет отправлением в CICAM APDU sd_info_req. Длина поля length_field в составе APDU sd_info_req должна быть в соответствии с форматом BER ASN.1 [2] (8.3.1).

CICAM должен ответить APDU sd_info_reply.

7.4.3 APDU sd_info_reply

CICAM направляет APDU sd_info_reply к Хосту в ответ на APDU sd_info_req. В нем перечислены drm_system_id и UUID для каждой системы защиты контента или системы DRM, которые CICAM поддерживает для дескремблирования семплов. Если система DRM может быть идентифицирована либо drm_system_id, либо его UUID, то должны быть сообщены оба идентификатора.

Синтаксис APDU sd_info_reply представлен в таблице 30.

Таблица 30 - Синтаксис APDU sd_info_reply

Ниже представлена семантика полей в составе APDU sd_info_reply:

- sd_info_reply_tag: поле 24 бита является тегом этого APDU co значением 0x9F9801;

- length_field: поле определяет длину полезной нагрузки этого APDU в формате BER ASN.1 в соответствии с [2] (8.3.1);

- number_of_drm_system_id: поле определяет количество записей, содержащихся в следующем списке идентификаторов системы DRM. Этот список не должен содержать идентификаторы систем СА вещания, которые могут поддерживаться CICAM, но система CA/DRM не поддерживает дескремблирование и СА вещания и дескремблирование семпла.

Примечание - Список поддерживаемых систем СА вещания предоставляет APDU CA_info_reply в ответ на APDU CA_info в соответствии с [2] и [1] (Е.17.3);

- drm_system_id: поле содержит значения, аналогичные значениям са_system_id, в соответствии с распределением идентификаторов и кодов для систем DVB [10];

- number_of_drm_uuid: поле содержит количество записей в следующем списке UUID DRM;

- drm_uuid: поле содержит записи UUID системы DRM, поддерживаемой CICAM.

7.4.4 APDU sd_start

Для инициирования дескремблирования CICAM треков семплов Хост должен послать для CICAM APDU sd_start, который содержит данные о типе интерфейса - интерфейс TS или локальный TS. Перед отправлением APDU Хост должен прекратить отправку любых пакетов, относящихся к этому локальному TS (в случае нескольких потоков) (например, пакеты TS от тюнера вещания).

Хост должен объявить program_number, которые будут использоваться в CICAM в сообщениях URI.

Для каждого трека Хост указывает PID (track_PID), с которыми будут переданы соответствующие семплы. Track_PID затем используется в качестве идентификатора трека в любом следующем APDU sd_update. Хост должен убедиться, что сигнализация PID в этом APDU является уникальной и не используется для других целей. Значения PID в области от 0x0000 до 0x001F зарезервированы.

Если Хост идентифицировал метаданные, связанные с системой DRM, поддерживаемой CICAM, то он должен добавить цикл метаданных DRM для каждого трека в APDU sd_start. Если метаданные DRM применяются ко всем трекам, то Хост должен повторить их для каждого трека.

Синтаксис APDU sd_start представлен в таблице 31.

Таблица 31 - Синтаксис APDU sd_start

Семантика полей APDU sd_start:

- sd_start_tag: поле 24 бита является тегом со значением 0x9F9802, идентифицирует этот APDU;

- Iength_field: поле определяет длину полезной нагрузки в формате BER ASN.1, определенной в соответствии с [2] (8.3.1);

- LTS_id: поле 8 битов содержит идентификатор локального TS;

- program_number: поле 16 битов содержит номер программы, который будет использоваться CICAM в сообщениях URI. Значение TS не должно совпадать со значением поля program_number в РМТ, включенной в TS. Для контента, представляемого не в формате TS, поля program_number не должны применяться, и Хост может устанавливать в них любое значение;

- ts_flag: имеет значение 0b1, если сделан запрос на дескремблирование семпла в формате TS, и имеет значение 0b0, если запрос сделан на дескремблирование семпла не в формате TS;

- number_of_Sample_Tracks: поле 8 битов содержит количество треков семплов, в которых семплы должны быть дескремблированы;

- track_PID: поле 13 битов содержит PID, с которым семплы дескремблированных треков семплов отправляются Хосту;

- number_of_metadata_records: поле 8 битов содержит количество записей DRM метаданных в этом цикле;

- drm_metadata_source: поле 8 битов определяет источник метаданных DRM в соответствии с таблицей 32;

Таблица 32 - Источник метаданных DRM

- drm_system_id: идентификация системы DRM со связанными метаданными. Значения для drm_system_id аналогичны значениям для са_system_id, как определено размещением идентификаторов кодов для систем DVB [10]. Если поле drm_system_id не будет использоваться для идентификации DRM, то в этом поле должно быть установлено 0xFFFF;

- drm_uuid: поле 128 битов содержит идентификатор UUID системы DRM, к которому относятся метаданные. Если drm_uuid не используется для идентификации DRM, то во всех байтах этого поля должно быть установлено 0xFF;

- drm_metadata_length: поле содержит длину в байтах метаданных DRM;

- drm_metadata_source: поле 8 битов содержит источник метаданных, определенный в таблице 32.

7.4.5 APDU sd_start_reply

CICAM в случае готовности к получению первого семпла для дескремблирования должен направить Хосту APDU sd_start_reply как ответ на APDU sd_start.

При передаче APDU sd_start_reply CICAM сообщает Хосту:

- о готовности CICAM к получению транспортных пакетов от интерфейса TS (transmission_status);

- о способности CICAM к дескремблированию транспортных пакетов (drm_status);

- о размере буфера (buffer_size), выделенного CICAM для всех объявленных треков семплов в APDU sd_start. Минимальное значение возвращаемых buffer_size составляет 5000 пакетов TS.

После получения APDU sd_start CICAM способен отправить более одного sd_start_reply. Например, CICAM может отправить первый sd_start_reply с transmission_status, равным 0х00 (готов к приему), и drm_status, установленным в 0x01 (статус в настоящее время не определен), а затем второй sd_start_reply с transmission_status, равным 0x00 (готов к приему), и drm_status, установленным в 0x00 (дескремблирование возможно). Это позволяет Хосту начать заполнение буфера CICAM с момента получения первой sd_start_reply, в то время как CICAM готовится для дескремблирования семплов, и, следовательно, улучшает условия работы пользователя за счет ускорения представления информации.

Значение buffer_size, установленное в первом sd_start_reply, не может быть изменено CICAM в последующем sd_start_reply.

Синтаксис AРDU sd_start_reply должен быть в соответствии с таблицей 33.

Таблица 33 - Синтаксис APDU sd_start_reply

Семантика полей APDU sd_start_reply:

- sd_start_tag: поле 24 бита с установленным значением 0x9F9803 идентифицирует этот APDU;

- length_field: поле 8 битов содержит длину полезной нагрузки APDU в формате BER ASN.1 в соответствии с [2] (8.3.1);

- LTS_id: поле 8 битов идентифицирует локальный TS;

- transmission_status: поле 8 битов содержит оценку готовности CICAM к приему. Значение 0x00 (готов к приему) указывает, что CICAM готов к приему семплов для дескремблирования. Другие значения указывают, что CICAM не готов к приему. В таблице 34 перечислены возможные значения поля transmission_status;

Таблица 34 - Возможные значения поля transmission_status

- drm_status: поле 16 битов содержит статус DRM в CICAM. Таблица 35 содержит возможные значения поля drm_status;

Таблица 35 - Возможные значения поля drm_status

- drm_system_id: поле 16 битов идентифицирует систему DRM. CICAM будет использовать этот идентификатор для дескремблирования семплов. Значения drm_system_id идентичны значениям са_system_id, определенным в распределении идентификаторов и кодов для системы и оборудования DVB [10]. Если drm_system_id не используется для идентификации DRM, то в поле должно быть установлено 0xFFFF;

- drm_uuid: UUID из DRM, который CICAM будет использовать для дескремблирования семплов. Если drm_uuid_id не используется для идентификации DRM, все байты этого поля должны быть установлены в 0xFF;

- buffer_size: размер буфера CICAM, выделенный для дескремблирования треков семпла, выраженных в числе транспортных пакетов. Если в APDU sd_start был объявлен больше чем один трек семпла, то буфер будет использован треками совместно.

7.4.6 APDU sd_update

Хост должен послать к CICAM APDU sd_update в тех случаях, если необходимо:

- указать на изменения в списке треков семплов, вследствие которых новые семплы должны быть дескремблированы. Этот APDU должен быть отправлен после изменения выбора пользователя, что приводит к изменению в наборе треков семплов для дескремблирования;

- предоставить дополнительные метаданные DRM, которые могут быть необходимы CICAM для продолжения дескремблирования семпла. Как правило, этот APDU может быть отправлен до ротации ключей с тем, чтобы обеспечить необходимые метаданные для CICAM с целью определения ключей, которые доступны для применения после ротации ключей.

Для контента, полученного не в форме транспортного потока, каждый трек семплов, связанный с его track_PID в соответствии с объявлением в одном из предыдущих APDU sd_start или sd_update, должен обрабатываться по следующим правилам:

- CICAM должен продолжать дескремблирование соответствующих семплов, если track_PID находится в списке;

- CICAM не должен останавливать дескремблирование соответствующих семплов и очищать свой буфер от всех пакетов TS с этим PID, если track_PID исчезнет из списка. Хост должен прекратить передачу любых пакетов TS с этим PID перед передачей этого APDU;

- все треки семплов, которые будут дескремблированы, должны быть перечислены в списке, даже если они были сообщены CICAM в предыдущих APDU. Однако в этом случае метаданные, если они не изменились, не должны повторяться;

- CICAM должен подготовиться к дескремблированию, если новый track_PID будет указан в списке и при готовности ответить sd_update_reply.

Для контента TS существует единственный трек семплов, это исключает возможность добавления или удаления трека. Поэтому отсутствует необходимость в идентификаторе трека, и APDU sd_update может быть использован только для предоставления дополнительных метаданных DRM.

Синтаксис APDU sd_update должен быть в соответствии с таблицей 36.

Таблица 36 - Синтаксис APDU sd_update

Семантика полей APDU sd_update:

- sd_update_tag: поле 24 бита при значении 0x9F9804 идентифицирует этот APDU;

- length_field: содержит длину полезной нагрузки APDU в формате BER ASN.1, определенном в [2] (8.3.1);

- LTS_id: поле 8 битов содержит идентификатор обновляемого локального TS;

- ts_flag: флаг, установленный в 0b1, указывает, что запрос дескремблирования семпла относится к семплу трека TS. В других случаях флаг устанавливается в 0b0. Ts_flag имеет то же значение, что и в APDU sd_start;

- number_of_Sample_Tracks: поле 8 битов указывает количество треков семплов, для которых семплы должны быть дескремблированы;

- Sample_track_PID: поле 13 битов указывает PID семпла, описанного трека семплов;

- number_of_metadata_records: поле 8 битов содержит количество записей метаданных DRM в настоящем цикле;

- drm_metadata_source: поле 8 битов указывает источник метаданных в соответствии с таблицей 32;

- drm_system_id: поле 16 битов содержит идентификатор DRM, который связывает метаданные. Значения для drm_system_id идентичны значениям для са_system_id в соответствии с [10]. Если drm_system_id не используется для идентификации DRM, то в этом поле должно быть установлено 0xFFFF;

- drm_uuid: поле 128 битов содержит идентификатор UUID DRM для связанных метаданных. Если drm_uuid_id не используется для идентификации DRM, то все байты этого поля должны иметь значение 0xff;

- drm_metadata_length: поле 16 битов содержит длину в байтах метаданных DRM;

- drm_metadata_byte: метаданные DRM в соответствии с таблицей 32.

7.4.7 APDU sd_update_reply

CICAM направляет Хосту APDU sd_update_reply как ответ на APDU sd_update.

Если APDU sd_update добавляет треки семплов, то Хост может начать передачу пакетов TS, содержащих семплы, соответствующие новым трекам семплов.

Если sd_update предоставляет некоторые дополнительные метаданные DRM, то Хост может начать передачу пакетов TS со скремблированными семплами и с дополнительными метаданными.

Синтаксис APDU sd_update_reply должен быть в соответствии с таблицей 37.

Таблица 37 - Синтаксис APDU sd_update_reply

Семантика полей APDU sd_update_reply:

- sd_update_reply_tag: поле 24 бита при значении 0x9F9805 идентифицирует этот APDU;

- length_field: поле содержит полезную нагрузку APDU в формате BER ASN.1 в соответствии с [2] (8.3.1);

- LTS_id: поле 8 битов содержит идентификатор локального TS;

- drm_status: поле 8 битов содержит статус DRM в CICAM. В таблице 35 перечислены его возможные значения.

7.5 Интерфейс транспортного потока

7.5.1 Общие замечания

Трек семплов в составе TS передается непосредственно через интерфейс TS без дополнительной инкапсуляции.

Если треки семплов не относятся к типу TS, то дополнительная сигнализация и инкапсуляция для семплов должны применяться в соответствии с 7.5.3 настоящего стандарта.

7.5.2 Передача контента в транспортном потоке

7.5.2.1 Выход Хоста

В тех случаях, когда трек семплов относится к типу TS, Хост должен посылать пакеты TS исходного трека семплов TS в CICAM через интерфейс TS.

Хост не должен выполнять синтаксический анализ и делать оценки трека семплов TS перед передачей на интерфейс TS. CICAM должен выполнять анализ принятого TS в объеме, включающем:

- извлечение PSI;

- идентификацию PID ЕСМ;

- идентификацию PID для дескремблирования.

Хост может отправить таблицы сброса FLT на comms_PID.

Хост может передать таблицы SET с теми же идентификаторами, которые используются для передачи треков семплов, аналогично тому, как это описано в 7.5.5.3 настоящего стандарта. Таблица SET не должна направляться на comms_PID, так как не гарантируется правильная последовательность поступающих SET по отношению к заключительным данным трека семплов.

Хост не должен отправлять таблицу SST.

7.5.2.2 Выход CICAM

Для дескремблирования трека семплов TS CICAM должен выводить транспортные пакеты в том же порядке, в каком они были получены от Хоста.

CICAM может буферизировать полученные транспортные пакеты.

CICAM должен непрерывно сообщать Хосту об уровне заполнения буфера CICAM в соответствии с 7.5.4.3 настоящего стандарта.

7.5.2.3 Треки семплов нескольких TS

С целью устранения коллизий PID локального TS, сконфигурированного в режиме семпла, должны выполняться следующие условия:

- локальный TS должен содержать не более одного трека семплов TS;

- локальный TS не должен содержать одновременно треки семплов в формате TS и в формате, отличающемся от формата TS.

Одновременное дескремблирование нескольких локальных TS при обработке нескольких потоков в зависимости от поддерживающих функций и доступности ресурса возможно в соответствии с разделом 6 настоящего стандарта.

7.5.3 Передача контента в формате, отличающемся от формата транспортного потока

7.5.3.1 Выход Хоста

7.5.3.1.1 Общие замечания

Когда интерфейс TS конфигурируется в режим семпла, а треки семплов не относятся к формату TS, то TS, отправленные Хостом к CICAM, должны содержать пакеты TS только с идентификаторами, объявленными в APDU sd_start или sd_update.

Каждый трек семплов TS, посланный Хостом через интерфейс TS, должен содержать последовательность семплов, имеющих отношение к указанному треку с присвоенным PID.

7.5.3.1.2 Передача семплов

Перед передачей семпла Хост должен объявить (декларировать) семпл, отправляя таблицу SST в TS и используя PID трека семплов. Хост может повторить SST при условии, что последнее повторение SST предшествует запуску семпла. SST содержит учетные данные, необходимые для дескремблирования семпла [обычно это вектор инициализации (IV) и идентификатор ключа].

Таблица SST содержит tsc_parity_bit, который указывает на биты четности transport_scrambling_control транспортных пакетов, содержащих скремблированные данные объявленного семпла. Хост должен переключать tsc_parity_bit в SST на следующий семпл трека семплов.

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

После передачи транспортного пакета, содержащего окончание семпла, Хост должен отправить в TS SET с тем же PID, как и трек семплов (track_PID) аналогично изложенному в 7.5.5.3 настоящего стандарта. Хост должен завершить передачу семпла до отправления SET этого семпла.

В любое время Хост может просить CICAM очистить свой буфер семплов, отправляя таблицу FLT в TS, используя значение comms_PID, равное 0x001С, как определено для локальной связи внутриполосной сигнализации в [3] (5.1.3). Хост должен остановить передачу семплов, прежде чем отправить FLT. Сразу после передачи FLT Xocт может запустить передачу новых семплов, объявленных в SST.

На рисунке 4 представлена последовательность операций переноса контента при использовании таблиц SST и SET.

Рисунок 4 - Последовательность операций переноса контента при использовании таблиц SST и SET

Примечание - Нумерация PID шестнадцатиричная.

1) Хост запускает дескремблирование семпла по интерфейсу TS, отправляя APDU sd_start. Есть только один объявленный трек [0] на PID 0x1000;

2) CICAM APDU sd_start_reply подтверждает, что он готов получить и дескремблировать семпл;

3) Хост объявляет о запуске sample[0], отправив SST на track_PID;

4) Хост передает sample[0] на track_PID [0]=0х1000;

5) Передача sample[0] закончена. Хост объявляет окончание передачи sample[0], передавая SET на track_PID;

6) Хост объявляет о запуске sample[1], отправив SST на track_PID;

7) Хост передает первую часть sample[1] на track_PID [0]=0х1000;

8) Хост просит CICAM сбросить буфер, отправляя FLT на comms_РID;

9) Хост перезапускает передачу другой позиции в треке TS, Хост не ожидает получения назад FLT от CICAM. Хост объявляет о запуске sample[100], отправляя SST на track_PID;

10) Хост повторяет SSТ для sample[100];

11) Хост передает sample[100] на track_PID[0]=0x1000;

12) Передача sample[100] закончена. Хост объявляет окончание передачи sample[100], передавая SET на track_PID.

В любое время Хост может запросить CICAM очистить буфер семпла, отправляя FLT в TS, использованием comms_PID со значением 0x001С. Хост должен остановить передачу семплов прежде, чем отправить FLT. Сразу после передачи FLT Хост может запустить передачу новых семплов, объявленных в SST.

7.5.3.1.3 Управление несколькими треками

При декларировании передачи более одного трека Хост может чередовать семплы из различных треков.

7.5.3.1.4 Обновление списка треков

Хост может обновлять список треков, находящихся в ожидании, отправив APDU sd_update. Если трек добавлен, то Хост не должен отправлять семплы, связанные с этим дополнительным треком, пока от CICAM не получит положительный ответ sd_update_reply. Если ранее декларированный трек будет удален, то Хост должен прекратить отправку семплов, связанных с удаленным треком, перед отправкой APDU sd_update.

7.5.3.2 Заголовки пакетов TS

В пакете, включающем данные семпла, передаваемым от Хоста к CICAM, заголовок пакета битов TS должен формироваться следующим образом:

- в байте синхронизации должен быть установлен LTS_id локального TS;

- в поле transport_error_indicator должен быть установлен 0b0;

- в поле payload_unit_start_indicator пакета, содержащего начало семпла, должен быть установлен 0b1. В противном случае payload_unit_start_indicator должен быть установлен в 0b0;

- в поле pointer_field должен быть установлен 0, когда payload_unit_start_indicator установлен в 0b1, в противном случае он не должен присутствовать;

- в поле transport_priority должен быть установлен 0b0;

- PID должен быть идентификатором соответствующего track_PID трека, как определено в APDU sd_start или sd_update;

- в поле transport_scrambling_control должно быть установлено или 0b10, или 0b11 для пакета, содержащего скремблированные данные семпла. Для данного семпла Хост должен использовать значение transport_scrambling_control в соответствии с tsc_parity_bit, указанным в секции SST соответствующего семпла, как это определено в 7.5.5.5 настоящего стандарта для всех пакетов, содержащих скремблированные данные из указанного семпла. В поле transport_scrambling_control будет установлено 0b00 для пакета, содержащего прозрачные (нескремблированные) данные семпла;

- в поле adaptation_field_control должно быть установлено: или 0b01, когда пакет TS содержит только данные семпла, или 0b11, когда пакет TS содержит поле для заполнения (адаптации), следующее после данных семпла;

- поле continuity_counter должно быть в соответствии с определением системы MPEG-2 [9]. Поле continuity_counter может быть отброшено для пакета, содержащего начало семпла.

Пакет полезной нагрузки TS должен содержать только данные от одного семпла.

Хост должен использовать adaptation_field только для заполнения (стаффинга). Когда используется поле adaptation_field, оно должно содержать только stuffing_byte, все индикаторы и флаги во втором байте adaptation_field должны быть установлены в ноль.

Хост должен запретить использование поля adaptation_field в следующих случаях:

- пакет TS содержит окончание семпла;

- пакет TS содержит прозрачные данные, когда следующий транспортный пакет с тем же track_PID содержит скремблированные данные;

- пакет TS содержит скремблированные данные, когда следующий транспортный пакет с тем же track_PID содержит прозрачные данные.

7.5.3.3 Выход CICAM

Для данного трека семплов CICAM должен выводить транспортные пакеты с track_PID в том же порядке, в котором они были получены. Структура транспортных пакетов не должна изменяться. Исключением являются следующие случаи:

- CICAM дескремблировал полезную нагрузку некоторых транспортных пакетов;

- CICAM повторно скремблировал некоторые из дескремблированных транспортных пакетов: биты пакетов transportscrambling_control должны быть установлены в соответствии с [1] (5.6.1);

- CICAM использовал различные исходные значения continuity_counter. В любом случае CICAM должен использовать в пакетах семпла совместимую последовательность значений continuity_counter.

Порядок транспортных пакетов для различных треков на выходе из CICAM может отличаться от порядка пакетов, посланных Хостом.

CICAM может буферизовать полученные пакеты TS. CICAM должен постоянно информировать Хост об уровне заполнения буфера CICAM, как указано в 7.5.4.3 настоящего стандарта.

После приема FLT CICAM должен избавиться от всех буферизованных пакетов TS, а затем отправить неизмененную FLT обратно на comms_PID.

7.5.3.4 Семплы ISOBMFF

7.5.3.4.1 Секция SST

Для объявления прозрачного семпла, происходящего из файла ISOBMFF, дескриптор цикла секции SST не должен содержать initialization_vector_descriptor или key_identifier_descriptor. Допускается присутствие частных дескрипторов.

Для объявления скремблированного семпла, происходящего из файла ISOBMFF, Хост должен включать один initialization_vector_descriptor и один key_identifier_descriptor в дескрипторе цикла секции SST. Initialization_vector_descriptor должен содержать lnitialization_Vector (вектор инициализации) семпла в байтах iv_data в соответствии с [5] (Приложение I).

Дескриптор kеу_identifier_descriptor в байтах key_id_data байт должен содержать KID семпла в соответствии с [5] (Приложение I).

7.5.3.4.2 Пакетирование семпла ISOBMFF

Пакетирование семплов ISOBMFF в TS должно выполняться в соответствии с правилами, описанными в 7.5.3.4.1. Схема пакетирования семплов ISOBMFF в пакеты транспортного потока в соответствии с рисунком 5.

Рисунок 5 - Схема пакетирования семплов ISOBMFF в пакеты транспортного потока

7.5.4 Буферизация CICAM

7.5.4.1 Общие замечания

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

7.5.4.2 Индикация размера буфера

CICAM должен предоставлять полный размер буфера, выделенного для всех треков семплов интерфейса TS, использованием APDU sd_start_reply.

7.5.4.3 Индикация уровня заполнения буфера

CICAM должен периодически предоставлять Хосту индикацию уровня заполнения буфера, вставляя таблицу уровня буфера BLT в TS, отправляемую обратно на Хост. Минимальный период времени между последовательными BLT должен быть 180 миллисекунд. Максимальный период времени между последовательными BLT должен быть 220 миллисекунд. CICAM должен вставлять секции BLT, используя значение comms_PID 0x001С, как установлено для локальной связи в полосе сигнализации в [3] (5.1.3). Информация об уровне буфера, обеспечиваемая CICAM, должна формироваться не менее чем за 100 мс до начала выхода на Хост соответствующей секции BLT.

Рекомендуется, чтобы Хост оценивал буферное пространство в буфере CICAM для локального TS каждый раз, когда принимается секция BLT, для того чтобы гарантировать непереполнение буфера CICAM при передаче на CICAM дополнительных пакетов TS. Хост не должен делать предположения о свободном пространстве буфера в CICAM и не отправлять больший объем данных, чем указано в последнем BLT.

7.5.4.4 Сброс буфера CICAM

Хост может потребовать от CICAM очистить буфер от всех транспортных пакетов, отправив FLT на comms_PID через интерфейс TS. При получении FLT CICAM должен очистить буфер от всех транспортных пакетов, полученных до приема FLT. CICAM подтверждает завершение операции очистки, вернув FLT на comms_PID через интерфейс TS. Хост может начать передачу новых семплов после отправки FLT, не дожидаясь FLT от CICAM (на основе информации, посланной CICAM в последнем полученном BLT).

7.5.5 Коммуникационные таблицы (comms)

7.5.5.1 Общие замечания

Когда интерфейс TS конфигурирован в режим семпла, Хост и CICAM через интерфейс TS обмениваются коммуникационными таблицами (comms) 39-42, представленными в 7.5.5.5-7.5.5.8 настоящего стандарта.

Коммуникационные таблицы 39-42 перед вставкой в пакеты TS должны быть сегментированы на частные секции с применением синтаксиса частной секции, определенного в системе MPEG-2 [9].

Пакеты TS, содержащие коммуникационные таблицы 39-42, не относящиеся к треку, т.е. FLT и BLT, должны использовать значение PID, равное 0x001С, назначенное локальной связью внутриполосной сигнализации в [3] (5.1.3), и должны быть отображены непосредственно в пакеты TS, как указано в 7.5.5.2 настоящего стандарта.

Пакеты TS, содержащие таблицы comms, которые имеют отношение к треку, т.е. SST и SET, должны использовать соответствующий track_PID и должны быть отображены в поле адаптации, как указано в 7.5.5.3 настоящего стандарта.

7.5.5.2 Отображение секций comms в пакеты TS

Секции comms, соответствующие таблицам comms, которые не ассоциируются с треком (FLT и BLT), должны быть отображены непосредственно в пакеты TS. Начало первой секции в полезной нагрузке пакета TS должно указываться полем pointer_field, и таблица comms может запускаться в начале полезной нагрузки пакета TS сразу после pointer_field. В пакете TS не должно быть больше одного pointer_field, а начало другой секции может быть идентифицировано подсчетом длины первой и последующих секций, так как интервалы между секциями в пакете TS синтаксисом недопустимы.

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

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

Стаффинг не должен выполняться использованием механизма adaptation_field.

Более подробное описание механизма и функциональности представлено в [9] (2.4.4 и приложение С).

Для пакета, содержащего часть секции comms, биты заголовка пакета TS должны быть установлены следующим образом:

- в поле байта синхронизации должен быть установлен LTS_id локального TS;

- в поле transport_error_indicator должно быть установлено 0b0;

- в поле payload_unit_start_indicator пакета, содержащего начало секции comms, должно быть установлено 0b1, поле роinter_field должно указывать на первый байт первой секции, запускающейся в пакете TS. В противном случае в поле payload_unit_star_indicator должно быть установлено 0b0;

- в поле transport_priority должно быть установлено 0b0;

- PID должен быть установлен в comms_PID со значением 0x001С для SST и SET, которые направляются в поле адаптации соответствующих медиапотоков пакетов TS;

- в поле transport_scrambling_control должно быть установлено 0b00. Секции comms не должны быть скремблированы;

- в поле adaptation_field_control должно всегда быть установлено 0b01: поле адаптации не должно использоваться для транспортного пакета, содержащего часть секции comms;

- поле continuity_counter должно быть в соответствии с системой MPEG-2 [9].

Пакет TS, содержащий конец секции comms, может содержать начало следующей секции.

Максимальное количество секций в пакете TS ограничивает размер пакета TS.

CICAM должен добавлять секции BLT в comms_PID и может изменять местоположение полученных секций comms в пакетах TS, но CICAM всегда должен генерировать совместимый пакет счетчика непрерывности для всех PID (в том числе comms_PID) на его выходе, за исключением того, что continuity_counter может быть сброшен для пакета TS, содержащего начало семпла.

Примечание - continuity_counter 4-битовое беззнаковое целое поле в транспортном потоке MPEG-2, который сигнализирует текущее значение continuity_counter для этого пакета ID. Каждый раз, когда кодер передает continuity_counter, счетчик для этого пакета ID увеличивается на 1, за исключением случая, когда максимальное значение 15 увеличивается, величина цикла возвращается в 0.

7.5.5.3 Отображение секций comms в полях адаптации пакета TS

Секции comms, соответствующие таблицам comms, имеющим отношение к треку (SST и SET), размещены в поле адаптации пакета TS. Такое размещение позволяет сигнализировать таблицы начала (SST) и окончания (SET) семпла в том же потоке PID, что и сами семплы.

Для пакета, содержащего секции comms, биты заголовка пакета TS должны быть установлены следующим образом:

- в поле байта синхронизации должен быть установлен LTS_id локального TS;

- в поле transport_error_indicator должно быть установлено 0b0;

- в поле payload_unit_start_indicator пакета должно быть установлено 0b0;

- в поле transport_priority должно быть установлено 0b0;

- PID должен соответствовать track_PID, с которым он ассоциирован;

- в поле transport_scrambling_control должно быть установлено 0b00: секции comms не должны быть скремблированы;

- в поле adaptation_field_control должно всегда устанавливаться 0b10: этот пакет не должен содержать data_bytes;

- поле continuity_counter должно соответствовать требованиям системы MPEG-2 [9].

Поле адаптации должно содержать:

- Adaptation_field_length: полная длина поля адаптации. Поскольку пакет TS содержит только поле адаптации, длина поля адаптации должна быть установлена равной 183 байта;

- Discontinuity_indicator: 0b0;

- Random_access_indicator: 0b0;

- Elementary_stream_priority_indicator: 0b0;

- PCR_flag: 0b0;

- OPCR_flag: 0b0;

- Splicing_point_flag: 0b0;

- Adaptation_field_extension_flag: 0b0;

- Transport_private_data_flag: 0b1;

- private_data_byte: первый байт частных данных - первый байт секции comms. Частные данные данного пакета должны содержать всю секцию comms. Секция comms не должна разделяться по нескольким пакетам TS. Таблица comms может быть разделена на последовательные пакеты TS.

Таблица comms, размещаемая в поле адаптации, может содержать дескрипторы, которые показаны в таблице 30 настоящего стандарта, а также дескрипторы, определенные в [1]:

- ciplus_initialization_vector_descriptor;

- ciplus_key_identifier_descriptor.

Схема отображения секций comms в полях адаптации пакетов TS показана на рисунке 6.

Рисунок 6 - Схема отображения секций comms в полях адаптации пакетов TS

7.5.5.4 Кодирование значений table_id

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

Таблица 38 - Значения table_id для коммуникационных таблиц

7.5.5.5 Секция таблицы начала семпла

Синтаксис секции SST соответствует синтаксису для частных секций, определенному в системе MPEG-2 [9].

Синтаксис секции SST должен быть в соответствии с коммуникационной таблицей 39.

Таблица 39 - Коммуникационная таблица. Синтаксис секции SST

Семантика полей секции SST:

- table_id: поле 8 битов, установленное в 0xD0, является идентификатором sample_start_section;

- section_syntax_indicator: индикатор 1 бит должен быть установлен в 0b0;

- section_length: поле 12 битов определяет количество байтов секции после поля section_length и до конца секции. Максимальная длина секции должна составлять 179 байтов и вписываться в пакет поля адаптации TS, первые 4 бита должны быть установлены в 0b0000;

- tsc_parity_bit: поле 1 бит указывает на четность битов transport_scrambling_control, которые будут использоваться для пакета TS, содержащего скремблированные данные соответствующего семпла. Если tsc_parity_bit устанавливается в 0b0, то в заголовке скремблированного пакета TS transport_scrambling_control должен быть установлен 0b10. Если tsc_parity_bit устанавливается в 0b1, то transport_scrambling_control должен быть установлен в 0b11;

- descriptor_loop_length: поле 12 битов содержит полную длину применяемых дескрипторов в байтах.

Дескрипторы в SST должны быть в соответствии с таблицей 43. Все дескрипторы должны иметь стандартный формат, включающий тег дескриптора, поле длины, данные дескриптора.

7.5.5.6 Секция таблицы окончания семпла

Синтаксис секции таблицы окончания семпла (SET) для частных секций должен быть в соответствии с [9] и коммуникационной таблицей 40.

Таблица 40 - Коммуникационная таблица. Синтаксис секции SET

Семантика полей секции SET:

- table_id: поле 8 битов содержит идентификатор sample_start_section; он должен быть установлен в 0xD1;

- section_syntax_indicator: однобитовый индикатор должен быть установлен в 0xb0;

- section_length: поле 12 битов определяет количество байтов секции после поля section_length и до конца секции. Максимальная длина секции должна составить 179 байтов и вписываться в пакет поля адаптации TS, первые 4 бита должны быть установлены в 0b0000;

- descriptor_loop_length: поле 12 битов содержит полную длину применяемых дескрипторов в байтах.

Дескрипторы в SET должны быть в соответствии с таблицей 43. Все дескрипторы должны иметь стандартный формат, включающий тег дескриптора, поле длины, данные дескриптора.

7.5.5.7 Секция таблицы очистки

Синтаксис секции таблицы очистки (FLT) должен соответствовать синтаксису для частных секций, определенному системой MPEG-2 [9] и коммуникационной таблицей 41.

Таблица 41 - Коммуникационная таблица. Синтаксис секции FLT

Семантика полей секции FLT:

- table_id: поле 8 битов содержит идентификатор flush_section. Он должен быть установлен в 0xD2;

- section_syntax_indicator: однобитовый индикатор должен быть установлен в 0xb0;

- section_length: полe 12 битов определяет количество байтов секции после поля section_length и до конца секции;

- descriptor_loop_length: поле 12 битов содержит полную длину применяемых дескрипторов в байтах.

Дескрипторы в FLT должны быть в соответствии с таблицей 43. Все дескрипторы должны иметь стандартный формат, включающий тег дескриптора, поле длины, данные дескриптора.

7.5.5.8 Секция таблицы уровня заполнения буфера

Синтаксис секции таблицы уровня заполнения буфера (BLT) должен соответствовать синтаксису для частных секций, определенному системой MPEG-2 [9] и коммуникационной таблицей 42.

Таблица 42 - Коммуникационная таблица. Синтаксис секции BLT

Семантика полей секции BLT:

- table_id: поле 8 битов содержит идентификатор buffer_level_section, когда он установлен в 0xD3;

- section_syntax_indicator: однобитовый индикатор должен быть установлен в 0xb0;

- section_length: полe 12 битов определяет количество байтов секции после поля section_length и до конца секции;

- buffer_level: поле 16 битов определяет текущий уровень свободного места в буфере, который выражается в количестве транспортных пакетов. Эта мера неиспользуемого пространства в буфере. buffer_level должна соответствовать уровню, измеренному CICAM за 100 мс до передачи этой секции Хосту;

- buffe_empty_flag: этот бит должен быть установлен в 0b1, когда буфер пуст, и должен быть установлен в 0b0, когда буфер полон;

- 10 (20, 30, 40, 50, 60, 70, 80, 90)%_flag: бит этих флагов должен быть установлен в 0b1, когда buffer_level ниже 10 (20, 30, 40, 50, 60, 70, 80, 90)% от максимума, и должен быть установлен в 0b0, когда уровень буфера выше 10 (20, 30, 40, 50, 60, 70, 80, 90)% от максимума;

- buffer_full_flag: флаг должен быть установлен в 0b1, когда буфер заполнен, и в 0b0, когда он не заполнен.

7.5.5.9 Дескрипторы

7.5.5.9.1 Общие замечания

В 7.5.5.9 настоящего стандарта определены дескрипторы, которые могут использоваться в таблице comms. Эти дескрипторы могут быть вставлены в любую из таблиц, определенных в 7.5.5.4, 7.5.5.5, 7.5.5.6 и 7.5.5.7 настоящего стандарта, в виде конструкции "дескриптор ()".

Все дескрипторы, определенные в 7.5.5.9 настоящего стандарта, имеют следующую семантику:

- descriptor_tag: тег дескриптора поле 8 битов, однозначно идентифицирует дескриптор. Значения descriptor_tag определены в таблице 43;

- descriptor_length: длина дескриптора поле 8 битов с указанием общего количества байтов блока данных дескриптора, следующего после поля descriptor_length.

Таблица 43 содержит список дескрипторов, представленных в настоящем стандарте, значения тегов дескрипторов и варианты рекомендуемого использования в таблицах comms. Символы "да" в пересечении между дескриптором и типом таблицы показывают, что дескриптор может быть включен в таблицу этого типа.

Таблица 43 - Значения дескрипторов для таблицы comms

7.5.5.9.2 Дескриптор вектора инициализации CI Plus

Дескриптор вектора инициализации CI Plus Ciplus_initialization_vector_descriptor используется Хостом для предоставления вектора инициализации, связанного со следующим семплом.

Синтаксис дескриптора вектора инициализации CI Plus ciplus_initialization_vector_descriptor должен быть в соответствии с таблицей 44.

Таблица 44 - Синтаксис дескриптора вектора инициализации CI Plus ciplus_initialization_vector_descriptor

Семантика полей вектора инициализации CI Plus:

- descriptor_tag: поле 8 битов определяет тег дескриптора и имеет значение 0xCD;

- descriptor_length: поле 8 битов содержит количество байтов IV_data_bytes;

- IV_data_byte: поле 8 битов содержит последовательность полей IV_data_byte, включающих IV.

7.5.5.9.3 Дескриптор идентификатора ключа CI Plus

Дескриптор идентификатора ключа CI Plus ciplus_key_identifier_descriptor используется Хостом для предоставления идентификатора ключа контента, связанного со следующим семплом.

Синтаксис дескриптора идентификатора ключа CI Plus ciplus_key_identifier_descriptor должен быть в соответствии с таблицей 45.

Таблица 45 - Синтаксис дескриптора идентификатора ключа CI Plus ciplus_key_identifier_descriptor

Семантика полей дескриптора ciplus_key_identifier_descriptor:

- descriptor_tag: поле 8 битов определяет тег дескриптора при значении 0xCF;

- key_id_data_byte: поле 8 битов содержит идентификатор ключа.

7.5.6 Информация о правилах использования

CICAM должен связывать информацию о URI с программой дескремблирования семпла по правилам, описанным в [1] (5.7).

CICAM должен использовать program_number, указанный в APDU sd_start, при отправке сообщения URI в Хост.

Хост должен применять URI, полученную от CICAM, в соответствии с [1] (5.7).

В течение периода, когда URI для программы еще неизвестна Хосту, например сразу после того, как было инициировано дескремблирование семпла, Хост должен использовать начальную URI по умолчанию, как определено в [1] (5.7).

8 CICAM в режиме проигрывателя контента IP

8.1 Общие замечания

Параметры доставки данных IP через интерфейс команд нормированы в [1]. Однако этот вариант доставки имеет ограниченную пропускную способность. Для увеличения скорости передачи данных для доставки видеоданных настоящий стандарт нормирует параметры передачи данных IP от Хоста к CICAM через интерфейс TS. Восходящий поток (Upstream) данных IP в сеть отправляется через интерфейс команд.

В некоторых реализациях Хоста поддержка приема и деинкапсуляции данных, полученных по IP, не поддерживается. В этих вариантах реализации Хост предоставляет ресурсы, позволяющие CICAM получать данные полезной нагрузки UDP/TCP через стек IP Хоста по интерфейсу TS. Этот режим будет использоваться в тех случаях, когда Хост не поддерживает транспортные механизмы UDP/TCP. Далее в стандарте этот режим работы обозначается как гибридный.

Данные, возвращенные CICAM, должны быть в формате SPTS, который Хост в режиме проигрывателя может использовать непосредственно.

При доставке IP на CICAM в режиме проигрывателя по требованию Хоста должен выполнять операции транскодирования или создания водяных знаков. При выполнении этих операций семплы на входе и выходе CICAM будут иметь различные размеры. Эти операции при доставке IP Хост в режимах проигрывателя или семпла выполнять не может.

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

Если информация о дате и времени от вещательного тюнера Хосту и CICAM недоступна, то Хост и CICAM могут получать информацию о дате и времени через сетевой интерфейс IP. Метод получения информации о дате и о времени через сетевой интерфейс IP настоящий стандарт не определяет.

Хост не может выполнять услуги игнорирования, определенные в [1] (раздел 10), для служб, предоставленных через IP CICAM в режиме проигрывателя.

8.2 Управление проигрывателем

Для управления потоком данных CICAM должен иметь данные о времени выполнения конкретных действий пользователя.

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

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

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

8.3 Инициализация сеанса проигрывания

8.3.1 Общие замечания

Потребление службы при доставке IP CICAM в режиме проигрывателя может инициировать CICAM использованием приложения CICAM или это инициирование может выполнить Хост через канал IP.

8.3.2 Проигрывание, инициируемое Хостом

В режиме проигрывания, инициируемого Хостом, пользователь передает Хосту запрос на проигрывание контента. Хост при использовании собственных ресурсов не может выполнить этот запрос и производит проверку CICAM на возможность выполнить проигрывание контента. Это достигается передачей APDU CICAM_player_verify_req. Такая проверка может быть выполнена Хостом и на более раннем этапе, например во время установки профиля каналов IP, используя механизм, описанный в 15.4 настоящего стандарта, при открытии и обновлении служб в соответствии с 15.4.2 настоящего стандарта.

Если CICAM подтверждает, что он может выполнить запрос проигрывания контента, то Хост при помощи APDU CICAM_player_play_req запрашивает CICAM о возможности проигрывания службы. После получения этого запроса СIСАМ должен отправить к Хосту APDU CICAM_player_start_req, сообщая PMT в SPTS и скорость, необходимую для передачи данных, через интерфейс TS. Хост должен ответить APDU CICAM_player_start_reply, в котором сообщается о локальном TS, который будет использоваться для передачи данных для этого сеанса проигрывателя.

CICAM после этого устанавливает необходимое количество соединений гибридных LSC, как определено в разделе 10 настоящего стандарта, с использованием выделенного LTS_id для доставки данных AV.

В дополнение к гибридным соединениям CICAM может также установить дополнительные соединения для управления, например, использованием протокола RTSP. Эти соединения должны выполняться в рамках нового сеанса LSC.

CICAM принимает данные, расшифровывает их и преобразует в локальный TS (SPTS) и, прежде чем отправить локальный TS через интерфейс TS в Хост, может (опционально) скремблировать его, используя управление скремблированием контента CI Plus.

Во время проигрывания контента команды проигрывателя могут быть направлены Хостом на CICAM для управления проигрыванием.

Когда Хост прекращает сеанс проигрывателя, он должен отправить к CICAM APDU CICAM_player_stop. CICAM в качестве подтверждения направляет Хосту APDU CICAM_player_end с сообщением о том, что CICAM прекратил проигрывание. Хост не освобождает занятые ресурсы для этого сеанса проигрывателя до окончания получения APDU CICAM_player_end. Интерфейс TS затем возвращается в нормальный режим как один из режимов TS, описанных в 7.2 настоящего стандарта.

8.3.3 Проигрывание, инициируемое CICAM

CICAM может установить сеанс Хоста проигрывателя в ответ на событие, которое настоящий стандарт не определяет. Установление такого сеанса выполняется передачей Хосту APDU CICAM_player_start_req, содержащего PMT в SPTS и скорость данных, необходимые для передачи данных через интерфейс TS, для включения этого запроса потребления контента. Хост отвечает APDU СIСАМ_player_start_reply, который сообщает локальный TS, который будет использоваться для передачи данных через интерфейс TS для этого сеанса проигрывателя.

CICAM устанавливает LSC гибридные соединения, как правило, с использованием выделенного LTS_id для доставки данных AV.

В случае, когда CICAM осуществляет прямые извлечения данных IP без использования ресурса LSC, CICAM может не устанавливать LSC гибридные соединения, однако во всех других отношениях взаимодействия между Хостом и CICAM одинаковы.

CICAM запрашивает данные, расшифровывает и преобразует входной SPTS в локальный TS, и может скремблировать пакеты TS, используя скремблирование управления контентом CI Plus, перед отправкой Хосту локального TS через интерфейс TS. В процессе потребления контента приложение режима спецэффектов может взаимодействовать с CICAM в режиме проигрывателя для управления режимами проигрывания в соответствии с протоколом, определение которого выходит за рамки настоящего стандарта. Когда CICAM будет завершать сеанс проигрывателя, он отправит Хосту APDU CICAM_player_session_end (0) о прекращении проигрывания. Этот APDU заставляет Хост освободить ресурсы, занятые для этого сеанса проигрывателя, и вернуть интерфейс TS в нормальный режим.

8.4 Обработка ошибок обмена

При обнаружении Хостом ошибки обмена на сетевом интерфейсе IP он должен передать эту информацию к CICAM через интерфейс команд использованием APDU LSC comms_reply, как определено в [2] (8.7.1.5). Ошибки сервера, объявленные через протоколы более высоких уровней протоколов TCP или UDP (например, HTTP по TCP), должны быть возвращены как пакеты IP, инкапсулированные в TS через интерфейс TS в гибридном режиме.

8.5 Поддержка режима спецэффектов

В тех случаях, когда CICAM поддерживает формат контента, протокол доставки и режим спецэффектов, CICAM может управлять потоком данных и контентом для поддержки режима спецэффектов.

CICAM должен продолжать выводить совместимый TS через интерфейс TS во время сеанса проигрывателя. Например, в случае проигрывания при ускоренной перемотке вперед CICAM может выводить последовательность l-кадров одновременно с аудиокадрами, содержащими в фонограмме паузу. В случае команды "пауза" CICAM может продолжать отправлять локальный TS, содержащий повторения последнего видеокадра, наряду с аудиокадрами, содержащими в фонограмме паузу.

Точные характеристики и метод управления режимом спецэффектов CICAM в настоящем стандарте не определяются.

8.6 Завершение сеанса

8.6.1 Общие замечания

Сеанс проигрывателя может быть прекращен по любой из причин, указанных в 8.6.2, 8.6.3, 8.6.4 настоящего стандарта. После окончания сеанса Хосту может потребоваться повторная инициализация его функций декодирования и визуализации AV, чтобы избежать нежелательных артефактов, вызванных потерей входного потока.

8.6.2 Неисправимая ошибка

В том случае, когда CICAM обнаружил ошибку, приводящую к необходимости завершения сеанса проигрывателя, CICAM должен сигнализировать пользователю о деталях ошибки, например через приложение MMI, и направлять к Хосту APDU CICAM_player_end.

Правила поведения в случае обнаружения неисправимой ошибки определяет инициатор сеанса: Хост или CICAM.

8.6.3 Завершение сеанса пользователем

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

Хост не должен переключаться на новый канал в локальном TS сеанса проигрывателя, пока не получит для сеанса CICAM APDU CICAM_player_end.

В случае сеанса, инициируемого CICAM, замена канала пользователем должна привести к передаче Хостом к CICAM APDU CICAM_player_stop, в ответ на который CICAM должен завершить сеанс.

Хост не должен отправлять к CICAM APDU са_pmt, сигнализирующий об изменении канала, пока он не получил от CICAM APDU CICAM_player_end для сеанса проигрывателя.

Хост не должен использовать этот локальный TS для передачи данных AV любого нового канала и не должен отправлять к CICAM ни APDU ca_pmt, ссылающийся на этот локальный TS, сигнализирующий об изменении канала, ни APDU sd_start, пока не получит для сеанса от CICAM APDU СICАМ_player_end.

8.6.4 Окончание контента

Если в инициированном Хостом сеансе CICAM проигрывателя будет достигнуто окончание актива контента, то CICAM должен сигнализировать Хосту об окончании контента, используя APDU CICAM_player_asset_end.

Когда Хост получает APDU CICAM_player_asset_end, то он должен дать CICAM команду завершения сеанса проигрывателя, отправляя к CICAM АPDU CICAM_player_stop.

Процедуры при окончании контента в инициированном СIСАМ сеансе CICAM в режиме проигрывателя настоящим стандартом не определяются.

8.7 Ресурс CICAM в режиме проигрывателя

8.7.1 Общие замечания

Ресурс CICAM в режиме проигрывателя позволяет Хосту предложить CICAM инициировать сеанс проигрывателя и проигрывать службу от имени Хоста. Это позволяет CICAM по своей инициативе запрашивать инициирование сеанса проигрывателя. Ресурс CICAM проигрывателя обеспечивается Хостом. CICAM может запросить сеанс к ресурсу CICAM в режиме проигрывателя, только если Хост объявил о ресурсе CICAM проигрывателя во время передачи протокола администратора ресурсов в соответствии с [2] (8.4.1.1). Хост может поддерживать ресурсы нескольких сеансов CICAM проигрывателя.

Следующие 8.7.2-8.7.19 настоящего стандарта определяют APDU, используемые Хостом для управления потреблением контента CICAM.

Примечание - Термин "сеанс проигрывателя" используется для описания сеанса проигрывания контента при поставке IP CICAM в режиме проигрывателя. Это не связано с понятием сеанса ресурса CI Plus.

8.7.2 APDU ресурсов CICAM в режиме проигрывателя

В таблице 46 перечислены APDU ресурса CICAM в режиме проигрывателя и приведены краткие описания назначения каждого APDU.

Таблица 46 - APDU ресурса CICAM в режиме проигрывателя

8.7.3 APDU CICAM_player_verify_req

Хост может передать этот APDU в СIСАМ для проверки способности CICAM проигрывания актива контента при IP-доставке в случае работы CICAM в режиме проигрывателя. CICAM должен ответить APDU CICAM_player_verify_reply. Синтаксис APDU CICAM_player_verify_req показан в таблице 47.

Таблица 47 - Синтаксис APDU CICAM_player_verify_req

Семантика полей APDU CICAM_player_verify_req:

- CICAM_player_verify_req_tag: поле 24 бита содержит значение тега, установленное на 0x9FA000;

- service_location_length: поле 16 битов содержит количество байтов, формирующих поле ServiceLocation;

- service_location_byte: поле 8 битов содержит структуру данных XML одиночного элемента ServiceLocation, описывающего службу, проверяемую Хостом. Схема элемента XML ServiceLocation специфицируется в приложении Г настоящего стандарта.

8.7.4 APDU CICAM_player_verify_reply

CICAM должен отправить этот APDU Хосту в ответ на APDU CICAM_player_verify_req. Этим APDU он указывает, что CICAM способен воспроизводить контент IP.

Синтаксис APDU CICAM_player_verify_reply показан в таблице 48.

Таблица 48 - Синтаксис APDU CICAM_player_verify_reply

Семантика полей APDU CICAM_player_verify_reply:

- CICAM_player_verify_reply_tag: поле 24 бита содержит значение тега, установленное на 0x9FA001;

- player_verify_status: поле 8 битов содержит возвращаемый Хосту статус проигрывателя на интервале сеанса проигрывателя. В таблице 49 перечислены возможные значения player_verify_status.

Таблица 49 - Значения player_verify_status

8.7.5 APDU CICAM_player_capabilities_req

CICAM направляет этот APDU Хосту с запросом о наборе кодеков, поддерживаемых Хостом. Эта информация будет использована CICAM для определения необходимости транскодирования исходного контента.

Синтаксис APDU CICAM_player_play_capabilities_req показан в таблице 50.

Таблица 50 - Синтаксис APDU CICAM_player_play_capabilities_req

Семантика APDU CICAM_player_play_capabilities_req:

СIСАМ_рlауеr_сараbilities_req_tag: поле 24 бита содержит значение тега, установленное на 0x9FA002.

8.7.6 APDU CICAM_player_capabilities_reply

Хост должен отправить этот APDU к CICAM в ответ на APDU CICAM_player_capabilities_teg, чтобы сообщить о кодеках, поддерживаемых Хостом. Эта информация используется CICAM для определения необходимости транскодирования исходного контента. Синтаксис АРDU CICAM_player_capabilities_reply показан в таблице 51.

Таблица 51 - Синтаксис АРDU CICAM_player_capabilities_reply

Семантика полей APDU CICAM_player_capabilities_reply:

- CICAM_player_player_capabilities_reply_tag: поле 24 бита содержит значение тега, установленное на 0x9FA003;

- number_of_component_types: поле 16 битов содержит количество поступающих компонент на входе, которые Хост может обрабатывать;

- stream_content: поле 4 бита определяет тип потока (например, видео, аудио или данные EBU). Кодирование этого поля должно быть в соответствии с правилом кодирования дескриптора компонент, определенным в [3];

- component_type: поле 8 битов определяет тип видео, аудио или данных EBU. Кодирование этого поля должно быть в соответствии с правилом кодирования дескриптора компонент, определенным в [3].

8.7.7 APDU CICAM_player_start_req

CICAM сообщает Хосту о начале сеанса проигрывателя, передавая поля, содержащие:

- необходимые скорости передачи данных через интерфейс TS от Хоста к CICAM и от CICAM к Хосту;

- флаг, характеризующий тип сеанса канала или без поддержки временного сдвига пакетов TS или канала VOD с поддержкой временного сдвига пакетов TS;

- количество байтов, формирующих РМТ;

- таблицу РМТ.

APDU может содержать РМТ с описаниями компонентов, которые будут поставлены на CICAM от Хоста через интерфейс TS. Перед РМТ в TS должна быть передана PAT. Если APDU содержит РМТ, то она должна быть идентична РМТ в TS.

Если во время передачи APDU CICAM_player_start_req РМТ CICAM неизвестна, то CICAM будет ожидать РМТ, которая будет определена до начала поставки TS. Когда РМТ известна, CICAM должен информировать Хост передачей APDU CICAM_player_update_req и ожидать от Хоста APDU CICAM_player_update_reply. После того как Хост получит РМТ, СICAM может начать передачу TS с гарантией корректной интерпретации Хостом пакетов TS с самого начала доставки локальных TS.

Хост для этого сеанса должен выделить локальный TS и должен переключиться на режим ввода. Если значение поля input_max_bitrate не будет равно нулю (т.е. CICAM хочет получить данные от Хоста на этом локальном TS), то CICAM должен установить гибридное соединение LSC, используя APDU comms_cmd в соответствии с разделом 10 настоящего стандарта.

CICAM должен выбрать соответствующие значения PID для выходных компонентов и для РМТ. Требования идентичности этих PID и PID, выделенных для гибридных соединений LSC, не предъявляются.

Синтаксис APDU CICAM_player_start_req представлен в таблице 52.

Таблица 52 - Синтаксис APDU CICAM_player_start_req

Семантика полей APDU CICAM_player_update_req:

- CICAM_player_start_req_tag: поле 24 бита определяет тег APDU и имеет значение 9FA004;

- input_max_bitrate: поле 16 битов определяет скорость передачи, которую CICAM запрашивает на поставку обрабатываемых данных через интерфейс TS от Хоста к CICAM, с шагом 10 Кбит/с, округленных до следующей границы 10 Кбит/с. Например, скорость передачи 512 Кбит/с будет кодирована как 0x0034;

- output_max_bitrate: поле 16 битов определяет скорость передачи, которую CICAM запрашивает на поставку обрабатываемых данных через интерфейс TS от CICAM к Хосту с шагом 10 Кбит/с;

- linearChannel: флаг, установленный в 0b1, сигнализирует сеанс канала без возможности смещения во времени. При установке в 0b0 он сигнализирует о сеансе актива VOD или канала со сдвигом во времени;

- РМТ_length: поле 16 битов определяет число байтов, составляющих РМТ;

- PMT_byte: поле 8 битов содержит таблицу РМТ MPEG, где первый байт содержит table_id РМТ.

8.7.8 APDU CICAM_player_start_reply

Хост должен переслать этот APDU как ответ на АРDU CICAM_player_start_req. Хост должен предоставить идентификатор локального TS, выделенного для доставки данных через интерфейс TS для этого сеанса. Этот идентификатор является также уникальным идентификатором сеанса CICAM проигрывателя.

До отправки этого APDU Хост должен определить необходимость создания нового локального TS. Если Хост определил для использования локальный TS, он должен прекратить передачу данных на этот локальный TS перед отправкой этого APDU. Хост может не передавать TS или отправлять нулевые пакеты до тех пор, пока не будет выполнено гибридное соединение LSC. В этом случае Хост должен использовать этот локальный TS для передачи данных IP в CICAM.

При приеме этого APDU CICAM должен отбросить любые данные TS на соответствующем локальном TS, полученные перед приемом этого APDU, и может начать поставлять SPTS Хосту, используя идентификатор локального TS, предоставленный Хостом.

Синтаксис APDU CICAM_player_start_reply показан в таблице 53.

Таблица 53 - Синтаксис APDU CICAM_player_start_reply

Семантика полей APDU CICAM_player_start_reply:

- CICAM_player_start_reply_tag: поле 24 бита определяет тег APDU и имеет значение 9FA005;

- LTS_id: поле 8 битов содержит идентификатор локального TS для проигрывателя, установленного Хостом. Он также используется для идентификации сеанса проигрывателя;

- input_status: поле 8 битов сообщает статус Хоста. Возможные значения статуса приведены в таблице 54.

Таблица 54 - Значения input_status

Если в поле input_status установлено значение, отличное от нуля, то поле LTS_id должно быть проигнорировано.

8.7.9 APDU CICAM_player_play_req

Хост направляет этот APDU к CICAM с запросом к CICAM о проигрывании службы от имени Хоста. CICAM должен ответить или APDU CICAM_player_status_error в случае, когда обнаружена ошибка, или APDU CICAM_player_start_req.

Синтаксис АРDU CICAM_player_play_req должен быть в соответствии с таблицей 55.

Таблица 55 - Синтаксис APDU CICAM_player_play_req

Семантика полей APDU CICAM_player_play_req:

- CICAM_player_play_req_tag: поле 24 бита содержит значение тега, которое должно быть 0x9FA006;

- service_location_length: поле 16 битов, содержит значение длины поля ServiceLocation;

- service_location_byte: поле 8 битов, формирует структуру данных XML с одиночным элементом ServiceLocation, описывающим службу, проверяемую Хостом. Схема XML ServiceLocation определена в приложении Г настоящего стандарта.

8.7.10 APDU CICAM_player_status_error

CICAM направляет этот APDU к Хосту в ответ на APDU CICAM_player_play_req, если обнаружена ошибка. В случае отсутствия ошибки CICAM направляет APDU CICAM_player_start_req.

Если обнаружена ошибка, то CICAM может отправить APDU CICAM_player_play_req в любое время сеанса проигрывателя или после сеанса проигрывателя, если обнаруживается состояние ошибки.

Отображение сообщения об ошибке выполняет CICAM с помощью приложения MMI.

CICAM направляет APDU CICAM_player_end для Хоста с предложением освободить ресурсы Хоста в режиме проигрывателя.

Синтаксис APDU CICAM_player_status_error показан в таблице 56.

Таблица 56 - Синтаксис APDU CICAM_player_status_error

Семантика полей APDU APDU CICAM_player_status_error:

- CICAM_player_play_req_tag: поле 24 бита содержит значение тега, которое должно быть 0x9FA007;

- valid_LTS_id: флаг устанавливается в 0b1, когда сообщение об ошибке относится к установленному сеансу проигрывателя с известным LTS_id. Если установлено значение 0b0, сообщение об ошибке относится к сеансу проигрывателя, который еще не установлен;

- LTS_id: поле 8 битов содержит идентификатор локального TS, используется сеансом проигрывателя. Он также используется для однозначной идентификации сеанса проигрывателя. Это поле не определено, если valid_LTS_id установлен в 0b0;

- player_status: поле 8 битов содержит возвращаемый статус сеанса проигрывателя. В таблице 57 перечислены возможные значения.

Таблица 57 - Значения play_status

8.7.11 APDU CICAM_player_control_req

Хост должен отправить этот APDU в CICAM для того, чтобы установить позицию проигрывания или изменение скорости на сеансе проигрывателя. CICAM должен ответить APDU CICAM_player_info_reply, который сигнализирует нужную позицию и скорость.

Синтаксис APDU CICAM_player_control_req показан в таблице 58.

Таблица 58 - Синтаксис APDU CICAM_player_control_req

Семантика полей APDU CICAM_player_control_req:

- CICAM_player_play_req_tag: поле 24 бита содержит значение тега, которое должно быть 0x9FA008;

- LTS_id: поле 8 битов содержит идентификатор локального TS, который используется сеансом проигрывателя. Он также используется для идентификации сеанса проигрывателя;

- command: поле 8 битов определяет действие, которое должно выполняться в соответствии со значениями, указанными в таблице 59;

Таблица 59 - Значения command

- seek_mode: поле 8 битов, интерпретация его значений должна быть в соответствии с таблицей 60;

Таблица 60 - Значения seek_mode

- seek_position: поле 12 битов содержит целое число со знаком, представляющее искомую позицию проигрывания, выраженную в миллисекундах. Значение 0xFFFFFFFF для потока в реальном времени означает "переход в реальное время", и для VOD это означает конец актива контента;

- speed: поле 8 битов содержит данные о скорости проигрывания, выраженной в сотых долях номинальной скорости. Отрицательная величина означает, что запрашивается скорость обратного направления.

Если CICAM не поддерживает запрос скорости или позиции проигрывания, то CICAM должен выбрать ближайшую скорость или позицию проигрывания, которые он поддерживает, или же CICAM может игнорировать команду. Поэтому APDU CICAM_player_info_reply должен оцениваться для определения фактической скорости и позиции проигрывания.

8.7.12 APDU CICAM_player_info_req

Хост должен отправить этот APDU к CICAM для того, чтобы получить информацию о проигрываемом контенте, в том числе о длительности проигрывания контента, о позиции и о скорости проигрывания. CICAM должен ответить APDU CICAM_player_info_reply.

Синтаксис АРDU CICAM_player_info_req должен быть в соответствии с таблицей 61.

Таблица 61 - Синтаксис APDU CICAM_player_info_req

Семантика полей APDU CICAM_player_info_req:

- CICAM_player_play_req_tag: поле 24 бита содержит значение тега, которое должно быть 0x9FA009;

- LTS_id: поле 8 битов содержит идентификатор локального TS, который используется сеансом проигрывателя. Он также используется для идентификации сеанса проигрывателя.

8.7.13 APDU CICAM_player_info_reply

CICAM направляет этот APDU как ответ на APDU CICAM_player_info_req. Синтаксис АРDU CICAM_player_info_reply показан в таблице 62.

Таблица 62 - Синтаксис APDU CICAM_player_info_reply

Семантика полей APDU CICAM_player_info_reply:

- CICAM_player_play_req_tag: поле 24 бита содержит значение тега, которое должно быть 0x9FA00A;

- LTS_id: поле 8 битов содержит идентификатор локального TS, который используется сеансом проигрывателя и для идентификации сеанса проигрывателя;

- duration: поле 32 бита содержит общую продолжительность проигрывания контента в секундах. Если она неизвестна, то в поле должно быть установлено 0xFFFFFFFF;

- position: поле 32 бита сигнализирует текущую позицию проигрывания, выраженную в секундах, прошедших с начала проигрывания контента. Если позиция неизвестна, то в поле должно быть установлено 0xFFFFFFFF;

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

8.7.14 APDU CICAM_player_stop

Хост посылает этот APDU к CICAM для прекращения сеанса проигрывателя.

Синтаксис АРDU CICAM_player_stop показан в таблице 63.

Таблица 63 - Синтаксис APDU CICAM_player_stop

Семантика полей APDU CICAM_player_info_reply:

- CICAM_player_play_req_tag: поле 24 бита содержит значение тега, которое должно быть 0x9FA00B;

- LTS_id: поле 8 битов содержит идентификатор локального TS, который используется сеансом проигрывателя и является идентификатором сеанса проигрывателя.

8.7.15 APDU CICAM_player_end

CICAM направляет этот APDU для завершения сеанса проигрывателя CICAM. Это позволяет Хосту освободить занятые ресурсы, например, интерфейса TS. CICAM должен закрыть все гибридные LSC, используемые сеансом проигрывателя CICAM, до отправления этого APDU.

Синтаксис APDU CICAM_player_end показан в таблице 64.

Таблица 64 - Синтаксис APDU APDU CICAM_player_end

Семантика полей APDU APDU CICAM_player_end:

- CICAM_player_play_req_tag: поле 24 бита содержит значение тега, которое должно быть 0x9FA00C;

- LTS_id: поле 8 битов содержит идентификатор локального TS, который используется сеансом проигрывателя и является идентификатором сеанса проигрывателя.

8.7.16 APDU CICAM_player_asset_end

CICAM должен отправить этот APDU для уведомления Хоста о том, что были достигнуты начало или конец актива контента.

Синтаксис APDU CICAM_player_asset_end показан в таблице 65.

Таблица 65 - Синтаксис APDU CICAM_player_asset_end

Семантика полей APDU CICAM_player_asset_end:

- CICAM_player_play_req_tag: поле 24 бита содержит значение тега, которое должно быть 0x9FA00D;

- LTS_id: поле 8 битов содержит идентификатор локального TS, который используется сеансом проигрывателя и является идентификатором сеанса проигрывателя;

- reserved: поле 7 битов должно содержать 0x7F;

- beginning: флаг при установке 0b1 означает, что достигнуто начало актива. Установка 0b0 означает, что достигнут конец актива.

8.7.17 APDU CICAM_player_update_req

CICAM должен отправить этот APDU, чтобы уведомить Хост о поставке Хосту описания компонентов РМТ через интерфейс TS. Этот APDU должен отправляться при каждом изменении РМТ в соответствующем локальном TS.

Синтаксис APDU CICAM_player_update_req показан в таблице 66.

Таблица 66 - Синтаксис APDU CICAM_player_update_req

Семантика полей APDU CICAM_player_update_req:

- CICAM_player_play_req_tag: поле 24 бита содержит значение тега, которое должно быть 0x9FA00E;

- LTS_id: поле 8 битов содержит идентификатор локального TS, который используется сеансом проигрывателя и является идентификатором сеанса проигрывателя;

- PMT_length: поле 16 битов содержит количество байт, составляющих РМТ. Оно не должно быть равно нулю;

- РМТ_byte: поле 8 битов содержит РМТ, представленную в виде таблицы MPEG, где первый байт содержит table_id РМТ.

8.7.18 APDU CICAM_player_update_reply

Хост должен отправить этот APDU в ответ на APDU CICAM_player_update_req. После приема этого APDU CICAM может доставлять на Хост достоверные SPTS с гарантией того, что Хост готов интерпретировать транспортные пакеты от начала доставки SPTS.

Синтаксис APDU CICAM_player_update_reply показан в таблице 67.

Таблица 67 - Синтаксис APDU CICAM_player_update_reply

Семантика полей APDU CICAM_player_update_reply:

- CICAM_player_play_req_tag: поле 24 бита содержит значение тега, которое должно быть 0x9FA00F;

- LTS_id: поле 8 битов содержит идентификатор локального TS для сеанса проигрывателя;

- update_status: поле 8 битов содержит значения статуса Хоста. Возможные значения update_status приведены в таблице 68.

Таблица 68 - Значения update_status

8.7.19 Сводный перечень ресурсов CICAM в режиме проигрывателя

В таблице 69 представлен сводный перечень атрибутов ресурса CICAM в режиме проигрывателя.

Таблица 69 - Сводный перечень атрибутов ресурса CICAM в режиме проигрывателя