ГОСТ Р 54456-2011 Телевидение вещательное цифровое. Домашняя мультимедийная платформа. Класс 1.0. Основные параметры

ГОСТ Р 54456-2011

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

ТЕЛЕВИДЕНИЕ ВЕЩАТЕЛЬНОЕ ЦИФРОВОЕ. ДОМАШНЯЯ МУЛЬТИМЕДИЙНАЯ ПЛАТФОРМА

Класс 1.0. Основные параметры

Digital broadcast television. Multimedia home platform.

Class 1.0. Basic parameters

ОКС 33.170

Дата введения 2012-07-01

Предисловие

1 ПОДГОТОВЛЕН Федеральным государственным унитарным предприятием "Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении" (ФГУП "ВНИИНМАШ") и Федеральным государственным унитарным предприятием "Ордена Трудового Красного Знамени Научно-исследовательский институт радио", Самарский филиал "Самарское отделение Научно-исследовательского института радио" (филиал ФГУП "НИИР-СОНИИР") на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Управлением технического регулирования и стандартизации Федерального агентства по техническому регулированию и метрологии

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

4 Настоящий стандарт разработан с учетом основных нормативных положений документа Европейского института по стандартизации в области телекоммуникаций (ЕТСИ) ETSI ES 201 812 V1.1.2 (2006-08)* "Телевидение вещательное цифровое. Домашняя мультимедийная платформа (МНР). Спецификация 1.0.3" [ETSI ES 201 812 V1.1.2 (2006-08) "Digital Video Broadcasting (DVB); Multimedia Home Platform (МНР). Specification 1.0.3", IDT].

________________

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

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2002 (подраздел 3.6)

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

6 ПЕРЕИЗДАНИЕ. Май 2020 г.

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

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

Настоящий стандарт распространяется на аппаратно-программный комплекс - домашняя мультимедийная платформа (Multimedia Home Platform; МНР) класса 1.0. Домашняя мультимедийная платформа обеспечивает доступ пользователя к интерактивным и вещательным службам.

Настоящий стандарт предназначен для обеспечения функциональной совместимости между приложениями МНР и реализациями МНР.

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

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

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

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

ГОСТ Р 53527-2009 Телевидение вещательное цифровое. Требования к реализации системы ограничения доступа DVB simulcrypt на головных станциях. Основные параметры. Технические требования

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

Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов и классификаторов на официальном интернет-сайте Межгосударственного совета по стандартизации, метрологии и сертификации (www.easc.by) или по указателям национальных стандартов, издаваемым в государствах, указанных в предисловии, или на официальных сайтах соответствующих национальных органов по стандартизации. Если на документ дана недатированная ссылка, то следует использовать документ, действующий на текущий момент, с учетом всех внесенных в него изменений. Если заменен ссылочный документ, на который дана датированная ссылка, то следует использовать указанную версию этого документа. Если после принятия настоящего стандарта в ссылочный документ, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение применяется без учета данного изменения. Если ссылочный документ отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.

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

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

3.1.1 администратор приложений (application manager): Объект в MHP, который обеспечивает управление жизненным циклом приложений MHP, в том числе приложений DVB-J.

3.1.2 агент пользователя (user agent): Приложение, которое интерпретирует формат контента. Допускается реализация агента пользователя в форме плагина.

3.1.3 актор DVB-HTML (DVB-HTML actor): Местоположение действия или процесса выполнения определенного набора документов DVB-HTML для некоторого приложения DVB-HTML в среде MHP. Актор выполняется в агенте пользователя.

3.1.4 аплет (applet): Подпрограмма, встроенная в прикладную программу и загружаемая с сервера вместе с запрашиваемыми документами DVB-HTML как прикрепленный файл.

3.1.5 байт-код (byte-code [Java byte-code]): Машинно-независимый код, генерируемый Java-компилятором.

3.1.6 букет DVB (Bouquet DVB): Совокупность служб, предлагаемых пользователю как единый продукт.

3.1.7 вещатель (broadcaster [Service Provider]): Организация, которая собирает последовательность событий или программ для доставки.

3.1.8 видео "капли" (video "drips"): Форма медиа, когда на вход видеодекодера транспортный поток MPEG-2 подается блоками, содержащими l-кадры и Р-кадры. Каждый блок должен содержать один кадр и определенное число синтаксических элементов в соответствии с ISO/IEC [1].

3.1.9 виртуальная машина Java (Virtual Machine Java; JVM): Основная часть исполняющей системы Java (Java Runtime Environment; JRE). Виртуальная машина Java интерпретирует и исполняет Java байт-код, предварительно созданный из исходного текста Java-программы Java-компилятором. JVM может использоваться для выполнения программ, написанных на других языках программирования.

3.1.10 внутриподсистемный интерфейс (intra-subsystem interface): Интерфейс между двумя объектами, находящимися в одной подсистеме.

3.1.11 глиф (glyphe): Компьютерный символ (буква, число, знак пунктуации), относящийся к графеме или графемоподобной единице текста, выражается в шрифтах.

3.1.12 граница приложения (application boundary): Краткое общее описание элементов данных [документы языка разметки гипертекста (Hyper Text Mark-up Language; HTML), файлы кода, файлы изображения], сформированное в одно приложение, и логический локатор точки входа. Граница приложения описывается регулярным выражением на языке URL.

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

3.1.14 документ DVB-HTML (DVB-HTML document): Полный (завершенный) модуль элементов или форматов контента одного семейства HTML, определенного в настоящем стандарте.

3.1.15 домашняя мультимедийная платформа (Multimedia Home Platform; MHP): Аппаратно-программный комплекс, обеспечивающий доступ пользователя к интерактивным и вещательным службам.

3.1.16 домен (domain): Автономная часть сети или распределенной системы.

3.1.17 загрузка (download): Пересылка файлов по сети от пользователя к серверу или от сервера к пользователю.

3.1.18 идентификатор типа пакета (packet identifier; PID): Тринадцатибитовый указатель в заголовке транспортного пакета, определяющий принадлежность пакета тому или иному потоку данных.

3.1.19 интернет-протокол (Internet protocol; IP): Межсетевой протокол пакетной передачи, который:

- работает с 32-битовыми адресами, обеспечивает адресацию и маршрутизацию пакетов в сети;

- работает без установления соединения, не обеспечивает сохранение порядка следования пакетов, не гарантирует доставку пакетов.

3.1.20 интероперабельность [функциональная совместимость] (interoperability): Нейтральная платформа, обеспечивающая прием и представление приложений для поставщика, автора и вещателя.

3.1.21 интерфейс: Семантическая и синтаксическая конструкция в коде программы, используемая для специфицирования услуг, предоставляемых классом или компонентом. Интерфейс определяет:

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

- перечень возможных вычислений, которые может выполнить та или иная часть программы, включая описание того, какие аргументы и в каком порядке требуется передавать на вход алгоритмам из этого перечня. Сами алгоритмы [действительный программный код], которые будут выполнять все эти вычисления, интерфейсом не задаются, программируются отдельно и называются реализацией интерфейса.

3.1.22 информация о службах (Service Information, SI): Совокупность таблиц, которые передаются в составе транспортных потоков MPEG-2, предназначенных для вещания. К основным таблицам информации о службах относятся таблицы, характеризующие параметры сети передачи, компоненты служб: таблица объединения букета программ (Bouquet Association Table; ВАТ), таблица информации о событиях (Event Information Table; EIT), таблица состояния событий (Running Status Table; RST), таблица описания служб (Service Description Table; SDT), таблица времени и даты (Time and Date Table; TDT), таблица смещения времени (Time Offset Table; TOT).

3.1.23 исполняющая система Java (Java Runtime Environment; JRE): Минимизированная реализация виртуальной машины, необходимая для исполнения Java-приложений (без Java-компилятора) и других средств разработки. Состоит из JVM и библиотеки Java-классов.

3.1.24 Карусель Данных (Data Carousel): Передача модулей данных с циклическим повторением.

3.1.25 Карусель Объектов (Object Carousel; ОС): Передача в транспортном потоке циклически повторяющихся объектов (файлов, каталогов, потоков).

3.1.26 класс (class): Разновидность абстрактного типа данных в объектно-ориентированном программировании (ООП). Содержит описание переменных и констант, характеризующих объект.

3.1.27 класс 1.0; класс 1.1; класс 1.2: Классы MHP по видам предоставляемых услуг.

3.1.28 Клиент (Client): Потребитель услуг одного или более серверов.

3.1.29 коммутируемый виртуальный канал (Switched Virtual Circuit; SVC): Тип логического соединения, устанавливаемого по запросу пользователя только на время, необходимое для обмена информацией.

3.1.30 конструктор класса (class constructor): Специальный блок инструкций, вызываемый при создании объекта.

3.1.31 конструктор по умолчанию (default constructor): Конструктор, создаваемый компилятором при отсутствии конструктора класса.

3.1.32 контекст (context): Состояние системы; окружение системы, среда выполнения программы; текущая ситуация.

3.1.33 контент (content): Содержание, мультимедийный продукт (например, телевизионная программа).

3.1.34 конфигурация (configuration): Совокупность аппаратных и программных средств и связей между ними.

3.1.35 конфигурирование: Установление конфигурации.

3.1.36 кэш (cache): Быстродействующая буферная память большой емкости, используемая для хранения копии областей оперативной памяти с наиболее частым доступом.

3.1.37 логическая служба MHP (MHP service): Служба, которая может быть выбрана через программный интерфейс приложения выбора службы или его функциональные эквиваленты. Логические службы MHP включают в себя службы DVB вещания и расширения, определяющие службы в будущих версиях этой спецификации.

3.1.38 локаль (locale): Набор параметров, включая набор символов, язык пользователя, страну, часовой пояс, а также другие предустановки, которые пользователь ожидает увидеть в пользовательском интерфейсе.

3.1.39 локатор (locator): Ссылка, выраженная в синтаксисе технической комиссии Интернет, разрабатывающей документы RFC (Internet Engineering Tack Force; IETF), в соответствии с IETF [2], которая обеспечивает однозначную ссылку на документ DVB- HTML, доступный для MHP в определенном транспортном потоке.

3.1.40 медиа (media): В контексте стандарта - информационные сообщения, передаваемые по каналам вещания (кадры звука MPEG, кадры изображения MPEG, кадры изображения JPEG, файлы текста, субтитров, загружаемых шрифтов, графическая информация в формате PNG).

3.1.41 междуобъектный интерфейс (inter-entity interface): Интерфейс между двумя объектами, находящимися в различных подсистемах.

3.1.42 менеджер сеансов и ресурсов; МСР (Session and Resource Manager; SRM): Субсистема протокола системы команд и управления для средств цифровой записи [Digital Storage Media - Command and Control (DSM-CC)], обеспечивающая централизованное управление сеансами DSM-CC и ресурсами одной или более основных технологий сети.

3.1.43 метод (metod): Метод обработки информации в объектно-ориентированных языках.

3.1.44 методы класса (klass metods): Процедуры, описывающие поведение объектов.

3.1.45 многоцелевые расширения почты Интернет (Multipurpose Internet Mail Extensions; MIME): 1 Стандарт, описывающий передачу различных типов данных. 2 Спецификация для кодирования информации и форматирования сообщений.

3.1.46 навигатор (navigator): Резидентное приложение, обычно обеспечиваемое производителем, которое конечный пользователь может активировать в любое время. Навигатор может использоваться для выбора службы, приложения и инициирования взаимодействующих приложений.

3.1.47 нормальная форма Бэкуса - Наура; БНФ (Backus Normal Form; BNF): Нотация (метаязык) для записи синтаксиса языков программирования.

3.1.48 обратный вызов (callback): Принцип регистрации вызова класса-обработчика события (слушателя) в среде класса-источника, в частности, при выполнении приложения DVB-J. Обратный вызов позволяет исполнять код, который задается в аргументах при вызове функции.

3.1.49 объект (entity): Функциональный модуль в составе подсистемы [например, в состав подсистемы клиента входят объекты пользователь-сеть (П-С) и пользователь-пользователь (П-П)].

3.1.50 объект данных (Java Data Objects; JDO): Содержание документа XML (один или несколько объектов).

3.1.51 ответвление (tap): Прикладной объект, связанный с более низким уровнем взаимодействия.

3.1.52 пакетированный элементарный поток; ПЭП (Packetized Elementary Stream; PES): Пакетированный элементарный поток, в котором данные разбиты на пакеты и снабжены заголовками.

3.1.53 парсинг (parsing): Синтаксический анализ.

3.1.54 переносимая сетевая графика (Portable Network Graphics, PNG): Формат файлов для растровых графических изображений.

