ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

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

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

Издание официальное

Предисловие

Цели и принципы стандартизации е Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N9 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации —- ГОСТ Р 1.0—2004 «Стандартизация в Российской Федерации. Основные положения »

Сведения о стандарте

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

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

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

4 Настоящий стандарт разработан с учетом основных нормативных положений документа Европейского института по стандартизации в области телекоммуникаций (ЕТСИ) ETS1 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)

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

Информация об изменениях к настоящему стандарту публикуется в ежегодно издаваемом информационном указателе «Национальные стандарты», а текст изменении и поправок— е ежемесячно издаваемых информационных указателях «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет

© Стандартинформ. 2012

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

Содержание

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

in

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

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

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

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

Oigitai broadcast television. Multimedia home platform.

Class 1.0. Basic parameters

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Издание официальное

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

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»): Форма медиа, когда на вход видеодекодера транспортный потокМРЕО-2подается блоками, содержащими 1-кадры и Р-кадры. Каждый блокдолженсодержатьодин кадр и определенное число синтаксических элементов в соответствии с 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: МНР): Аппаратно-программный комплекс, обеспечивающий доступ пользователя к интерактивным и вещательным службам.

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 Тable; 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: Классы МНР по видам предоставляемых услуг.

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

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

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

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

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

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

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

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

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

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

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

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

