ГОСТ Р 56951-2016. Национальный стандарт Российской Федерации. Телевидение вещательное цифровое. Сигнализация и доставка интерактивных приложений и услуг в гибридных широковещательных/широкополосных средах. Основные параметры

(утв. и введен в действие Приказом Росстандарта от 07.06.2016 № 544-ст)

Утвержден и введен в действие

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

Дата введения 1 июня 2017 года

Предисловие

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

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

4 Настоящий стандарт разработан с учетом основных нормативных положений стандарта Европейского института по стандартизации в области телекоммуникаций (ETSI) ЕТСИ ТС 102 809 V1.2.1 (2013-07) «Телевидение вещательное цифровое. Сигнализация и доставка интерактивных приложений и услуг в гибридных широковещательных/широкополосных средах» [ETSI TS 102 809 V1.2.1 (2013-07) «Digital Video Broadcasting (DVB); Signalling and carriage of interactive applications and services in Hybrid broadcast/broadband environments», NEQ]

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

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

Настоящий стандарт определяет структуру сигнализации и доставки интерактивных приложений или услуг в вещательных и широкополосных сетях. Эта структура содержит следующие разделы:

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

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

Требования настоящего стандарта следует учитывать при проектировании и эксплуатации сетей DVB и при внедрении в них новых приложений или услуг.

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

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

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

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

ГОСТ Р 54994-2012 Телевидение вещательное цифровое. Передача служб DVB по сетям с IP протоколами. Общие технические требования

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

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

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

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

3.1.2 выбранная услуга (selected service): Телевизионная или радиоуслуга, которая в настоящее время воспроизводится приемником и чьи уведомления о приложениях отслеживаются приемником.

3.1.3 услуга (service): Последовательность программ под управлением вещателя, которые могут передаваться как часть расписания.

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

ФОП — файл описания приложения;

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

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

bslbf — строка битов, левый бит первый (bit string, left bit first);

DSM-CC — управление и контроль над хранением/передачей цифровых данных (Digital Storage Media — Command and Control);

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

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

HTTP — протокол передачи гипертекста (Hyper Text Transport Protocol);

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

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

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

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

uimsbf — целое без знака, старший значащий бит первый (unsigned integer, most significant bit first);

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

4 Модели приложений

4.1 Введение

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

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

4.2 Запуск и остановка приложений

4.2.1 Приложения, связанные с вещательными услугами

При выборе широковещательной услуги должны выполняться следующие действия:

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

Если широковещательная услуга остается запрошенной, как определено выше, применяют следующие правила:

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

Когда вещательная услуга перестает быть выбранной, применяют следующие правила:

• приложения, где элемент serviceBound дескриптора приложения application_descriptor имеет значение «истина», должны быть остановлены;
• когда приложение продолжает работать после смены широковещательной услуги, оно должно работать согласно сигнализации в новой услуге.

4.2.2 Приложения, связанные с элементами контента по запросу

Приложения, связанные с элементом контента по запросу, будут либо обрабатываться так же, как приложения, связанные с частью широковещательной услуги (включая возможность для динамических изменений во время действия элемента контента по запросу), либо будут действительны в течение всего срока действия элемента контента. В последнем случае приложения с контрольным кодом AUTOSTART должны запускаться, когда элемент контента появляется, и должны быть остановлены, когда элемент контента пропадает. Изменения в контрольных кодах приложений невозможны.

4.2.3 Приложения, связанные с сетевыми операторами

Приложения, связанные с сетевыми операторами, могут работать в любое время, когда терминал подключен к сети оператора. Приложения с контрольным кодом AUTOSTART должны быть запущены автоматически при первом подключении терминала к сети или когда приложение(-я) добавлено(-ы) к сигнализации. Если терминалы могут переподключаться от одного сетевого оператора к другому как часть этого процесса, приложения бывшего сетевого оператора должны быть остановлены, а приложения нового сетевого оператора запущены.

5 Сигнализация интерактивных приложений и услуг

5.1 Семантика

В данном разделе изложены следующие вопросы:

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

5.2 Метаданные приложений

5.2.1 Введение

Приложения могут иметь ряд элементов метаданных, ассоциированных с ними. К ним относятся следующие:

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

- контрольный код — определяет состояние жизненного цикла приложения;

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

5.2.2 Типы приложений

При кодировании MPEG-2 типы приложений должны идентифицироваться 15-битовым числом. Определенные типы приложений регистрируются DVB [1].

При кодировании XML типы приложений являются строками, как правило, типа MIME.

5.2.3 Идентификация приложений

Каждое приложение должно иметь идентификатор приложения, состоящий из двух частей:

