ГОСТ Р 55688-2013. Национальный стандарт Российской Федерации. Аудиовизуальная информационная система реального времени (РАВИС). Формирователь контента. Структура и протоколы передачи данных

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

Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 31 октября 2013 г. № 1331-ст

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

АУДИОВИЗУАЛЬНАЯ ИНФОРМАЦИОННАЯ СИСТЕМА РЕАЛЬНОГО ВРЕМЕНИ (РАВИС)

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

Realtime audiovisual information system (RAVIS). Content composer. Structure and data transmission protocols

ГОСТ Р 55688-2013

ОКС 33.170

Дата введения 1 сентября 2014 года

Предисловие

1 РАЗРАБОТАН Обществом с ограниченной ответственностью «Научно-производственная фирма „САД-КОМ“ (ООО „НПФ „САД-КОМ“)»

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 480 «Связь»

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

4 ВВЕДЕН ВПЕРВЫЕ

5 ПЕРЕИЗДАНИЕ. Февраль 2020 г.

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

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

Настоящий стандарт распространяется на формирователь контента системы цифрового наземного узкополосного мультимедийного вещания РАВИС в ОВЧ-диапазоне частот, предназначенный для формирования мультиплекса РАВИС, передаваемого на цифровой модулятор РАВИС для вещания.

Система РАВИС позволяет осуществлять мультимедийное вещание для стационарного, переносного и мобильного приема. Система РАВИС обеспечивает передачу цифрового информационного потока в узкополосном канале с шириной полосы 100, 200 или 250 кГц.

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

Требования настоящего стандарта следует учитывать при разработке, изготовлении и эксплуатации формирователей контента РАВИС.

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

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

ГОСТ 12.1.030 Система стандартов безопасности труда. Электробезопасность. Защитное заземление, зануление

ГОСТ 12.2.007.0 Система стандартов безопасности труда. Изделия электротехнические. Общие требования безопасности

ГОСТ 15150 Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды

ГОСТ 22261 Средства измерений электрических и магнитных величин. Общие технические условия

ГОСТ Р 54309-2011 Аудиовизуальная информационная система реального времени (РАВИС). Процессы формирования кадровой структуры, канального кодирования и модуляции для системы цифрового наземного узкополосного радиовещания в ОВЧ диапазоне. Технические условия

ГОСТ Р 54708 Система цифрового звукового радиовещания DRM. Протокол распределения и коммутации (DCP)

ГОСТ Р МЭК 60065 <1> Аудио-, видео- и аналогичная электронная аппаратура. Требования безопасности

<1> Действует ГОСТ IEC 60065-2013.

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

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

3.1 Термины и определения

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

3.1.1 байт: Набор из 8 битов.

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

3.1.3 мультиплекс: Совокупность логических каналов КОС, НСК, НКД.

3.1.4 полезная нагрузка: Данные страницы, подстраницы или пакета, следующие за заголовком.

3.1.5 протокол распределения и коммуникации (Distribution and Communication Protocol): Протокол связи транспортного уровня, обеспечивающий фрагментацию, адресацию и/или надежную передачу данных по каналам с ошибками с использованием кода Рида — Соломона для прямой коррекции ошибок путем введения избыточности.

3.1.6 сервис: Логически объединенный набор элементарных потоков.

3.1.7 строка ASCII: Текстовая строка, состоящая из символов, закодированных в соответствии с американской стандартной таблицей кодировки (American Standard Code for Information Interchange, ASCII).

3.1.8 студия: Комплекс аппаратного и программного обеспечения, формирующий на выходе один или несколько сервисов РАВИС.

3.1.9 схема мультиплекса: Перечисление входящих в мультиплекс сервисов (при необходимости с входящими в их состав элементарными потоками) и их места в мультиплексе с указанием источников данных для них.

3.1.10 транспортный поток MPEG-2 (MPEG-2 Transport Stream): Транспортный контейнер в соответствии со стандартом MPEG-2, часть 1 [1].

3.1.11 элементарный поток: Закодированный поток информации одного типа от одного источника данных.

3.1.12 Ethernet — Ethernet network — сеть Ethernet: Технология передачи данных в локальных компьютерных сетях, описанная стандартами IEEE группы 802.3.

3.1.13 TAG-значение (TAG Value): Нагрузка TAG-элемента.

3.1.14 TAG-название (TAG Name): Название поля в индивидуальном TAG-элементе, используемое для идентификации индивидуальной части информации.

3.1.15 TAG-пакет (TAG Packet): Набор TAG-элементов, переносящий связанный и отдельный блок данных.

3.1.16 TAG-элемент (TAG Item): DCP-элементный тип, объединяющий в единых логических данных имя, длину и значение данных.

3.1.17 UTF-8 текст: Текст, состоящий из символов, закодированных с помощью 8-битного Юникода (Unicode Transformation Format, UTF).

3.2 Обозначения

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

