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

ГОСТ Р 55712-2013

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

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

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

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

Digital broadcast television. Multimedia home platform. Classes 1.1. Basic parameters

ОКС 33.170

ОКП 657400

Дата введения 2014-09-01

Предисловие

1 РАЗРАБОТАН Автономной некоммерческой организацией "Научно-технический центр информатики" (АНО "НТЦИ")

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

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

4 Настоящий стандарт разработан с учетом основных нормативных положений:

- Европейского института по стандартизации в области телекоммуникаций (ETSI) ЕТСИ* Телевидение вещательное цифровое; Домашняя мультимедийная платформа (МНР) Спецификация 1.1.1 (ETSI TS 102 812 V1.2.1 (2003-06) Digital Video Broadcasting (DVB); Multimedia Home Platform (МНР) Specification 1.1.1);

________________

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

- Европейского союза вещания (EBU) Телевидение вещательное цифровое; Домашняя мультимедийная платформа (МНР) Спецификация 1.1.3 (DVB Document А068 Rev.3: Digital Video Broadcasting (DVB); Multimedia Home Platform (МНР) Specification 1.1.3, NEQ).

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

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

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

Настоящий стандарт распространяется на аппаратно-программный комплекс - домашняя мультимедийная платформа (Multimedia Home Platform; МНР), поддерживающий совокупность стандартов цифрового телевизионного вещания (Digital Video Broadcasting; DVB). Стандарты DVB обеспечивают широкий набор спецификаций цифровых систем вещания для различных сред передачи, включающих спутниковые, кабельные, наземные.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1.18 Интернет-клиент (приложение доступа в Интернет, приложение Интернет-клиент) (Internet client; Internet access application): Резидентное приложение терминала МНР, используемое для представления контента Интернета.

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

3.1.20 интерфейс API СА: Интерфейс между системой условного доступа (СА) и приложением МНР, является независимым интерфейсом высокого уровня, обеспечивающим доступ приложения к системам СА.

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

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

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

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

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

3.1.26 класс 1.0; класс 1.1: Классы МНР по видам предоставляемых услуг.

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

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

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

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

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

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

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

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

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

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

3.1.37 локатор DVB-HTML (locator): 1 Определитель местоположения. 2 В зависимости от формата приложения представляет собой ссылку, выраженную в синтаксисе стандарта IETF [2], которая является однозначным указанием на документ DVB-HTML, доступный для МНР в конкретном транспортном потоке. Определение этого термина действительно только в контексте DVB-HTML.

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

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

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

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

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

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

3.1.44 настройка (tuning): Акт (событие) переключения между двумя транспортными потоками MPEG или мультиплексами.

Примечание - Переключение между двумя службами DVB, переносимыми в одном и том же транспортном потоке, не является настройкой.

3.1.45 обратный канал (return channel): Механизм передачи информации, который обеспечивает соединение между МНР и удаленным сервером.

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

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

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

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

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

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

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

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

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

3.1.55 программный интерфейс приложения (интерфейс прикладных программ, прикладной программный интерфейс) (Application Programming Interface: API): Интерфейс между приложением и отдельными функциями или ресурсами МНР, используется приложением для управления выполнением системных процедур.

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

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

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

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

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

3.1.61 рекламные ссылки (Promotional links): Ссылки, определяющие механизм для ссылки на связанный материал в реальном времени. Предоставляют зрителю возможность заказывать просмотр контента, связанный с тем, что в настоящее время просматривается.

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

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

3.1.64 "сборщик мусора": Специальный код, периодически освобождающий память. "Сборщик мусора" удаляет объекты, которые не будут востребованы приложением. Используется в объектно-ориентированном языке программирования Java, использующем механизм "сборки мусора".

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

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

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

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

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

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

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

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

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

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

3.1.75 слушатель события (event-listener): Интерфейс "слушатель", который "прослушивает" происходящее на объекте для того, чтобы отследить возникновение события и обработать его.

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

3.1.77 совместимый плагин (interoperable plug-in): Плагин, который требует только стандартных интерфейсов API МНР.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1.99 язык XML (расширяемый язык разметки) (Extensible Markup Language; XML): Язык прикладного программного обеспечения, используется для создания веб-страниц.

3.1.100 DVB-HTML (Digital Video Broadcast - Hyper Text Markup Language): Технология, обеспечивающая доступ телевизионных приемников DVB к контенту в сети Интернет использованием языка HTML.

3.1.101 язык разметки гипертекста (язык HTML) (Hyper Text Markup Language; HTML): Стандартный язык описания гипертекстовых документов, используемых в сети Интернет. Язык HTML поддерживает функции форматирования текста, параметров шрифта, включения видео и звука, запуска программ поиска, вывода на экран документов и создания гиперссылок.

3.1.102 HTML-3.2: Версия языка HTML, обеспечивающая расширение свойств языка применением таблиц, аплетов, размещением текста вокруг изображения.

3.1.103 RGB (Red, Green, Blue); красный, зеленый, синий: Модель цвета, основанная на аддитивном смешивании цветов.

3.1.104 STB (Set Top Box): Модуль, включающий в себя модули Set Top Unit (STU) и Network Interface Unit (NIU). STB может иметь интегрированное или модульное исполнение. Интегрированный STB предназначен для подключения к единственному интерфейсу DAVIC А1 или к эквивалентному интерфейсу. Модульный STB может иметь интерфейс DAVIC А0 в соответствии со стандартами DAVIC [5] (приложение I, 2.2). EN [6] (приложение В, раздел 4) или его эквивалент и позволяет подключение нескольких NIU.

3.1.105 STU (Set Top Unit): Модуль, содержащий "сеть независимых" функциональностей приставок для STB. Типовой STU обеспечивает следующие функциональные возможности: обработка и функции памяти, демультиплексор MPEG-2 и аудио-, видеодекодеры, графический дисплей, модулятор ТВ-сигнала, интерфейсы периферийных устройств.

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

3.1.107 trick: Режим воспроизведения записи PVR.

3.1.108 Usenet: Всемирная сеть системы Unix, имеющая централизованное управление и используемая телеконференциями в качестве системы электронных досок.

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

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

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

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

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

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

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

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

ТВ Anytime (TV-Anytime) - телевидение в любое время;

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

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

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

AWT (Abstract Windowing Toolkit) - инструментарий работы с окнами;

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

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

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

CORBA (Common Object Request Broker Architecture) - архитектура брокера общих объектных запросов;

CRID (Content Reference IDentifier) - идентификатор ссылок контента;

CRL (Certificate Revocation Lists) - список отозванных сертификатов;

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

DII (Download lnfo lndication) - сообщение индикации информации загрузки Download lnfo lndication в Карусели Объектов DSM-CC;

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

DOM (Document Object Mode) - объектная модель документа;

DTD (Document Type Definition) - описание типа документа;

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 application - приложение DVB-HTML;

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

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

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

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

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

DVB-HTML locator - локатор DVB-HTM;

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

DVB network - сеть DVB;

EBU (European Broadcasting Union) - Европейский союз радиовещания;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IOP (input/output processor) - процессор ввода/вывода:

IOR (Interoperable object reference) - ссылка на интероперабельный объект;

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

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

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

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

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

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

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;

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

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

MHP-PVR (Multimedia Home Platform - Personal Video Recorder) - система PVR в составе МНР;

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

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

MMI_done - сообщение о состоянии готовности интерфейса MMI;

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

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

