1
Доступно поисковых запросов: 1 из 2
Следующий пробный период начнётся: 11 октября 2022 в 17:09
Снять ограничение

ГОСТ Р 56950-2016

Телевидение вещательное цифровое. Расширенная спецификация общего интерфейса в системах ограничения доступа CI Plus™. Основные параметры
Действующий стандарт
Проверено:  03.10.2022

Информация

Название Телевидение вещательное цифровое. Расширенная спецификация общего интерфейса в системах ограничения доступа CI Plus™. Основные параметры
Название английское Digital Video Broadcasting. Extensions to the CI PlusTM Specification. Basic parameters
Дата актуализации текста 01.01.2021
Дата актуализации описания 01.01.2021
Дата издания 12.07.2016
Дата введения в действие 01.06.2017
Область и условия применения Настоящий стандарт содержит расширенные характеристики общего интерфейса в системах ограничения доступа CI Plus™, определенного в [1]. Стандарт распространяется на оборудование защиты информации, передаваемой по каналам вещания и по каналам Интернет протокола (Internet Protocol; IP)
Опубликован Официальное издание. М.: Стандартинформ, 2016 год
Утверждён в Росстандарт

Расположение в каталоге ГОСТ


ГОСТ Р 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 для различных вариантов использования

Вариант использования

Порядок следования пакетов TS

Задержка пакетов TS

Изменения задержки байтов TS на входе CICAM

Только вещание

CICAM должен поддерживать порядок пакетов с одинаковыми LTS_id

При обработке входных транспортных пакетов CICAM должен обеспечивать постоянную задержку и требования в соответствии с [2] (5.4.2)

CICAM должен обеспечивать выполнение требований к максимальным изменениям задержки в соответствии с [2] (5.4.2)

Только в режиме IP-доставки Хосту в режиме проигрывателя

CICAM не должен поддерживать порядок пакетов с одинаковыми LTS_id. Порядок следует поддерживать для пакетов с одинаковыми PID

Допускается несоответствие CICAM требованию постоянной задержки [2] (5.4.2) при обработке входных IP-пакетов

Допускается несоответствие CICAM требованиям к максимальным изменениям задержки [2] (5.4.2)

Только в режиме IP-доставки CICAM в режиме проигрывателя

Не применяется, так как CICAM создает новый TS

Не применяется, так как CICAM создает новый TS

Не применяется, так как CICAM создает новый TS

Вещание и IP-доставка Хосту в режиме проигрывателя

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

CICAM не должен поддерживать порядок пакетов с одинаковыми LTS_id в режиме доставки IP Хосту в режиме проигрывателя.

Порядок следует поддерживать для пакетов с одинаковыми PID

Допускается несоответствие  CICAM требованию постоянной задержки [2] (5.4.2) при обработке входных транспортных пакетов вещания.

Допускается несоответствие  CICAM требованию постоянной задержки [2] (5.4.2) при обработке входных IP-пакетов

Допускается несоответствие CICAM требованиям к максимальным изменениям задержки [2] (5.4.2)

Вещание и IP-доставка CICAM в режиме проигрывателя

К CICAM не предъявляется требование поддержки порядка пакетов вещания с одинаковыми LTS_id.

Не предъявляется к IP контенту, так как CICAM создает новый TS

Допускается несоответствие  CICAM требованию постоянной задержки [2] (5.4.2) при обработке входных транспортных пакетов вещания.

Не предъявляется контенту при доставке IP, так как CICAM создает новый TS

Допускается несоответствие CICAM требованиям к максимальным изменениям задержки [2] (5.4.2).

Не предъявляется к контенту при доставке IP, так как CICAM создает новый TS


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 многопоточного ресурса

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

Объект приложения

Направление передачи

Идентификатор ресурса

Класс

Тип

Версия

Teг APDU

Значение тега

Хост

CICAM

00 90 00 41

144

1

1

CICAM_multistream_capability

9F 92 00


PID_select_req

9F 92 01


PID_select_reply

9F 92 02




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

Синтаксис

Количество битов

Мнемоника

CICAM_multistream_capability () {

CICAM_multistream_capability_tag

24

uimsbf

length_field ()

max_local_TS

8

uimsbf

max_descramblers

16

uimsbf

}


Семантика полей 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

Синтаксис

Количество битов

Мнемоника

PID_select_req () {

PID_select_req_tag

24

uimsbf

length_field ()

LTS_id

8

uimsbf

num_PID

8

uimsbf

for (i = 0; i<num_PID; i++) {

reserved

2

bslbf

critical_for_descrambling_flag

1

bslbf

PID

13

uimsbf

}

 

}