• идентификатора организации organisation_id;
• идентификатора приложения application_id.

organisation_id: данное поле глобально идентифицирует организацию, отвечающую за приложение согласно [1]. Значение 0 не следует применять. Для совместимости старшие 8 битов должны быть равны 0.

application_id: данное поле уникально идентифицирует приложение и определяется организацией, соответствующей полю organisation_id, из диапазона значений согласно таблице 1.

Таблица 1

Диапазон значений application_id

Синтаксис идентификатора приложения приведен в таблице 2. Согласно таблице 2 при кодировании MPEG-2 идентификатор приложения должен содержать 6 байт.

Таблица 2

Синтаксис идентификатора приложения

При кодировании XML идентификатор приложения должен определяться согласно следующему фрагменту кода XML:

5.2.4 Контрольные коды приложения

Таблица 3

Значения контрольных кодов приложения

При кодировании MPEG-2 контрольный код приложения указывается через поле application_control_code таблицы AIT. Значения согласно таблице 3.

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

5.2.5 Профили платформ

Профиль платформы должен содержать следующие поля.

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

version.major: числовое значение старшего подполя номера версии профиля.

version.minor: числовое значение младшего подполя номера версии профиля.

version.micro: числовое значение микроподполя номера версии профиля.

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

где \in — знак принадлежности к множеству;

\wedge — логическое И;

\vee — логическое ИЛИ.

При кодировании MPEG-2 профили должны быть кодированы как часть дескриптора приложения согласно таблице 4.

Таблица 4

При кодировании XML профиль приложения должен определяться согласно следующему фрагменту кода XML:

5.2.6 Видимость приложения

Определение состояний видимости приложений приведено в таблице 5.

Таблица 5

Определение состояний видимости приложений

При кодировании MPEG-2 видимость приложения указывается через поле дескриптора приложения таблицы AIT. Значения данного поля приведены в таблице 5.

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

5.2.7 Приоритет приложения

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

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

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

При кодировании MPEG-2 приоритет приложения кодируется в поле application_priority дескриптора приложения.

При кодировании XML приоритет приложения кодируется в поле приоритета дескриптора приложения.

5.2.8 Пиктограммы приложений

Одна или несколько пиктограмм могут быть связаны с приложением. Формат содержания пиктограмм должен быть PNG.

Каждая пиктограмма должна содержать локатор пиктограммы и набор флагов, определяющих размер и соотношение сторон пиктограммы.

Локатор пиктограммы является первой частью строки, указывающей на расположение файла пиктограммы. Локатор приложения не должен заканчиваться символом слэша «/».

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

filename = icon_locator «/dvb.icon.» hex_string

hex_string = 4*4hex

hex = digit | «A» | «B» | «C» | «D» | «E» | «F» | «a» | «b» | «c» | «d» | «e» | «f»

digit = «0» | «1» | «2» | «3» | «4» | «5» | «6» | «7» | «8» | «9»

При кодировании MPEG-2 информация о пиктограмме приложения закодирована в дескрипторе application_icons_descriptor согласно таблице 6.

Синтаксис дескриптора пиктограммы приложения

Пиктограмма содержащейся в файле пиктограммы должна иметь формат, определенный четырьмя шестнадцатеричными цифрами постскриптума имени файла. Значение этого постскриптума определено соответствующим кодированием MPEG-2 флагов пиктограммы (см. таблицу 7).

Таблица 7

При кодировании XML информация о пиктограмме закодирована в одном или нескольких элементах дескриптора IconDescriptor согласно следующему фрагменту кода XML:

<xsd:complexType name=«Icon Descriptor»>

<xsd:attribute name=«filename» type=«xsd:string» use=«required»/>

<xsd:attribute name=«size» type=«xsd:unsignedShort» use=«optional»/>

<xsd:attribute name=«aspectRatio» type=«mhp:AspectRatio» use=«optional»/> </xsd:complexType>

5.2.9 Графические ограничения

При кодировании MPEG-2 дескриптор graphics_constraints_descriptor, приведенный в таблице 8, указывает, какие графические ограничения применимы к приложению.

Дескриптор graphics_constraints_descriptor

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

Значения байта графической конфигурации

5.2.10 Применение приложения

Дескриптор применения приложения указывает тип специальной стандартной услуги, предоставляемой приложением (телетекст, электронный гид, чат и т.п.). Формат дескриптора применения приложения application_usage_descriptor при кодировании MPEG-2 приведен в таблице 10.

usage_type: указывает, какую услугу предоставляет приложение. Типы применения приложения приведены в таблице 11.

Типы применения приложения

Если дескриптор application_usage_descriptor отсутствует, приложение не должно предоставлять специальных стандартных услуг.