Nx — числовое значение «N», выраженное по основанию «x» (основание «x» должно быть десятичным числом, таким образом, 2A₁₆ есть шестнадцатеричное представление десятичного числа 42);

Nb — числовое значение «N», выраженное по основанию «2».

3.3 Сокращения

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

16-QAM — 16-позиционная модуляция QAM;

64-QAM — 64-позиционная модуляция QAM;

ASCII — американская стандартная таблица кодировки (American Standard Code for Information Interchange);

ASI — асинхронный последовательный интерфейс (Asynchronous Serial Interface);

CRC — циклический избыточный код (Cyclic Redundancy Check);

CRC-32 — 32-битный циклический избыточный код;

DCP — протокол распределения и коммутации (Distribution and Communication Protocol);

FOURCC — четырехбайтная последовательность, используемая для идентификации форматов данных (Four Character Code);

IP — межсетевой протокол пакетной передачи данных (Internet Protocol);

JSON — текстовый формат обмена данными, удобный для чтения и написания как человеком, так и компьютером [2];

QAM — квадратурно-амплитудная модуляция (Quadrature Amplitude Modulation);

QPSK — четырехпозиционная фазовая манипуляция (Quadrature Phase Shift Keying);

TAG — тег, длина, значение (Tag, Length, Value);

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

USB — последовательный интерфейс передачи данных для среднескоростных и низкоскоростных периферийных устройств в вычислительной технике (Universal Serial Bus);

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

XML — текстовый формат, предназначенный для хранения структурированных данных (eXtensible Markup Language);

КД — кадр данных;

КОС — канал основного сервиса;

МФВМ — модуль формирования TAG-пакетов для входа модулятора;

МУКД — модуль упаковки данных логических каналов в кадры данных РАВИС;

МУЛК — модуль упаковки данных логического канала;

НКД — надежный канал данных;

НСК — низкоскоростной канал;

ОВЧ — диапазон очень высоких частот (30 — 300 МГц);

ППС — параметры передачи сигнала;

РАВИС — Аудиовизуальная информационная система реального времени (Realtime AudioVisual Information System, RAVIS);

ТК — транспортный контейнер;

ТП — транспортный поток.

4 Общее описание

4.1 Мультиплекс РАВИС

4.1.1 Все данные, передаваемые в одном радиоканале в системе РАВИС, логически представляют собой мультиплекс (см. рисунок 1). Мультиплекс состоит из логических каналов:

• КОС (обязательный);
• НСК (опциональный);
• НКД (опциональный).

Рисунок 1 — Логическая структура мультиплекса РАВИС

4.1.2 Каждый логический канал может содержать один или несколько сервисов.

4.1.3 Сервис представляет собой один или несколько логически объединенных элементарных потоков.

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

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

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

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

4.1.8 На вход формирователя контента должны поступать данные элементарных потоков и/или готовые сервисы. На выходе формирователь контента выдает мультиплекс в формате входа модулятора РАВИС.

4.2 Система формирования контента РАВИС

4.2.1 Система формирования контента включает в себя:

• кодеры источников (кодеры аудио-, видео- и дополнительной информации);
• студии, выдающие готовые к дальнейшей упаковке и передаче сервисы;
• формирователь контента.

4.2.2 Формирователь контента должен включать:

• модуль упаковки данных логического канала (МУЛК), осуществляющий упаковку данных, предназначенных для передачи в логическом канале, в заданный формат, например ТК РАВИС (см. приложение А) или ТП MPEG-2;
• модуль упаковки данных логических каналов в КД РАВИС (МУКД);
• модуль формирования TAG-пакетов для входа модулятора (МФВМ).

Рисунок 2 — Система формирования контента РАВИС

4.3 Упаковка данных логических каналов мультиплекса РАВИС

4.3.1 Использование ТП MPEG-2 для упаковки данных логических каналов

ТП MPEG-2 может использоваться для упаковки данных логических каналов КОС, НСК и НКД мультиплекса РАВИС. В этом случае программа ТП MPEG-2 представляет собой сервис РАВИС. В соответствующих КД биты 0 и 1 поля TYPE должны быть установлены в 11b, а бит 3 — в 0b (см. ГОСТ Р 54309-2011, пункт 5.2).

4.3.2 Использование ТК РАВИС для упаковки данных логических каналов

ТК РАВИС может использоваться для упаковки данных логических каналов КОС, НСК и НКД мультиплекса РАВИС (см. приложение А). В этом случае группа элементарных потоков ТК РАВИС представляет собой сервис РАВИС. В соответствующих КД биты 0 и 1 поля TYPE должны быть установлены в 11b, а бит 3 — в 1b (см. ГОСТ Р 54309-2011, пункт 5.2).

4.3.3 Использование других способов упаковки данных логических каналов