Семантика полей 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

Синтаксис

Количество битов

Мнемоника

PID_select_reply () {

PID_select_reply _tag

24

uimsbf

length_field ()

LTS_id

8

uimsbf

reserved

7

uimsbf

PID_selection_flag

1

uimsbf

num_PID

8

uimsbf

for (i=0; i<num_PID; i++)

reserved

2

bslbf

PID_selected_flag

1

uimsbf

PID

13

uimsbf

}

}


Семантика полей 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 - Контент ресурса управления в обобщенной форме

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

Объект приложения

Направление передачи

Идентификатор ресурса

Класс

Тип

Версия

Teг APDU

Значение тега

Хост

CICAM

00 8С 10 41

140

65

1

cc_open_req

9F 92 01


cc_open_cnf

9F90 02


cc_data_req

9F 9003


cc_data_cnf

9F 90 04


cc_sync_req

9F 90 05


cc_sync_cnf

9F 90 06


cc_sac_data_req (Примечание 1)

9F 90 07


cc_sac_data_cnf (Примечание 1)

9F 90 08


cc_sac_sync_req

9F 90 09


cc_sac_sync_cnf

9F 90 10


cc_PIN_capabilities_req

9F 90 11


cc_PIN_capabilities_reply

9F 90 12


cc_PIN_cmd

9F 90 13


cc_PIN_reply (Примечание 2)

9F 90 14


cc_PIN_event (Примечание 2)

9F 90 15


cc_PIN_playback

9F 90 16


cc_PIN_MMI_req

9F 90 17


Примечания

1 Синтаксис APDU не расширен, но поле LTS_id входит в отдельные протоколы SAC, как указано в 6.4.3.3 настоящего стандарта.

2 Этот APDU расширен и включает поле LTS_id.


Пункт 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

Синтаксис

Количество битов

Мнемоника

cc_PIN_reply() {

cc_PIN_reply_tag

24

uimsbf

length_field()

reserved

7

uimsbf

LTS_bound_flag

1

uimsbf

if (LTS_bound_flag == 1) {

LTS_id

8

uimsbf

} else {

reserved

8

uimsbf

}

PINcode_status_field

8

uimsbf

}


Семантика полей 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

Синтаксис

Количество битов

Мнемоника

cc_PIN_event () {

cc_PIN_reply_tag

24

uimsbf

length_field()

LTS_id

8

uimsbf

program_number

16

uimsbf

PINcode_status_field

8

uimsbf

rating

8

uimsbf

pin_event_time_utc

40

uimsbf

pin_event_time_centiseconds

8

uimsbf

private_data

8x15

uimsbf

}


Семантика полей 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

Операция

APDU

Содержание

1 CICAM передает URI на Хост

cc_sac_data_req

send_datatype_nbr = 3

i

datatype_id

datatype_len, бит

0

25 (operating_mode)

64

1

26 (program_number)

16

2

50 (LTS_id)

8

request_datatype_nbr = 1

i

datatype_id

0

27 (uri_confirm)

2 Хост передает CICAM подтверждение

cc_sac_data_cnf

send_datatype_nbr = 1

i

datatype_id

datatype_len, бит

0

27 (uri_confirm)

256


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 - Параметры модифицированного протокола начала записи

Операция

APDU

Содержание

1 Хост информирует CICAM о начале записи

cc_sac_data_req

send_datatype_nbr = 3 или 4

i

datatype_id

datatype_len, бит

0

38 (operating_mode)

8

1

26 (program_number)

16

2

39 (PINcode data)

переменное количество (опционально)

3

50 (LTS_id)

8

request_datatype_nbr = 1

i

datatype_id

0

40 (record_start_status)

2 CICAM передает Хосту подтверждение

cc_sac_data_cnf

send_datatype_nbr = 1

i

datatype_id

datatype_len, бит

0

40 (record_start_status)

8


При выполнении протокола начала записи Хост указывает, поддерживается выбранная программа пользователем или не поддерживается. Если выбранная программа пользователем не поддерживается, то 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 - Параметры модифицированного протокола остановки записи

Операция

APDU

Содержание

1 Хост информирует CICAM об остановке записи

cc_sac_data_req

send_datatype_nbr = 2

i

datatype_id

datatype_len, бит

0

26 (program_number)

16

1

50 (LTS_id)

16

request_datatype_nbr = 1

i

datatype_id

0

42 (record_stop_status)

2 CICAM передает Хосту подтверждение

cc_sac_data_cnf

send_datatype_nbr = 1

i

datatype_id

datatype_len, бит

0

42 (record_stop_status)

8


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

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

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

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


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

Операция

APDU

Содержание