3.1.55 персистентность (Persistence): Сохраняемость, живучесть.

3.1.56 "песочница" (sandbox): Механизм защиты, включенный в состав виртуальной Java-машины - специально выделенная изолированная среда, в которой можно тестировать и выполнять потенциально опасные, полученные из Сети, аплеты.

3.1.57 плагин (plug-in): Подключаемая программа, содержащая дополнительные функции, которая может быть добавлена в общую платформу в порядке, представляемом зарегистрированной интерпретацией платформы DVB MHP, но не DVB-J (например, форматы приложения HTML-3.2 или MHEG-5).

3.1.58 пользователь (user): Оконечная система, которая может передавать или принимать информацию от других таких же оконечных систем с использованием сети и которая может функционировать как клиент, сервер или как клиент и сервер одновременно.

3.1.59 постоянный виртуальный канал (Permanent Virtual Circuit; PVC): Логическое соединение, устанавливаемое на сетевом уровне на определенный период времени.

3.1.60 потоковый протокол реального времени (Real Time Streaming Protocol; RTSP): Прикладной протокол предназначен для использования в системах, работающих с мультимедийными данными. Описан в IETF [2].

3.1.61 приложение (application): 1 Программное обеспечение, предоставляющее клиенту возможность решения определенной задачи и реализуемое в среде клиента. 2 Функциональная реализация программного обеспечения, обслуживающего один или несколько взаимодействующих аппаратных объектов.

3.1.62 приложение DVB-HTML (DVB-HTML application): Совокупность документов, выбранных из семейства DVB-HTML элементов и форматов контента, определенных в спецификации. Границы множества документов определяются границами приложения.

3.1.63 приложение DVB-J (DVB-J application): Совокупность классов DVB-J, которые функционируют совместно. Приложение DVB-J должно сообщать администратору приложений о существовании этой копии приложения DVB-J для управления временем жизни копии через интерфейс жизненного цикла.

3.1.64 примитив (primitive): Программный модуль, выполняющий одну элементарную операцию, или блоки данных, передаваемые между разными уровнями системы для вызова каких-либо процедур.

3.1.65 программный интерфейс приложения (Application Programming Interface; API): Набор определенных интерфейсов, посредством которых приложение общается с операционной системой (ОС) или с другими программами.

3.1.66 программный поток данных (Program Stream; PS): Поток данных, образованный путем мультиплексирования элементарных потоков видеоданных и звукоданных цифрового вещательного телевидения, имеющих одну общую тактовую частоту, и сформированный из программных пакетов вещательного телевидения переменной длины.

3.1.67 протокол управления группами (пользователей) в сети Интернет (Internet Group Management Protocol; IGMP): Протокол многоадресной рассылки управляет передачей пакетов между конечными пользователями и поддерживается протоколами IP в соответствии с IETF [3].

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

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

3.1.70 регулярное выражение (egular expression): 1 Нотация для описания текстовых фрагментов (образов) в процедурах типа "найти" и "найти-и-заменить". 2 Система поиска текстовых фрагментов в электронных документах, основанная на специальной системе записи образцов для поиска и включающая в себя формальный язык поиска, основанный на использовании образцовой строки (шаблона) и устанавливающий правила поиска.

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

3.1.72 ресурс (resource): Способность или качество системного объекта, которая может использоваться для создания вклада в реализацию службы (например, декодер стандарта MPEG, графическая система).

3.1.73 решение MHP (MHP solution): Решение, охватывающее набор технологий, необходимых, чтобы реализовать MHP, включая протоколы и программные интерфейсы приложений.

3.1.74 сеанс (session): Последовательность операций, при которой между пользователями сети устанавливается соединение, проводится обмен данными и завершается соединение.

3.1.75 секция (section): Синтаксическая структура, используемая для отображения сервисной информации в пакетах транспортного потока.

3.1.76 семантика (semantics): Система правил, предназначенная для определения смысловых значений отдельных конструкций алгоритмического языка.

3.1.77 сервер (server): Программный объект, экспортирующий ресурс имеющихся данных и устанавливаемый на физическое устройство, подключенное к сети, и предоставляющее услуги другим устройствам, работающим в этой сети.

3.1.78 сервис [служба, услуга] (service): 1 Последовательность программ, которая под управлением вещателя может быть в режиме вещания передана как часть расписания. 2 Логический объект в системе предоставляемых функций и интерфейсов, поддерживающий одно или множество приложений, отличие которого от других объектов заключается в доступе конечного пользователя к управлению шлюзом сервисов.

3.1.79 сеть (network): Совокупность элементов, поддерживающих связь, обеспечивающая соединение элементов, управление сеансом связи и/или управление подключением пользователя.

3.1.80 сеть DVB (DVB network): Набор мультиплексов транспортных потоков MPEG-2, переданных по единственной системе доставки (например, все цифровые каналы в конкретной кабельной системе).

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

3.1.82 система DSM-CC (system): Вся область действия протокола DSM-CC, включая субсистемы и их интерфейсы.

3.1.83 состояния приложения DVB-HTML (DVB-HTML application states): Логические состояния, в которых может находиться агент DVB-HTML.

3.1.84 специфические протоколы (Specific protocols): Специфические протоколы службы для вещания данных.

3.1.85 специфические протоколы службы (Service Specific): Протоколы, обеспечивающие регистрацию в MHP новых протоколов вещания.

3.1.86 ссылка на программные часы (Program Clock Reference; PCR): Тридцатитрехбитовое число, оцениваемое в периодах частоты 90 кГц, вводимое на программном уровне индивидуально для каждой передаваемой телевизионной программы.

3.1.87 стаб (stub): Программный модуль, временно подменяющий реальную процедуру другой версией, предусматривающей возможность передачи параметров вызываемой процедуры через сеть в "прозрачном" режиме.

3.1.88 субсистема (subsystem): Единица логического "оборудования" в пределах DSM-CC системы (например, клиент, сервер или менеджер сеансов и ресурсов).

3.1.89 суффикс (suffix): Логический знак (символ, слово), обозначающий конец сообщения.

3.1.90 таблица информации приложений (Application Information Table; AIT): Таблица, обеспечивающая полную информацию о вещании данных и о необходимых операциях для активизации приложений.

3.1.91 таблица описания служб (Service Description Table; SDT): Таблица, описывающая службы, передаваемые в конкретном транспортном потоке.

3.1.92 тег (tag): Служебный элемент, который размещен в начале заголовка и хранится вместе с данными, не может быть использован как самостоятельный элемент.

3.1.93 тег объединения (association tag): Признак, идентифицирующий группы ресурсов или разделенные ресурсы, которые вместе составляют соединение пользователь-пользователь (П-П), при подключении к ресурсам являющийся уникальным в пределах сеанса.

3.1.94 телетекст (teletext): Формат контента, поддерживающий передачу субтитров.

3.1.95 тело (body): Набор операторов внутри некоторой структуры (например, тело цикла, тело процедуры).

3.1.96 терминал MHP (MHP terminal): Единственная часть физического оборудования, соответствующего требованиям MHP, содержит виртуальную машину и комплект программного интерфейса приложений MHP.

3.1.97 транспорт [передача, транспортировка] (transport): Передача информации между различными объектами транспортного уровня, при котором гарантируется заданная степень надежности связи.

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

3.1.99 триггер (trigger): Событие, которое может вызвать изменение в поведении того приложения DVB-HTML, которое зарегистрировало интерес к такому событию. Триггеры могут приходить из потоков вещания, могут быть сгенерированы от других источников (таких как системные часы) или могут быть сгенерированы в результате взаимодействия пользователя. Триггер может включать ссылку на всемирное координированное время (Universal Time Coordinated; UTC) относительно некоторого другого события, относительно нормального времени воспроизведения (Normal Play Time, NPT) потока медиа.

3.1.100 универсальный набор символов (Universal Character Set; UCS): Универсальный набор символов, который задает однозначное соответствие символов кодам - элементам кодового пространства, представляющим неотрицательные целые числа. Семейство кодировок определяет машинное представление последовательности кодов UCS.

3.1.101 форвардинг (forwarding): Продвижение, пересылка (сообщения).

3.1.102 формат графического обмена (Graphics Interchange Format; GIF): Файловый формат 8-битной растровой графики используется для передачи растровых графических изображений.

3.1.103 шлюз сервиса (Service Gateway): Интерфейс, предоставляющий клиенту каталог услуг и возможность подключаться к домену сервиса.

3.1.104 цветовое пространство (colour space): Средство описания цвета в цифровой среде.

3.1.105 экземпляр (instance): Конкретный объект описанного класса.

3.1.106 экземпляр класса: Объект, типом которого является некоторый класс.

3.1.107 экземпляр приложения (application instance): Уникальный вызов приложения. Запуск того же самого приложения дважды дает два различных экземпляра приложения.

3.1.108 экстент (Extent): Непрерывная область (пространство) (например, в памяти), резервируемая для определенного набора данных.

3.1.109 юникд (Unicode): Стандарт кодирования символов, представляющих знаки письменных языков.

3.1.110 l-кадр (l-frame): Видеокадр, сформированный при внутрикадровом кодировании потока данных.

3.1.111 P-кадр (P-frame): Видеокадр, полученный предсказанием "вперед".

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

БНФ (Backus Normal Form, BNF) - нормальная форма Бэкуса - Наура;

МСР (Session and Resource Manager, SRM) - менеджер сеансов и ресурсов;

МСЭ (International Telecommunication Union, ITU) - Международный союз электросвязи;

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

ООП - объектно-ориентированное программирование;

ОС (Operating System, OS) - операционная система;

П-П (User-to-User, U-U) - пользователь-пользователь;

П-С (User-to-Network, U-N) - пользователь-сеть;

ПЭП (Packetized Elementary Stream, PES) - пакетированный элементарный поток;

ТВВЧ - телевидение высокой четкости;

ТП (transport stream, TS) - транспортный поток (цифрового вещательного телевидения);

ТФОП (Public Switched Telecommunications Network, PSTN) - телефонная сеть общего пользования;

ЦСИС (Integrated Services Digital Networks, ISDN) - цифровая сеть с интеграцией служб [услуг];

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

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

AWT (Abstract Windowing Toolkit) - оконная библиотека графического интерфейса языка Java, независимая от платформы;

BAT (Bouquet Association Table) - таблица объединения букета программ;

BlOP (Broadcast Inter-ORB Protocol) - протокол взаимодействия брокеров (посредников) запросов к объектам вещания;

BNF (Backus Normal Form) - нормальная форма Бэкуса - Наура; БНФ;

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

CORBA (Common Object Request Broker Architecture) - архитектура брокера общих объектных запросов, открытый стандарт для взаимодействия (интероперабельности) приложений;

DAVIC (DAVIC Digital Audiovisual Council) - комитет по аудиовизуальным проектам;

DECT (Digital Enhanced Cordless Telecommunications) - цифровая усовершенствованная беспроводная связь. Общеевропейский стандарт беспроводного доступа;

DCT (Discrete Cosine Transformation) - случай дискретно-косинусного преобразования Фурье четной функции, содержащего только косинусоидальные члены;

DII (Downloadlnfolndication) - сообщение индикации информации загрузки;

DNS (Domain Name System) - система доменных имен;

DNS (Domain Name Server) - сервер доменных имен;

DSM (Digital Storage Media) - цифровая запоминающая среда;

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

DSM-CC U-U (DSM-CC User to User) - набор протоколов DSM-CC передачи от пользователя к пользователю;

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

DVB-HTML actor - актор DVB-HTML;

DVB-HTML application - приложение DVB-HTML;

DVB-HTML application states - состояния приложения DVB-HTML;

DVB-HTML document - документ DVB-HTML;

DVB-IPTV - цифровое телевизионное вещание по каналам с IP-протоколами;

DVB-J - платформа Java, являющаяся частью спецификации MHP;

DVB-JAPI - один из программных интерфейсов приложений Java, стандартизированных как часть спецификации MHP;

DVB-J application - приложение DVB-J;

DVB network - сеть DVB;

EIT (Event Information Table) - таблица информации о событиях;

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

GIF (Graphics Interchange Format) - формат обмена графическими изображениями;

GSM (Global System for Mobile communications) - глобальная система подвижной связи;

GUI (Graphical User Interface) - графический интерфейс пользователя;

HTML (Hyper Text Mark-up Language) - язык разметки гипертекста;

HTML-3.2 - версия языка HTML-3.2;

HTTP (Hyper Text Transfer Protocol) - протокол передачи гипертекстовых файлов;

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

IEEE (Institute of Electrical and Electronics Engineers) - Институт инженеров по электротехнике и радиоэлектронике;