3.1.40 медиа (media): 6 контексте стандарта — информационные сообщения, передаваемые по каналам вещания (кадры звука 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.46 обратный вызов (callback): Принцип регистрации вызова класса’Обработчика события (слушателя) в среде класса’источника. в частности, при выполнении приложения DVB-J. Обратный вызов позволяет исполнять код. который задается в аргументах при вызове функции.

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

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

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

3.1.52 пакетированный элементарный поток; ПЭП (Packeti2ed 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 МНР. ноне DVB-J (например, форматы приложения HTML-3.2 или MHEG-5).

3.1.56 пользователь (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): Описание группы минимальных конфигураций, определяющих часть спецификации, обеспечивающей возможности МНР и отображающей функции, которые характеризуют контекст опций службы.

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

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

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

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

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

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 состояния приложения OVB-HTML (DVB-HTML application states): Логические состояния, в которых может находиться агент DVB-HTML.

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

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

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

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

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

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

S

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

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

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

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

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

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

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

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

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

3.1.99 триггер (trigger): Событие, которое может вызвать изменение в поведении того приложения OVB-HTML. которое зарегистрировало интерес к такому событию. Триггеры могут приходить из потоков вещания, могут быть сгенерированы от других источников (таких как системные часы) или могут быть сгенерированы в результате взаимодействия пользователя. Триггер может включать ссылку на всемирное KOOpAHi«ipOBaHHoeepeMB(Universa!TtmeCoordinated;UTC)OTHOCHTenbHO некоторого другого события, относительно нормального времени воспроизведения (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 t-кадр (l-frame): Видеокадр, сформированный при вкутрикадроаом кодировании потока данных.

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

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

БНФ (Backus Normal Form. 8NF) — нормальная форма Бэкуса—Наура;

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

МСЭ (International Тelecommunication 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 независимая от платформы;

ВАТ (Bouquet Association ТаЫе)—таблица объединения букета программ;

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

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

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

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

DAVIC (DAV1C Digital Audio Visual Council)—комитет no аудиовиэульным проектам;

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

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

Dll (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 — цифровое телевизионное вещание no каналам c IP протоколами;

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

DVB-J API —один изпрограммных интерфейсов приложений Java, стандартизированных какчасть спецификации МНР;

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 (HyperText 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) — Институт инженеров no электротехнике и радиоэлектронике;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

МНР service — логическая служба МНР;

МНР solution — решение МНР;

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

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

MPEG-2 video «drips»—режим декодирования видеоизображения, использующий только 1-кадры и Р-кадры;

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

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

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

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

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

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

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

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

РМТ (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 —стек протоколов сетевого и транспортного уровня:

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

ТОТ (Time OffsetTable) — таблица смещения времени;

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 — глобальная распределенная система гипермедиа, размещенная в сети Интернет;

XJet — интерфейс, который используется для управления жизненным циклом приложения DVB-J; XML (Extensible Markup Language) — расширяемый язык разметки:

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

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

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

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

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

• класс 1.2 — дополнительно к классу 1.1 обеспечивается обработка приложений профиля DVB-IPTV. Дополнительно определены требования к МНР для доставки «видео по запросу» с помощью протокола RTSP. а также требования к методам инкапсуляции видео- и аудиоформатов в MPEG-2 TS. Для МНР класса 1.2 устанавливаются условия применения протоколов IGMPn UDP для доставки данных для МНР приложений.

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

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

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

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

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

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

– контекстом применения МНР;

• собственно архитектурой МНР;

• интерфейсами МНР;

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

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

• программное обеспечение МНР имеет доступ к потокам и данным;

• МНР может сохранять частьпринятыхданных;

• МНР может направить потоки и данные за пределы МНР на внешний приемник данных или в хранилищеданных;

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

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

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

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

• ресурсы,

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

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

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

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

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

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

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

• транспортные протоколы:

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

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

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

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

ПрогремимаЮ жтерфейсы прилов» *6 Три юпарт ы> протаапм Виртушыял им) им Лт Адитшрвтср прилежен*

Оистииое протрем инее сбаамцита

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

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

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

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

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

• интероперабельные плагины:

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

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

и

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

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

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

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

Перечень профилей платформ МНР. к которым обеспечивается доступ протоколов вещания, должен быть в соответствии с 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/1EC [6]

(2.4).

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

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

Г^зшюжш

Программ ьй интерфейс гфмккания (API)

***** Объекта
Ц т>
Кцтуоагь Объектов овмсс	ииг
IP	DVBSI
•И Дмдес ОСМОС
мнмвпСупшуш DVO

секции црева{йъамоаи-ссо

Т^мнаюрлмК nonx UPE&2

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

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

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

ПрилОввнт

Программный мкшрфайепрнлсмимя <АИ)

	DSU-CC U-U IWO-RPC/ UNO-COR	КГТР	UDP		Инфор мация оадеМВск
	TCP
IP
ПрОтрирпы. З&аиС— ■) Уг Сети

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 Терминалы МНР должны обеспечивать преобразование доменных имен DNS в IP-адреса в соответствии с требованиями стандартов IETF [29]. IETF [30] и уточнениями в соответствии со стандартами IETF [31]. IETF [32].

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

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

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

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

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

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

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

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

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

7.1.2 МНР должна поддерживать обработку 1-кадров MPEG-2, которые определяются в соответствии с ISO/IEC [1] (6.1.1.11). Параметры полезной нагрузки файлов, представляющих 1-кадры 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);

ptcture_data();

sequence_end_code().

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

предусмотренных технологией MPEG-2 (в том числе в соответствии с ITU-R [41]), в цветовые пространства sRG8.

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

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

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

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

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

И нема файлов библиотеки Java 2 JMF	Иден?ифика?оры типов расширений4	Определение шнтента
’■mage.’tpeg’	* IP9*	В соответствии со стандартом ETSt |5| (7.1.1.2)
‘■mage/png*	‘•png’	в соответствии со стандартом ETSI [5] (7.1.1.3)
’image/gif	“ д>г	8 соответствии со стандартом ETSI [5] (7.1.1.4)
‘imagefmpeg*	\rnpg*	В соответствии со стандартом ETSI [S] (7.1.2)
*video/mpeg*	•трд*	В соответствии со стандартом ETSI |5] (7.2.2)
*v»deo/dvb.mpeg.drtp*	\drip*	В соответствии со стандартом ETSI (5) (7.1.3)
‘audio/mpeg*	*.тр2*	в соответствии со стандартом ETSI |5) (7.1.4)
Mexbdvb.utfB’	‘.txt*	В соответствии со стандартом ETSI [5] (7.1.5)
‘■mage/dvb.subtitte*	‘.sub*	В соответствии со стандартом ETSl |5) (7.2.3)
*iexbdvb.subtnle*
*text/dvb.ieletext*	Mix*	В соответствии со стандартом ETSI |5] (7.2.3.2)
*appl»cetion/dvb.pfr*	\pfr*	8 соответствии со стандартом ETSI [5] (7.4)
•appltcationfdvbf	■.Claes’	В соответствии со стандартом ETSI [5] (6.2.5.1)
*muitipart/dvb.service’	*.8VC“	Применяется, если программа MPEG (Служба DVB) соответствует нормам OVB
* Вновь появляющиеся форматы могут иметь расширения с увеличенным количеством символов.

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

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

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

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

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

