Товары в корзине: 0 шт Оформить заказ
Стр. 1
 

40 страниц

487.00 ₽

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

Официально распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО "ЦНТИ Нормоконтроль".

Наши цены ниже, чем в других местах, потому что мы работаем напрямую с поставщиками документов.

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

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

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

Показать даты введения Admin

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

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

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

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

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

Москва

Стандартинформ

2012

Предисловие

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

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

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

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

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

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

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

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

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

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

13.3    Нотация XML...................................................30

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Digital broadcast television. Multimedia home platform. Class 1.0. Basic parameters

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

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

Настоящий стандарт распространяется на аппаратно-программный комплекс — домашняя мультимедийная платформа (Multimedia Home Platform; MHP) класса 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): Объект в MHP, который обеспечивает управление жизненным циклом приложений MHP, в том числе приложений 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»): Форма медиа, когда на вход видеодекодера транспортный потокMPEG-2 подается блоками, содержащими I-кадры и P-кадры. Каждый блокдолжен содержать один кадр и определенное число синтаксических элементов в соответствии с ISO/IEC [1].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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    конструктор поумолчанию (default constructor): Конструктор, создаваемый компилятором при отсутствии конструктора класса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DVB network — сеть DVB;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

РМТ (Program MapTable) — таблицы состава программы;

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

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

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

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

РVC (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) — коммутируемый виртуальный канал;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-    ресурсы;

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

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

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

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

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

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

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

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

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

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

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

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

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

Программные интерфейсы приложений Транспортные протоколы Виртуальная машина Java Администратор приложений


Канал вещания

Интерактивный канал < >

Алгоритмы стандарта MPEG Устройства ввода-вывода Графическая система



с


Ресурсы


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

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

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

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

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

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

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

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

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

Видео

выход

Удаленное управление (клавиатура, «мышь»)

Сеть

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

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

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

6.1.1    Протоколы канала вещания относятся к типу протоколов независимых от сети. На рисунке 3 показана структура стека протоколов канала вещания DVB, которые должны быть доступны приложениям МНР. Другие протоколы и соответствующие им API должны рассматриваться как расширения платформы DVB MHP. Требования к ним должны быть в соответствии с 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/IEC [6]

(2.4).

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

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

Приложения

Программный интерфейс приложения (API)

Карусель

Объектов

DVB

Карусель

Объектов

DSM-CC

User-to-User

ииг

IP

Карусель

Данных

DSM-CC

Мультипротокол ьная инкапсуляция DVB

Секции MPEG-2 (Секции DSM-CC)

Транспортный поток MPEG-2

Канал вещания

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

6.1.6    Требования к протоколу DSM-CC U-U Карусель Объектов должны быть в соответствии с ISO/IEC [7] (раздел 11), с ограничениями и расширениями, определенными стандартами ETSI [8] (раздел 11), ETSI [9] (4.7), ETSI [5] (приложение B). Должны учитываться следующие особенности обработки протокола 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    Требования к протоколу ^должны быть в соответствии со стандартом IETF RFC [10] (разделы 2, 3).

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

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

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

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

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

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

Приложения Программный интерфейс приложения (API)

DSM-CC

U-U

HTTP

UNO-RPC / UNO-CDR

UDP

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

TCP

IP

Протоколы, зависимые от сети

Соединения сети Рисунок 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);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.2.11    Терминалы МНР должны обеспечивать преобразование доменных имен 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 или прогрессивный режим, основанный на DCT в соответствии с ISO/IEC [33]. Формат обмена файлами должен быть JFIF [34].

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

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

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

sequence_header();

sequence_extension();

extension_and_user_data(0);

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

picture_header (picture_coding_type = «I frame»);

picture_coding_extension ( picture_structure = «frame picture»);

extension_and_user_data(2);

picture_data();

sequence_end_code().

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

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

МНР должна поддерживать ограничения, накладываемые на Р-кадры, в соответствии с ISO/IEC [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) с ограничениями в соответствии со стандартом ETSI TR [36] (раздел 6).

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