При кодировании XML тип применения приложения указывают в элементе дескриптора ApplicationUsageDescriptor согласно следующему фрагменту кода XML:

Элемент ApplicationUsage должен указывать, какая услуга предоставляется приложением. Кодирование значений ApplicationUsage должно выполняться согласно примеру в таблице 12.

Пример кодирования XML типов применения приложения

5.2.11 Сохраненные приложения

Дескриптор хранения приложения содержит информацию о способе запуска приложений из хранилищ.

Дескриптор хранения приложения должен содержать следующие флаги:

is_launchable_with_older_version: указывает, что разрешен запуск более ранней версии из кэша, даже если вещательная сеть сообщает о наличии более новой версии.

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

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

Комбинация флагов дескриптора хранения приведена в таблице 13.

Таблица 13

Комбинация флагов дескриптора хранения

Кодирование MPEG-2 дескриптора хранения приложения приведено в таблице 14.

Таблица 14

Кодирование MPEG-2 дескриптора хранения приложения

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

5.2.12 Файл описания приложения

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

Размещение ФОП должно определяться спецификацией платформы. Рекомендуемый формат имени ФОП следующий:

'dvb.storage.oooooooo.aaaa',

где oooooooo — organisation_id в формате 8-символьной шестнадцатеричной строки;

Старшие символы organisation_id и application_id должны заполняться нулями до достижения указанной длины.

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

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

Семантика:

version: десятичное число, обозначающее номер версии этого приложения. Значение этого атрибута не должно содержать ведущих нулей (если он сам не является «0»). Значение этого атрибута должно совпадать с номером версии, указанной в поле дескриптора хранилища приложения в записи AIT этого приложения; если это не так, то ФОП является недействительным. Это поле позволяет авторам приложений убедиться, что номер версии, указанный в AIT, является правильным. Если он неправильный, любые сохранения файлов предотвращаются.

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

Если имя выглядит как «.» или «..», содержит разделитель «/» или содержит символ NUL (U + 0000), то приемник должен отклонить этот ФОП как недействительный.

Priority: этот атрибут указывает, как важно сохранить этот объект. Его значение должно быть между 0 и 255 включительно. Если оно находится за пределами этого диапазона, то ФОП является недействительным. Нулевое значение указывает на наивысший приоритет, более высокие значения указывают на низкий приоритет для сохранения.

Значение по умолчанию для атрибута приоритета равно нулю (наивысший приоритет).

Size: этот атрибут определяет размер в байтах файла или файлов, в которых имя атрибута включает в себя подстановочный символ.

6 Ссылки на DVB услуги

Ноль или более дескрипторов service_identifier_descriptor могут быть включены в таблицу SDT услуги. Каждый такой дескриптор определяет один текстовый идентификатор для данной услуги. Синтаксис текстового идентификатора услуги должен быть следующим:

<service_name> «.» <service_provider_domain_name>,

где <service_name> — уникальное имя услуги в домене провайдера;

<service_provider_domain_name> — доменное имя в сети Интернет, принадлежащее поставщику услуг.

Одному экземпляру услуги может быть сопоставлено несколько идентификаторов услуг.

Дескриптор идентификатора услуги service_identifier_descriptor приведен в таблице 15.

Дескриптор идентификатора услуги

descriptor_tag: идентификатор дескриптора, должен быть равен 0x71.

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

7 Доставка приложений

7.1 Карусель объектов

Если широковещательное приложение передается с использованием каруселей объектов от пользователя к пользователю DSM-CC, следует руководствоваться спецификациями [2], [3], [4].

7.2 HTTP

Если приложение загружается с помощью протокола HTTP, должен поддерживаться протокол HTTP 1.1 согласно [5].

8 Синхронизация

8.1 Введение

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

Такими событиями могут быть:

• события немедленной обработки («Do-it-now» («Сделай-это-сейчас») события), направляемые в приложение, как только они принимаются терминалом;
• события, синхронизированные с временной диаграммой DVB, направляемые в приложение, когда временная диаграмма достигает времени, указанного для события.

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

8.2 Ссылки

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

- по ссылке объекта потокового события DSM-CC в карусель объектов. Для этого требуется, чтобы услуга содержала карусель объектов, а также элементарный поток, несущий сообщения потоковых событий;

- по ссылке XML-файла, содержащего эквивалентную информацию на объект потокового события DSM-CC, как определено в следующей схеме. Такой механизм обеспечивает синхронизацию с услугами, несущими сообщения потоковых событий, но не содержащих карусели объектов. Если востребован тип MIME, для таких XML-файлов должен использоваться тип MIME «application/vnd.dvb.streamevent+xml»:

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