1 Хост информирует CICAM об изменении режима работы

cc_sac_data_req

send_datatype_nbr = 3

i

datatype_id

datatype_len, бит

0

38 (operating_mode)

8

1

26 (program_number)

16

2

50 (LTS_id)

8

request_datatype_nbr = 1

i

datatype_id

0

41 (mode_change_status)

2 CICAM передает Хосту подтверждение

cc_sac_data_cnf

send_datatype_nbr = 1

i

datatype_id

datatype_len, бит

0

41 (mode_change_status)

8


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

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

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

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


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

Операция

APDU

Содержание

1 CICAM поставляет Хосту контент лицензии

cc_sac_data_req

send_datatype_nbr = 4 или 5

i

datatype_id

datatype_len, бит

0

26 (program_number) (Примечание 1)

16

1

34 (license_status) (Примечание 2)

8

2

25 (uri_message)

64

3

33 (cicam_license)

переменное количество (опционально)

4

50 (LTS_id)

8

request_datatype_nbr = 1

i

datatype_id

0

35 (license_rcvd_status) (Примечание 3)

2 Хост подтверждает получение

cc_sac_data_cnf

send_datatype_nbr = 1

i

datatype_id

datatype_len, бит

0

35 (license_rcvd_status) (Примечание 3)

8

Примечания

1 program_number соответствует program_number в сообщениях Record Start (начало записи).

2 Допустимые значения и значение этого поля содержатся в [1] (таблица 11.45).

3 Допустимые значения и значение этого поля содержатся в [1] (таблица 11.42).


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

Синтаксис

Количество битов

Мнемоника

ca_pmt () {

ca_pmt_tag

24

uimsbf

length_field ()

LTS_id

8

uimsbf

ca_pmt_list_management

8

uimsbf

program_number

16

uimsbf

reserved

3

bslbf

PMT_PID

13

uimsbf

reserved

2

bslbf

version_number

5

uimsbf

current_next_indicator

1

bslbf

reserved

4

bslbf

program_info_length

12

uimsbf

if (program_info_length ! = 0) {

ca_pmt_cmd_id /* at program level */

8

uimsbf

for (i = 0; i < n; i++) {

ca_descriptor() /* CA descriptor at programme level */

}

}

for (i = 0; i < n; i++) {

stream_type

8

uimsbf

reserved

3

bslbf

elementary_PID /* elementary stream PID */

13

uimsbf

reserved

4

bslbf

es_info_length

12

uimsbf

if (es_info_length ! = 0) {

ca_pmt_cmd_id /* at ES level */

8

uimsbf

for (i = 0; i < n; i++) {

ca_descriptor() /* CA descriptor at elementary stream level */

}

}

}

}


Семантика полей 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 в многопоточном режиме

Значение

Содержание

0x03

Only (только)

0x05

Update (обновление)

Другие значения

Reserved (зарезервировано)


В многопоточном режиме "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

Синтаксис

Количество битов

Мнемоника

ca_pmt_reply () {

ca_pmt_reply_tag

24

uimsbf

length_field()

LTS_id

8

uimsbf

program_number

16

uimsbf

reserved

2

bslbf

version_number

5

uimsbf

current_next_indicator

1

bslbf

ca_enable_flag

1

bslbf

if (ca_enable_flag == 1) {

ca_enable /* at programme level */

7

uimsbf

} else {

reserved

7

bslbf

}

for (i = 0; i<n; i++) {

reserved

3

bslbf

elementary_PID

13

uimsbf

ca_enable_flag

1

bslbf

if (ca_enable_flag == 1) {

ca_enable /* at elementary stream level */

7

uimsbf

} else {

reserved

7

bslbf

}

}

}


Семантика полей 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, поддерживающих многопоточный тип ресурса управления Хоста

APDU

Направление передачи

Хост

CICAM

tune_broadcast_req


tune_triplet_req


une_lcn_req


tune_ip_req


tune_reply


ask_release


ask_release_reply


tuner_status_req


tuner_status_reply



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

Синтаксис

Количество битов

Мнемоника

tune_broadcast_req(){

tune_broadcast_req_tag

24

uimsbf

length_field()

reserved

4

uimsbf

background_tune_flag

1

uimsbf

tune_quietly_flag

1

uimsbf

keep_app_running_flag

1

uimsbf

pmt_flag

1

uimsbf

service_id

16

uimsbf

reserved

4

uimsbf

descriptor_loop_length

12

uimsbf

for (i=0; i<N; i++) {

descriptor()

}

if (pmt_flag == 1) {

program_map_section ()

}

}


Семантика полей 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

Синтаксис

Количество битов

Мнемоника