7.1.6    MHP должна обеспечивать прием и вывод на экран терминала латинских символов, входящих в состав базового набора в соответствии со стандартом 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). При выводе на экран монитора субтитры DVB должны иметь приоритет перед телетекстом.

Управление приложением и обнаружение субтитров DVB или субтитров телетекста должно выполняться с помощью библиотеки 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 имя шрифта должно бытьЮпШ полем в файле шрифта. Файл 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, должны передаваться в цветовом пространстве YCrCb в соответствии с ETSI [5] (7.5.2).

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

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

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

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

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

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

Имена файлов библиотеки Java 2.JMF

Идентификаторы типов расширений*

Определение контента

“image/jpeg”

“.jpg”

В соответствии со стандартом ETSI [5] (7.1.1.2)

“image/png”

“.png”

В соответствии со стандартом ETSI [5] (7.1.1.3)

“image/gif”

“.gif”

В соответствии со стандартом ETSI [5] (7.1.1.4)

“image/mpeg”

“.mpg”

В соответствии со стандартом ETSI [5] (7.1.2)

“video/mpeg”

“.mpg”

В соответствии со стандартом ETSI [5] (7.2.2)

“video/dvb.mpeg.drip”

“.drip”

В соответствии со стандартом ETSI [5] (7.1.3)

“audio/mpeg”

“.mp2”

В соответствии со стандартом ETSI [5] (7.1.4)

“text/dvb.utf8”

“.txt”

В соответствии со стандартом ETSI [5] (7.1.5)

“image/dvb.subtitle”

“.sub”

В соответствии со стандартом ETSI [5] (7.2.3)

“text/dvb.subtitle”

“text/dvb.teletext”

“.tlx”

В соответствии со стандартом ETSI [5] (7.2.3.2)

“application/dvb.pfr”

“.pfr”

В соответствии со стандартом ETSI [5] (7.4)

“application/dvbj”

“.class”

В соответствии со стандартом ETSI [5] (6.2.5.1)

“multipart/dvb.service”

“.svc”

Применяется, если программа MPEG (Служба DVB) соответствует нормам DVB

* Вновь появляющиеся форматы могут иметь расширения с увеличенным количеством символов.

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

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

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

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

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

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

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

8.2.2    МНР должна поддерживать остановку приложений DVB-J по любой из причин, перечисленных для приложений вещания MHP по 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 [5] (9.2.3, таблица 7).

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

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

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

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

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

Вид вызова

Состояния Xlet

notifyDestroyed (уведомление о ликвидации)

все состояния

notifyPaused (уведомление о паузе)

активное

esumeRequest (запрос состояния)

пауза

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-    загрузка;

-    активное;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Преимущество в конфликте должно иметь приложение с более высоким application_priority.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(10.9);

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

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

таблица 39).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ся элементами одной субтаблицы.

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

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

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

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

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

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

7.1.5,13.5 настоящего стандарта.

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

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

application_identifier, передаваемого в таблице AIT. Идентификатор application_identifier включает в себя

поле organisation_id (32 бита), идентифицирующее организацию, ответственную за вещание приложения, и поле application_id (16 бит), уникально идентифицирующее приложение. Формирование значений

organisation_id должно быть в соответствии со стандартом ETSI TR [43]. Классификация полей

application_id должна быть в соответствии со стандартом ETSI [5] (10.5.1).

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

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

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

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

Коды управления жизненным циклом приложения DVB-J платформы МНР должны быть в соответствии с кодами, представленными в стандарте ETSI [5] (10.6.2.1, таблица 13). Параметры и состояния жизненного цикла приложений DVB-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.

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

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

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

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

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

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

Все дескрипторы сигнализации приложений платформы МНР должны переноситься в таблице РМТ элементарного потока. Параметры таблицы РМТ должны быть в соответствии с ГОСТ Р 53527 (приложение А.3). Значение поля stream_type, равное 0х05, индицирует передачу в элементарном потоке таблицы 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. Внешняя авторизация применяется к приложениям с идентифицированным полем application_identifier (), которые имеют поле application_type, идентифицированное