IETF (Internet Engineering Tack Force) - техническая комиссия Интернет, разрабатывающая документы RFC;

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

IIOP (Internet Inter-ORB Protocol) - межброкерный протокол для Интернет, является составной частью архитектуры CORBA;

INT (IP/MAC Notification Table) - таблица нотификации [извещений] IP-протокола;

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

IPCP (Internet Protocol Control Protocol) - протокол управления интернет-протоколом;

ISBN (International Standard Book Number) - международный стандартный номер книги;

ISDN (Integrated Services Digital Network) - цифровая сеть с интеграцией служб [услуг]; ЦСИС;

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

ITU (International Telecommunications Union) - Международный союз электросвязи; МСЭ;

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

JDO (Java Data Objects) - объект данных;

JFIF (JPEG File Interchange Format) - формат обмена файлами JPEG;

JMF (Java Media Framework) - универсальная библиотека для работы с аудио- и видеоданными, является стандартным расширением платформы Java 2.JMF;

JPEG (Joint Picture Expert Group) - группа экспертов по кодированию фотографических изображений [название группы и разработанного ею стандарта сжатия фотографических (неподвижных) изображений];

JRE (Java Runtime Environment) - исполняющая система Java;

JVM (Java Virtual Machine) - виртуальная машина Java;

LMDS (Local Multi-point Distribution Systems) - система местного многоточечного распределения;

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

MHP (Multimedia Home Platform) - аппаратно-программный комплекс - домашняя мультимедийная платформа;

MHP service - логическая служба MHP;

MHP solution - решение MHP;

MIME (Multipurpose Internet Mail Extensions) - многоцелевые расширения почты Интернет;

MPEG (Motion Pictures Expert Group) - группа экспертов по движущимся изображениям; группа стандартов сжатия видео- и аудиоданных;

MPEG-2 video "drips" - режим декодирования видеоизображения, использующий только l-кадры и P-кадры;

NPT (Normal Play Time) - нормальное время воспроизведения;

OC (Object Carousel) - Карусель Объектов;

OS (Operating System) - операционная система, ОС;

OSD (On Screen Display) - экранная индикация;

PCR (Program Clock Reference) - ссылка на программные часы;

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

PFR0 (Portable Font Resource version 0) - переносимый ресурс шрифта, версия 0;

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

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

PNG (Portable Network Graphics) - переносимая сетевая графика, формат файлов для растровых графических изображений;

PS (Program Stream) - программный поток данных;

PSI (Program Specific Information) - программно-зависимая информация;

PSTN (Public Switched Telephone Network) - телефонная сеть общего пользования; ТФОП;

PVC (Permanent Virtual Circuit) - постоянный виртуальный канал;

RGB (Red, Green, Blue) - модель цвета, основанная на аддитивном смешивании цветов;

RFC (Request for Comments) - предложения для обсуждения, серия нормативных документов, стандартизирующих протоколы Интернет;

RPC (Remote Procedure Call) - вызов удаленных процедур;

RST (Running Status Table) - таблица состояния событий;

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

SDL (Specification and Description Language) - язык спецификаций и описаний, использующий графическое исполнение описания поведения системы. Применение SDL определено Рекомендацией ITU-T [4];

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

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

SMATV (Satellite Master Antenna TV) - спутниковое телевидение с коллективной телевизионной антенной;

sRGB (specific RGB) - стандартное пространство RGB;

SRM (Session and Resource Manager) - менеджер сеансов и ресурсов; МСР;

STC (System Time Clock) - системный таймер;

SVC (Switched Virtual Circuit) - коммутируемый виртуальный канал;

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

TCP/IP - стек протоколов сетевого и транспортного уровня;

TDT (Time and Date Table) - таблица времени и даты;

TOT (Time Offset Table) - таблица смещения времени;

TS (Transport Stream) - транспортный поток (цифрового вещательного телевидения); ТП;

UCS (Universal Character Set) - универсальный набор символов;

UCS-2 (Universal Character Set) - универсальный набор символов, раздел стандарта Юникод кодирования символов;

UDP (User Datagram Protocol) - протокол передачи дейтаграмм;

Ul (User Interface) - интерфейс пользователя;

U-N (User-to-Network) - пользователь-сеть; П-С.

UNO-CDR (Universal Networked Object - Common Data Representation) - универсальный объект сетевой структуры - общее представление данных;

UNO-RPC (Universal Networked Object - Remote Procedure Call) - универсальный объект сетевой структуры - вызов удаленных процедур;

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

UTC (Universal Time Coordinated) - всемирное координированное время;

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

U-U (User-to-User) - пользователь-пользователь, П-П;

World Wide Web - глобальная распределенная система гипермедиа, размещенная в сети Интернет;

Xlet - интерфейс, который используется для управления жизненным циклом приложения DVB-J;

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

YCrCb - полный цифровой компонентный видеосигнал.

4 Классы домашней мультимедийной платформы

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

- класс 1.0 - обеспечивается поддержка вещательных приложений и передачи данных через сети с IP-протоколом;

- класс 1.1 - дополнительно к возможностям класса 1.0 обеспечивается обработка приложений с сохранением контента на устройстве клиента, обработка приложения через каналы с IP-протоколом, поддержка смарт-карт, поддержка ТВВЧ, поддержка "видео по запросу", поддержка экранной графики высокого разрешения, поддержка стандарта DVB-HTML (рекомендательно);

- класс 1.2 - дополнительно к классу 1.1 обеспечивается обработка приложений профиля DVB-IPTV. Дополнительно определены требования к MHP для доставки "видео по запросу" с помощью протокола RTSP, а также требования к методам инкапсуляции видео- и аудиоформатов в MPEG-2 TS. Для MHP класса 1.2 устанавливаются условия применения протоколов IGMP и UDP для доставки данных для MHP-приложений.

В каждом из классов 1.0, 1.1, 1.2 допускается применение двух базовых профилей:

- Enhanced Broadcast Profile (расширенный профиль вещания) - вся информация поступает от провайдера цифрового телевизионного вещания;

- Interactive Broadcast Profile (интерактивный профиль вещания) - предполагает наличие обратного канала через IP-подключение, что дает возможность подключаться к удаленным серверам.

5 Основные параметры домашней мультимедийной платформы

5.1 Базовая архитектура домашней мультимедийной платформы

5.1.1 Базовая архитектура MHP характеризуется:

- контекстом применения MHP;

- собственно архитектурой MHP;

- интерфейсами MHP;

- возможностью использования плагинов.

5.1.2 Контекст применения MHP включает в себя следующие условия:

- программное обеспечение MHP имеет доступ к потокам и данным;

- MHP может сохранять часть принятых данных;

- MHP может направить потоки и данные за пределы MHP на внешний приемник данных или в хранилище данных;

- MHP принимает данные от устройств ввода данных абонента (телезрителя) и выводит результаты обработки данных для представления абоненту (телезрителю) на экран монитора или на другие выходы;

- ресурсы MHP, доступные приложению, могут содержаться в совокупности различных физических объектов;

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

5.1.3 Структура базовой архитектуры платформы MHP показана на рисунке 1. Она иллюстрирует организацию элементов аппаратных средств и программного обеспечения платформы MHP и включает в себя следующие основные уровни:

- ресурсы;

- системное программное обеспечение;

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

Ресурсы включают в себя аппаратные средства и программное обеспечение этих средств. Примерами ресурса являются: декодеры стандарта MPEG, процессор, устройства памяти, устройства ввода-вывода, графическая подсистема. Требования к группированию ресурсов в настоящем стандарте не предъявляются. Доступность приложений к ресурсам всех аппаратных средств должна быть прозрачной.

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

Допускается наличие в составе MHP более одного аппаратного объекта.

5.1.4 Системное программное обеспечение формирует для приложений абстрактное представление ресурсов. В состав системного программного обеспечения входят:

- программные интерфейсы приложения;

- транспортные протоколы;

- виртуальная машина Java;

- администратор приложений.

Администратор приложений управляет приложениями на интервале жизненного цикла всех приложений.

5.1.5 Совокупность приложений (Приложение 1 - Приложение N) является реализациями программного обеспечения, которое обслуживает один или несколько взаимодействующих аппаратных объектов.

Рисунок 1 - Структура базовой архитектуры платформы MHP

5.2 Интерфейсы между приложениями платформы MHP и системой MHP

5.2.1 Интерфейсы между приложениями платформы MHP и системой MHP обеспечивают доступ приложений к ресурсам приемника, включающим в себя базы данных, декодеры медиа потоков, декодеры статического контента и доступ к каналам связи. Состав интерфейсов между приложениями MHP и системой MHP показан на рисунке 2. Настоящий стандарт определяет параметры интерфейсов, расположенных непосредственно на границе между приложением и остальной частью системы. Вся остальная часть схемы зависит от реализации MHP и показана только с целью информирования.

5.2.2 Плагины представляют собой сменные программные модули (наборы функциональных возможностей), которые могут вводиться в универсальную платформу MHP для поддержки интерактивных систем и форматов контента конкретным терминалом платформы MHP с привязкой к платформе этого терминала.

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

Допускается применение плагинов двух типов:

- интероперабельные плагины;

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

Требования к параметрам внутренней структуры плагинов стандарт не устанавливает.

Рисунок 2 - Интерфейсы между приложениями MHP и системой MHP

6 Параметры транспортных протоколов, поддерживаемых платформой MHP

6.1 Параметры транспортных протоколов канала вещания

6.1.1 Протоколы канала вещания относятся к типу протоколов независимых от сети. На рисунке 3 показана структура стека протоколов канала вещания DVB, которые должны быть доступны приложениям MHP. Другие протоколы и соответствующие им API должны рассматриваться как расширения платформы DVB MHP. Требования к ним должны быть в соответствии с ETSI [5] (приложение Н).

Перечень профилей платформ MHP, к которым обеспечивается доступ протоколов вещания, должен быть в соответствии с ETSI [5] (раздел 15, таблица 65).

Перечень и характеристики программных интерфейсов приложений (API), которым обеспечивается доступ к протоколам вещания, должны быть в соответствии с ETSI [5] (раздел 11).

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

6.1.2 Параметры транспортного потока MPEG-2 должны быть в соответствии с ISO/IEC [6] (2.4).

6.1.3 Параметры секций транспортного потока MPEG-2 должны быть в соответствии с ISO/IEC [6] (2.4).

6.1.4 Параметры протокола DSM-CC передачи частных данных должны быть в соответствии с ISO/IEC [7] (9.2).

6.1.5 Параметры протокола DSM-CC Карусель Данных должны быть в соответствии с ISO/IEC [7] (раздел 7).

Рисунок 3 - Структура стека протоколов канала вещания DVB

6.1.6 Требования к протоколу DSM-CC U-U Карусель Объектов должны быть в соответствии с ISO/IEC [7] (раздел 11) с ограничениями и расширениями, определенными стандартами ETSI [8] (раздел 11), ETSI [9] (4.7), ETSI [5] (приложение В). Должны учитываться следующие особенности обработки протокола DSM-CC U-U Карусель Объектов.

6.1.6.1 Файлы DVB-J для каждого класса Java должны передаваться байт-кодом Java как байты контента BIOP:: FileMessage по правилам интерпретации и исполнения байт-кода Java виртуальной машиной Java в соответствии со стандартом ETSI [5] (6.2.5.1).

6.1.6.2 Документы, содержащие приложения DVB-HTML, должны транспортироваться байтами контента BIOP:: FileMessage, соответствующими содержанию документов (BIOP:: FileMessage не включает HTTP-заголовки).

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

- долговременной потери обмена данными;

- временного разъединения обмена данными.

Детализированные правила работы платформы MHP при потере режима Карусели должны быть в соответствии со стандартом ETSI [5] (6.2.5.3).

6.1.7 При мультипротокольной инкапсуляции должен использоваться протокол частных данных DSM-CC и должна обеспечиваться поддержка протокола IP. Требования к мультипротокольной инкапсуляции должны быть в соответствии со стандартом ETSI [8] (раздел 7).

6.1.8 Требования к протоколу IP должны быть в соответствии со стандартом IETF RFC [10] (разделы 2, 3).

6.1.9 Требования к протоколу UDP должны быть в соответствии со стандартом IETF RFC [11].

6.1.10 Передача информации о службах (SI) должна выполняться в соответствии со стандартом ETSI [12] (разделы 4-7) и стандартом ETSI [13].

6.1.11 Сигнализация о доступности и расположении потоков IP/MAC в сетях DVB, определяемая таблицей INT, должна выполняться в соответствии со стандартом ETSI [8] (8.4).

6.2 Параметры транспортных протоколов интерактивных каналов