Для упаковки данных логических каналов КОС, НСК, НКД могут использоваться другие пакетные или потоковые протоколы. Формирование КД для пакетных и потоковых данных логических каналов описано в пункте 5.2 ГОСТ Р 54309-2011. Потоковые данные в логическом канале следует трактовать как один сервис.

5 Основные параметры

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

5.2 Параметры модуляции:

• полоса радиоканала (100, 200 или 250 кГц);
• тип модуляции несущих канала КОС (QPSK, 16-QAM или 64-QAM);
• скорость помехоустойчивого кода канала КОС (1/2, 2/3 или 3/4);
• количество кадров временного перемежения;
• наличие канала НСК;
• наличие канала НКД.

5.3 Способ упаковки данных логических каналов мультиплекса РАВИС (см. пункт 4.3) должен выбираться исходя из количества передаваемых сервисов, требований к битовому потоку сервисов, требований приемного оборудования и пр.

5.4 Схема мультиплекса должна включать перечисление сервисов, входящих в каналы КОС, НСК, НКД. Для каждого сервиса, если он не поступает в формирователь контента РАВИС уже готовым к передаче, должен быть указан список элементарных потоков, из которых он состоит, а для каждого такого элементарного потока должна быть указана информация об источнике данных элементарного потока.

5.5 Скорости битовых потоков данных логических каналов не должны превышать значений:

• для канала КОС — в соответствии с таблицей 1;
• для канала НСК — 11 408,6 бит/с;
• для канала НКД — 4548,0 бит/с.

Необходимо учитывать, что битовый поток каждого логического канала состоит из заголовков КД РАВИС, полезной нагрузки (данных элементарных потоков) и системных данных (описаний элементарных потоков и описаний сервисов), поэтому битовый поток каждого логического канала на выходе формирователя контента превышает суммарный битовый поток всех входящих в его состав элементарных потоков.

Таблица 1

Пропускная способность канала КОС в разных режимах (в бит/с)

6 Технические требования

6.1 Требования назначения

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

6.2 Требования к интерфейсам

6.2.1 Вход формирователя контента должен иметь интерфейс Ethernet 10/100/1000 Base-T. Сетевое соединение Ethernet должно использоваться для передачи IP-пакетов. IP-пакеты должны содержать данные готовых сервисов и/или данные элементарных потоков, организующихся затем в сервисы. Упаковка должна осуществляться в соответствии с протоколом DCP ГОСТ Р 54708. Правила формирования TAG-пакета для входа формирователя контента приведены в приложении В.

Дополнительно допускается использование иных интерфейсов (ASI, USB и пр.).

6.2.2 Выход формирователя контента должен иметь интерфейс Ethernet 10/100/1000 Base-T. Сетевое соединение Ethernet должно использоваться для передачи IP-пакетов. IP-пакеты должны содержать кадры данных логических каналов КОС, НСК, НКД и параметры, передаваемые на несущих ППС, в соответствии с ГОСТ Р 54309. Упаковка кадров данных логических каналов и параметров передачи должна осуществляться в соответствии с протоколом DCP ГОСТ Р 54708.

6.2.3 Формирователь контента должен иметь интерфейс дистанционного управления и мониторинга Ethernet 10/100/1000 Base-T. Управление должно осуществляться в соответствии с протоколом DCP ГОСТ Р 54708.

6.3 Требования безопасности

6.3.1 При эксплуатации, хранении, транспортировке и испытаниях оборудование формирователя контента должно соответствовать требованиям безопасности и санитарии по ГОСТ 12.1.030, ГОСТ Р МЭК 60065 и ГОСТ 12.2.007.0.

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

6.3.3 Температура наружных поверхностей оборудования формирователя контента во время работы при нормальных климатических условиях по ГОСТ 15150 не должна превышать плюс 45 °C в местах постоянного контакта оператора с поверхностью и плюс 60 °C в местах случайного прикосновения к поверхности.

6.3.4 В оборудовании формирователя контента должна быть исключена возможность прикосновения персонала к точкам с напряжением более 36 В.

6.3.5 Электрическая прочность изоляции между элементом заземления и каждым из потенциальных полюсов ввода электропитания должна выдерживать без пробоя испытательное напряжение постоянного тока 1410 В.

6.3.6 Сопротивление изоляции между элементом заземления и каждым из потенциальных полюсов ввода электропитания должно быть не менее 2 МОм.

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

Значение сопротивления между элементом заземления и каждой доступной прикосновению металлической нетоковедущей частью оборудования формирователя контента, которая может оказаться под напряжением, не должно превышать 0,1 Ом.

6.4 Требования к электропитанию

6.4.1 Электропитание формирователя контента должно осуществляться от одного из следующих источников питания:

1. от сети переменного тока с номинальными значениями напряжения 220 В и частоты 50 Гц. В этом случае требования к электропитанию должны соответствовать приложению 2 [3];

2. от внешнего источника постоянного тока с номинальным напряжением от 12 до 60 В. В этом случае требования к электропитанию должны соответствовать приложению 3 [3];