субтаблицей AIT, где содержится этот дескриптор.

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

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

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

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

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

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

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

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

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

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

дартом ETSI TR [43].

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

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

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

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

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

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

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

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

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

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

10.2.5    МНР не должен выполнять настройку, не предусмотренную в 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;

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

-    java.util;

-    java.util.zip;

-    java.io;

-    java.net;

-    java.beans;

-    java.math

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

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

-    java.io.FilePermission;

-    java.io.SerializablePermission;

-    java.lang.RuntimePermission;

-    java.util.PropertyPermission;

-    java.net.SocketPermission;

-    java.awt.AWTPermission

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.5.2    Требования к фильтру секций MPEG-2 программного интерфейса приложений платформы МНР должны быть в соответствии со спецификацией 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] (приложение H (за исключением H.4) и стандартом ETSI [5] (11.6.3).

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

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

-    javax.tv.service;

-    javax.tv.service.guide;

-    javax.tv.service.navigation;

-    javax.tv.service.transport

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

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

10.7.1 Программные интерфейсы приложений, поддерживающие жизненный цикл приложения DVB-J платформы МНР, должны формироваться из классов 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), в составе: ApplicationOrigin; 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] (приложение H, H.4), а также пакета класса javax.tv.locator в соответствии со спецификацией Java TV [45]. Уточнения применения API ссылок контента должны быть в соответствии со стандартом ETSI [5] (11.7.6).

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

-    NotAuthorizedException;

-    ObjectUnavailableException;

-    ResourceException;

-    TuningException.

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

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

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

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

(11.8.1.2);

-    в числе других классов должны поддерживаться классы:    java.io.FilePermission;

java.io.SerializablePermission;    java.lang.RuntimePermission;    java.util.PropertyPermission;

java.net.SocketPermission; java.awt.AWTPermission в соответствии со стандартом ETSI [5] (11.8.1.3).

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

-    javax.net;

-    javax.net.ssl;

-    javax.security.cert,

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

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

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

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

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

(11.9.1).

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

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

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

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

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

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

ниже:

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

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

-    код страны;

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

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

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

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

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

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

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

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

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

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

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

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

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

-    службы:

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

MPEG/DVB;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-    нотации XML;

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

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

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

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

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

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

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

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

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

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

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

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

или

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

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

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

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

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

13.3    Нотация XML

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

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

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

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

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

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

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

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

В тех случаях, когда идентификаторы organisation_id и application_id объединены в идентификатор

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

ранее описанного правила кодирования с идентификатором organisation_id как старшим значащим

битом и application_id как младшим значащим битом.

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

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

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

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

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

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

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

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

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

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

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

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

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

-    триплет числовых идентификаторов SI original_network_id, transport_stream_id иservice_id, соот

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типы медиа

Ссылки на настоящий стандарт

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

Загружаемые шрифты

7.4

org.dvb.ui.FontFactory

Аудиофайлы

7.1.4

org.havi.ui.HSound JMF только со ссылками на файлы

I-кадры изображений MPEG

7.1.1

org.havi.ui.HBackgroundImage

Изображения PNG

7.1.1.3

java.awt.Image

Изображения JPEG

7.1.1.2

java.awt.Image

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

ETSI EN [12]

JMF только со ссылками на службы DVB для воспроизведения непосредственно от сети

Видео “капли”

7.1.3

org.dvb.media.DripFeedDataSource

Файлы текста

7.1.5

Все программные интерфейсы приложений Java, читающие или пишущие текстовые файлы

Файлы субтитров

7.2.3

JMF только как часть службы DVB

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1]    ISO/IEC 13818-2 1996

2]    IETF RFC 2396 August 1998

3]    IETF RFC 1112 August 1989

4]    ITU-T Recommendation Z.100 (11/2007)

5]    ETSI ES 201 812 V1.1.2 (2006-08)

6]    ISO/IEC 13818-1 1996

7]    ISO/IEC 13818-6 1998