MPEG-5 - стандарт кодирования интерактивных мультимедийных приложений;

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

NIU (Network Interface Unit) - модуль интерфейса сети;

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

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

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

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

PDR (Personal Digital Recorder) - персональный цифровой магнитофон (см. PVR);

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

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

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

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

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

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

PVR (Personal Video Recorder) - персональный видео рекордер (магнитофон);

RCMM (Root Certificate Management Messages) - сообщения управления корневым сертификатом;

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

RGB (Red, Green, Blue) - красный, зеленый, синий;

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

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

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

SDL (Specification and Description Language) - язык спецификаций и описаний;

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

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

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

SSL (Secure Sockets Layer) - уровень защищенных сокетов;

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

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

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

TLS (Transport Layer Security) - протокол безопасности транспортного уровня;

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

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

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) - унифицированный локатор (определитель местонахождения) ресурса;

Usenet - всемирная сеть системы Unix;

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

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

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

TV-Anytime (ТВ Anytime) - телевидение в любое время;

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

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

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

YCrCb - цветовое пространство.

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

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

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

- класс 1.1 - дополнительно к возможностям класса 1.0 обеспечивается обработка приложений с сохранением контента на устройстве пользователя, обработка приложения через каналы с IP протоколом, поддержка смарт-карт, поддержка доступа в Интернет.

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

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

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

- Internet Access Profile (профиль доступа в Интернет).

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

5.1 Базовая структура МНР

Базовая структура МНР характеризуется следующими основными условиями и решениями:

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

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

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

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

5.2 Контекст применения МНР

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

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

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

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

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

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

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

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

5.3.1 Базовая архитектура МНР показана на рисунке 1. Аппаратурные средства и программное обеспечение МНР размещены на следующих основных уровнях:

- уровень приложений;

- уровень системного программного обеспечения;

- уровень ресурсов.

Рисунок 1 - Базовая архитектура МНР

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

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

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

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

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

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

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

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

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

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

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

5.5 Плагины

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

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

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

- совместимых плагинов, требующих только стандартных API МНР;

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

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

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

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

МНР поддерживает следующие транспортные протоколы:

- транспортные протоколы канала вещания в соответствии со стандартом ETSI [7] (6.1), ГОСТ Р 54456 (6.1);

- транспортные протоколы интерактивных каналов в соответствии со стандартом ETSI [7] (6.3), ГОСТ Р 54456 (6.2);

- транспортные протоколы для загрузки приложений через интерактивный канал ETSI [7] (6.4).

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

В таблице 1 представлен перечень основных транспортных протоколов, поддерживаемых профилями платформы МНР.

Таблица 1 - Перечень основных транспортных протоколов, поддерживаемых профилями платформы МНР

6.2 Транспортные протоколы для загрузки приложений через интерактивный канал

Предусматриваются три сценария загрузки приложений:

- файловая система полностью реализована в канале телевизионного вещания (классическая МНР модель 1.0, которая в настоящем стандарте не описывается);

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

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

6.2.1 Файловая система, реализующаяся через интерактивный канал

Нормируется вариант, в котором интерактивный канал предоставляет файловую систему с ID протокола 0x0003.

6.2.1.1 Логическая структура файловой системы

Список элементов (URL), сигнализированных в дескрипторе (дескрипторах) транспортного протокола согласно стандарту ETSI [7] (10.8.1.3), позволяет формировать единственное пространство имен.

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

Элементы в списке согласно стандарту ETSI [7] (6.4.1.1) должны быть или ссылками на файлы с расширением zip в соответствии со стандартом ATSC [25] или на базовые URL, заканчивающиеся в " /' ", с которыми должен быть связан путь к требуемому файлу. Должны игнорироваться любые элементы в списке, не относящихся к одному из этих двух типов. Конкретный файл с обнаруживаемыми ошибками через конкретный элемент списка должен игнорироваться.

Пример процедуры извлечения файла "dvb.fontindex" для приложения представлен в стандарте ETSI [7] (6.4.1.1).

6.2.1.2 Передача файлов

Файлы должны передаваться при использовании профиля HTTP/1.0 в соответствии со стандартом ETSI [7] (6.3.7.2).

6.2.1.3 Кодирование класса

Классы приложений DVB-J могут поставляться как дискретные файлы класса или как файлы ZIP согласно стандарту ATSC [25].

Примечание - Этот случай отличается от случая вещания, где объектные файлы Карусели являются файлами класса.

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

Примечание - Это означает, что файлы класса DVB-J на сервере HTTP могут быть любыми дискретными файлами класса или файлами ZIP согласно стандарту ATSC [25], где файлы ZIP являются частью полной файловой системы.

6.2.1.4 Содержание каталога в файловой системе

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

- аутентификация в соответствии со стандартом ETSI [7] (12.4.1.5);

- перечисление файлов в каталоге в соответствии со стандартом ETSI [7] (14.7).

6.2.2 Параметры гибридного варианта файловой системы вещательного потока и интерактивного канала

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

6.2.2.1 Передача файлов

6.2.2.1.1 Передача файла по каналу вещания

Содержание файла переносят при использовании протокола BIOP::File. В соответствии с нормальным случаем Карусели Объектов, определенной в ГОСТ Р 54456 (6.1.6) или стандарте ETSI [7] (6.4.2.1.1), от привязки файла до его наполнения используется или BIOPProfileBody или LiteOptionsProfileBody.

6.2.2.1.2 Передача файла через интерактивный канал

В случае доставки файла через интерактивный канал ссылка IOR для идентификации расположения контента файла в интерактивном канале от привязки файла до наполнения файла использует HTTPProfileBody. В таблице 2 представлен синтаксис тела профиля HTTP. Эта форма IOR должна использоваться только для объектов BIOP:: File.

Таблица 2 - Синтаксис тела профиля HTTP

Для профиля HTTP получение (поиск) содержания файла выполняется в соответствии со стандартом ETSI [7] (6.3.7.2).

Параметры семантики полей:

version: Поле 8 битов указывает на версию протокола, который сервер будет использовать для доставки определенного файла. Значение версии HTTP 1.0 указывает, что транспортный протокол определяется в соответствии со ETSI [7] (6.3.7.2).

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

port: Поле 16 битов указывает номер порта TCP/IP в указанном узле, где целевой агент прослушивает запросы.

objectKey_data: Эти байты формируют строку, которая переносит часть URL path_segments, которая уникально идентифицирует объект на сервере в соответствии со стандартом IETF [2].

6.2.2.1.3 Синтаксис HTTPProfileBody

Тело профиля HTTP определяет узел, порт и путь, состоящий из сегментов (path_segments). В запросах HTTP они соединены для формирования URL в виде строки:

http://host:port/path_segments

6.2.2.2 Кодирование класса

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

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

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

- статические форматы в соответствии с ГОСТ Р 54456 (7.1);

- форматы потокового вещания в соответствии с ГОСТ Р 54456 (7.2);

- форматы резидентных шрифтов в соответствии с ГОСТ Р 54456 (7.3);

- форматы загружаемых шрифтов в соответствии с ГОСТ Р 54456 (7.4);

- форматов представления цвета в соответствии с ГОСТ Р 54456 (7.5);

- форматы многоцелевых расширений почты Интернета в соответствии с ГОСТ Р 54456 (7.6).

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

8.1 Общие характеристики приложений вещания

Параметры приложений вещания платформы МНР, параметры управления жизненным циклом приложения вещания платформы МНР должны быть в соответствии с ГОСТ Р 54456 (8.1).

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