• выбор службы вещания.

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

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

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

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

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

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

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

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

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

– из-за дефицита ресурсов терминала МНР.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вил вызова	Состояния Xiet
notityDestroyed (уведомление о ликвидации)	все состояния
notlfyPaused (уведомление о паузе)	активное
esunreRequest (запрос состояния)	пауза

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

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

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

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

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

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

Комплект документов, составляющих приложение DV8-HTML платформы МНР. определяется регулярным выражением на языке локатора. Как правило, локатор состоит из текстовой строки в форме, определенной в соответствии с IETF [2), и действует как связующее звено, скрепляющее приложение: scheme ://host/dir1/dim/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 МНР должна предусматривать (после поступления заявки на запуск при» ложения DVB-HTML) поиск агента пользователя и поиск актора.

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

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

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

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

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

• загрузка;

• активное;

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

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

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

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

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

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

• прииэменении данныхАГГ.

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

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

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

– в состоянии «загрузка»—доступ к ресурсам контента и ресурсам сигнализации. Контент зрителю не представляется;

– в состоянии «активное» — полный доступ актора к контенту действующего документа и всем ресурсам МНР в соответствии с правилами управления ресурсом и условиями обеспечения безопасности;

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

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

– в состоянии «уничтоженное» (Killed) — потеря всех ресурсов; переход в состояние «уничтоженное» (Killed) инициирует сброс актора и возвращение платформе МНР необходимых ресурсов.

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

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

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

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

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

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

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

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

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

• идентификацию приемником платформы МНР источников данных вещания, по требованию приложений службы.

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

• РМТ с дескриптором сигнализации приложения (с целью идентификации компонента службы, переносимого в таблице AIT):

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

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

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

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

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

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

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

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

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

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

• дескриптор IP сигнализации или в общем цикле дескриптора, или в цикле дескриптора приложений всоответствиисостандартомЕТВ! [5] (10.8.2) и 9.7.1 настоящего стандарта:

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

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