8]    ETSI EN 301 192 1.3.1

9]    ETSI TR 101 202 1.1.1

10]    IETF RFC 791 1.09.1981

11]    IETF RFC 768 28.08.1980

12]    ETSI EN 300 468 1.5.1

13]    ETSI ETR 211

14]    ETSI ETS 300 800

15]    ETSI ETS 300 801

[16]

ETSI

EN

301

193

1.1.1

[17]

ETSI

EN

301

195

1.1.1

[18]

ETSI

EN

301

199

1.2.1

[19]

ETSI

TR

101

201

1.1.1

[20]

ETSI

EN

301

790

V1.2.2

[21]

ETSI

EN

302

307

V1.2.1

(2009-04)

22]    IETF RFC 1332 May 1992

23]    IETF RFC 1661 July 1994

24]    IETF RFC 1717 November

1994

25]    IETF RFC 1877 December

1995

26]    IETF RFC 793 01.09.1981

27]    CORBA/IIOP 2.1

28]    IETF RFC2616 June 1999

29]    IETF RFC 1034 November 1987

30]    IETF RFC 1035 November 1987

31]    IETF RFC 1982 August

1996

32]    IETF RFC 2181 July 1997

33]    ISO/IEC 10918-1 1994

Information technology—Generic coding of moving pictures and associated audio information — Part 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 Description Language (SDL)

Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.0.3

Information technology — Generic coding of moving pictures and associated audio information — Part 1: Systems

Information technology — Generic coding of moving pictures and associated audio information — Part 6: Extensions for Digital Storage Media Command and Control (DSM-CC)

Specification for Data Broadcast Guidelines for the use of EN 301 192 (IP) Internet Protocol, J. Postel (UDP) 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 distribution systems (CATV)

DVB Interaction Channel through PSTN/ISDN DVB Interaction Channel through DECT

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) distribution systems; Guide lines for versions based on satellite and coaxial sections Digital Video Broadcasting (DVB); Interaction channel for satellite distribution 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 Point-to-Point Protocol (PPP)

The PPP Multilink 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

Serial Number Arithmetic

Clarifications to the DNS Specification

Information technology; digital compression and coding of continuous-tone still images; part 1: requirements and guidelines

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


[35] ISO/IEC 11172-3 1993

[36]    ETSI TR 101 154 1.9.1

[37]    ETSI EN 300 472 1.2.2

[38]    ETSI ETS 300 706 Edition 1-1997-05

[39]    DAVIC 1.4.1p9 June 1999 DAVIC 1.4.1 Specification Part 9

[40]    ISO 10646-1:2011

[41]    ITU-R BT.709

[42]    POSIX

[43]    ETSI TR 101 162

[44]    Java Media Player Specification

[45]    Java TV Part of ISBN:1-892488-25-6

[46]    JAE 1.1.8 const Part of ISBN:1-892488-25-6

[47]    JAE 1.2.2 const Part of ISBN:1-892488-25-6

[48]    JMF const Part of ISBN:1-892488-25-6

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)

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

Complete DAVIC. Specifications, DAVIC

Information technology — Universal multipleoctet coded character set (UCS), part 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) — Part 2: Shell and Utilities

Digital broadcasting systems for television, sound and data services; Allocation of Service Information (SI) codes for Digital Video Broadcasting (DVB) 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:681.327.8    ОКС    33.170    0КП65    7400

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

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

Сдано в набор 09.07.2012. Подписано в печать 05.09.2012. Формат 60 х 84^. Гарнитура Ариал.

Усл. печ. л. 4,65. Уч.-изд. л. 4,30. Тираж 114 экз. Зак. 759.

ФГУП «СТАНДАРТИНФОРМ», 123995 Москва, Гранатный пер., 4. www.gostinfo.ruinfo@gostinfo.ru Набрано во ФГУП «СТАНДАРТИНФОРМ» на ПЭВМ.

Отпечатано в филиале ФГУП «СТАНДАРТИНФОРМ» — тип. «Московский печатник», 105062 Москва, Лялин пер., 6.