Параметры модели приложений DVB-J должны быть в соответствии с ГОСТ Р 54456 (8.2).

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

Параметры модели приложений DVB-HTML должны быть в соответствии с ГОСТ Р 54456 (8.3).

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

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

Общие параметры сигнализации приложения МНР должны быть в соответствии с ГОСТ Р 54456 (9.1).

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

Параметры сигнализации программно-зависимой информации должны быть в соответствии с ГОСТ Р 54456 (9.2).

9.3 Параметры сигнализации таблицы информации

Параметры сигнализации таблицы информации приложений должны быть в соответствии с ГОСТ Р 54456 (9.3).

9.4 Параметры сигнализации идентификации

Параметры сигнализации идентификации приложений должны быть в соответствии с ГОСТ Р 54456 (9.4).

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

Параметры сигнализации механизма управления жизненным циклом приложений должны быть в соответствии с ГОСТ Р 54456 (9.5).

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

Параметры универсальных дескрипторов сигнализации приложений должны быть в соответствии с ГОСТ Р 54456 (9.6).

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

Параметры дескрипторов транспортного протокола должны быть в соответствии с ГОСТ Р 54456 (9.7).

9.8 Параметры специфичных дескрипторов DVB-J

Параметры специфичных дескрипторов DVB-J (дескриптора приложений DVB-J и дескриптора локации DVB-J ) должны быть в соответствии с ГОСТ Р 54456 (9.8).

9.9 Параметры специфичных дескрипторов приложения DVB-HTML