3. от аккумуляторов и батарей. В этом случае требования к электропитанию устанавливаются в соответствии с разделом X [3].

6.4.2 Для оборудования формирователя контента, устанавливаемого внутрь компьютера или иного электронно-цифрового устройства, требования к электропитанию оборудования определяются устройством, в которое оно устанавливается.

6.5 Требования устойчивости к климатическим и механическим воздействиям

6.5.1 Оборудование формирователя контента должно сохранять работоспособность при климатических и механических воздействиях, параметры которых приведены в таблице 2 (в соответствии с ГОСТ 22261 для средств измерений группы 2).

Таблица 2

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

Приложение А (обязательное)

ОПИСАНИЕ ТК РАВИС

А.1 Общие положения

ТК РАВИС является универсальным протоколом хранения и передачи информации.

С помощью ТК РАВИС можно мультиплексировать до (232 — 1) независимых потоков данных.

Поток ТК РАВИС состоит из страниц, которые могут содержать:

• пакеты данных элементарных потоков;
• пакеты описаний элементарных потоков;
• пакеты описаний групп элементарных потоков.

Структура пакетов описаний элементарных потоков приводится в разделе А.2.3. Структура пакетов описаний групп элементарных потоков приводится в разделе А.2.4.

Пакеты описаний элементарных потоков и пакеты описаний групп элементарных потоков называются системными пакетами.

При использовании ТК РАВИС в системе РАВИС группа элементарных потоков представляет собой сервис РАВИС.

Описания элементарных потоков и описания групп элементарных потоков при потоковом вещании должны периодически вставляться в поток ТК РАВИС. При файловом хранении описания могут вставляться один раз в начале файла.

А.2 Описания структуры страниц и пакетов ТК РАВИС

А.2.1 Страница с данными одного элементарного потока, страница с системными пакетами

Данные типы страниц используются для размещения пакетов данных одного элементарного потока или системных пакетов соответственно.

Заголовки страниц данных типов отличаются только значением флага «page_type»: для страницы с данными одного элементарного потока это биты 00b, для страницы с системными пакетами — 01b.

Заголовок страницы состоит из:

• флагов заголовка;
• данных заголовка.

Структура флагов заголовка страницы представлена в таблице А.1. Описание флагов заголовка представлено в таблице А.2.

Таблица А.1

Структура флагов заголовка страницы с данными одного элементарного потока, заголовка страницы с системными пакетами

Таблица А.2

Описание флагов заголовка страницы с данными одного элементарного потока и заголовка страницы с системными пакетами

<1> Поле packet_sz размещается в зависимости от значения флага same_sz: если значение 1, то packet_sz размещается один раз перед данными первого пакета, если 0 — то перед данными каждого пакета.

Таблица А.3

Значения поля «packet_part»

Структура данных заголовка зависит от значений флагов. В таблице А.4 представлена побайтовая структура страницы с возможными (в зависимости от флагов) размерами полей данных заголовка.

Таблица А.4

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

Для всех флагов в байтах, следующих в таблице А.1 за байтом, где флаг «more» равен 0b, принимаются значения по умолчанию. Для последнего байта флагов заголовка и подзаголовка флаг «more» должен быть равен 0b.

Поле «size» должно определять размер полезной нагрузки страницы, т.е. данных страницы, следующих после заголовка. Размер поля «size» определяется флагом «has_size» заголовка страницы.

Поле «es_id» присутствует только в странице с пакетами одного элементарного потока («page_type» = 00b) и должно содержать идентификатор элементарного потока. Размер поля определяется флагом «has_es_id». В случае страницы, содержащей системные пакеты («page_type» = 10b), флаг «has_es_id» определяет размер поля «es_id» для пакетов описания элементарных потоков (см. раздел А.2.3).

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

Поле «4cc» может присутствовать только в странице с пакетами одного элементарного потока («page_type» = 00b) и должно содержать значение FOURCC для пакетов данного элементарного потока в данной странице. Присутствие данного поля определяется флагом «has_4cc». Для страницы, содержащей системные пакеты («page_type» = 10b), флаг «has_4cc» должен быть установлен в 0b.

Поле «CRC» должно содержать значение CRC-32, вычисленное для полезной нагрузки страницы (алгоритм расчета приведен в приложении Г). Присутствие поля «CRC» определяется флагом «has_crc».

Поля «begin_pkt_part» и «end_packet_part», если присутствуют, должны содержать размер частичных данных в начале и в конце полезной нагрузки страницы соответственно. Присутствие и размер данных полей определяются флагом «packet_part» в соответствии с таблицей А.3. Частичные данные в начале полезной нагрузки считаются принадлежащими к предыдущей в хронологическом порядке странице, а в текущей странице эта часть данных должна быть проигнорирована.