• для дополнительных транспортных протоколов с расширением согласно стандарту ETS! (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 МНРдолжнаеыполнятъобработкутаблицЗОТвсоответстеиисостандартом ETSI (5) (10.12).

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

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

• локации потока, транспортирующего А1Т;

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

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

– поле stream_type имеет значение 0x05 в соответствии с ISO/IEC (6):

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

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

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

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

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

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

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

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

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

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

Синтаксис 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 Параметры идентификации приложений

МНР должна выполнять идентификацию приложений использованием идентификатора applicationjdentifier, передаваемогов таблице AIT. Идентификатор applicationjdentifier включает в себя поле organisation^ (32 бита), идентифицирующее организацию, ответственную за вещание приложения, и поле apptication_id (16 бит), уникально идентифицирующее приложение. Формирование значений organisationjd должно быть в соответствии оо стандартом ETSI TR (43]. Классификация полей applicationjd должна быть в соответствии со стандартом ETSI (5] (10.5.1).

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

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

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

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

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

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

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

9.6.1 Дескрипторсигнализации приложений предназначен для ислользованияв цикле элементарного потока РМТ. в этом случае значение поля stream_type равно 0 х 05.

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

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

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

• дескрипторы приложения:

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

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

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

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

• транспортный формат вещания данных, «основной компонент» которых находится в этом элементарном потоке:

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

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

Дескриптор идентификатора вещания данных платформы МНР применяется во всех случаях, когда вещание данных выполняется в соответствии с константами, установленными в стандарте ETSI {5] (10.11, таблица 39). Применение этого дескриптора обеспечивает расширение возможностей универсального дескриптора вещания данных в соответствии со стандартом ETSI [5] (10.7.2.2). Синтаксис дескрипторов идентификаторов вещания данных МНР должен быть в соответствии со стандартом 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. внешняя авторизация применяется к приложениям с идентифицированным полем applicationjdentifier (}, которые имеют поле application_type. идентифицированное субтабпицей АН. где содержится этот дескриптор.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.8.1 В состав специфичных дескрипторов DVB-J платформы МНР входят: дескриптор лриложе-ния 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 Дескриптор локации приложения OVB-J содержит информациюо маршруте приложения, что обеспечивает поиск приложения и управление приложением DVB-J. Один экземпляр дескриптора дол* жен содержаться в прикладном цикле дескрипторов AIT для каждого приложения DVB*J. Синтаксис и семантика дескриптора локации приложения OVB-J должны быть в соответствии со стандартом ETSI [5] (10.9.2, таблица 34).

9.9 Дескрипторы приложения DVB*HTML платформы МНР

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)служба приложений МНР должна использоваться для служб, которые предусматривают не менее одного автоматического запуска приложения МНР. если это приложение является основным компонентом службы.

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 Д045.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 (51(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 OAVIC & OVB должны быть в соответствии с ETSI [5] (11.2.6.11.2.7) соответственно.

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

10.2.6 Управление ресурсом внутреннего приложения медиа МНР должно выполняться в соответствии с 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 МНР должна поддерживать следующие основные программные интерфейсы приложений платформы Java:

• пакет java.lang;

• naKeTjava.Iang.reftect:

• java.util;

– java.util.zJp:

– java.to;

• java.net:

• java.beans:

• java.math

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

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

• java.to.FiiePermission:

• java.to.SeriallzatHePermission;

• java.lang. RuntimePermission;

• java.util. PropertyPermission:

• java.net.SocketPermission;

– java.awt AWTPermisston

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.4.4 МНР поддерживает два способа приема входных событий: использованием метода 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).

Ограничения правил кэширования терминалом МНР контента из Карусели Объектов должны быть в соответствии со стандартом ETSI (5) (приложение B.S).

Ограничения применения метода iava.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 программного интерфейса приложений платформы МНР должны быть в соответствии со спецификацией DAVIC [39] (приложение Е).

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

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

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

10.6.1 Параметры специфичного программного интерфейса приложений информации о службе DVB платформы МНР должны быть в соответствии со стандартом 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 Параметры программного интерфейса приложений условного доступа МНР должны быть в соответствии со спецификацией OAVIC [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 платформы МНР. должны формироваться из классов Java и интерфейсов, входящих в состав пакета javax.tv.xlet. которые определены спецификацией Java TV API. версия 1.00. и стандартом ETSI [5]

(11.7.1).

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

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

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

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

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

10.7.5 Программный интерфейс приложений платформы МНР уведомления о ресурсе должен определяться в соответствии со спецификацией 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 Программный интерфейс приложений создания отчетов распространенных ошибок дол* женформироваться «интерфейса NotAuthorizedlnterfaceH исключений, определенных спецификацией 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.SocketPermiss ion; 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 мс:

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

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

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

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

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

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

• код страны;

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

Другие установки, предпочитаемые пользователями, должны быть доступны в том случае, когда UserPreferencePermission предоставлено для «чтения» в соответствии со стандартом ETS! (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 Соответствие базирования контента

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

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

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

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

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

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

• службы:

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

MPEG/DVB;

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

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

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

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

• метод, возвращающий экземпляр локатора «dvb:». ссылающегося на каталог:

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

• «несущественные» методы;

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

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

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

8 разделе устанавливаются требованиякследующим областям, влияющим на беэопасностьМНР:

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

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

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

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

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

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

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

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

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

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

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

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

• нотации XML;

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

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

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

• файлов и имен файлов, обеспечивающих доступ МНР к контенту, сохраненному в файлах:

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

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

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

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

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

Для адресования объектов DVB SI. а также файлов в Каруселях Объектов в МНР должен использоваться расширенный формат DVB OAVIC URL. согласно спецификации DAVIC [39] и стандарта ETSI (5]

(14.1). Указанное расширение локатора DAVIC должно быть совместимо и в обратном направлении для обоих оригиналов. При этом должны использоваться следующие форматы локатора:

dvt>://<origina1_networkJd>. [<transport_streamJd>j [. <servicejd> (. <component_tag> {&<component_Ter>}) [; <eventJd>Q {/<path_segments>}

или

dvb://’<textuaJ_serviceJdentifier>’ (. <component_tag> {&<component_tag>)] [: <eventjd>]) {/<path_segments >}.

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

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

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

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

13.3 Нотация XML

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

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

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

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

МНР должна поддерживать следующие требования к кодированию текстов идентификаторов organisation^ или applicationjd:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• триплет числовых идентификаторов SI original_network Jd. transport_stream_id и servicejd. соответствующих идентификаторам, определенным в ETSI (12);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Терминалы МНР должны игнорировать блоки данныхдАМА(гамма) hcHRM (цветность), передаваемые в файлах PNG.

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

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

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

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

Типы медиа	Ссыпки на настоящий стандарт	Прогрдмымыо интерфейсы приложений DVB-J
Загружаемые шрифты	7.4	org.dvb.ui.FontFactory
Аудиофайлы	7.1.4	org.havuul HSound JMF только со ссылками не файлы
l-кадры изображений MPEG	7.1.1	org.havi.ui.H8acfcgroundlmage
Изображения PNG	7.1.1.3	Java.awt.lmsge
Изображения JPEG	7.1.1.2	Java.awl.image
Информация о службе DVB	ETSI EN (12)	JMF только со ссылками на службы DVB для воспроизведения непосредственно от сети
Видео ‘капли*	7.1.3	org.dvb.media.DripFeedDateSource
Файлы текста	7.1.5	Все программные интерфейсы приложений Java, читающие или пишущие текстовые файлы
Файлы субтитров	7.2.3	JMF только как часть службы 0VB

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

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

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

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

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

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

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

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

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

15.2 Требования к константам OVB-J платформы МНР

МНР должна обеспечивать выполнение требований к общедоступным, защищенным, заключительным, статическим примитивным полям пакетов 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].

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

information technology—Generic coding of moving pictures and associated audio information — Рал 2: Video (MPEG-2 Video)

IETF Uniform Resource Identifiers (URI): Generic Syntax

IETF Host extensions for IP multicasting

SERIES Z: Languages and general software aspects for telecommunication systems. Formal description techniques (FDT) — Specification and Description Language (SDL). Specification and Descnption Language (SOL)

Digitel Video Broadcasting (DVB); Multimedia Home Platform (МНР) Specification 1.0.3

Information technology — Genenc coding of moving pictures and assocated audio information — Рал 1: Systems

Information technology — Genenc coding of moving pictures and assocated audio information — Рал 6: Extensions for Digital Storage Media Command and Control (DSM-CC)

Specification for Data Broadcast Guldehnes for the use of EN 301 192 (IP) Internet Protocol. J. Postel (UOP) User Datagram Protocol. J. Postel

Digital broadcasting systems for television, sound and data services: Specification for Service Information (SI) in Digital Video Broadcasting (DVB) systems Digital Video Broadcasting (DVB); Guidelines on implementation and usage of Service Information (SI)

DVB Interaction Channel for Cable TV distnbution systems (CATV)

DVB Interaction Channel through PSTN/ISDN DVB Interaction Channel through OECT

DVB. interaction Channel through the Global System for Mobile communications GSM

DVB: Interaction channel for Local Multipoint distribution systems (LMDS)

DVB. Interaction channel for Satellite Master Antenna TV (SMATV) distnbution systems. Guide Ines for versions based on satellite and coaxial sections Digitel Video Broadcasting (DVB); interaction channel for satellite distnbution systems

Digital Video Broadcasting (DVB):

Second generation framing structure, channel coding and modulation systems for Broadcasting, interactive Services. News Gathering and other broadband satellite applications (DVB-S2)

The PPP Internet Protocol Control Protocol (IPCP)

The Polnt-to-Pomi Protocol (PPP)

The PPP MuMink Protocol (MP)

PPP Internet Protocol Control Protocol Extensions for Name Server Addresses (TCP) Transmission Control Protocol. J. Postel

The Common Object Request Broker. Architecture and Specification. Object Management Group

IETF Hypertext Transfer Protocol — HTTP/1.1 Domain Names — Concepts and facilities

Domain Names — implementation and specification

Senal Number Arithmetic

Clarifications to the DNS Specification

Informauon technology; digital compression and coding of continuous-tone still

images; part 1: requirements and guidelines

JPEG File Interchange Format, Eric Hamilton, C-Cube Microsystems

information technology: Coding of moving pictures and associated audio for digital storage media at up to about 1.5 Mbit’s; part 3: audio (Note: known as MPEG-1 Audio)

OVB; Implementation Guidelines for the use of MPEG-2 Systems. Video and Audio in satellite, cable and terrestrial broadcasting applications OVB; Specification for conveying ITU-R System В Teletext m DVB bitstreams Enhanced Teletext Specification

Complete OAVIC. Specifications. OAVIC

information technology — Universal muitipieoctet coded character set (UCS), pan 1: Architecture and Basic Multilingual Plane

Parameter values for the HDTV standards for production and international programme exchange

IEEE Standard for Information Technology — Portable Operating System interface (POSIX) — Pan 2: Shell and Utilities

Digital broadcasting systems for television, sound and data services: Allocation of Service information (SI) codes for Digital Video Broadcasting (DV8) systems Java Media Framework API Version 1.0 specification

Java TV API Version 1.0 specification

JAE 1.1.8 API Constants

JAE 1.2.2 API Constants

Java Media Framework API Version 1.0 Constants

УДК 621.397:631.327.8 ОКС33.170 ОКП65 7400

Ключевые слова: телевидение вещательное цифровое, домашняя мультимедийная платформа, прото* кол высокоскоростной передачи информации DSM-CC. сеть, пользователь. Карусель Объектов

Редактор Н.А. Аргунова Технический редактор В.Н. Прусакова Корректор Л.Я. Митрофанова Компьютерная оерстка И.А . НапеиконоО

Сдано о набор 09.07.2012. Подписано о печать 05.09.2012. Формат 00 » 84^. Гарнитура Ариел. Уел. печ. п. 4.05. Ум -и»д. п. 4.30 Тираж П4 экэ. Зак 759.

ФГУП «СТАНДАРТИНФОРМ*. 123995 Москва. Гранатный пер . 4. info@goslmlo ги Набрано ао на ПЭВМ.

Отпечатано в филиале — тип. «Московский печатник». 105002 Москва. Лялин пер., 8.

Кялвеимт

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

6.1.6 Требования к протоколу DSM-CC U-U Карусель Объектов должны быть в соответствии с ISO/1EC [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 Потеря режима Карусели должна относиться к случаям потери потоков данных Карусели, обслуживающих файлы системы вещания. Указанные потери потоков данных классифицируются как случаи:

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

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

Детализированные правила работы платформы МНР при потере режима Карусели должны быть в соответствии со стандартом 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].

Соединения сети

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

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

• для распределительных систем кабельного телевидения в соответствиисостандартом 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);