Параметры специфичных дескрипторов приложения DVB-HTML (дескриптор приложения DVB-HTML, дескриптор локации приложения DVB-HTML, (дескриптор границ приложения DVB-HTML) должны быть в соответствии с ГОСТ Р 54456 (9.9).

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

Область применения, типы, величины и ссылка на источник определения констант дескрипторов должны быть в соответствии с ГОСТ Р 54456 (9.10).

9.11 Дескриптор идентификатора службы

Дескриптор идентификатора службы должен быть в соответствии с ГОСТ Р 54456 (9.11).

10 Параметры DVB-J

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

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

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

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

Перечень общих правил применения программных интерфейсов приложений DVB-J со ссылками на нормативные документы, определяющими параметры их применения, в соответствии с ГОСТ Р 54456 (10.2) представлен в таблице 3.

Таблица 3 - Перечень общих правил применения программных интерфейсов приложений DVB-J

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

Параметры основных программных интерфейсов приложений DVB-J должны быть в соответствии с ГОСТ Р 54456 (10.3).

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

Параметры программных интерфейсов приложений представления (воспроизведения) должны быть в соответствии с ГОСТ Р 54456 (10.4).

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

Параметры программных интерфейсов приложений доступа к данным должны быть в соответствии с ГОСТ Р 54456 (10.5).

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

В состав программных интерфейсов приложений информации о службе и выбора службы входят следующие API:

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

- API выбора службы;

- API настройки МНР;

- протокол API независимой служебной информации;

- API ограниченного (условного) доступа.

Параметры API информации о службах (SI) должны быть в соответствии с ГОСТ Р 54456 (10.6.1).

Параметры API выбора службы должны быть в соответствии с ГОСТ Р 54456 (10.6.2).

Параметры API настройки МНР должны быть в соответствии с ГОСТ Р 54456 (10.6.3).

Параметры протокола API независимой SI определены следующими пакетами Java TV:

- javax.tv.service;

- javax.tv.service.guide;

- javax.tv.service.navigation;

- javax.tv.service.transport.

Отображение этих пакетов на протокол DVB-SI определено стандартом ETSI [7] (11.6.5 и приложение О).

10.6.1 Программный интерфейс приложения системы ограниченного (условного) доступа

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

Интерфейс API СА обеспечивает приложения системы условного доступа независимым интерфейсом для доступа к функциям, связанным с СА, например, к электронным путеводителям по программам (Electronic Program Guide, EPG). Операции низкого уровня функциональности (например, операция обработки сообщений EMM и ЕСМ) выполняются системой СА автономно, они остаются невидимыми для приложений МНР и в настоящем стандарте не рассматриваются.

10.6.1.2 Общие параметры

Интерфейс API СА должен поддерживать реализацию приложений пользовательских диалогов высокого уровня MMI при условии обеспечения необходимой безопасности. Решения интерфейса API СА должны быть совместимыми с требованиями настоящего стандарта и требованиями к интерфейсу условного доступа технической спецификации DAVIC [5] (приложение I).

10.6.1.3 Общие требования к системе СА и к интерфейсу API СА

Интерфейс API СА должен поддерживать модули СА, которые могут быть модулями типа DAVIC СА0 в соответствии с технической спецификацией стандарта DAVIC [5] (приложение I, 2.2) или совместимыми модулями типа DAVIC СА1. Должны поддерживаться конфигурации модулей смешанных типов (СА0 и СА1 одновременно).

Примечание - В настоящем стандарте устройство СА упоминается как модуль, даже если в случае СА1 он представляет собой смарт-карту.

Интерфейс API СА должен обеспечивать поддержку собственной системы СА с расширениями DAVIC, относящимися к системе СА.

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

Интерфейс API СА должен обеспечивать передачу приложениям уведомлений об удалении или установке модулей СА во время выполнения приложений.

Интерфейс API СА должен обеспечивать приложению получение списка идентификаторов систем условного доступа, поддерживаемых STB.

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

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

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

10.6.1.4 Требования масштабируемости API СА

Интерфейс API СА должен:

- поддерживать МНР с несколькими модулями сетевого интерфейса и несколькими входящими транспортными потоками;

- поддерживать не менее одного модуля СА;

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

10.6.1.5 Требования к дескремблированию

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

Интерфейс API СА должен обеспечивать формирование отчета о возможности (или невозможности) дескремблирования транспортного потока в случаях отсутствия доступа модуля NIU к модулю безопасности или в случае несовпадения скремблирующих алгоритмов.

Интерфейс API СА должен поддерживать процедуры проверки возможности дескремблирования определенной службы или события в случаях, когда модуль имеет для этой цели необходимые ресурсы. Служба или событие могут находиться или могут не находиться в процессе обработки. Интерфейс API СА должен позволить системе СА накладывать ограничения на доступ к этим данным. Например, для СА0 в соответствии со стандартом EN [6] (приложение В, часть 4).

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

10.6.2 Модель объекта API СА и состояния API СА

10.6.2.1 Модель объекта

Параметры модели объекта API СА должны быть в соответствии со стандартом DAVIC [5] (приложение I, 3.1).

Модель объекта включает следующие основные части:

- класс CAModule, который является абстракцией физического модуля СА. Он обеспечивает функции запроса о правах и получения соответствующей информации;

- класс DescramblerProxy, реализующий интерфейс ResourceProxy для управления ресурсами;

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

- классы TransportStream, Service (служба) и ElementaryStream от API компонентов MPEG, использующиеся в качестве параметров в методах классов CAModule и DescramblerProxy;

- объект CAModuleManager, управляющий модулями СА и отслеживающий доступные модули в STU. При реализации объекта CAModuleManager автоматически создает экземпляр CAModule и регистрирует его, когда модуль вставляется в STU. Класс CAModule не имеет общедоступного конструктора. CAModule автоматически удаляется из объекта CAModuleManager при удалении модуля из STU.

10.6.2.2 Состояния интерфейса API СА

На рисунке 3 показаны три состояния, в которых может находиться система СА:

- "дескремблирование не введено" (no_descrambling),

- "готовность интерфейса MMI" (MMI_done);

- "дескремблирование введено" (descrambling).

Рисунок 3 - Изменения состояния системы СА

По умолчанию система (класс CAModule) устанавливается в состояние "дескремблирование не введено". В этом состоянии дескремблирование не выполняется. Переход в состояние "дескремблирование введено" может быть выполнен двумя способами. Первый способ реализуется прямым вызовом метода startDescrambling. После вызова этой функции начинается процесс дескремблирования. В этом случае представление информации может включать диалоги пользователя по запросам системы СА. Если дескремблирование при использовании первого способа невозможно, то применяется второй способ, который заключается в вызове метода startDescramblingDialog. Это заставляет систему СА, в случае необходимости, начинать диалог с пользователем и ввести состояние "готовность интерфейса MMI" MMI_done. После этого состояние "дескремблирование введено" может быть достигнуто вызовом метода startDescrambling.

10.6.3 Определения интерфейса API СА, параметры интерфейса API СА

В API СА входят следующие составные части:

- исключения (Exceptions);

- модель слушателя событий (Event-Listener model);

- модель слушателя событий MMI;

- модель слушателя событий, пересылка сообщений (Event-Listener model, Message passing);

- CAModule-Manager;

- CAModule;

- DescramblerProxy;

- CA0Module;

- CA1Module;

- MMI;

- передачи сообщений (Message Passing).

Перечень составных частей API СА и их определений должен быть в соответствии со стандартом DAVIC [5] (приложение I, раздел 4).

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

Параметры общей инфраструктуры программных интерфейсов приложений DVB-J должны быть в соответствии с ГОСТ Р 54456 (10.7).

10.8 Параметры API, обеспечивающие безопасность приложений DVB-J

Параметры API, обеспечивающие безопасность приложений DVB-J, должны быть в соответствии с ГОСТ Р 54456 (10.8).

10.9 Программные интерфейсы приложений DVB-J поддержки таймера, установок и предпочтений пользователя

Программные интерфейсы приложений DVB-J поддержки таймера должны быть в соответствии с ГОСТ Р 54456 (10.9.1) с ограничением в соответствии со стандартом DVB [27] (11.9.1).

Программный интерфейс приложений DVB-J поддержки установок и предпочтений пользователя должен быть в соответствии с ГОСТ Р 54456 (10.9.2).

Требования к обнаружению приложениями профилей, поддерживаемых терминалом, должны быть в соответствии со стандартом DVB [27] (11.9.3).

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

Правила доступа к ресурсам приложений должны обеспечиваться в соответствии с ГОСТ Р 54456 (10.10) с уточнениями в соответствии со стандартом DVB [27] (11.10.1.11, 11.101.12, 11.10.2.11-11.10.2.15).

10.11 Параметры соответствия между объектами, типами локатора и их текстовыми представлениями

Параметры соответствия между объектами, типами локатора и их текстовыми представлениями должны быть в соответствии с ETSI [7] (11.11).

10.12 Параметры автономных приложений

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

Параметры автономных приложений должны быть в соответствии со стандартом ETSI [7] (11.12).

10.13 Параметры поддержки DVB-HTML

10.13.1 Объектная модель документа (Document Object Mode, DOM) представляет собой программный интерфейс, обеспечивающий программам доступ к содержимому HTML-документов, а также возможность изменять содержимое, структуру и оформление таких документов. Требования к объектной модели документа должны быть в соответствии со стандартом ETSI [7] (11.13.1).

10.13.2 Параметры расширенной модели DOM, определенные DVB, должны быть в соответствии со стандартом ETSI [7] (приложения AD и AD.1).

10.13.3 Доступ к объектной модели документа для чтения (только) или вызова методов в API DOM для изменения модели DOM должен выполняться в соответствии со стандартом ETSI [7] (11.13.1.3).

10.13.4 Список семантических различий в API МНР между приложениями DVB-J и xlets, встроенными в страницу DVB-HTML приложения DVB-HTML, должен быть в соответствии со стандартом ETSI [7] (11.13.2).

10.14 Доступ в Интернет

10.14.1 Прикладные программные интерфейсы управления Интернет-клиентами

Параметры прикладных программных интерфейсов приложений управления Интернет-клиентам должны быть в соответствии со стандартом ETSI [7] (приложение АН).

Интернет-клиенты, доступные приложениям МНР, должны появляться в списке служб, обслуживаемых методом SIManager, которые возвращаются при вызове метода SIManager.fillerServices. Детализированные правила поддержки приложений Интернет-клиентов должны быть в соответствии со стандартом ETSI [7] (11.14.1).

10.14.2 Поддержка аплетов Интернета

Аплеты Интернета должны поддерживаться с помощью меток "< >" и "<object" с семантикой, определенной в Спецификации [28].

Для аплетов Интернета должны поддерживаться особенности платформы DVB-J (так же, как они поддерживаются для DVB-J приложений) в соответствии со стандартом ETSI [7] (11.14.2.2).

Для аплетов Интернета должны расширяться или изменяться общие характеристики платформы МНР в соответствии со стандартом ETSI [7] (11.14.2.3).

Должны поддерживаться пакеты Java.awt в соответствии со стандартом Java [29] с изменениями в соответствии со стандартом ETSI [7] (11.14.2.4).

Должны обеспечиваться дополнительные возможности поддержки аплетов Интернет в соответствии со стандартом ETSI [7] (11.14.2.4).

Настоящий стандарт не требует поддержки аплетов Интернета подписью или поддержки механизма подписывания кода и API-интерфейсов, как определено в стандарте Java [29].

Аплеты Интернета должны иметь разрешения в соответствии со стандартом ETSI [7] (11.14.2.6).

11 Безопасность МНР

11.1 Состав параметров безопасности МНР

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

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

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

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

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

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

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

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

Размещение файлов зависит от их функций и определяется соответствующими заголовками в соответствии со стандартом ETSI [7] (12.4).

"Хэш-коды" применяются к следующим типам информации:

- файлы;

- каталоги (директории).

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

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

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

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

- значением (величиной), используемой при создании цифровой подписи.

Детализированные параметры аутентификации приложений должны быть в соответствии со стандартом ETSI [7] (12.2).

11.3 Параметры передачи сообщений безопасности

Сообщения безопасности передаются в файлах в соответствии со стандартом ETSI [7] (12.3).

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

Параметры профилирования приложений, соответствующих стандарту ITU-Т [30], определенных в соответствии со стандартом IETF [31] для аутентификации приложений вещания платформы МНР, должны быть в соответствии со стандартом ETSI [7] (12.5).

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

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

- права доступа по требованию вещателя с использованием сигнализации;

- права доступа, предоставляемые пользователю.

Детализированные параметры политики безопасности должны быть в соответствии со стандартом ETSI [7] (12.6).

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

Пример создания приложения, которое может быть аутентифицировано, является справочным. Он включает в себя примеры вычисления хэшей и "подписей". Детализированное описание примера приведено в стандарте ETSI [7] (12.7).

11.7 Процедуры сертификации МНР

Процедуры сертификации МНР в настоящем стандарте не рассматриваются.

11.8 Процесс управления сертификатом

Процесс управления сертификатом должен включать операции управления списком отозванных сертификатов (Certificate Revocation Lists; CRL) и операции управления корневым сертификатом с использованием механизма сообщений управления корневым сертификатом (Root Certificate Management Messages; RCMM).

Параметры управления списком отозванных сертификатов должны быть в соответствии со стандартом ETSI [7] (12.9.1).

Параметры управления корневым сертификатом должны быть в соответствии со стандартом ETSI [7] (12.9.2).

11.9 Параметры безопасности обратного канала

11.9.1 Протокол безопасности транспортного уровня

Основной вклад в безопасность обратного канала обеспечивается применением протокола безопасности транспортного уровня (Transport Layer Security; TLS) в соответствии со стандартами ETSI [7] (12.10) и IETF [32].

11.9.2 Функциональные возможности МНР при обеспечении безопасности

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

К МНР не следует предъявлять требования:

- выполнения функций сервера TLS;

- соответствия требованиям протокола SSL 3.0 в соответствии со стандартом IETF [33];

- выполнения аутентификации клиента TLS.

11.9.3 Комплекты шифров TLS

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

- RSA ( );

- MD5;

- SHA-1;

- DES.

Детализация методов шифрования для реализаций МНР представлена в стандарте ETSI [7] (12.10, таблица 132). Определения терминов приведены в стандарте IETF [32].

11.9.4 Загрузка сертификатов протокола TLS

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

Интерфейс API, используемый загружаемым приложением, описан в подразделе 10.8 и в ETSI [7] (11.8.2).

Процесс проверки подлинности сервера включает в себя проверку цепочки сертификатов, отправленного сервером TLS.

Правила использования сертификата TLS для случаев, когда корневые сертификаты передаются вместе с заявкой, должны быть в соответствии с ETSI [7] (12.10.3.2.1).

Правила использования сертификата TLS для случая, когда передача сертификатов не предусмотрена, должны быть в соответствии с ETSI [7] (12.10.3.2.2).

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

11.10 Параметры профиля Интернет

Параметры профиля Интернет на основе стандарта ITU-T [30] по версии стандарта IETF [31], описывающего (справочно) основную часть сертификатов и стандартные расширения сертификатов, приведены в стандарте ETSI [7] (12.11).

11.11 Аппаратная реализация МНР

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

11.12 Безопасность применения плагинов

Безопасность применения плагинов должна обеспечиваться также, как и в случае применения любого приложения DVB-J. Детализация вопросов безопасности применения плагинов должна быть в соответствии со стандартом ETSI [7] (12.13).

11.13 Безопасность загрузки приложений из интерактивного канала

Безопасность загрузки приложений из интерактивного канала должна обеспечиваться аналогично случаю загрузки приложений из вещательного канала при следующих особенностях загрузки. Особенности загрузки приложений из интерактивного канала включают в себя инициацию начала загрузки, загрузку приложения и динамическую загрузку на интервале жизни приложения, загрузку кода приложения и поддержку загруженных данных. Детализация правил загрузки должна быть в соответствии со стандартом ETSI [7] (12.14.1).

11.14 Хранение приложений

Хранение приложений должно выполняться в соответствии со стандартом DVB [27] (12.15).

11.15 Безопасность внутренних приложений и контента, встроенного в другие приложения

Безопасность внутренних приложений и контента, встроенного в другие приложения, обеспечивается наследованием набора полномочий, предоставленных приложению, в которое они встроены, в соответствии с ETSI [7] (12.16).

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

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

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

Обязательные требования к графическим возможностям терминала МНР должны быть в соответствии со стандартом ETSI [7] (G.1).

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

Аспекты системной интеграции МНР включают в свой состав следующие части:

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

- зарезервированные имена файлов;

- нотация XML;

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

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

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

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

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

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

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

Требования к перечисленным частям должны быть в соответствии с ГОСТ Р 54456 (13.1-13.10).

14 Определения профилей МНР

14.1 Детализированные определения профилем МНР должны быть в соответствии со стандартом ETSI [7] (таблица 137).

14.2 Требования к формату PNG должны быть в соответствии с ГОСТ Р 54456 (14.1).

14.3 Требования к составу форматов медиа, поддерживаемых API DVB-J, должны быть в соответствии с ГОСТ Р 54456 (14.2).

14.4 Требования к формату JPEG должны быть в соответствии с ГОСТ Р 54456 (7.1.1.2 и 14.3).

14.5 Требования к поддержке локалей должны быть в соответствии с ГОСТ Р 54456 (14.4).

14.6 Требования к растру видеоизображения в зависимости от формата видеоизображения должны быть в соответствии с ГОСТ Р 54456 (14.5).

15 Параметры системы хранения контента на персональном устройстве видеозаписи в составе МНР

15.1 Базовая архитектура персонального устройства видеозаписи в составе МНР

При использовании этого раздела стандарта должны дополнительно выполняться требования стандарта ETSI [7].

15.1.1 Архитектура персонального устройства видеозаписи, работающего в составе МНР (MHP-PVR)

На рисунке 4 представлена упрощенная архитектура MHP-PVR.

Рисунок 4 - Упрощенная архитектура MHP-PVR

Ядром архитектуры MHP-PVR является список записей и устройство управления записью. Список записей включает ожидаемые и завершенные записи. Ожидаемые записи могут включать записи фиксированные по времени и продолжительности на определенном телеканале, а также записи, выполнение которых может перемещаться во времени или по каналам. Например, записи, определенные DVB SI или CRID TV-Anytime.

Устройство управления записью обеспечивает:

- управление ожиданием (очередями) записей;

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

- взаимодействие механизма ссылки контента TV-Anytime при ожидании записи с конкретным идентификатором CRID TV-Anytime;

- обновление состояния (параметров) записей в перечне записей.

Приложения MHP-PVR могут использовать API управления записью для выполнения следующих задач:

- записи поступающих запросов;

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

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

Приложения MHP-PVR могут использовать API ссылок контента TV-Anytime, чтобы получить доступ к реализации механизма ссылки контента TV-Anytime. Приостановка текущего ("живого") телеканала поддерживается использованием API "сдвиг времени". Воспроизведение завершенных записей поддерживается расширенными версиями существующего МНР API воспроизведения медиа.

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

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

- база данных для TV-Anytime, определяемая метаданными и API, для получения доступа к этой базе данных;

- механизмы, обеспечивающие точные методы записи.

15.1.2 Общие требования к системе PVR в составе МНР (MHP-PVR)

К пакетам, определенным в настоящем стандарте, должны применяться требования к слушателям событий ETSI [26] (11.2.5) и к моделям событий DAVIC и интерфейсов DVB API в соответствии со стандартом ETSI [26] (11.2.7).

Приложения не должны определять классы или интерфейсы в пространстве имен пакета, определенных в настоящем стандарте.

Терминалы МНР должны использовать механизм SecurityManager.checkPackageDefinition.

15.2 Параметры процесса записи и воспроизведения в системе MHP-PVR

15.2.1 Параметры управления запланированной записью

Процесс управления запланированными записями в соответствии со стандартом ETSI [34] (6.1) должен включать следующие мероприятия:

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

- обслуживание списка записи запросов:

- выявление записей, которые были успешно завершены (COMPLETED_STATE);

- выявление записей, которые были начаты, но не были успешно завершены (INCOMPLETE_STATE);

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

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

- обслуживание ссылок на запросы записи, которые не удалось выполнить (FAILED_STATE) в списке записи запросов.

В дополнение к перечисленным мероприятиям должны выполняться следующие операции, определенные стандартом ETSI [35] (6.1):

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

- разрешение конфликтов между отдельными "записями в ожидании" независимо от способа их формирования.

Примечание - Настоящий стандарт не устанавливает требований к алгоритмам или механизмам для разрешения этих конфликтов. Единственное требование настоящего стандарта состоит в том, что реализации MHP-PVR должны содержать такой механизм;

- отбрасывание запросов "записей в ожидании", когда истек срок их действия, но не ранее (опционально);

- отбрасывание поврежденных запросов "записей в ожидании", если срок их действия истек, но не ранее (опционально).

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

15.2.2 Операции процесса записи

Процесс записи в соответствии со стандартом ETSI [34] (6.2) должен включать следующие мероприятия:

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

- запись идентифицированных потоков (до пределов возможностей терминалов);

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

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

- формирование времени записи медиа, которое линейно увеличивается на скорости 1,0 от начала до конца записи;

- запись SI, достаточной для идентификации языка, связанного с записываемыми потоками (например, аудио);

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

- запись начинается, необходимый ресурс не доступен;

- запись происходит, необходимый ресурс потерян;

- запись происходит без необходимого ресурса, и ресурс становится доступным;

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

- добавлен элементарный поток с аудиоданными, видеоданными или данными;

- удален элементарный поток с аудиоданными, видеоданными или данными;

- элементарный поток с аудиоданными, видеоданными или данными изменен, например, изменен PID.

В дополнение к перечисленным мероприятиям должны выполняться следующие операции, определенные стандартом ETSI [35] (6.2):

- выполнение точной записи с использованием механизмов, определенных в стандарте ETSI [36] (11);

- получение полномочий (разрешения) вещательной компании (вещателя) для частей контента в записи в соответствии со стандартом ETSI [35] (9.1.2). В том случае, если оценка полномочия вещателя согласно стандарту ETSI [35] (10.1.1) показывает, что разрешение на запись не получено, то запись не должна быть начата и запрос записи должен перейти в состояние FAILED_STATE;

- ассоциирование (связывание) с записью описательных метаданных DVB SI (заголовок, резюме и дескриптор расширенного события) для части контента, который составляет самую большую часть записи и для всех полных частей из контента, найденных в записи. Любые описательные метаданные, ранее связанные с запросом записи, отбрасываются;

- соединение дескрипторов разрешения вещателя с записями следующим образом:

- для записей, определенных event_id DVB-SI, дескриптор разрешения вещателя для указанного event_id DVB-SI должен быть сохранен;

- для записей, определенных только по времени и продолжительности (без tva_id или event_id), дескрипторы разрешения вещателя для всех событий DVB-SI в этом интервале должны быть сохранены.

Примечание - Записи, определенные по времени, продолжительности (или без tva_id или без event_id), предназначены для использования в тех случаях, когда EIT не совпадает с контентом. В этих случаях полномочия вещателя с изменениями дескриптора также не будут совпадать с контентом, к которому они обращаются;

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

Протоколы для переданных сроков доставки, упомянутых в стандарте ETSI [34], должны синхронизироваться вспомогательными данными в соответствии со стандартом ETSI [37] и нормальным временем воспроизведения DSM-CC в соответствии со стандартами ETSI [7], [26].

15.2.3 Идентификация записываемых потоков

В настоящем стандарте термин "записываемые потоки", используемый в ETSI [34], обозначает потоки, определенные в стандартах ETSI [7] (7.2), [26].

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

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

Примечание - Обязательные минимальные возможности записи потоков определены в разделе 15 настоящего стандарта;

- если существующее количество потоков любого типа превышает количество потоков, которое терминал MHP-PVR может записать, решение о записи должно быть принято в соответствии со стандартами ETSI [7], [26] (11.4.2.3).

15.2.4 Идентификация и запись приложении MHP-PVR

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

- если приложение не использует динамические данные и не использует синхронизацию аудио/видео и если было сигнализировано разрешение записи приложения (флаг дескриптора scheduled_recording_flag в записи приложения установлен в "1"), тогда приложение должно быть записано;

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

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

В процессе записи терминал MHP-PVR должен:

- выполнять мониторинг изменений в таблице AIT или в таблицах AIT, определенных в стандарте ETSI [26] (10.4.2);

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

- определить все "записываемые" приложения, перечисленные в этом AIT, и начать сбор приложений и связанных потоков в соответствии с дескриптором записи приложения (определяется реализацией MHP-PVR терминала).

15.2.5 Управление завершенными записями

Процесс управления завершенными записями в соответствии со стандартом ETSI [34] (6.3) должен включать следующие мероприятия:

- поддержание со всеми завершенными записями (COMPLETED_STATE или INCOMPLETE_STATE) следующей информации тех пор, пока сохраняется контент:

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

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

- время и канал выполнения записи;

- приложение конкретных данных, связанных с записью;

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

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

В дополнение к этим мероприятиям процесс управления завершенными записями должен согласно стандарту ETSI [35] (6.3) включать следующие действия:

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

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

- о всех успешно полученных AIT, приложениях и связанных потоках за исключением тех, которые связаны с частями контента, которые не были полностью записаны и которые не формируют самую большую часть записи. Сохранение их зависит от реализации;

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

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

15.2.6 Параметры процесса воспроизведения записей в системе MHP-PVR

Параметры процесса воспроизведения должны быть в соответствии со стандартом ETSI [34] (6.4).

Во время воспроизведения контента, записанного в процессе запланированной записи, в соответствии со стандартом ETSI [35] (6.4), должны поддерживаться события, представленные в таблице 4.

Таблица 4 - События во время нормального воспроизведения и характер процесса воспроизведения

15.2.7 Параметры записи и воспроизведения MHP-PVR в режиме Timeshift

Параметры процесса записи и воспроизведения в режиме TimeShift должны быть в соответствии со стандартом ETSI [34] (6.5) со следующими уточнениями по стандарту ETSI [35]:

- все потоки службы должны быть записаны, включая те, которые переносят динамические данные, такие как приложения сигнализации МНР, Карусели Объектов DSM-CC, события потока и частные секции MPEG-2, которые будут получены использованием доступа через секции фильтрации API;

- все приложения в службе должны записываться, если это явно не исключено при установке в приложении в записи дескриптора флага time_shift_flag в "0";

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

- терминал MHP-PVR должен связывать буфер TimeShift (буфер устройства хранения в составе терминала MHP-PVR) с контекстом службы, создаваемым навигатором МНР, в котором навигатор интерфейса пользователя выбирает службы. Настоящий стандарт не определяет механизмы, связывающие буферы TimeShift с другими контекстами службы.

15.2.8 Параметры записи и воспроизведения MHP-PVR в режиме TV-Anytime

При работе в среде TV-Anytime должны выполняться следующие дополнительные действия, являющиеся частью процесса управления запланированной записью, определенного в пункте 15.2.1 настоящего стандарта:

- разрешение запросов записи групп CRID с элементами в их составе;

- мониторинг появления доступной дополнительной информации о разрешении для частично разрешенных CRID и действий по этой дополнительной информации.

В среде TV-Anytime выполняются следующие дополнительные действия как часть процесса записи, определенного в пункте 15.2.2 настоящего стандарта:

- ассоциирование с завершенными записями всех CRID, которые были сигнализированы одновременно с контентом во время записи с помощью дескриптора идентификатора контента, определенного в стандарте ETSI [36] (раздел 12);

- ассоциирование соответствующих метаданных TV-Anytime с записями, в которых любая из перечисленных ниже частей контента имеет идентификаторы CRID, сигнализированные с дескриптором идентификатора контента:

- часть контента, составляющая наибольшую часть записи;

- все полные части контента, найденные в записи.

Метаданные, соответствующие TV-Anytime для CRID, определены следующим образом. Для группы CRID - это Grouplnformation, для листа CRID - это Programlnformation и информация о сегментации (если она сообщена). Если метаданные экземпляра для выбранного экземпляра доступны, то они переопределяют эквивалентные поля в Programlnformation. Информация о сегментации должна получаться в конце записи и включать в себя динамическую информацию. Другие метаданные могут быть получены в любой момент во время записи. Если метаданные базы данных были специфицированы во время записи, то их следует использовать из этой базы данных;

Для записей, имеющих дескриптор разрешения вещателя tva_id, должны быть сохранены дескрипторы разрешения всех событий DVB-SI в границах, определенных tva_id. Если записанный контент включает больше одного идентификатора события DVB-SI event_id, то запрос LeafRecordingRequest должен иметь сегменты для части контента, который составляет самую большую часть записи и для всех полных частей контента.

15.3 Метаданные системы MHP-PVR

15.3.1 Метаданные системы MHP-PVR при работе в среде TV-Anytime

Настоящий стандарт не определяет функциональные профили или уровни спецификаций TV-Anytime.

15.3.2 Определение метаданных системы MHP-PVR

При работе системы MHP-PVR в среде TV-Anytime должны поддерживаться метаданные, определенные в стандарте ETSI [36] (8).

15.3.3 Передача метаданных через канал вещания

Передача метаданных через канал вещания должна поддерживаться в соответствии со стандартами ETSI [35] (7.1.2), [36] (раздел 9).

Фрагменты метаданных TV-Anytime, полученные из DVBDatabase, должны включать значения атрибутов fragmentVersion и fragmentld, которые получены из соответствующих полей структуры инкапсуляции, определенной в стандарте ETSI [38]. Любые значения, найденные во фрагментах, будут отброшены и заменены.

15.3.4 Передача метаданных через интерактивный канал

Передача метаданных через интерактивный канал должна поддерживаться в соответствии со стандартом ETSI [38].

15.4 Параметры модели приложения системы MHP-PVR

15.4.1 Воспроизведение записанных приложений

Воспроизведение записанных приложений должно выполняться в соответствии со стандартом ETSI [34] (раздел 9) со следующим ограничением по стандарту ETSI [35] (8.1): терминалы MHP-PVR в режиме воспроизведения trick при возврате к нормальному режиму могут задерживать перезапуск приложения в течение одной минуты. Поведение терминала в течение этой минуты определяется его реализацией.

15.4.2 Контексты службы и поддержка виртуальных каналов

Терминалы MHP-PVR в соответствии со стандартом ETSI [35] (8.2) должны одновременно поддерживать следующие контексты службы:

- контекст службы, создаваемой реализацией терминала МНР класса МНР 1.0, используемый навигатором для представления (презентации) службы вещания;

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

Оба контекста могут использоваться приложениями MHP-PVR для презентации вещания и при воспроизведении содержания.

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

15.4.3 Управление ресурсом системы MHP-PVR

Правила управления ресурсом системы MHP-PVR должны быть в соответствии со стандартами ГОСТ Р 54456 (10.2.6) и ETSI [7] (11.2.9) со следующим дополнением: в случае поступления запроса на использование ресурсов приложения декодирования медиа, которые заняты обслуживанием запроса на эти ресурсы, поступившего ранее, то допускается использование ресурса приложения для обслуживания нового запроса.

15.5 Параметры сигнализации приложения в системе MHP-PVR

15.5.1 Запись атрибутов безопасности

15.5.1.1 Сигнализация представляемых прав

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

Этот дескриптор предназначен для использования в таблицах SDT и EIT. При использовании в таблице SDT контекстом этого дескриптора является служба. При использовании в таблице EIT контекстом этого дескриптора является рассматриваемое событие. Параметры синтаксиса и семантики дескриптора broadcaster_permission_descriptor() должны быть в соответствии со стандартом ETSI [35] (9.1.1, таблицы 2, 3).

15.5.1.2 Процесс определения полномочий вещателя

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

Уточнения процедуры определения дескриптора разрешения для реализаций должны быть в соответствии со стандартом ETSI [35] (9.1.2).

15.5.2 Сигнализация для записи приложения

Система MHP-PVR должна поддерживать параметры сигнализации приложений, определенные в стандарте ETSI [34] (раздел 8) и дескриптора записи приложения, определенные в стандарте ETSI [34] (приложение А). Для флага av_synced_flag обработка триггера событий должна выполняться в соответствии со стандартами ETSI [7] (приложение В, В.2.4), [26].

15.5.3 Расширения сигнализации приложения

Расширение кодов управления приложений DVB-J и DVB-HTML, нормированных в стандарте ETSI [7] (10.6.2.1 и 10.6.2.2), должно быть в соответствии с таблицей 5.

Таблица 5 - Расширение кодов управления приложениями

15.6 Параметры платформы DVB-J в системе MHP-PVR

15.6.1 Персональный цифровой магнитофон

15.6.1.1 Общее ядро системы MHP-PVR. Параметры API записи и воспроизведения

Параметры API записи и воспроизведения PVR, работающего в составе МНР, должны соответствовать требованиям стандарта ETSI [34] (раздел 7).

Поведение методов в зависимости от запроса записи специфических атрибутов безопасности в соответствии с ETSI [35] (раздел 10) должно быть следующим:

- ограничения вызова не должны применяться, если вызов приложения метода при запросе записи (полем this_organization_id) в дескрипторе разрешении вещателя исходит от вещателя контента;

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

15.6.1.2 Расширения DVB в системе MHP-PVR

В соответствии со стандартом ETSI [35] (10.1.2) система MHP-PVR должна поддерживать пакеты org.dvb.pvr и org.dvb.pvr.navigation.

Все экземпляры org.ocap.shared.dvr.RecordedService, создаваемые терминалом MHP-PVR, должны быть экземплярами org.dvb.pvr.DVBRecordedService.

Все экземпляры org.ocap.shared.dvr.LeafRecordingRequest, создаваемые терминалом MHP-PVR, должны быть экземплярами org.dvb.pvr.DVBLeafRecordingRequest.

Сигнализация для идентификаторов CRID в методе DVBRecordedService.getCRIDs должна быть идентификатором дескриптора контента в соответствии со стандартом ЕТSI [36] (12.1).

Рекомендации по реализации в MHP-PVR защиты от злоупотреблений механизмом записи, инициированного пользователем, должны быть в соответствии со стандартом ETSI [35] (10.1.2).

15.6.1.3 Поддержка системой MHP-PVR рекламных ссылок

Реализация терминала MHP-PVR должна поддерживать пакет org.dvb.media.rct. Это позволит пользователю использовать механизм формирования рекламных ссылок для создания заявок на просмотр контента. Параметры механизма формирования рекламных ссылок определены в стандарте ETSI [36] (раздел 10).

15.6.2 Параметры платформы DVB-J при работе системы MHP-PVR в среде TV-Anytime

15.6.2.1 Обращение к контенту

В соответствии со стандартом ETSI [35] (10.2.1) терминал MHP-PVR должен поддерживать пакеты контента org.dvb.tvanytime.resolution и org.dvb.locator.

15.6.2.2 Параметры метаданных

Реализация терминала MHP-PVR должна поддерживать пакеты org.dvb.tvanytime.metadata и org.dvb.xml.jdom. Платформа МНР должна поддерживать схемы классификации, определенные в стандарте ETSI [38] (приложение А). Исключением является ActionTypeCS. На эти резидентные схемы классификации можно ссылаться, используя псевдонимы, перечисленные в стандарте ETSI [35] (таблица 6).

15.6.3 Параметры PDR при работе в среде TV-Anytime

15.6.3.1 Записи при работе в основной среде TV-Anytime

Для выполнения записей при работе в основной среде TV-Anytime PDR должен поддерживать пакеты org.dvb.tvanytime.pvr и org.dvb.tvanytime.pvr.navigation.

Все экземпляры org.ocap.shared.pvr.RecordingManager должны быть экземплярами org.dvb.tvanytime.pvr.navigation.CRIDRecordingManager.

15.6.3.2 API идентификации контента

Должен поддерживаться пакет org.dvb.si.tva, включая явные и косвенные идентификаторы контента (Content Reference Identifier; CRID). определяющие режимы сигнализации, параметры которых определены стандартом ETSI [36] (раздел 12).

15.6.4 Свойства версии

Свойства класса java.lang.System должен быть в соответствии с представленным в стандарте ETSI [35] (10.4).

15.6.5 Расширенная семантика для платформы DVB-J МНР

Настоящий стандарт устанавливает следующие расширенные режимы работы для API, определенные в стандартах ETSI [7], [26].

15.6.5.1 API пользовательских настроек и привилегий

Параметры API пользовательских настроек и привилегий, определенные в стандарте ETSI [7] (11.9.2), должны быть расширены следующим образом:

- должна быть установлена дополнительная стандартизированная привилегия "Перечень доступа записи" ("Recording List Access");

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

- строка имеет значение "истина", если конечному пользователю предоставляется доступ к перечню из всего контента, записанного в PDR;

- строка имеет значение "ложь", если конечному пользователю не предоставляется доступ к списку из всего контента, записанного в PDR.

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

15.6.5.2 API информации о службе DVB

Параметры API информации о службе DVB должны быть в соответствии со стандартом ETSI [7] (11.6.1).

15.6.5.3 Открытие приложения и запуск API

Параметры открытия приложения и запуска API, определенные в стандартах ETSI [7] (11.7.2), [26] (11.7.2) и ГОСТ Р 54456 (10.7.2), должны быть дополнены для описания класса org.dvb.application.AppsDatabase в соответствии со стандартом ETSI [35] (10.5.3).

15.7 Безопасность в системе MHP-PVR

15.7.1 Расширения файла запроса разрешения

Терминалы MHP-PVR должны поддерживать требования стандарта ETSI [34] (раздел 10). Допускается использовать две модели безопасности, регулирующие способность приложения обрабатывать запросы записи:

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

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

Терминалы MHP-PVR (в соответствии со стандартом ETSI [7]) должны поддерживать новые определения типа документа (Document Type Definition; DTD) для файла запроса разрешения следующим образом:

- применением общедоступного идентификатора "PublicLiteral" (в соответствии со стандартом ETSI [7]) для определения DTD в декларациях типов файлов XML: "-//DVB//DTD Permission Request File 1.1+PVR//EN";

- применением URL для идентификатора SystemLiteral в соответствии с "http://www.dvb.org/mhp/dtd/permissionrequestfile-1-1-pvr.dtd";

- применением измененного элемента permissionrequestfile в соответствии с: <! ELEMENT permissionrequestfile (file?, capermission?, applifecyclecontrol?, returnchannel?, tuning?, servicesel?, userpreferences?, network?, dripfeed?, persistentfilecredential *, applicationstorage?, smartcardaccess?, providerpermission?, recordingpermission?)>. Элемент recordingpermission определен в соответствии со стандартом ETSI [34] (подраздел 10.2), а все другие элементы не изменяются.

15.8 Вопросы совместного использования систем TV-Anytime и телевизионного вещания платформой MHP-PVR

15.8.1 Базирование контента TV-Anytime

Настоящий стандарт не устанавливает требований к функциональным профилям или уровням спецификаций TV-Anytime.

15.8.2 Использование канала телевизионного вещания

При использовании канала телевизионного вещания терминалы MHP-PVR должны соответствовать требованиям стандарта ETSI [36] (разделы 5, 6, 7).

15.9 Детализированные определения профиля платформы MHP-PVR

Детализированные определения профиля платформы в соответствии со стандартом ETSI [35] (раздел 13) представлены в таблице 6.

Таблица 6 - Детализированные определения профиля платформы

15.10 Минимально допустимые возможности системы MHP-PVR

Терминалы MHP-PVR в соответствии со стандартом ETSI [34] (раздел 11) должны поддерживать следующие скорости воспроизведения: -16х, -8х, -4х, -2х, -1х, 0, 0,5х, 1х, 2х, 4х, 8х, 16х.

Примечание - Для скорости -1х допускается выводить на экран только I-кадры.

Терминалы MHP-PVR должны поддерживать:

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

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

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

Примечание - Настоящий стандарт не определяет минимальные допустимые значения основных параметров в TV-Anytime.

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

16.1 Требования к системным константам МНР должны быть в соответствии со стандартом ETSI [7] (16.1, таблица 140).

16.2 Требования к константам DVB-J МНР должны быть в соответствии со стандартом ETSI [7] (16.2).

17 Доступ Интернет-клиентов МНР в сеть Интернет

17.1 Ссылки служб DVB и контента на контент WWW

Платформа МНР для доступа в сеть Интернет должна поддерживать следующие механизмы ссылки на службы DVB и на контент, содержащийся в сети Интернет (WWW):

- использование гипертекстовой ссылки "href", являющейся атрибутом в документе HTML и определяющей ссылку на другой документ во WWW, запускающий службу DVB;

- Интернет-клиенты доступа МНР в Интернет должны поддерживать атрибуты element.attribute, определенные в стандарте ETSI [7] (таблица 13), с использованием элементов типов медиа в соответствии со стандартом ETSI [7] (таблица 15). Дополнительным условием является использование только следующих типов MIME:

- audio/mpeg, video/mpeg;

- multipart/dvb.service.

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

17.2 Требования к Интернет-клиентам

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

Таблица 7 - Минимально необходимые протоколы

Интернет-клиенты браузера WWW должны поддерживать URL "mailto", определенный стандартами IETF (24], [41].

Интернет-клиенты электронной почты должны поддерживать использование URL "http" и "https" в соответствии со стандартом IETF [18] (3.2.2).

При наличии Интернет-клиента новостей Usenet браузер WWW и e-mail Интернет-клиента должны поддерживать URL "новости" в соответствии со стандартом IETF [42].

Интернет-клиенты новостей Usenet должны поддерживать использование URL "http", "https" и "mailto".

17.3 Обработка потокового медиа из сети Интернет

Настоящий стандарт не предъявляет требований к обработке терминалами МНР контента потоков медиа из сети Интернет. Однако в тех случаях, когда такая обработка поддерживается и терминалам МНР доступны приложения DVB-J, то обработку рекомендуется выполнять при использовании медиа платформы Java в соответствии со стандартом Java [43].

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

__________________________________________________________________________

УДК 621.397:681.327.8:006.354 ОКС 33.170 ОКП 657400

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

__________________________________________________________________________

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

и сверен по:

, 2014