Поле «stuffing», если присутствует, должно содержать размер заполнения в конце полезной нагрузки, которое должно быть проигнорировано при дальнейшей обработке содержимого страницы. Длина поля «stuffing» определяется флагом «has_stuffing» (см. таблицу А.2). Присутствие поля «stuffing» имеет смысл в страницах фиксированного размера.

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

Если пакетов в странице несколько, то могут быть указаны их размеры. Для указания длины поля с размером пакетов («packet_size») используется флаг «has_pkt_sz».

Если «has_pkt_sz» не равно 00b, то в зависимости от значения флага «same_sz» поле «packet_size» размещается (см. таблицу А.4):

• один раз и относится ко всем пакетам («same_sz» = 1b);
• перед каждым пакетом («same_sz» = 0b).

Если «same_sz» = 1b и «has_pkt_sz» = 00b, то страница должна быть проигнорирована.

Если «has_pkt_ts» = 1b, то временная метка указывается для каждого пакета отдельно, ее размер определяется полем «has_ts», временная метка для страницы в целом в этом случае не указывается (см. таблицу А.4).

А.2.2 Страница с пакетами данных разных элементарных потоков и системными пакетами

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

Заголовок страницы состоит из:

• флагов заголовка;
• данных заголовка.

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

• флагов подзаголовка;
• данных подзаголовка.

Структура флагов заголовка страницы представлена в таблице А.5.

Таблица А.5

Структура флагов заголовка страницы с пакетами данных разных элементарных потоков и системными пакетами

Структура флагов заголовка подстраницы представлена в таблице А.6.

Таблица А.6

Структура флагов заголовка подстраницы страницы с пакетами данных разных элементарных потоков и страницы с системными пакетами

Описание флагов заголовка страницы и заголовка подстраницы представлено в таблице А.7.

Таблица А.7

Описание полей заголовка и подзаголовка страницы с пакетами данных разных элементарных потоков и страницы с системными пакетами

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

Таблица А.8

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

Данная страница определяется по значению поля «page_type», которое должно быть установлено в значение 10b.

Для всех флагов в байтах, следующих в таблицах А.5 и А.6 за байтом, где флаг «more» равен 0b, принимаются значения по умолчанию. Для последнего байта флагов заголовка и подзаголовка флаг «more» должен быть равен 0b.

А.2.2.1 Описание полей заголовка страницы

Поле «size» должно определять размер полезной нагрузки страницы, т.е. данных страницы, следующих после заголовка. Размер поля «size» определяется флагом «has_size» заголовка страницы.

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

Поля «begin_pkt_part» и «end_packet_part», если присутствуют, должны содержать размер частичных данных в начале и в конце полезной нагрузки страницы соответственно. Присутствие и размер данных полей определяются флагом «packet_part» в соответствии с таблицей А.3. Частичные данные в начале полезной нагрузки считаются принадлежащими к предыдущей в хронологическом порядке странице, а в текущей странице эта часть данных должна быть проигнорирована.

Поле «stuffing», если присутствует, должно содержать размер заполнения в конце полезной нагрузки, которое должно быть проигнорировано при дальнейшей обработке содержимого страницы. Длина поля «stuffing» определяется флагом «has_stuffing» (см. таблицу А.7). Поле «stuffing» имеет смысл в страницах фиксированного размера.

Поле «CRC» должно содержать значение CRC-32, вычисленное для полезной нагрузки страницы (алгоритм вычисления CRC-32 приведен в приложении Г). Присутствие поля «CRC» определяется флагом «has_crc».

А.2.2.2 Описание полей заголовка подстраницы

Поле «es_id» присутствует только в подстранице с пакетами данных элементарного потока. Оно должно содержать идентификатор элементарного потока. Размер поля определяется флагом «has_es_id». В случае, когда подстраница содержит системные пакеты, флаг «has_es_id» определяет размер поля «es_id» для соответствующих системных пакетов (см. разделы А.2.3, А.2.4).

Поле «4cc» присутствует только в подстранице с пакетами данных элементарного потока. Оно должно содержать значение FOURCC для пакетов данного элементарного потока в данной подстранице. Присутствие данного поля определяется флагом «has_4cc». В случае, когда подстраница содержит системные пакеты, флаг «has_4cc» должен быть установлен в 0.

Данные подстраницы составляет один или несколько пакетов данных элементарного потока или системных пакетов.

Если пакетов в странице несколько, то могут быть указаны их размеры. Для указания длины поля с размером пакетов («packet_size») используется флаг «has_pkt_sz».

Если «has_pkt_sz» не равно 00b, то в зависимости от значения флага «same_sz» поле «packet_size» размещается (см. таблицу А.8):

• один раз и относится ко всем пакетам («same sz» = 1b);
• перед каждым пакетом (same_sz» = 0b).

Если «same_sz» = 1b и «has_pkt_sz» = 00b, то вся страница должна быть проигнорирована.