6.2.1 Протоколы интерактивных каналов относятся к типу независимых от сети. Протоколы интерактивных каналов, доступных приложениям MHP, должны соответствовать перечню профилей MHP по стандарту ETSI [5] (приложение 15, таблица 65). Структура стека протоколов показана на рисунке 4.

Состав и характеристики программных интерфейсов приложения (API), обеспечивающих эти протоколы, должны быть в соответствии с ETSI [5] (раздел 11).

Рисунок 4 - Структура стека протоколов интерактивного канала

6.2.2 MHP должна поддерживать протоколы, зависимые от сети. Состав протоколов, зависимых от сети, и требования к их параметрам должны быть следующими:

- для распределительных систем кабельного телевидения в соответствии со стандартом ETSI [14] (4.1; 5.2-5.5);

- для интерактивных каналов ТФОП и ЦСИС в соответствии со стандартом ETSI [15] (разделы 5, 6);

- для интерактивных каналов DECT в соответствии со стандартом ETSI EN [16] (разделы 4, 5);

- для интерактивных каналов GSM в соответствии со стандартом ETSI EN [17] (разделы 4, 5);

- для интерактивных каналов системы LMDS в соответствии со стандартом ETSI EN [18] (разделы 4-6);

- для интерактивных каналов распределительной системы SMATV в соответствии со стандартом ETSI TR [19] (разделы 4-6);

- для интерактивных каналов спутниковых распределительных систем в соответствии со стандартами ETSI EN [20] (разделы 4-9), [21].

Параметры протоколов "точка-точка" для интерактивных каналов должны быть:

- протокола IPCP - в соответствии со стандартом IETF RFC [22] (разделы 2-4);

- протокола "точка-точка" РРР - в соответствии со стандартом IETF RFC [23] (разделы 2-6);

- протокола многоканального режима Multilink РРР - в соответствии со стандартом IETF RFC [24] (разделы 2-4);

- дополнительные параметры конфигурации протокола IPCP, обеспечивающих поддержку доменных имен, предоставляемых сервером DNS, должны быть в соответствии со стандартом IETF [25] (раздел 1).

6.2.3 Параметры Интернет-протокола должны быть в соответствии со стандартом IETF RFC [10] (разделы 2, 3).

6.2.4 Параметры протокола управления передачей (TCP) должны быть в соответствии со стандартом IETF [26] (разделы 2, 3).

6.2.5 Вызов удаленных процедур (UNO-RPC) должен выполняться при использовании протокола IIОР. Параметры протокола UNO-RPC должны быть в соответствии с CORBA/IIOP [27].

6.2.6 Параметры протокола UNO-CDR должны быть в соответствии с CORBA/IIOP [27].

6.2.7 Параметры протокола DSM-CC U-U должны быть в соответствии с ГОСТ Р 53528 и ISO/IEC [7]. Ограничения требований и расширения требований к протоколу DSM-CC U-U должны быть в соответствии с ETSI [8] (раздел 11), ETSI [9] (4.7).

6.2.8 Параметры протокола HTTP, версия 1.1, должны быть в соответствии со стандартом IETF RFC [28].

6.2.9 Протоколы специфических служб используются службой вещания данных и представляют механизм регистрации новых протоколов вещания. Параметры протокола специфических служб должны быть в соответствии с ETSI [9] (4.7).

6.2.10 Параметры протокола передачи дейтаграмм UDP должны быть в соответствии с IETF [11].

6.2.11 Терминалы MHP должны обеспечивать преобразование доменных имен DNS в IP-адреса в соответствии с требованиями стандартов IETF [29], IETF [30] и уточнениями в соответствии со стандартами IETF [31], IETF [32].

7 Параметры форматов контента, поддерживаемых платформой MHP

7.1 Параметры статических форматов контента

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

7.1.1.1 Один пиксель (элемент) изображения должен соответствовать одному графическому пикселю (элементу) в текущей графической конфигурации.

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

Ограничения кодирования цвета должны быть в соответствии с 7.5 настоящего стандарта.

7.1.1.2 В соответствии с ETSI [5] (7.1.1.2) MHP должна использовать формат файла JPEG с кодированием, использующим последовательный режим DCT или прогрессивный режим, основанный на DCT в соответствии с ISO/IEC [33]. Формат обмена файлами должен быть JFIF [34].

7.1.1.3 MHP должна поддерживать формат файлов для растровых графических изображений PNG. Терминалы MHP должны поддерживать типы цвета PNG, определенные в ETSI [5] (таблица 66). Ограничения параметров воспроизведения цвета и форматов PNG должны быть в соответствии с ETSI [5] (15.1).

7.1.1.4 MHP должна поддерживать формат обмена графическими изображениями GIF, версия 89а в соответствии с ETSI [5] (15.1).

7.1.2 MHP должна поддерживать обработку l-кадров MPEG-2, которые определяются в соответствии с ISO/IEC [1] (6.1.1.11). Параметры полезной нагрузки файлов, представляющих I-кадры MPEG-2, должны быть в соответствии с ETSI [5] (7.1.2). Структура полезной нагрузки файла, предоставляющего l-кадры MPEG-2, должна быть в соответствии с представленным ниже перечнем:

sequence_header();

sequence_extension();

extension_and_user_data(0);

дополнительно group_of_pictures_header() и extension_and_user_data(1);

picture_header (picture_coding_type = "I frame");

picture_coding_extension (picture_structure = "frame picture");

extension_and_user_data(2);

picture_data();

sequence_end_code().

7.1.3 В режиме обработки медиа, имеющего формат "видео "капли"", платформой MHP обрабатываются только l-кадры и Р-кадры MPEG-2. Каждый блок должен содержать один кадр и определенное число синтаксических элементов (в соответствии с ISO/IEC [1]), таких как sequence_header () или group_of_picture_header ().

MHP должна поддерживать обработку блоков байтов контента, поступающих на декодер MHP, синтаксис которых соответствует ETSI [5] (7.1.3).

MHP должна поддерживать ограничения, накладываемые на Р-кадры, в соответствии с ISO/IEC [1]) и ETSI [5] (7.1.3).

7.1.4 Платформа MHP должна выполнять обработку аудиоклипов в формате MPEG-1 audio (Level I, II). Каждый файл аудиоконтента должен передаваться файлом двоичных данных элементарного потока. Каждый файл аудиоконтента должен содержать целое число аудиомодулей доступа. Первый байт каждого файла аудиоконтента должен быть первым байтом аудиомодуля доступа.

Параметры формата MPEG-1 audio (Level I, II) должны быть в соответствии с Рекомендацией ISO/IEC [35] (раздел 2) с ограничениями в соответствии со стандартом ETSI TR [36] (раздел 6).

7.1.5 Платформа MHP должна поддерживать правила кодирования текста в соответствии с требованиями к модифицированному UTF-8 языку программирования Java спецификации Java Language Spec в соответствии с ETSI [5] (7.1.5).

7.1.6 MHP должна обеспечивать прием и вывод на экран терминала латинских символов, входящих в состав базового набора в соответствии со стандартом ETSI [5] (приложение Е).

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

7.2 Параметры форматов потоков вещания

7.2.1 MHP должна поддерживать обработку аудиоформатов MPEG, передаваемых в потоках вещания, в соответствии с требованиями стандарта ETSI [36] (раздел 6).

7.2.2 MHP должна поддерживать обработку видеоформатов MPEG с частотой кадров 25 Гц и 50 Гц, передаваемых в потоках вещания, в соответствии с требованиями стандарта ETSI [36] (раздел 5).

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

- форматов субтитров DVB;

- форматов телетекста.

MHP должна обеспечивать выполнение требований к установкам языка и воспроизведению субтитров DVB и телетекста, передаваемых в потоках вещания, в соответствии с ETSI [5] (13.5). При выводе на экран монитора субтитры DVB должны иметь приоритет перед телетекстом.

Управление приложением и обнаружение субтитров DVB или субтитров телетекста должно выполняться с помощью библиотеки JMF в соответствии с ETSI [5] (7.2.3).

MHP должна поддерживать обработку субтитров в соответствии с ETSI [5] (7.2.3.1).

MHP должна поддерживать обработку телетекста как альтернативного формата контента, предназначенного только для формирования субтитров. Параметры передачи телетекста должны быть в соответствии со стандартом ETSI [37]. Формат данных передачи телетекста должен быть в соответствии со стандартом ETSI [38] при уровне представления не более 1.5. Сигнализация страницы подзаголовка телетекста должна выполняться через дескриптор телетекста в соответствии с ETSI [12] (6.2.42).

7.3 Параметры резидентных шрифтов

MHP должна поддерживать обработку резидентных шрифтов и отображение текста в соответствии с требованиями стандарта ETSI [5] (раздел 4, приложение G, G.4, приложение D).

7.4 Параметры загружаемых шрифтов

MHP должна поддерживать обработку загружаемых шрифтов и отображение текста в соответствии с требованиями стандарта ETSI [5] (7.4).

Формат кода для шрифтов должен быть PFR, версия 0 в соответствии со спецификацией DAVIC [39]. Значение charCode в PFR charRecord должно быть в соответствии с ISO [40] для глифа, закодированного с использованием UCS-2. Для шрифтов в формате PFR имя шрифта должно быть fontlD-полем в файле шрифта. Файл PFR каждого шрифта может содержать вспомогательные данные в физической записи шрифта. Эти вспомогательные данные должны использовать синтаксис в соответствии со стандартом ETSI [5] (7.4, таблица 1).

7.5 Параметры представления цвета платформой MHP

7.5.1 Рекомендуется обеспечивать поддержку платформой MHP всех переданных изображений, находящихся в пределах гаммы цветового пространства sRGB, соответствующего требованиям стандарта ETSI [5] (7.5.1).