tune_triplet_req () {

tune_triplet_req_tag

24

uimsbf

length_field()

reserved

5

uimsbf

background_tune_flag

1

uimsbf

tune_quietly_flag

1

uimsbf

keep_app_running_flag

1

uimsbf

original_network_id

16

uimsbf

transport_stream_id

16

uimsbf

service_id

16

uimsbf

delivery_system_descriptor_tag

8

uimsbf

if (delivery_system_descriptor_tag == 0x7f){

descriptor_tag_extension

8

uimsbf

}

else {

reserved

8

uimsbf

}

}


Семантика полей 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

Синтаксис

Количество битов

Мнемоника

tune_lcn_req () {

tune_lcn_req_tag

24

uimsbf

length_field()

reserved

7

uimsbf

background_tune_flag

1

uimsbf

tune_quietly_flag

1

uimsbf

keep_app_running_flag

1

uimsbf

logical_channel_number

14

uimsbf

}


Семантика полей 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

Синтаксис

Количество битов

Мнемоника

tune_ip_req () {

tune_ip_req_tag

24

uimsbf

length_field()

reserved

1

uimsbf

background_tune_flag

1

uimsbf

tune_quietly_flag

1

uimsbf

keep_app_running_flag

1

uimsbf

service_location_length

12

uimsbf

for (i=0; i<N; i++) {

service_location_data

8

uimsbf

}

}


Семантика полей 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

Синтаксис

Количество битов

Мнемоника

tune_reply () {

tune_reply_tag

24

uimsbf

length_field ()

LTS_id

8

uimsbf

status_field

8

uimsbf

}


Семантика полей 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

Синтаксис

Количество битов

Мнемоника

RequestStart() {

RequestStartTag

24

uimsbf

length_field()

reserved

7

bslbf

LTS_bound_flag

1

bslbf

if (LTS_bound_flag == 1) {

LTS_id

8

uimsbf

} else {

reserved

8

bslbf

}

AppDomainldentifierLength

8

uimsbf

InitialObjectLength

8

uimsbf

for (i=0; i<AppDomainldentifierLength; i++){

AppDomainldentifier

8

uimsbf

}

for (i=0; i< InitialObjectLength; i++){

InitialObject

8

uimsbf

}

}


Семантика полей 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

Синтаксис

Количество битов

Мнемоника

enq(){

enq_tag

24

uimsbf

length_field()

reserved

6

bslbf

LTS_bound_flag

1

bslbf

blind_answer

1

bslbf

if (LTS_bound_flag == 1) {

LTS_id

8

uimsbf

}else {

reserved

8

bslbf

}

 

answer_text_length

8

uimsbf

for (i=0; i_enq_length - 3; i++){

text_char

8

uimsbf

}

}


Семантика полей 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

answ_id

Значение

Cancel (отменить)

0x00

Answer (ответ)

0x01

Reserved (зарезервировано)

от 0x02 до 0xFE

Unattended (не обслуживается)

0xFE


Значение 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

Синтаксис

Количество битов

Мнемоника

menu(){

menu_tag

24

uimsbf

length_field()

reserved

7

bslbf

LTS_bound_flag

1

bslbf

if (LTS_bound_flag == 1) {

LTS_id

8

uimsbf

}else {

reserved

8

bslbf

}

choice_nb

8

uimsbf

TEXT() /* title text */

TEXT() /* sub-title text */

TEXT() /* bottom text */

for (i=0; i<choice_nb; i++) { /* when choice_nb != 'FF' */

TEXT()

}

}


Семантика полей 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

choice_ref

Значение

Cancel (отменить)

0x00

Количество выборов, сделанных пользователем

от 0x01 до 0xFE

Unattended (не обслуживается)

0xFE


Значение 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

Синтаксис

Количество битов

Мнемоника

list(){

list_tag

24

uimsbf

length_field()

reserved

7

bslbf

LTS_bound_flag

1

bslbf

if (LTS_bound_flag == 1) {

LTS_id

8

uimsbf

}else {

reserved

8

bslbf

}

item_nb

8

uimsbf

TEXT() /* title text */

TEXT() /* sub-title text */

TEXT() /* bottom text */

for (i=0; i<item_nb; i++){/*when item_nb != 'FF' */

TEXT()

}

}


Семантика 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 - Параметры ресурса дескремблирования семпла

Закупки не найдены
Свободные
Р
Заблокированные
Р
Роль в компании Пользователь

Для продолжения необходимо войти в систему

После входа Вам также будет доступно:
  • Автоматическая проверка недействующих стандартов в закупке
  • Создание шаблона поиска
  • Добавление закупок в Избранное