Если «h_pkt_ts» = 1b, то временная метка указывается для каждого пакета отдельно, ее размер определяется полем «has_ts», временная метка для подстраницы в целом в этом случае не указывается (см. таблицу А.8).

А.2.3 Пакеты описания элементарных потоков

Данный тип пакетов относится к системным пакетам и предназначен для хранения описания элементарного потока.

Пакет может располагаться на странице с системными пакетами («page_type» = '01b') либо на подстранице (с установленным флагом «system») страницы «page_type» = 10b.

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

Заголовок пакета состоит из:

• флагов заголовка;
• данных заголовка.

Структура флагов заголовка пакета представлена в таблице А.9. Описание флагов заголовка представлено в таблице А.10.

Таблица А.9

Структура флагов заголовка пакета, содержащего описание элементарного потока

Таблица А.10

Описание флагов заголовка пакета, содержащего описание элементарного потока

Структура данных заголовка зависит от значений флагов. В таблице А.11 представлена побайтовая структура пакета с возможными (в зависимости от флагов) размерами полей данных заголовка.

Таблица А.11

Побайтовая структура пакета с описанием элементарного потока

Под родителем пакета далее будет пониматься страница с «page_type» = 01b или подстраница страницы с «page_type» = 10b, содержащая данный пакет.

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

Если флаг «sys_std» = 1b, то данный пакет является одним из стандартных системных пакетов, тогда тип этого пакета определяется флагом «std_sys_type» (2-й и 3-й биты первого байта заголовка, см. таблицу А.10). Для пакета описания элементарного потока значение флага «std_sys_type» должно быть равно 00b.

Если флаг «sys_std» = 0b, то такой пакет должен быть проигнорирован (зарезервировано для возможных дальнейших расширений протокола).

Поле «es_id» должно определять идентификатор описываемого в данном пакете элементарного потока. Размер поля «es_id» определяется флагом «has_es_id» родителя пакета.

Присутствие поля «FOURCC» определяется флагом «has_4cc» заголовка пакета, если он равен 1b, то поле присутствует и должно содержать значение FOURCC для описываемого данным пакетом элементарного потока.

Поле «ts_a_f», если присутствует, должно определять формат абсолютной временной метки, которая находится в поле «timestamp» родителя пакета, относящемся к данному пакету. Присутствие поля «ts_a_f» определяется флагом «h_ts_a_f». Возможные значения поля «ts_a_f» указаны в таблице А.12. Если поле «timestamp» родителя пакета, относящееся к данному пакету, присутствует (оно содержит абсолютную временную метку), а «h_ts_a_f» = 0b, то формат абсолютной временной метки определяется исходя из размера поля «timestamp» родителя пакета в соответствии с таблицей А.13.

Таблица А.12

Возможные значения формата временной метки

Таблица А.13

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

Поле «ts_es_f», если присутствует, должно определять формат временных меток описываемого элементарного потока. Присутствие поля «ts_es_f» определяется флагом «h_ts_es_f», и если он равен 1b, то поле присутствует. Возможные значения поля «ts_es_f» указаны в таблице А.12. Если поле «ts_es_f» отсутствует, то формат временных меток для описываемого элементарного потока определяется исходя из размера поля «timestamp», относящегося к пакетам данных потока в соответствии с таблицей А.13.

Поле «ts_es», если присутствует, должно определять временную метку описываемого элементарного потока, которой соответствует абсолютная временная метка для данного пакета описания элементарного потока. Формат временной метки, помещаемой в поле «ts_es», должен соответствовать формату временных меток описываемого потока. Присутствие поля «ts_es» определятся флагом «h_ts_es», если «h_ts_es» = 1b, то поле присутствует.

Если размер пакета, указанный в родителе пакета, больше, чем заголовок пакета, то остальные данные — расширенные данные пакета. Их формат определяется флагами «compress» и «dformat». Флаг «compress» определяет способ сжатия расширенных данных (см. описание флага «compress» в таблице А.10). Флаг «dformat» определяет формат, в котором представлены расширенные данные (см. описание флага «dformat» в таблице А.10).

Флаг «crypted» указывает, что данные описываемого элементарного потока зашифрованы. Данные, необходимые для дешифрации, должны находиться в расширенных данных потока (см. приложение Б).

А.2.4 Пакеты описания групп элементарных потоков

Данный тип пакетов относится к системным пакетам и предназначен для хранения описания одной или нескольких групп элементарных потоков.

Пакет может располагаться на странице с системными пакетами («page_type» = 01b) либо на подстранице (с установленным флагом «system») страницы «page_type» = 10b.

Пакет состоит из заголовка, основных данных пакета и опционально из расширенных данных пакета.

Заголовок пакета состоит из флагов.

Структура флагов заголовка пакета представлена в таблице А.14. Описание флагов заголовка представлено в таблице А.15.

Таблица А.14

Структура флагов заголовка пакета с описанием группы элементарных потоков

Таблица А.15