7.5.2 Формирование изображений платформой MHP рекомендуется выполнять в пределах палитры, находящейся в цветовом пространстве sRGB. Допускается формирование изображений платформой MHP (по выбору производителя) выполнять в цифровых пространствах, отличных от sRGB. Допускается транскодирование платформой MHP изображений, находящихся в цветовом пространстве sRGB, в другое цветовое пространство, если цветовая гамма этого пространства будет находиться в цветовом пространстве sRGB (изображения JPEG, совместимые с форматом JFIF, должны передаваться в цветовом пространстве в соответствии с ETSI [5] (7.5.2).

7.5.3 MHP должна поддерживать преобразования цветового пространства sRGB в цветовые пространства, предусмотренные технологией MPEG-2 (в том числе в цветовые пространства, соответствующие ITU-R [41]). MHP должна поддерживать обратные преобразования цветовых пространств, предусмотренных технологией MPEG-2 (в том числе в соответствии с ITU-R [41]), в цветовые пространства sRGB.

7.5.4 Основные параметры эталонного режима работы дисплея платформы MHP и условий визуального отображения для цветового пространства sRGB должны быть в соответствии со стандартом ETSI [5] (7.5.2). Полное описание параметров эталонного режима работы дисплея и условий визуализации для цветового пространства sRGB представлено в Рекомендации ITU-R [41].

7.5.5 Платформа MHP должна поддерживать определения колориметрии трехцветных значений sRGB и правила кодирования колориметрии трехцветных значений sRGB в соответствии со стандартом ETSI [5] (7.5.2.2).

7.6 Типы многоцелевых расширений почты Интернета

Совокупность типов многоцелевых расширений почты Интернета определяет пространство имен для поддержки загружаемых в будущем проигрывателей библиотеки Java 2.JMF. Перечень таких типов MIME представлен в таблице 1.

Таблица 1 - Наименования расширений имени файлов библиотеки Java 2.JMF

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

Расширения имени файла для приложений DVB-J должны быть в соответствии со стандартом ETSI [5] (11.3.1.6, таблица 41). Применение расширенных имен файла в соответствии с таблицей 41 ограничено минимально необходимым перечнем типов медиа и поддерживающих их программных интерфейсов приложений DVB-J для расширенного вещательного профиля 1 и для интерактивного профиля 1, обрабатываемых платформой MHP, и представленных в таблице 3 настоящего стандарта.

8 Параметры моделей приложений платформы MHP

8.1 Параметры приложений вещания платформы MHP

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

- выбор службы вещания;

- запуск (старт) приложения;

- остановка приложений.

8.1.2 Основным способом выбора службы вещания платформы MHP должно быть использование возможностей EPG. Последовательность и основное содержание процедур управления жизненным циклом приложения платформы MHP должны быть в соответствии с требованиями стандарта ETSI [5] (9.1.1).

8.1.3 Операция запуска (старта) приложения должна выполняться платформой MHP после окончания операции выбора службы вещания в соответствии со стандартом ETSI [5] (9.1.2). Режим автоматического запуска приложений должен активизироваться в соответствии со стандартом ETSI [5] (10.6). Параметры механизма управления жизненным циклом приложений MHP установлены в 9.5 настоящего стандарта.

8.1.4 MHP должна обеспечивать поддержку одновременного представления и выполнения нескольких приложений в границах, предусмотренных службой, в соответствии со стандартом ETSI [5] (9.1.3).

8.1.5 MHP должна поддерживать остановку приложений самими приложениями (при использовании API этих приложений) и при ручном управлении от терминала MHP. Примеры ситуаций, в которых допускается остановка приложений, приведены ниже:

- выбор новой службы для замены службы, выбранной ранее;

- остановка одного приложения другим приложением по решению администратора приложений из соображений безопасности;

- по решению вещателя об остановке приложения;

- из-за дефицита ресурсов терминала MHP.

Детализированные характеристики этих ситуаций должны быть в соответствии со стандартом ETSI [5] (9.1.4).

8.1.6 MHP должна поддерживать персистентность (сохраняемость) приложений за границами, предусмотренными службой, в соответствии со стандартом ETSI [5] (9.1.5). Условия сохраняемости приложений в случае потери режима Карусели должны быть в соответствии с 6.1.6.3 настоящего стандарта.

8.1.7 MHP должна поддерживать управление автоматическим запуском приложений вещания в условиях, определенных стандартом ETSI [5] (9.1.2, 9.1.6) и 8.1.3 настоящего стандарта.

8.1.8 MHP не должна поддерживать попытки настройки пользователем терминала MHP на транспортные потоки методами, которые не используют метод выбора службы вещания MHP.

8.1.9 MHP должна поддерживать возможность выбора службы при активизации приложений DVB-J использованием API выбора службы. Программный интерфейс приложений выбора службы включает класс ServiceContext, что дает доступ к контекстам, в которых могут быть представлены службы. Детализированное описание процедур выбора службы должно быть в соответствии со стандартом ETSI [5] (9.1.8).

8.2 Параметры модели приложений DVB-J

8.2.1 MHP должна поддерживать запуск приложений DVB-J любым из способов, установленных для приложений MHP стандартом ETSI [5] (9.2.1). Листинг API и процедуры активизации API должны быть в соответствии со стандартом ETSI [5] (приложение S).

8.2.2 MHP должна поддерживать остановку приложений DVB-J по любой из причин, перечисленных для приложений вещания MHP по 8.1.5 настоящего стандарта. Детализация процедур остановки должна быть в соответствии со стандартом ETSI [5] (9.2.2).

8.2.3 Состояния жизненного цикла приложений DVB-J и параметры состояний платформы MHP должны поддерживаться виртуальной машиной Xlet. Виртуальная машина Xlet обеспечивает функционирование программного интерфейса Xlet с учетом следующих условий:

- допускается короткая задержка запуска программного интерфейса Xlet;

- допускается возможность возникновения условий, в которых программный интерфейс приложений Xlet не предоставляет свою услугу;

- обеспечивается возможность уничтожения программного интерфейса Xlet в любое время.

Модель состояний виртуальной машиной Xlet представлена на рисунке 5 и включает в себя следующие состояния приложения DVB-J:

- загруженное (копия приложения DVB-J была загружена и не была инициализирована);

- приостановленное (пауза) (приостановленная копия приложения DVB-J должна минимизировать использование ресурсов, если необходимо максимизировать вероятность выживания копии приложения);

- активное (экземпляр приложения DVB-J нормально функционирует и предоставляет услугу);

- уничтоженное (копия приложения DVB-J освободила все свои ресурсы и завершилась).

Рисунок 5 - Модель состояний виртуальной машиной Xlet

Детализированные параметры допустимых состояний жизненного цикла экземпляров приложения DVB-J платформы MHP должны быть в соответствии со стандартом ETSI [5] (9.2.3.2, таблица 6).

Параметры и состояния виртуальной машины Xlet для API DVB-J и методы, которыми администратор приложений может влиять на состояние жизненного цикла, должны быть в соответствии со стандартом ETSI [5] (9.2.3.1).

Типичная последовательность выполнения приложения DVB-J платформы MHP представлена в стандарте ETSI [5] (9.2.3, таблица 7).

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

Параметры программного интерфейса приложений Xlet должны быть в соответствии со стандартом ETSI [5] (11.7.1) и 10.6.1 настоящего стандарта.

Семантика изменения состояния Xlet должна быть в соответствии со стандартом ETSI [5] (9.2.4.1).

Состояния Xlet, в которых допускаются вызовы управления состоянием, должны быть в соответствии с таблицей 2.

Таблица 2 - Состояния Xlet для допустимых вызовов управления состоянием

8.2.5 Платформа DVB-J в составе платформы MHP должна обеспечивать одновременное выполнение нескольких приложений DVB-J. При этом должно обеспечиваться совместное использование ресурсов MHP несколькими приложениями DVB-J. Характеристики платформы DVB-J в режиме выполнения нескольких приложений должны быть в соответствии со стандартом ETSI [5] (9.2.5).

Характеристики платформы DVB-J должны быть в соответствии с разделом 10 настоящего стандарта.

8.3 Параметры модели приложений DVB-HTML

8.3.1 Приложение DVB-HTML в составе платформы MHP должно включать в свой состав комплект документов (из семейства документов DVB-HTML), элементы и форматы контента, определенные настоящим стандартом. Размер (экстент) комплекта документов определяется границами приложения DVB-HTML в соответствии со стандартом ETSI [5] (9.3.1.4).

MHPдолжна обеспечивать поддержку взаимодействия агента пользователя, актора и приложения DVB-HTML.

Допускается в составе терминала платформы MHP реализация механизма доступа к ресурсам, находящимся вне границы приложения (реализация этого механизма не должна входить в контекст исходного приложения DVB-HTML).

Комплект документов, составляющих приложение DVB-HTML платформы MHP, определяется регулярным выражением на языке локатора. Как правило, локатор состоит из текстовой строки в форме, определенной в соответствии с IETF [2], и действует как связующее звено, скрепляющее приложение: scheme://host/dir1/dirn/file#subref.

Определение регулярного выражения должно быть в соответствии со стандартом ETSI [5] (9.3.1.4).

Форма регулярного выражения, используемого для определения границы приложения, должна быть в соответствии со стандартом IEEE [42] (2.8.4).

Синтаксис регулярного выражения должен быть в соответствии со стандартом ETSI [5] (9.3.1.4.1).

8.3.2 Модель DVB-HTML MHP должна предусматривать (после поступления заявки на запуск приложения DVB-HTML) поиск агента пользователя и поиск актора.

MHP должна обеспечивать поддержку запуска приложений DVB HTML на интервале их жизненного цикла одним из следующих способов:

- по требованию администратора приложений;

- по условиям автоматического запуска;

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

Актор DVB-HTML может находиться в одном из следующих состояний приложения DVB-HTML:

- загрузка;

- активное;

- приостановленное;

- уничтоженное (Destroyed);

- уничтоженное (Killed).

Переходы актора DVB-HTML из одного состояния в другое состояние могут выполняться при появлении следующих событий:

- триггера - запроса на переход в новое состояние;

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

- при изменении данных AIT.

Требования к параметрам сигнализации в приложениях DVB-HTML должны быть в соответствии с разделом 9 настоящего стандарта.

Управление жизненным циклом приложения DVB-HTML должно выполняться в соответствии с параметрами сигнализации для приложений DVB-HTML по стандарту ETSI [5] (9.3.2.3, 10.6).

Модель состояний приложения DVB-HTML соответствует состояниям виртуальной машины. В каждом из состояний должно обеспечиваться:

- в состоянии "загрузка" - доступ к ресурсам контента и ресурсам сигнализации. Контент зрителю не представляется;

- в состоянии "активное" - полный доступ актора к контенту действующего документа и всем ресурсам MHP в соответствии с правилами управления ресурсом и условиями обеспечения безопасности;

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

- в состоянии "уничтоженное" (Destroyed) - потеря ресурса контента и сохранение возможности для актора запуска приложения DVB-HTML;

- в состоянии "уничтоженное" (Killed) - потеря всех ресурсов; переход в состояние "уничтоженное" (Killed) инициирует сброс актора и возвращение платформе MHP необходимых ресурсов.

Детализированные характеристики состояний конечного автомата должны быть в соответствии со стандартом ETSI [5] (9.3.3).

Требования к транспортировке набора документов, определяющих приложение DVB-HTML, приведены в стандарте ETSI [5] (6.2.5.2).

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

Детализированные правила обработки конфликтов между приложениями MHP должны быть в соответствии со стандартом ETSI [5] (9.4).

9 Параметры сигнализации приложения платформы MHP

9.1 Общие параметры сигнализации приложения платформы MHP

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

- идентификацию приемником платформы MHP приложений, связанных со службой, и определение местоположения этих приложений;

- управление жизненными циклами приложений в соответствии с данными, передаваемыми в потоках вещания;

- идентификацию приемником платформы MHP источников данных вещания по требованию приложений службы.

Сигнализация для любых приложений платформы MHP должна обеспечивать формирование:

- PMT с дескриптором сигнализации приложения (с целью идентификации компонента службы, переносимого в таблице AIT);

- AIT со следующей информацией в цикле общего дескриптора (common_descriptor_loop) таблицы AIT: дескриптор транспортного протокола [все дескрипторы приложений должны быть (по крайней мере) в области действия одного дескриптора транспортного протокола];

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

9.1.2 Для приложений DVB-J платформа MHP должна обеспечивать дополнительно сигнализацию: в таблице AIT в цикле дескриптора информации приложения должны передаваться:

- дескриптор приложения DVB-J;

- дескриптор местоположения приложения DVB-J.

9.1.3 Для приложений DVB-HTML платформа MHP должна обеспечивать дополнительно сигнализацию: в таблице AIT в цикле дескриптора информации приложения должны передаваться:

- дескриптор приложения DVB-HTML;

- дескриптор местоположения приложения DVB-HTML.

9.1.4 Для приложений, передаваемых через Карусель Объектов, платформа MHP должна обеспечивать передачу дескриптора транспортного протокола или в цикле общего дескриптора или в цикле дескриптора приложения. Параметры дескриптора транспортного протокола должны быть в соответствии со стандартом ETSI [5] (10.8.1.1) и 9.7.1 настоящего стандарта.

9.1.5 Для приложений, передаваемых через каналы с протоколом IP, платформа MHP должна обеспечивать дополнительно сигнализацию в таблице AIT в общем цикле дескриптора:

- дескриптор IP сигнализации или в общем цикле дескриптора, или в цикле дескриптора приложений в соответствии со стандартом ETSI [5] (10.8.2) и 9.7.1 настоящего стандарта;

- дескриптор транспортного протокола в общем цикле дескриптора или в цикле дескриптора приложений. Селекторные байты, содержащие IP специфическую информацию, должны быть в соответствии со стандартом ETSI [5] (10.8.1, таблица 29).

9.1.6 Платформа MHP должна обеспечивать возможность расширения сигнализации приложений. Расширение должно быть предусмотрено:

- для дополнительных транспортных протоколов с расширением согласно стандарту ETSI [5] (10.8.1, таблица 27);

- для дополнительных дескрипторов IP сигнализации в формах, предусмотренных стандартом ETSI [5] (10.8.2);

- для дополнительных приложений:

- для дополнительных дескрипторов DVB-J в формах, предусмотренных стандартом ETSI [5] (10.9);

- для дополнительных кодов управления жизненным циклом приложения - в границах, предусмотренных стандартом ETSI [5] (10.6);

- для регистрации значений констант в форме, предусмотренной стандартом ETSI [5] (10.11, таблица 39).

9.1.7 MHP должна выполнять обработку таблиц SDT в соответствии со стандартом ETSI [5] (10.12).

9.2 Параметры программно-зависимой информации

Цикл (внутренний) элементарного потока PMT для службы DVB должен поддерживать потоки ссылок не менее одного приложения MHP с целью:

- локации потока, транспортирующего AIT;

- локации потоков, транспортирующих коды и данные приложений.

Информация элементарного потока PMT описывает элементарный поток, переносящий AIT-сигнализации приложений, и имеет следующие характеристики:

- поле stream_type имеет значение 0x05 в соответствии с ISO/IEC [6];

- дескриптор сигнализации приложений в соответствии с 9.6.1 настоящего стандарта.

Количество элементарных потоков сигнализации приложений может быть больше одного.

Минимальная сигнализация, связанная с компонентами вещания данных, обеспечивается значением поля stream_type в соответствии с ETSI EN [8]. Детализированные данные протокола вещания представлены в AIT в соответствии с 10.2 настоящего стандарта. Обработка информации, содержащейся в PMT и AIT, должна выполняться в соответствии со стандартом ETSI EN [5] (10.2.2).

9.3 Параметры таблицы информации приложений

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

Обработка AIT, содержащих ошибки данных, должна выполняться в соответствии со стандартом ETSI [5] (10.4.1).

Терминал MHP должен контролировать в PMT изменения количества представленных AIT элементарных потоков только тех приложений, которые он может декодировать. Изменения должны фиксироваться в течении 1 с. Частота повторения субтаблиц должна быть не менее 10 с. При условии, что AIT поддерживает не менее трех элементарных потоков, интервал времени между обновлением AIT может составлять 30 с.

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

Опционально поле AIT_version_number, переносящее дескриптор сигнализации приложения, обеспечивает оптимизацию нагрузки приемника, позволяющую получать AIT после появления изменения версии AIT (в соответствии с 9.6 настоящего стандарта).

Все секции, имеющие AIT с одинаковыми table_id и одинаковые значения application_type, являются элементами одной субтаблицы.

Синтаксис AIT должен быть в соответствии со стандартом ETSI [5] (таблица 9).

AIT содержит два цикла дескриптора, описывающих приложения в данной AIT:

- цикл дескриптора "общий", содержащий дескрипторы, которые применяются ко всем приложениям в данной AIT;

- цикл дескриптора "приложение", содержащий дескрипторы, которые применяются к конкретному приложению.

Частные дескрипторы могут включаться в AIT при условии их соответствия требованиям стандарта ETSI EN [12] и условиям стандарта ETSI [5] (10.4.7).

Текстовые строки в AIT должны кодироваться при использовании формата UTF-8 в соответствии с 7.1.5, 13.5 настоящего стандарта.

9.4 Параметры идентификации приложений

MHP должна выполнять идентификацию приложений использованием идентификатора application_identifier, передаваемого в таблице AIT. Идентификатор application_identifier включает в себя поле organization_id (32 бита), идентифицирующее организацию, ответственную за вещание приложения, и поле application_id (16 бит), уникально идентифицирующее приложение. Формирование значений organization_id должно быть в соответствии со стандартом ETSI TR [43]. Классификация полей application_id должна быть в соответствии со стандартом ETSI [5] (10.5.1).

MHP должна поддерживать эффекты жизненного цикла и правила выполнения аутентификации приложений в соответствии со стандартом ETSI [5] (10.5.2, 10.5.3).

9.5 Параметры механизма управления жизненным циклом приложений MHP

9.5.1 MHP должна поддерживать механизм сигнализации вещания, обеспечивающий вещателям возможность управления жизненным циклом приложений стандартных типов. Параметры приложений вещания нормируются в 8.1 настоящего стандарта и в стандарте ETSI [5] (9.1). Домен приложения определен как совокупность служб, перечисленных во внешнем или внутреннем цикле AIT. Службы, перечисленные иными способами, находятся за пределами домена приложения.

9.5.2 Динамическое управление жизненным циклом приложения платформы MHP должно обеспечиваться передачей в AIT кода управления application_control_code. Этим кодом вещатель сигнализирует приемнику о необходимых операциях, которые должны выполняться с учетом фазы его жизненного цикла. Если приемник получает код, который он не может опознать, то выполнение приложения должно продолжаться. В том случае, когда изменение в кодах управления вызывает изменение состояния рабочего приложения MHP, должно генерироваться сообщение AppStateChangeEvent для всех приложений DVB-J, которые зарегистрировались для получения событий затронутого приложения.

Коды управления жизненным циклом приложения DVB-J платформы MHP должны быть в соответствии с кодами, представленными в стандарте ETSI [5] (10.6.2.1, таблица 13). Параметры и состояния жизненного цикла приложений DVB-J платформы MHP должны быть в соответствии с 8.2.4 настоящего стандарта и стандартом ETSI [5] (9.2.3).

Коды управления жизненным циклом приложения DVB-HTML платформы MHP должны быть в соответствии с представленными в стандарте ETSI [5] (10.6.2.2, таблица 14). Параметры и состояния жизненного цикла приложений DVB-HTML платформы MHP должны быть в соответствии с 8.3.2 настоящего стандарта и стандартом ETSI [5] (9.3.2).

9.6 Параметры универсальных дескрипторов сигнализации приложений платформы MHP

9.6.1 Дескриптор сигнализации приложений предназначен для использования в цикле элементарного потока PMT, в этом случае значение поля stream_type равно 0x05.

В состав универсальных дескрипторов сигнализации приложений платформы MHP входят:

- дескрипторы идентификаторов вещания данных;

- универсальные дескрипторы вещания данных;

- дескрипторы приложения;

- дескрипторы информации для пользователя;

- дескрипторы авторизации внешних приложений.

Все дескрипторы сигнализации приложений платформы MHP должны переноситься в таблице PMT элементарного потока. Параметры таблицы PMT должны быть в соответствии с ГОСТ Р 53527-2009 (приложение А.3). Значение поля stream_type, равное 0x05, индицирует передачу в элементарном потоке таблицы AIT (9.4). Синтаксис дескрипторов сигнализации приложений должен быть в соответствии со стандартом ETSI [5] (10.7.1, таблица 15).

9.6.2 Дескрипторы идентификаторов вещания данных переносят информацию о элементарном потоке в PMT и должны идентифицировать:

- транспортный формат вещания данных, "основной компонент" которых находится в этом элементарном потоке;

- набор типов приложений вещания данных для автоматического запуска (старта). Детализация условий применения должна быть в соответствии со стандартом ETSI [5] (10.7.2.).

Универсальный дескриптор вещания данных должен быть в соответствии со стандартом ETSI [5] (10.7.2.1, таблица 16).

Дескриптор идентификатора вещания данных платформы MHP применяется во всех случаях, когда вещание данных выполняется в соответствии с константами, установленными в стандарте ETSI [5] (10.11, таблица 39). Применение этого дескриптора обеспечивает расширение возможностей универсального дескриптора вещания данных в соответствии со стандартом ETSI [5] (10.7.2.2). Синтаксис дескрипторов идентификаторов вещания данных MHP должен быть в соответствии со стандартом ETSI [5] (таблица 17).

9.6.3 В каждом цикле "приложение" дескриптора AIT должно находиться не менее одного дескриптора приложения. Параметры дескриптора приложения и синтаксис дескриптора приложения должны быть в соответствии со стандартом ETSI [5] (10.7.3).

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

Дескриптор имени приложения должен позволять отличать одно приложение от другого и должен быть информативным для пользователя. Один экземпляр дескриптора должен быть включен в информацию по применению приложения. Синтаксис этого дескриптора должен быть в соответствии со стандартом ETSI [5] (таблица 20).

Нулевой или первый экземпляр дескриптора иконок приложения должен быть включен в информацию по применению приложения. Формат контента возможных иконок должен быть ограничен PNG в соответствии с 14.1 настоящего стандарта. Семантика дескрипторов иконок приложений должна быть в соответствии со стандартом ETSI [5] (таблица 21). Семантика локаторов иконок должна быть в соответствии со стандартом ETSI [5] (таблица 22). Флаги иконок должны быть в соответствии со стандартом ETSI [5] (таблица 23). Кодирование файлов для файлов иконок должно быть в соответствии со стандартом ETSI [5] (10.7.4.2).

9.6.5 Дескрипторы авторизации внешних приложений (external_application_authorisation_descriptors) могут размещаться в "общем" цикле дескриптора таблицы AIT. Каждый такой дескриптор содержит информацию о внешних приложениях, которые могут работать с приложениями, перечисленными в субтаблице таблицы AIT. Внешняя авторизация применяется к приложениям с идентифицированным полем application_identifier (), которые имеют поле application_type, идентифицированное субтаблицей AIT, где содержится этот дескриптор.

Синтаксис дескрипторов авторизации внешних приложений должен быть в соответствии со стандартом ETSI [5] (таблица 24).

9.7 Параметры дескрипторов транспортного протокола для платформы MHP

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

Дескриптор транспортного протокола может применяться или в цикле дескрипторов "общий" для транспортных протоколов всех приложений, перечисленных в субтаблице, или в цикле дескрипторов "приложение" для дополнительных транспортных протоколов, доступных конкретному приложению. Каждому приложению, описанному в этой секции, должен соответствовать (по крайней мере) один дескриптор транспортного протокола.

В том случае, когда источником транспортного протокола является Карусель Объектов, идентификатор транспортного протокола имеет значение 0x0001, селектор байтов должен быть в соответствии со стандартом ETSI [5] (таблица 28).

В том случае, когда источником транспортного протокола является IP-канал, идентификатор транспортного протокола имеет значение 0x0002, селектор байтов должен быть в соответствии со стандартом ETSI [5] (таблица 29). Эта структура включает компоненты data_broadcast_descriptor, определенные в соответствии с ETSI EN [8] и включающие всю информацию, необходимую для получения приложения и компонент приложения, доставленных протоколами IP, включая детализированные профили (обязательные или опциональные), перечисленные в ETSI [5] (раздел 15, таблица 65).

Дескриптор IP сигнализации идентифицирует организацию, обеспечивающую многоадресные IP-потоки, используемые всеми приложениями (передается в общем цикле AIT) или конкретным приложением (передается в цикле приложения AIT) в соответствии с определениями INT согласно ETSI EN [8]. Этот дескриптор и INT со значением action_type 0х01 обеспечивают соответствие между многоадресным IP, портом и локализацией потока. Синтаксис дескриптора IP представлен в ETSI [5] (таблица 30).

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

Идентификация, предусмотренная в дескрипторе сигнализации IP, позволяет восстановить таблицу нотификации IP-протокола INT с полем action_type, имеющим значение 0x01, и установить соответствие между многоадресным IP, портом и местоположением потока.

Синтаксис идентификатора дескриптора сигнализации IP должен быть в соответствии со стандартом ETSI [5] (таблица 30). Значения идентификатора platform_id определяются в соответствии со стандартом ETSI TR [43].

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

Дескрипторы "0" или "1" упреждающей выборки могут входить в цикл дескрипторов "приложение" таблицы AIT.

Синтаксис дескрипторов упреждающей выборки должен быть в соответствии со стандартом ETSI [5] (таблица 31).

Модули, которые являются частью Карусели Объектов DSM-CC, передаются в сообщении Downloadlnfolndication (DII).

Для выявления всех модулей, которые имеют метку упреждающей выборки в соответствии со стандартом ETSI [5] (10.8.3.2), платформы MHP, реализующие упреждающую выборку, должны обеспечивать поиск всех сообщений DII. Поиск сообщений DII выполняется с помощью дескриптора расположения DII, который перечисляет расположения DII. Платформы MHP должны исследовать сообщения DII на наличие меток в том порядке, в котором они перечислены в дескрипторе DII.

Синтаксис дескрипторов расположения меток DII должен быть в соответствии со стандартом ETSI [5] (таблица 32).

9.8 Специфичные дескрипторы DVB-J платформы MHP

9.8.1 В состав специфичных дескрипторов DVB-J платформы MHP входят: дескриптор приложения DVB-J и дескриптор локации приложения DVB-J.

9.8.2 Дескриптор приложения DVB-J несет информацию о параметрах запуска этого приложения. Один экземпляр дескриптора приложения DVB-J должен содержаться в прикладном цикле дескрипторов AIT для каждого приложения DVB-J. Синтаксис и семантика дескриптора приложения DVB-J должны быть в соответствии со стандартом ETSI [5] (10.9.1, таблица 33).

9.8.3 Дескриптор локации приложения DVB-J содержит информацию о маршруте приложения, что обеспечивает поиск приложения и управление приложением DVB-J. Один экземпляр дескриптора должен содержаться в прикладном цикле дескрипторов AIT для каждого приложения DVB-J. Синтаксис и семантика дескриптора локации приложения DVB-J должны быть в соответствии со стандартом ETSI [5] (10.9.2, таблица 34).

9.9 Дескрипторы приложения DVB-HTML платформы MHP

9.9.1 В состав дескрипторов приложения DVB-HTML входят: дескриптор приложения DVB-HTML, дескриптор локации приложения DVB-HTML, дескриптор границ приложения.

9.9.2 Дескриптор приложения DVB-HTML содержит значения параметров приложения и сигнализации управления, примененные вещателем приложения.

Один экземпляр дескриптора приложения DVB-HTML и дескриптора локации DVB-HTML должен содержаться в прикладном (внутреннем) цикле дескрипторов AIT для каждого приложения DVB-HTML.

Синтаксис и семантика дескриптора приложения DVB-HTML должны быть в соответствии со стандартом ETSI [5] (10.10.1, таблица 35).

9.9.3 Дескриптор локации приложения DVB-HTML. Один экземпляр дескриптора локации приложения DVB-HTML должен содержаться в прикладном (внутреннем) цикле дескрипторов AIT для каждого приложения DVB-HTML. Синтаксис и семантика дескриптора локации приложения DVB-HTML должны быть в соответствии со стандартом ETSI [5] (10.10.2, таблицы 36, 37).

Точка входа приложения определяется путем (маршрутом) "main/index.htm". Этот маршрут сохранен и в строке дескриптора локации initial_path_bytes.

9.9.4 Дескриптор границы приложения DVB-HTML является опциональным, он устанавливается в прикладном (внутреннем) цикле дескрипторов AIT и позволяет создавать регулярное выражение, описывающее элементы данных, которые формируют приложение. Синтаксис и семантика дескриптора границы приложения DVB-HTML должны быть в соответствии со стандартом ETSI [5] (10.10.3, таблица 38).

9.10 Константы дескрипторов

9.10.1 Значения констант дескрипторов должны быть в соответствии со стандартом ETSI [5] (таблица 39). Все дескрипторы, определяемые пользователями, должны соответствовать требованиям к данным частных дескрипторов в соответствии с 9.3 настоящего стандарта.

9.10.2 В соответствии со стандартом ETSI [5] (10.11.1) служба приложений MHP должна использоваться для служб, которые предусматривают не менее одного автоматического запуска приложения MHP, если это приложение является основным компонентом службы.

9.11 Информация о службе

9.11.1 Дескрипторы идентификатора службы могут быть включены в таблицу SDT, содержащую описание службы. Каждый такой дескриптор определяет единственный текстовый идентификатор службы. Синтаксис, семантика и детализированные условия применения дескриптора идентификатора службы должны быть в соответствии со стандартом ETSI [5] (10.12.1, таблица 40).

Синтаксис и семантика текстового идентификатора службы должны быть в соответствии с 13.9.1 настоящего стандарта.

10 Параметры платформы DVB-J

10.1 Параметры виртуальной машины DVB-J

Параметры виртуальной машины DVB-J должны быть в соответствии со спецификацией Java VM.

Виртуальная машина Java должна поддерживать файлы класса Java, номер версии которых находится в диапазоне значений от 45.3 до 45.65535.

10.2 Общие вопросы применения программных интерфейсов приложений DVB-J

10.2.1 Правила использования классов, методов, интерфейсов, конструкторов с учетом спецификаций API приложений DVB-J должны быть в соответствии с ETSI [5] (11.2.1, 11.2.2).

10.2.2 Правила загрузки и разгрузки классов приложений DVB-J должны быть в соответствии с ETSI [5] (11.2.3, 11.2.4).

10.2.3 Прослушивание событий в org.dvb и org.davic в приложениях DVB-J должно выполняться в соответствии с ETSI [5] (11.2.5).

10.2.4 Определения моделей событий программных интерфейсов приложений API DAVIC и API DAVIC & DVB должны быть в соответствии с ETSI [5] (11.2.6, 11.2.7) соответственно.

10.2.5 MHP не должен выполнять настройку, не предусмотренную в API непосредственно.

10.2.6 Управление ресурсом внутреннего приложения медиа MHP должно выполняться в соответствии с ETSI [5] (11.2.9).

10.2.7 Приоритет потока приложений должен быть в соответствии с ETSI [5] (11.2.10).

10.2.8 Кодирование символов в текстовых файлах API приложений DVB-J и текста в SI должно быть в соответствии с ETSI [5] (11.2.11).

10.3 Основные программные интерфейсы приложений DVB-J

10.3.1 MHP должна поддерживать следующие основные программные интерфейсы приложений платформы Java:

- пакет java.lang;

- пакет java.lang.reflect;

- java.util;

- java.util.zip;

- java.io;

- java.net;

- java.beans;

- java.math

в соответствии с требованиями стандарта ETSI [5] (11.3.1) и спецификации программных интерфейсов приложений платформы Java, версия 1.1.

В соответствии со стандартом ETSI [5] (11.8.1.3) MHP должна также поддерживать классы интерфейсов:

- java.io.FilePermission;

- java.io.SerializablePermission;

- java.lang.RuntimePermission;

- java.util.PropertyPermission;

- java.net.SocketPermission;

- java.awt.AWTPermission.

10.3.2 Параметры программных интерфейсов приложений платформы MHP rg.dvb.lang должны быть в соответствии со стандартом ETSI [5] (11.3.2.1 и приложение I).

10.3.3 Параметры программного интерфейса приложений платформы MHP org.dvb.event должны быть в соответствии со стандартом ETSI [5] (11.3.2.2 и приложение J).

10.4 Параметры программных интерфейсов приложений представления (воспроизведения)

10.4.1 В состав графических API пользователя должны входить следующие интерфейсы:

- базовый программный интерфейс приложений GUI;

- телевизионный интерфейс пользователя;

- интерфейс расширенной графики;

- интерфейс обработки входных событий;

- интерфейс компоновки шрифта;

- интерфейс PFR0.

Базовый программный интерфейс приложений GUI определен пакетом java.awt, его параметры должны быть в соответствии со спецификацией платформы Java, версия API JAE 1.1.8.

Состав классов и интерфейсов пакета java.awt, методы, входящие в набор инструментов в составе MHP, а также детализированные правила формирования графических API и использования графических API должны быть в соответствии со стандартом ETSI [5] (11.4.1.1).

10.4.2 Параметры телевизионного интерфейса пользователя должны быть в соответствии с ETSI [5] (11.4.1.2).

10.4.3 Параметры интерфейса расширенной графики должны быть в соответствии с ETSI [5] (приложение U).

10.4.4 MHP поддерживает два способа приема входных событий: использованием метода AWT в java.awt.Component и пакета API org.dvb.event в соответствии с 10.3.3 настоящего стандарта. Детализированные правила приема входных событий должны быть в соответствии с ETSI [5] (11.4.1.4).

10.4.5 Для шрифтов, имеющих формат согласно 7.4 настоящего стандарта, параметры привязки программных интерфейсов приложений Java, касающихся метрик шрифта и формата самого шрифта, должны быть в соответствии с ETSI [5] (11.4.1.5).

10.4.6 Решения платформы потокового медиа и параметры программного интерфейса приложений потокового медиа должны быть в соответствии со спецификацией [44] проигрывателя медиа Java. Расширения, разъяснения и ограничения спецификации [44] должны быть в соответствии с ETSI [5] (11.4.2).

10.5 Программные интерфейсы приложений доступа к данным

10.5.1 Программный интерфейс приложения должен обеспечить доступ приложения к файлам, инкапсулированным в Карусели Объектов, или к файлам, доступным через интерактивную сеть DSM-CC. Протокол доступа к транспорту вещания должен быть в соответствии со стандартом ETSI [5] (приложение Р). Имена файлов, используемые для доступа к объектам Карусели Объектов, должны формироваться в соответствии со стандартом ETSI [5] (11.5.1).

Ограничения правил кэширования терминалом MHP контента из Карусели Объектов должны быть в соответствии со стандартом ETSI [5] (приложение В.5).

Ограничения применения метода java.io.File для Карусели Вещания должны быть в соответствии со стандартом ETSI [5] (11.5.1.1).

Детализация правил использования методов, выполняющих операции с доступом к записи и операции потери Карусели Вещания, должна быть в соответствии со стандартом ETSI [5] (11.5.1.2, 11.5.1.3).

Правила поддержки многоадресного IP-протокола в канале вещания и поддержки IP-протокола по обратному каналу должны быть в соответствии со стандартом ETSI [5] (11.5.2, 11.5.3).

10.5.2 Требования к фильтру секций MPEG-2 программного интерфейса приложений платформы MHP должны быть в соответствии со спецификацией DAVIC [39] (приложение Е).

10.5.3 Условия применения и параметры коммуникационного программного интерфейса приложений установления соединений по обратному каналу в составе MHP должны быть в соответствии со стандартом ETSI [5] (11.5.5 и приложение R).

10.5.4 Параметры программного интерфейса приложений постоянного хранения MHP должны быть в соответствии со стандартом ETSI [5] (11.5.6).

10.6 Программные интерфейсы приложений информации о службе и выбора службы

10.6.1 Параметры специфичного программного интерфейса приложений информации о службе DVB платформы MHP должны быть в соответствии со стандартом ETSI [5] (приложение М).

10.6.2 Параметры программного интерфейса приложений выбора службы определены пакетом javax.tv.service.selection спецификации Java TV, версия 1.0, и стандартом ETSI [5] (11.6.2).

10.6.3 Параметры настраиваемого программного интерфейса приложений определены в спецификации DAVIC [39] [приложение Н (за исключением Н.4)] и стандартом ETSI [5] (11.6.3).

10.6.4 Параметры программного интерфейса приложений условного доступа MHP должны быть в соответствии со спецификацией DAVIC [39] (приложение I) и стандартом ETSI [5] (11.6.4).

10.6.5 Параметры независимого программного интерфейса приложений SI для следующих пакетов:

- javax.tv.service;

- javax.tv.service.guide;

- javax.tv.service.navigation;

- javax.tv.service.transport

должны определяться в соответствии со спецификацией Java TV API, версия 1.0, и стандартом ETSI [5] (11.6.5).

10.7 Параметры общей инфраструктуры программных интерфейсов приложений

10.7.1 Программные интерфейсы приложений, поддерживающие жизненный цикл приложения DVB-J платформы MHP, должны формироваться из классов Java и интерфейсов, входящих в состав пакета javax.tv.xlet, которые определены спецификацией Java TV API, версия 1.00, и стандартом ETSI [5] (11.7.1).

Платформа MHP должна поддерживать следующие Xlet: dvb.org.id; dvb.app.id; dvb.caller.parameters.

Метод уничтожения приложений (Destroy) должен выполняться в соответствии с процедурами по стандарту ETSI [5] (10.7.1.2).

10.7.2 Программные интерфейсы приложений MHP обнаружения приложений и активизации приложений должны формироваться из пакета org.dvb.application в соответствии со стандартом ETSI [5] (приложение S). Параметры метода AppAttributes.getProperty, используемого для обнаружения и активизации приложения, должны быть в соответствии со стандартом ETSI [5] (11.7.2).

10.7.3 Параметры пакетов коммуникационного интерфейса между приложениями MHP должны быть в соответствии со стандартом ETSI [5] (приложение Y). Пример передачи объектов между приложениями MHP представлен в стандарте ETSI [5] (приложение W.2). Программный интерфейс приложений коммуникационного интерфейса между приложениями MHP должен формироваться из интерфейсов, классов, пакетов и Xlet в соответствии со стандартом ETSI [5] (11.7.3).

10.7.4 Программный интерфейс приложений основных концепций MPEG должен формироваться из классов Java, определенных в спецификации DAVIC [39] (приложение G), в составе: ApplicationOrigin; ElementaryStream; Service; TransportStream; DvbElementaryStream; DvbService; DvbTransportStream. Методы возвращения экземпляров элементарного потока, службы или транспортного потока должны обеспечивать возврат экземпляров подкласса DVB (например, DvbElementaryStream).

10.7.5 Программный интерфейс приложений платформы MHP уведомления о ресурсе должен определяться в соответствии со спецификацией DAVIC [39] (приложение F). Детализация применения API уведомления о ресурсе должна выполняться в соответствии со стандартом ETSI [5] (11.7.5).

10.7.6 Программный интерфейс приложений ссылок контента должен формироваться из классов Locator и DvbLocator в соответствии со спецификацией DAVIC [39] (приложение Н, Н.4), а также пакета класса javax.tv.locator в соответствии со спецификацией Java TV [45]. Уточнения применения API ссылок контента должны быть в соответствии со стандартом ETSI [5] (11.7.6).

10.7.7 Программный интерфейс приложений создания отчетов распространенных ошибок должен формироваться из интерфейса NotAuthorizedInterface и исключений, определенных спецификацией DAVIC [39] (приложение G):

- NotAuthorizedException;

- ObjectUnavailableException;

- ResourceException;

- TuningException.

10.8 Безопасность

10.8.1 Базовая безопасность должна обеспечиваться поддержкой следующих пакетов и классов:

- в пакете java.security должны поддерживаться классы в соответствии со стандартом ETSI [5] (11.8.1.1);

- в пакете java.security.cert должны поддерживаться классы в соответствии со стандартом ETSI [5] (11.8.1.2);

- в числе других классов должны поддерживаться классы: java.io.FilePermission; java.io.SerializablePermission; java.lang.RuntimePermission; java.util.PropertyPermission; java.net.SocketPermission; java.awt.AWTPermission в соответствии со стандартом ETSI [5] (11.8.1.3).

10.8.2 Безопасность программных интерфейсов приложений в обратных каналах должна обеспечиваться поддержкой следующих пакетов:

- javax.net;

- javax.net.ssl;

- javax.security.cert,

определяемых в соответствии со стандартом ETSI [5] (11.8.2).

10.8.3 Дополнительные классы полномочий доступа должны быть в соответствии со стандартом ETSI [5] (приложение Т).

10.8.4 Вопросы общей безопасности для случая субкласса java.security.Permission должны рассматриваться в соответствии со стандартом ETSI [5] (11.8.4).

10.9 Другие программные интерфейсы приложений

10.9.1 Программный интерфейс приложений поддержки таймера определяется параметрами API-таймера в пакете javax.tv.util в спецификации Java TV, версия 1.0, в соответствии со стандартом ETSI [5] (11.9.1).

Реализации API таймера должны обеспечивать:

- минимальный интервал повторения не более 40 мс;

- дискретность формирования интервала повторения не более 10 мс.

Минимизированные требования к другим ресурсам реализации API-таймера должны быть в соответствии со стандартом ETSI [5] (таблица G.4).

10.9.2 Требования к программному интерфейсу приложений установок и предпочтений пользователя должны быть в соответствии со стандартом ETSI [5] (приложение L).

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

- язык пользователя;

- мнение родителей;

- код страны;

- размер шрифта (по умолчанию).

Другие установки, предпочитаемые пользователями, должны быть доступны в том случае, когда UserPreferencePermission предоставлено для "чтения" в соответствии со стандартом ETSI [5] (11.10.2.8).

10.9.3 Приложения должны обнаруживать поддерживаемый терминалом профиль и версию профиля и поддерживать работоспособность в соответствии со стандартом ETSI [5] (10.9.3). Свойства, перечисленные в стандарте ETSI [5] (таблица 46), должны быть включены в набор свойств класса java.lang.System.

10.10 Полномочия приложений DVB-J

10.10.1 Правила доступа к ресурсам приложений "без знака" должны обеспечиваться в соответствии со стандартом ETSI [5] (11.10.1).

10.10.2 Правила доступа к ресурсам приложений, отмеченные "знаком", должны быть в соответствии со стандартом ETSI [5] (11.10.2).

10.11 Соответствие базирования контента

Платформа DVB-J MHP должна отображать соответствие между объектами, типами локатора и их текстовыми представлениями в соответствии со стандартом ETSI [5] (таблица 64).

Платформа DVB-J MHP должна поддерживать методы и конструкторы Java, которые выполняют прием или возврат (в соответствии с сигнатурой) экземпляров локаторов org.davic.net.Locator, javax.tv.locator.Locator, javax.media.MediaLocator, или их подклассы в соответствии со стандартом ETSI [5] (11.11).

В состав методов приема и возврата экземпляров объектов, соответствующих стандарту ETSI [5] (11.11), входят:

- методы, обрабатывающие экземпляры объектов, описывающих транспортный поток MPEG;

- методы, обрабатывающие экземпляры объектов, описывающих сеть DVB;

- методы, обрабатывающие экземпляры объектов, описывающих букет DVB;

- службы:

- методы, обрабатывающие экземпляры объектов, относящихся к специфическим службам MPEG/DVB;

- методы, обрабатывающие экземпляры объектов, со ссылкой на универсальную службу;

- методы, обрабатывающие экземпляры объектов, описывающих события DVB;

- методы, обрабатывающие экземпляры объектов, описывающих элементарный поток MPEG;

- методы, обрабатывающие ссылочные файлы;

- метод, возвращающий экземпляр локатора "dvb:", ссылающегося на каталог;

- методы обработки локаторов со ссылкой на декодер drip feed;

- "несущественные" методы;

- методы, обрабатывающие множество типов локаторов;

- методы и классы, поддерживающие протокол HTTP в DVB-J.

11 Безопасность

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

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

- политика безопасности для приложений;

- аутентификация и конфиденциальность обратного канала связи;

- управление сертификатом.

Параметры перечисленных областей безопасности MHP должны быть в соответствии со стандартом ETSI [5] (раздел 12).

12 Параметры эталонной ссылочной модели графики MHP

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

Объем минимально необходимой поддержки этих функций должен удовлетворять требованиям стандарта ETSI [5] (раздел 13, приложение G).

13 Требования к аспектам системной интеграции MHP

Состав параметров MHP, обеспечивающих ее системную интеграцию, включает в себя следующие параметры:

- отображения пространства имен объектов и файлов;

- имен файлов с учетом зарезервированных имен;

- нотации XML;

- сетевой сигнализации;

- кодирования текста идентификаторов приложений;

- имен файлов с учетом обеспечения персистентности хранения;

- файлов и имен файлов, обеспечивающих доступ MHP к контенту, сохраненному в файлах;

- типов объектов, локаторов и их текстовых представлений;

- механизмов, обеспечивающих идентификацию службы;

- механизмов, обеспечивающих функционирование MHP с системой условного доступа при выборе службы, выборе компонент медиа (аудио, видео субтитры), Карусели Объектов и частных данных.

Ниже представлены детализированные параметры системной интеграции.

13.1 Отображение пространства имен объектов и файлов (локатор DVB)

Для адресования объектов DVB SI, а также файлов в Каруселях Объектов в MHP должен использоваться расширенный формат DVB DAVIC URL, согласно спецификации DAVIC [39] и стандарта ETSI [5] (14.1). Указанное расширение локатора DAVIC должно быть совместимо и в обратном направлении для обоих оригиналов. При этом должны использоваться следующие форматы локатора:

dvb://<original_network_id>. [<transport_stream_id>] [. <service_id> [. <component_tag> {&<component_тег*>}] [; <event_id>]] {/<path_segments>}

_________________

* Текст документа соответствует оригиналу. - .

или

dvb://'<textual_service_identifier>' [. <component_tag> {&<component_tag>}] [; <event_id>]] {/<path_segments >}.

Формализованная спецификация DVB URL, выраженная в BNF, должна быть в соответствии со стандартом ETSI [5] (14.1).

13.2 Зарезервированные имена файлов

Имена файла, начинающиеся с символов "dvb", должны быть зарезервированы для использования в качестве "хорошо известных" файлов, определенных в этой или в будущей спецификации.

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

13.3 Нотация XML

При обработке и кодировании всех файлов, где XML используется в качестве формата кодирования, в MHP должны использоваться правила в соответствии со стандартом ETSI [5] (14.3).

13.4 Сетевая сигнализация

Функционирование терминалов MHP при работе в сети должно соответствовать требованиям, определенным в стандарте ETSI [36] (14.4).

13.5 Кодирование текста идентификаторов приложений

MHP должна поддерживать следующие требования к кодированию текстов идентификаторов organization_id или application_id:

- должно использоваться шестнадцатеричное представление значения символа;

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

- не должны использоваться нулевые старшие разряды.

В тех случаях, когда идентификаторы organization_id и application_id объединены в идентификатор приложения, они будут представлены как единственное шестнадцатеричное число с использованием ранее описанного правила кодирования с идентификатором organization_id как старшим значащим битом и application_id как младшим значащим битом.

13.6 Требования к имени файла

Для обеспечения персистентности хранения приемники MHP должны поддерживать путь доступа и имена файла, как определено persistentpath и persistentfilename в стандарте ETSI [5] (14.6.1).

Приемники MHP должны поддерживать Карусель Объектов DSM-CC в соответствии со следующими требованиями:

- пути к файлам (совокупности имен каталогов, разделителей каталога и имени файла) должны быть не более 1024 байт;

- с учетом требования к пути к файлу имена файла и имена каталогов должны занимать не более 255 байт;

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

Другие ограничения к Каруселям Объектов должны быть в соответствии с требованиями стандарта ETSI [5] (14.6.2, приложение В.2.8).

13.7 Требования к файлам и именам файлов

Для обеспечения приложениями MHP доступа к контенту, сохраненному в файлах, требования к MHP, к файлам и именам файлов должны быть в соответствии со стандартом ETSI [5] (14.7).

13.8 Требования к объектам, локаторам и текстовым представлениям

Требования к составу объектов, локаторов и их текстовых представлений MHP должны быть в соответствии со стандартом ETSI [5] (14.8).

13.9 Требования к идентификации службы

13.9.1 MHP должна содержать два механизма однозначного определения службы:

- триплет числовых идентификаторов SI original_network_id, transport_stream_id и service_id, соответствующих идентификаторам, определенным в ETSI [12];

- текстовый идентификатор службы textual_service_identifier_bytes, переносимый в дополнительном дескрипторе идентификатора службы в SDT, должен быть в соответствии с 9.11.1 настоящего стандарта.

Оба механизма полностью обеспечивают уникальную идентификацию службы.

Дополнительно текстовый идентификатор службы обеспечивает:

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

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

13.9.2 Синтаксис и семантика текстового идентификатора службы должны быть в соответствии со стандартом ETSI [5] (14.9.1).

Терминал MHP обнаруживает текстовые идентификаторы службы для данной службы, как и наличие самой службы, по таблице SDT. Детализированная процедура обработки терминалом MHP текстовых идентификаторов службы должны выполняться в соответствии со стандартом ETSI [5] (14.9.2).

13.10 Требования к функционированию MHP совместно с системой условного доступа

Функционирование MHP совместно с системой условного доступа при выборе службы, выборе компонента медиа (аудио, видео или субтитры), выборе компонента "не media" (например, Карусель Объектов DSM-CC и частных данных) должно быть в соответствии со стандартом ETSI [5] (14.10).

14 Детализированные определения профилей платформ MHP

Детализированные определения профилей платформ для "улучшенного профиля вещания 1" и "интерактивного профиля вещания 1", включающих области: статических форматов, форматов потокового вещания; шрифтов, протоколов канала вещания, протоколов интерактивного канала и DVB-J, должны быть в соответствии со стандартом ETSI [5] (раздел 15, таблица 65).

14.1 Уточненные требования к формату PNG

14.1.1 Терминалы MHP должны поддерживать отображение цвета в соответствии с форматами по стандарту ETSI [5] (15.1, таблица 66).

Терминалы MHP должны обеспечивать возможность активизации любой комбинации PNG с различными типами цвета. Терминалы MHP должны поддерживать отображение цветов спецификации RGB16, поддерживаемых экранным меню терминала.

В тех случаях, когда графика PNG использует цвета, в соответствии с минимальной палитрой согласно стандарту ETSI [5] (приложение G, таблица G.1), эти цвета должны воспроизводиться правильно. Другие цвета (находящиеся за пределами минимальной палитры) должны воспроизводиться с максимально возможным качеством.

Терминалы MHP должны игнорировать блоки данных gAMA(гамма) и cHRM (цветность), передаваемые в файлах PNG.

14.1.2 Форматы изображения PNG должны быть в соответствии со стандартом ETSI [5] (15.1.1).

14.2 Требования к составу форматов медиа, поддерживаемых API DVB-J

Требования к форматам медиа, поддерживаемым программными интерфейсами для приложений DVB-J "улучшенного профиля вещания 1" и "интерактивного профиля вещания 1", должны быть в соответствии с таблицей 3.

Таблица 3 - Требования к форматам медиа, поддерживаемым программными интерфейсами для приложений DVB-J "улучшенного профиля вещания 1" и "интерактивного профиля вещания 1"

14.3 Требования к формату JPEG

Требования к формату JPEG должны быть в соответствии с 7.1.1.2 настоящего стандарта. Не должен поддерживаться формат JPEG при прогрессивном режиме, основанном на DCT.

14.4 Требования к поддержке локалей

Требования к поддержке локалей должны быть в соответствии с ETSI [5] (15.4).

14.5 Зависимости формата растрового изображения

MHP должна поддерживать форматы растрового изображения в соответствии с используемыми в стандарте ETSI [36]. Должно поддерживаться стандартное разрешение видеоизображения с частотой кадра 25 Гц.

15 Требования к константам

15.1 Требования к системным константам MHP

MHP должна обеспечивать выполнение требований к системным константам в соответствии со стандартом ETSI [5] (таблицы 68, 69).

15.2 Требования к константам DVB-J платформы MHP

MHP должна обеспечивать выполнение требований к общедоступным, защищенным, заключительным, статическим примитивным полям пакетов DVB в соответствии со стандартом ETSI [5] (16.2.1).

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

- константы JAE, версия 1.1.8, API Constans [46];

- константы JAE, версия 1.2.2, API Constants [47];

- константа JMF Java Media Framework API, версия 1.0, Constants [48].

Библиография

Электронный текст документа

и сверен по:

, 2020