Описание флагов заголовка пакета с описанием групп элементарных потоков

Структура данных заголовка зависит от значений флагов. В таблице А.16 представлена побайтовая структура пакета.

Таблица А.16

Побайтовая структура пакета с описанием групп элементарных потоков

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

Если флаг «sys_std» = 1b, то данный пакет является одним из стандартных системных пакетов, тогда тип этого пакета определяется флагом «std_sys_type» (2-й и 3-й биты первого байта заголовка, см. таблицу А.15). Для пакета описания групп элементарных потоков значение флага «std_sys_type» должно быть равно 01b.

Если флаг «sys_std» = 0b, то такой пакет должен быть проигнорирован (зарезервировано для возможных дальнейших расширений протокола).

Поле «num_groups», если присутствует, должно содержать количество описываемых в данном пакете групп элементарных потоков. Присутствие поля «num_groups» определяется флагом «has_num_groups». Если поле «has_num_groups» = 0b, то поле «num_groups» отсутствует, и в данном пакете описывается одна группа элементарных пакетов.

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

• g_id — идентификатор описываемой группы, длина этого поля определяется флагом «has_g_id»;
• num_es — количество элементарных потоков в группе, длина этого поля — 1 байт;
• последовательность полей, каждое из которых представляет идентификатор элементарного потока, входящего в состав описываемой группы; длина этих полей определяется флагом «has_es_id» заголовка пакета.

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

Если размер пакета, указанный в родителе пакета, больше, чем заголовок пакета в сумме с данными пакета, то остальные данные — расширенные данные пакета. Их формат определяется флагами «compress» и «dformat». Флаг «compress» определяет способ сжатия расширенных данных (см. описание флага «compress» в таблице А.15). Флаг «dformat» определяет формат, в котором представлены расширенные данные (см. описание флага «dformat» в таблице А.15).

А.2.5 Алгоритм разбора потока ТК РАВИС

Каждая страница ТК РАВИС должна начинаться с 4-байтного кода FOURCC «RAVS».

За ним следует считать 1-й байт заголовка страницы. По первым 2 битам определяется тип страницы ТК РАВИС:

• 00b — страница с данными одного элементарного потока;
• 01b — страница с системными пакетами;
• 10b — страница с данными разных элементарных потоков (в этой странице также могут содержаться системные пакеты).

Далее, в соответствии с типом страницы ТК РАВИС следует считать оставшуюся часть флагов заголовка страницы.

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

Из данных страницы с помощью использования данных заголовка страницы могут быть извлечены пакеты данных элементарных потоков (из страницы типа 00b), системные пакеты (из страницы типа 01b) или подстраницы (из страницы типа 10b). Из подстраниц при дальнейшем разборе могут быть извлечены пакеты данных элементарных потоков и системные пакеты.

Системные пакеты разбираются в соответствии с разделами А.2.4 и А.2.5.

Приложение Б (информационное)

ПРИМЕРЫ РАСШИРЕННЫХ ДАННЫХ СИСТЕМНЫХ ПАКЕТОВ ТК РАВИС

Ниже приводится пример расширенных данных пакетов описания элементарных потоков и пакетов описания групп элементарных потоков в формате JSON.

Б.1 Расширенные данные пакетов описания элементарных потоков в формате JSON

Б.2 Расширенные данные пакета описания сервисов в формате JSON

Приложение В (обязательное)

ПРАВИЛА ФОРМИРОВАНИЯ TAG-ПАКЕТА ДЛЯ ВХОДА ФОРМИРОВАТЕЛЯ КОНТЕНТА

TAG-пакет, подаваемый на вход формирователя контента, может содержать данные элементарного потока или данные сервиса. Кроме того, TAG-пакет может содержать дополнительную информацию.

Ниже описаны TAG-элементы, передаваемые в одном TAG-пакете.

В.1 TAG-элементы

Формирователь контента РАВИС должен уметь декодировать и интерпретировать все TAG-элементы, приведенные в таблице В.1.

Таблица В.1

Основные TAG-элементы

В.1.1 Тип протокола и версия (*ptr)

Формат данного TAG-элемента представлен на рисунке В.1. Данный TAG-элемент должен быть включен в каждый TAG-пакет, поступающий на вход формирователя контента.

Рисунок В.1 — Тип протокола и версия

64 бита (8 байтов) TAG-значения определяются следующим образом (от старшего байта к младшему):

• 4 байта определяют тип протокола (строка ASCII «RCCI»);
• 2 байта определяют старшую часть версии (текущее значение — 0016);
• 2 байта определяют младшую часть версии (текущее значение — 0016).

В.1.2 Счетчик TAG-пакетов (rtpc)

Формат данного TAG-элемента представлен на рисунке В.2. Данный TAG-элемент должен быть включен в каждый TAG-пакет, поступающий на вход формирователя контента.

Рисунок В.2 — Счетчик TAG-пакетов

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

..., FFFFFFFE₁₆, FFFFFFFF₁₆, 0000000016, 0000000116, ... .

Счетчик служит для обнаружения потерь TAG-пакетов и для переупорядочивания пакетов при необходимости (например, при передаче TAG-пакетов по сети Ethernet по протоколу UDP порядок прихода пакетов может нарушиться).

Получение нескольких одинаковых TAG-пакетов не является ошибкой. Формирователь контента должен игнорировать дополнительные пакеты с идентичным содержанием.

В.1.3 Идентификатор элементарного потока (reid)

Формат данного TAG-элемента представлен на рисунке В.3. Данный TAG-элемент должен быть включен в TAG-пакет, содержащий данные элементарного потока.

Рисунок В.3 — Идентификатор элементарного потока

TAG-длина может иметь значения 0, 8, 16, 32.

В случае, когда длина не равна 0, в TAG-значении находится идентификатор элементарного потока.

Если длина равна 0, то это обозначает, что в данном TAG-пакете находятся данные элементарного потока. В этом случае формирователь контента, при необходимости, может определить идентификатор элементарного потока другими способами (например, по адресу отправителя данного TAG-пакета или по номеру порта приема, если они были согласованы ранее).

В.1.4 Идентификатор сервиса (rsid)

Формат данного TAG-элемента представлен на рисунке В.4. Данный TAG-элемент должен быть включен в TAG-пакет, содержащий данные сервиса.

Рисунок В.4 — Идентификатор сервиса

TAG-длина может иметь значения 0, 8, 16, 32, 64.

В случае, когда длина не равна 0, в TAG-значении находится идентификатор сервиса.

Если длина равна 0, то это обозначает, что в данном TAG-пакете находятся данные сервиса. В этом случае формирователь контента, при необходимости, может определить идентификатор сервиса другими способами (например, по адресу отправителя данного TAG-пакета или по номеру порта приема, если они были согласованы ранее).

В.1.5 Идентификатор источника (rsrc)

Формат данного TAG-элемента представлен на рисунке В.5. Данный TAG-элемент может быть включен в TAG-пакет.

Рисунок В.5 — Идентификатор источника

UTF-8 текст — произвольное число байтов, кодирующих текстовую строку с использованием формата UTF-8 [4]. Эта информация может использоваться в том числе для определения содержания TAG-пакета по предварительной информации.

В.1.6 Данные элементарного потока или сервиса (rdt)

Формат данного TAG-элемента представлен на рисунке В.6. Данный TAG-элемент должен быть включен в TAG-пакет.

Рисунок В.6 — Данные элементарного потока или сервиса

В данном TAG-элементе передаются данные элементарного потока или сервиса.

Приложение Г (обязательное)

ВЫЧИСЛЕНИЕ ЦИКЛИЧЕСКОГО ИЗБЫТОЧНОГО КОДА

Реализация проверки с помощью циклических избыточных кодов (CRC-кодов) позволяет выявлять ошибки передачи на приемной стороне. С этой целью данные CRC-кода могут быть включены в передаваемые страницы данных. Данные CRC-кода определяются в соответствии с описанной в настоящем приложении процедурой.

Код CRC определяется с помощью полинома степени n:

Gn(x) = xn + gn-1·xn-1 + ... + g2·x2 + g1·x + 1

при n >= 1 и g_{i} \in {0,1} , i = 1, ..., n — 1.

CRC-код может быть вычислен с помощью сдвигового регистра, содержащего n ячеек, где n равно степени полинома. Блок-схема вычисления CRC-кода представлена на рисунке Г.1. Ячейки обозначаются как b0 ... bn-1, где b0 соответствует 1; b1 соответствует x; b2 соответствует x2; ...; bn-1 соответствует xn-1. Сдвиговый регистр дополняется с помощью вставки операторов XOR на входе тех ячеек, где соответствующие коэффициенты gi полинома равны 1.

Рисунок Г.1 — Блок-схема вычисления CRC-кода

В начале вычисления кода CRC-32 все ячейки сдвигового регистра инициализируются нулями.

После поступления первого бита блока данных на вход данных (старший бит поступает первым) тактовый генератор обеспечивает сдвиг ячеек регистра на одну ячейку в направлении ячейки старшего бита bn-1. При этом в промежуточные ячейки помещают данные после соответствующих операций XOR. Затем процедуру повторяют для каждого входного бита данных. После поступления последнего бита (младший бит) блока данных на вход, сдвиговый регистр будет содержать слово CRC-кода, которое вслед за этим считывают. При передаче данных и слова CRC-кода старший бит следует первым.

Код CRC-32, используемый в ТК РАВИС, основан на следующем полиноме:

G8(x) = x32 + x₂₆ + x23 + x22 + x16 + x12 + x11 + x10 + x8 +

• x7 + x5 + x4 + x2 + x + 1.

БИБЛИОГРАФИЯ