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

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

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

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

ОБОРУДОВАНИЕ ЦИФРОВОЙ ВСТАВКИ (СПЛАЙСИНГА) РЕГИОНАЛЬНЫХ ПРОГРАММ В ТРАНСПОРТНЫЙ ПОТОК MPEG-2 ВЕЩАТЕЛЬНОГО ТЕЛЕВИДЕНИЯ

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

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

Москва

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

2014

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

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

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

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

3    Настоящий стандарт разработан с учетом основных нормативных положений Американского национального стандарта / Общества инженеров кабельных телекоммуникаций, подкомитет Цифрового Видео «Прикладной программный интерфейс сплайсинга вставки цифровых программ» (ANSI/SCTE 30 2009 Digital Program Insertion Splicing Application Program Interface)

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

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

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

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

Рисунок 2- Операция флага OverridePlaying

Момент времени tl: Сервер 1 выпускает сообщение Splice_Request и начинает передавать свой поток к сплайсеру. Сплайсер переключает этот поток канала ввода на выходной канал. В сообщении Splice_Request был сделан запрос о вставке продолжительностью от времени tl до времени t5. Сплайсер должен отправить Серверу 1 сообщение SpliceComplete_Response с SpliceType с установкой флага KSpliceJn и с установкой значения Кода Результата «100»: «Успешный Ответ».

Момент времени t2: Сервер 2 выпускает сообщение Splice_Request с флагом OverridePlaying установленным в «1», которое имеет равный или более высокий приоритет (по сравнению с каналом ввода (от Сервера 1)). Во время, определенное в сообщении Splice_Request, поток канала ввода 2 переключен на выходной канал (заменяет продолжающийся поток от Сервера 1). Сервер 2 сообщением Splice_Request запросил вставку продолжительностью от времени t2 до времени t3. Сплайсер должен отправить Серверу 1 сообщение SpliceComplete_Response с флагом SpliceType, установленным в Splice_out и с Кодом Результата «125»: «Переопределение Канала». Сплайсер отправляет Серверу 2 сообщение SpliceComplete_Response с установкой флага SpliceType в Splicejn и устанавливает значение Кода Результата «100»: «Успешный Ответ». Если Сервер 1 решает, что переопределение канала является ошибкой, он может отправить сообщение Abort_Request и завершить поток.

Момент времени t3: Вставка от Сервера 2 завершена, и сплайсер возвращается к материалу от Сервера 1, направляя его к выходному каналу. Сплайсер не переключает основной канал к выходному каналу. Сплайсер передает Серверу 1 сообщение SpliceComplete_Response с набором флага SpliceType к Splicejn и устанавливает значение Кода Результата «125»: «Переопределение канала». Сплайсер передает на Сервер 2 сообщение SpliceComplete_Response с установкой флага SpliceType к Splice_out и устанавливает значение Кода Результата «100»: «Успешный Ответ».

Момент времени t4: Сервер 2 выпускает сообщение Splice_Request с установкой флага OverridePlaying, установленным в «1». Во время, определенное сообщением Splice JRequest, поток канала ввода 2 переключается на выходной канал (заменяя поток от Сервера 1). Сервер 2 сообщением Splice_Request запрашивает вставку продолжительностью от времени t4 до времени t6. Сплайсер должен отправить Серверу 1 сообщение SpliceComplete_Response с флагом SpliceType, установленным в Splice_out и со значением Кода Результата «125»: «Переопределение канала». Сплайсер отправляет на Сервер 2 сообщение SpliceComplete_Response с установкой флага SpliceType, установленным в Splicejn, и со значением Кода Результата «100»: «Успешный Ответ».

Момент времени t5: Сервер 1 заканчивает проигрывать вторую часть потока вставки, переопределенную Сервером 2.

Момент времени t6: Заключительная часть вставки завершена, сплайсер возвращается к материалу от основного канала и направляет его к выходному каналу. Сплайсер передает Серверу 2 сообщение SpliceComplete_Response с установкой флага SpliceType к Splice_out и устанавливает значение Кода Результата «100»: «Успешный Ответ».

Возможна ситуация, когда несколько серверов должны будут разделить сообщение Cue_Request с возможностью вставки общей продолжительностью 60 с, когда один Сервер будет использовать первые 30 с, а второй Сервер будет использовать последние 30 с. В зависимости от приоритетов и в случае, если будут приняты сообщения Splice_Request, сплайсер должен установить Код Результата «109» «Коллизия вставки», если она возникнет. Настоящий стандарт не устанавливает параметры API, обеспечивающие возможность координации двух Серверов. Указанная координации может быть выполнена по взаимному соглашению между Серверами или API в версии сервер -сервер.

7

4.3    Аномальные завершения вставки

Было показано, что во время воспроизведения (проигрывания) вставка будет переопределена вставкой с более высоким приоритетом. В этом случае сплайсер должен возвратиться к переопределенной вставке при окончании вставки с более высоким приоритетом. Если вставка с более высоким приоритетом прервана сообщением Abort_Request, сплайсер должен возвратиться к переопределенной вставке. Если первоначальный канал ввода более не доступен, то сплайсер не должен возвращаться к основному каналу, если это возможно.

Если сервер запрашивает вставку на основном канале, в котором в настоящий момент нет допустимых данных, сплайсер должен выполнить вставку и в сообщении SpliceComplete_Response к серверу сообщить Код Результата «111»: «Не найден основной канал». Аналогичным образом вставка от канала ввода назад к основному каналу, у которого нет допустимых (правильных) данных, завершится с Кодом Результата «111»: «Не найден основной канал».

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

4.4    Требования к процессу вставки

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

Поле ChannelName используется для идентификации выходного канала. Поле ChannelName содержит уникальное имя, присвоенное каждому выходному каналу (например, НТВ или CNN), оно устанавливается в сплайсер, и необходимо серверу для определения основного канала, который будет заменен каналом ввода.

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

4.5    Параметры передачи информации между сервером и сплайсером

Передачу информации между сервером и сплайсером производят через один TCP/IP сокет. После установления Соединения API оно сохраняется до тех пор, пока одно из устройств его не завершит. Для повторной инициализации требуется новая установка соединения.

Все сообщения, которыми обмениваются сплайсер и сервер, используют общий формат, детализированный в разделе 7 настоящего стандарта. Для передачи между сплайсером и сервером необходимо использовать только сообщения, поддерживающие этот формат. Формат разрешает класс сообщений типа «Определен пользователем», который может использоваться в качестве шаблона для частных сообщений между сплайсером и сервером. Нормирование этого класса сообщений настоящим стандартом не предусмотрено.

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

5 Синтаксис API

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

-    сообщения Splicing_API_Message;

-    функции передачи сообщений;

-    функции инициализации передачи сообщений:

-    сообщение запроса lnit_Request;

-    сообщение ответа lnit_Response;

-    встроенные сообщения меток Cue_Request;

-    сообщения вставки:

8

ГОСТ P 55715—2013

-    Splice_Request;

-    Splice_Response;

-    SpliceComplete_Response;

-    сообщения о состоянии (статусе) сплайсера:

-    Alive_Request;

-    Alive_Response;

-    сообщения расширенных данных:

-    ExtendedData_Request;

-    ExtendedData_Response;

-    сообщения прерывания:

-    прерывания вставок Abort_Request;

-    Abort_Response;

-    TearDownFeed_Request;

-    TearDownFeed_Response;

-    сообщения запроса параметров конфигурации:

-    GetConfig_Request;

-    GetConfig_Response;

-    General_Response.

5.1 Синтаксис сообщения Splicing_API_Message

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

Сообщение Splicing_API_Message кодируется в соответствии с таблицей 1.

Таблица!    - Кодирование сообщения Splicing_API_Message

Синтаксис	Количество байтов	Тип
Splicing_API_Message { MessagelD MessageSize Result Result_Extension data() }	2 2 2 2 *	uimsbf uimsbf uimsbf uimsbf *

MessagelD: Значение поля указывает на параметры отправляемого сообщения в соответствии с таблицей 2.

9

Таблица2 - Параметры отправляемого сообщения в зависимости от значения поля MessagelD

Значение поля MessagelD Имя сообщения Источник сообщения Описание 0x0000 General_Response Сплайсер или сервер Используется для передачи асинхронной информации между устройствами. Это не данные (data()), связанные с этим сообщением 0x0001 lnit_Request Сервер Первоначальное сообщение сплайсеру на порт 5168 0x0002 lnit_Response Сплайсер Первоначальный ответ серверу на установленное соединение 0x0003 ExtendedData_ Request Сервер Запрос на детализированное воспроизведение информации от сплайсера. 0x0004 ExtendedData_Response Сплайсер По запросу сервера отправляет на сервер структуру, содержащую детализированные данные о воспроизведении 0x0005 Alive_Request Сервер Отправляет сообщение запроса статуса сплайсера для того, чтобы получить оценку его текущего статуса 0x0006 Alive_Response Сплайсер Ответ на запрос текущего статуса сплайсера 0x0007 Splice_Request Сервер Запрос вставки в определенное время 0x0008 Splice_Response Сплайсер Ответ, указывающий что Splice_Request был получен и сплайсер обрабатывает вставку 0x0009 SpliceCoplete_ Response Сплайсер Ответ о начале вставки и об окончании вставки ОхОООА GetConfig_Request Сервер Запрос для получения конфигурации текущей вставки для этого Соединения API 0x000В GetConfig_Response Сплайсер Содержит всю информацию о вставке для Соединения API ОхОООС Cue_Request Splicer Сплайсер Сплайсер, отправляющий секцию метки серверу OxOOOD Cue_Response Сервер Подтверждение, что секция метки была получена ОхОООЕ Abort_Request Сервер Запрос немедленного возврата к основному каналу или к переопределению канала ввода OxOOOF Abort_Response Сплайсер Подтверждение получения сообщения Abort_Request. В случае необходимости должно быть сгенерировано сообщение SpliceComplete Response 0x0010 TearDownFeed_Requ est Сервер Запрос на удаление выходного канала, созданный с помощью дескриптора create feed descriptor) 0x0011 TearDownFeed_Response Сплайсер Ответ, показывающий, что выходной канал был удален 0x0012- 0x7FFF Зарезервировано Диапазон значений зарезервирован для будущей стандартизации 0x8000 -OxFFFE Определяется пользователем Диапазон функций, доступный для определения пользователем

ю

ГОСТ P 55715—2013

MessageSize: Размер поля data() в байтах.

Result: Поле передается в ответ на запрашиваемое сообщение. Детализация Кодов Результата в соответствии с приложением А. На сообщениях запроса в поле установлено OxFFFF.

Result_Extension: В поле должно быть установлено OxFFFF, если в сообщении ответа не передается информация дополнительного результата.

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

5.2    Требования и соглашения передачи сообщений

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

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

-    все строки имеют пространство, зарезервированное для нулевого символа окончания строки, и должны завершаться нулевым символом. Например, строка, длина которой определена в 16 символов, может иметь не больше 15 символов данных, сопровождаемых символом нуля (0x00) сразу после последнего символа данных. После символа нуль в остальной части строки символы имеют произвольное значение. Размер строки, является постоянным и не изменяется в зависимости от ее длины. В настоящем стандарте в строке используются символы ASCII на 8 битов;

-    все значения времени устанавливаются в соответствии с UTC;

-    в поле, состояние которого безразлично, устанавливаются только 1. В 4-байтовом поле это значение было бы OxFFFFFFFF;

-    сообщения ответа должны отсылаться без неоправданных задержек. Устройство, должно ожидать ответ в интервале 5 с, не указывая на ошибку задержки (тайм-аут). Когда сервер подозревает тайм-аут, он должен отправить сообщение Alive_Request. Если сплайсер не дает ответа, предусмотренного настоящим стандартом, соединение для этого канала должно быть удалено и восстановлено;

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

-    поле Result в сообщении Splicing_API_Message используется для возврата Кода Результата. Множество кодов ответа могут быть возвращены в любое время отправлением нескольких сообщений General_Response;

-    если сплайсер или сервер не могут проанализировать сообщение запроса, они должны возвратить General_Response с Кодом Результата «123». Имя результата в соответствии с таблицей А.1 приложения А настоящего стандарта.

5.3    Инициализация передачи сообщений

Первоначальное сообщение начинается со сплайсера, прослушиванием порта 5168, и сервером, открывающим Соединение API со сплайсером. Сервер отправляет сплайсеру сообщение lnit_Request. После этого сервер прислушивается к ответу от сплайсера по установленному Соединению API. Все дальнейшие передачи выполняются на этом Соединении API. Сплайсер или сервер могут завершить связь, закрывая это Соединение API. Каждое устройство ответственно за то, что обнаружило и должным образом обработало Соединение API.

Когда сплайсер подготавливает к работе приемную сторону TCP, порт 5168, он должен увеличить не менее чем в три раза число каналов ввода для Соединений API со сплайсером. Например, если сплайсер управляет 70 каналами, из которых 40 пригодны для вставки, то он должен предусмотреть одновременное подключение 120 API.

5.3.1 Сообщение запроса lnit_Request

11

Поле data() этого сообщения содержит структуру lnit_Request_Data, приведенную в таблице 3. ТаблицаЗ - Структура lnit_Request_Data поля data() сообщения запроса lnit_Request

Синтаксис	Количество байтов	Тип
lnit_Request_Data { VersionQ
ChannelName	32	Строка
SplicerName Hardware_Config() для (i=0; i <N; i++) splice API descriptor) }	32	Строка

VersionQ: В соответствии с подразделом 6.1 настоящего стандарта.

ChannelName: Логическое имя выходного канала этого соединения. Оно также используется для проверки корректности Соединения API при ответе сплайсера серверу.

SplicerName: Имя сплайсера для того случая, когда сервер использует API для связи с устройством, управляющим несколькими сплайсерами.

Hardware_Config(): В соответствии с подразделом 6.2 настоящего стандарта.

splice_API_descriptor(): Синтаксис этого дескриптора должен быть в соответствии с подразделом 6.5 настоящего стандарта. Для запроса lnit_Request может использоваться дескриптор miss-ing_Primary_Channel_action_descriptor().

5.3.2 Сообщение ответа lnit_Response

После того, как сервером отправлен запрос lnit_Request, сплайсер по открытому Соединению API отправляет сообщение lnit_Response. Прием этого сообщения позволяет серверу проверить, что версия, отправленная сплайсеру, поддерживается и что у него есть Соединение API с корректным основным каналом. Поле data() этого сообщения содержит структуру lnit_Response_Data, приведенную в таблице 4.

ChannelName: Поле возвращается сервером, что указывает на корректное выполнение соединения.

5.4 Встроенные сообщения меток

Сплайсеры имеют возможность получать встроенные сообщения метки, предусмотренные стандартом ANSI/SCTE [2]. При получении сплайсером сообщений метки они должны быть переданы на сервер. Сообщение Cue_Request используется для передачи сообщений метки

от сплайсера к серверу. Когда сплайсер получает сообщение метки, он отправляет серверу всю секцию splice_info_section( ), включающую время вставки. Сервер подтвердит прием этого сообщения сообщением Cue_Response. Сообщение Cue_Response состоит только из сообщений Splicing_API_Message и не имеет связанных данных data(), но может иметь код возврата. Сплайсер должен дешифровать секцию splice_info_section() (если она будет зашифрована) прежде, чем отправить ее серверу.

Если сплайсер получит сообщение метки, имеющее недопустимое значение CRC, то он должен отправить General_Message к серверу с Кодом Результата «117»: «Недопустимое сообщение метки». В этом случае сплайсер не должен отправлять сообщение Cue_Request.

ГОСТ P 55715—2013

Допускается возможность изменения сплайсером конфигурации сообщения Cue_Request в соответствии со стандартом ANSI/SCTE [2]. Конфигурации сообщения могут включать:

-    возможность передачи сообщения новых версий стандарта ANSI/SCTE [2], которые сплайсер в старой версии стандарта ANSI/SCTE [2] не понимает;

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

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

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

Поле data( ) сообщения Cue_Request содержат структуру Cue_Request_Data, приведенную в таблице 5.

Таблица 5    -    Структура    Cue_Request_Data поля data() сообщения меток Cue_Request

Синтаксис Cue_Request_Data { time() splice info sectionQ }_

time(): Значение поля формируется из поля splice_time() в секции

splice_info_section( ) сообщений метки сплайсера стандарта ANSI/SCTE [2]. Если в стандарте ANSI/SCTE [2] используется режим вставки компонентов splice_info_section, то поле time() ссылается на время вставки «по умолчанию», детализированному в стандарте ANSI/SCTE [2] (7.5.2.1). В случае, если секция splice_info_section() не содержит поле pts_time(), это требует преобразования аналогичного случаю команды splice_schedule(), тогда временная структура должна быть заполнена последовательностью «1», чтобы обозначить определенное время. Выбор правила отображения времени PTS к времени UTC для связи с сервером зависит только от сплайсера. Оно может изменяться для различных сплайсеров, чтобы должным образом управлять своими внутренними буферами. Синтаксис структуры time() показан в подразделе 6.4 настоящего стандарта.

Подробности структуры секции splice_info_section() изложены в стандарте ANSI/SCTE [2].

5.5 Сообщения вставки

После инициализации и конфигурирования сплайсера для инициирования сеанса сервер может выпустить сообщение Splice_Request. На сообщение от сервера Splice_Request сплайсер отвечает сообщениями Splice_Response и SpliceCompleteResponse. Продолжительность передачи сервером сообщения Splice_Request должна быть не менее 3 с до окончания передачи в сообщении Splice_Request поля time(). Это позволяет сплайсеру установить свою конфигурацию и приготовить вставку. Поток канала ввода для сеанса должен начаться в интервале времени между 300 и 600 мс перед полем time() при измерении на входе сплайсера. Ссылка на программные часы (PCR) должна быть передана не позднее первого видео модуля доступа потока канала ввода. Видеопоток контента вставки должен начаться с заголовка последовательности и 1-кадра. Сплайсер должен поддерживать в очереди не менее 10 сообщений Splice_Request на данном Соединении API. Если очередь сообщения сплайсера будет заполнена, то сплайсер ответит Кодом Результата «114»: «Очередь вставки заполнена». Подробности физического соединения предоставлены в сообщении lnit_Request. Предусмотрены два способа индикации канала в мультиплексе вставки и используемого РЮ:

-    если в сообщении Splice_Request идентификатор ServicelD не равен OxFFFF, то поле ServicelD определяет номер программ в РАТ, который указывает на связанную РМТ. РАТ и РМТ должны быть стабильными в канале вставки на интервале не менее 200 мс перед отправлением сообщения Splice_Request и должны оставаться стабильными на интервале сеанса. Они должны соответствовать расширенным версиям таблиц MPEG;

-    если ServicelD равно OxFFFF, то в сообщении Splice_Request необходимо использовать структуру splice_elementary_stream() (PCR, видео, аудио и PID данных).

Примечание - Если будет использован этот метод, то в поле ServicelD должен быть установлен OxFFFF. Сплайсер для выходного мультиплекса должен предоставлять совместимые транспортные потоки MPEG-2 (мультиплекс ввода не должен содержать PSI).

13

Должен обеспечиваться следующий порядок отправления сообщений вставки. Первое сообщение из последовательного ввода передается непрерывно и должно использовать поле time(), в то время как все другие сообщения Splice_Request могут использовать поле PriorSession. Номер поля PriorSession должен ссылаться на существующий сеанс, который еще не завершился. Во всех других случаях возвращается код ошибки 123, указывающий на поле PriorSession или поле time().

Сервер в мультиплексе ввода выбирает PID элементарных потоков. РЮ не могут быть общими для смежных сеансов одного и того же сервера одного и того же самого мультиплекса ввода, вследствие того, что потоки смежных сеансов могут накладываться во времени из-за требований API.

5.5.1 Сообщение вставки Splice_Request

Поле data() этого сообщения содержит структуру Splice_Request_Data, приведенную в таблице

6.

Таблицаб    -    Структура    Splice_Request_Data    поля    data() сообщения вставки

Splice_Request

Синтаксис Количество байтов Тип Splice_Request_Data { SessionID 4 uimsbf PriorSession 4 uimsbf time() ServicelD 2 uimsbf if (ServicelD = OxFFFF) { PcrPID 2 uimsbf PIDCount 4 uimsbf for(j=0; j <PidCount; j ++) splice elementary streamQ } Duration 4 uimsbf SpliceEventID 4 uimsbf PostBlack 4 uimsbf AccessType 1 uimsbf OverridePlaying 1 uimsbf ReturnToPriorChannel 1 uimsbf for(i=0; i <N; i ++) splice API descriptor) J_

SessionID: Идентификатор сеанса. Используется для того, чтобы отличать этот запрос от других запросов «это было или будет выпущено». Не разрешается выполнять конкурирующие сообщения Splice_Request с одинаковыми SessionID.

PriorSession: Это поле позволяет применять упрощенный метод последовательного ввода вставок. Это поле содержит SessionID сеанса, который ему предшествует. Значение этого поля OxFFFFFFFF указывает, что этот сеанс использует поле time( ) для инициирования вставки, а не SessionID предыдущего сеанса. Это поле будет иметь допустимый SessionID только в том случае, если предыдущий сеанс выполнен тем же самым сервером. Для создания режима последовательного ввода вставок от множества серверов должно использоваться поле time(), но не поле PriorSession.

time(): Время вставки события. Это поле, как правило, соответствует полю time() сообщения Cue_Request (от сплайсера). Если событие не было инициировано Cue_Request, тогда оно определяет время, когда сервер форсирует (вынуждает) вставку события. Это поле должно быть игнорировано, если PriorSession не равен OxFFFFFFFF. Если это значение не связано с сообщением метки стандарта ANSI/SCTE [2], то могут возникать различия между сплайсерами в зависимости от буфера и модели фактического выполнения вставки. Синтаксис структуры поля time() приведен в подразделе

6.4 настоящего стандарта.

ServicelD: Номер канала в мультиплексе ввода, который будет вставлен вместо основного канала. Если поле имеет значение OxFFFF, то необходимо использовать поля splice_elementary_stream( ) и PIDCount.

PCR: Указывает на PID PCR.

PIDCount: Указывает количество PID в канале ввода (не считая PID PCR).

14

ГОСТ P 55715—2013

Duration (продолжительность): Количество тактов системных часов на 90 кГц, которое сервер запрашивает у сплайсера для вставки. Это поле может быть использовано для корректировки значения продолжительности по стандарту ANSI/SCTE [2]. В этом поле может быть установлен «0», чтобы указать, что сплайсер должен переключиться на канал ввода до прибытия новых сообщений Splice_Request или Abort_Request.

SpliceEventID: Это поле используется, чтобы связать это событие вставки с сообщением метки стандарта ANSI/SCTE [2], которое могло инициировать эту вставку. Это поле должно быть эквивалентно полю splice_event_id из команды splicejnsert, связанной с сообщением метки стандарта ANSI/SCTE [2]. Это сообщение должно быть одинаковым для всех сообщений Splice_Request, имеющих отношение к сообщению метки стандарта ANSI/SCTE [2].

Для события, которое не инициировалось сообщением метки стандарта ANSI/SCTE [2], в этом поле будет установлено OxFFFFFFFF.

PostBlack: Количество тактов системных часов на 90 кГц BVMA, которое будет проигрываться в конце воспроизведения контента вставки. Интервал PostBlack не включается в отрезок времени, определенный полем Duration. Если поле PostBlack не затребовано, то в этом поле будет установлен «0».

AccessType: Указывает на тип доступа, который имеет это соединение. Это целое число от 0 до 9. Число 0 обладает самым низким приоритетом, число 9 обладает самым высоким приоритетом.

OverridePlaying: Когда этот флаг равен «0», поле Splice_Request не может переопределить вставку, проигрываемую в настоящий момент. Если этот флаг будет установлен в 1, то поле Splice_Request должно переопределить любую в настоящий момент проигрываемую вставку с равным или более низким приоритетом. Проигрывание вставки происходит между точкой входа в вставку и точкой выхода из вставки.

ReturnToPriorChannel: Когда этот флаг равен «0», то при завершении сообщения Splice_Request сплайсер не должен возвращаться к основному каналу или к переопределенному каналу ввода. Предполагается, что новый Splice_Request будет выпущен перед завершением этой вставки. Если новый Splice_Request не будет получен, то сплайсер должен прекратить передачу на этом выходном канале. Когда этот флаг будет равен 1, он не должен возвращаться к предшествующему каналу, если последующее сообщение Splice_Request принято и указывает иные параметры вставки.

splice_API_descriptore(): Это дескриптор, который должен поддерживать синтаксис, определенный в подразделе 6.5 настоящего стандарта.

5.5.2 Сообщение Splice_Response

Поле data() этого сообщения содержит структуру Splice_Response_Data, основные параметры которой приведены в таблице 7. Сообщение Splice_Response_Message может содержать код ошибки. Поле Splice_Offset использует сплайсер для информирования сервера о смещении времени поставки контента для этого сообщения. Это поле не влияет на точку входа в основном канале, где произойдет вставка.

Таблица7    -    Структура    Splice_Response_Data    поля data() сообщения вставки Splice_Response

Синтаксис Количество байтов Тип Splice_Response_Data { Splice Offset } 2 tcimsbf

Splice_Offset: В этом поле должен быть установлен «0», если поле не используется для передачи информации о смещении времени. Величина смещения времени оценивается в мс. Отрицательная величина означает, что запрос на вставку контента канала был доставлен ранее, положительная величина - что запрос на вставку контента канала был доставлен позднее.

Поле Splice_Offset будет использоваться для устройств сплайсинга, которые выполняют операции вставки «без шва», изменяя задержку распространения основного канала в сплайсере. Когда такое устройство управляет вставкой в отсутствие сообщений метки стандарта ANSI/SCTE [2], сплайсер не имеет возможности выполнять опережение или задержку синхронизации события сервера событий (объявлений) изменением уравнения в преобразовании pts_time ко времени UTC (потому что отсутствуют сообщения метки стандарта ANSI/SCTE [2] и, следовательно, невозможны преобразования и сообщения запроса метки). В таком случае, сплайсер может использовать новое поле

15

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

5.5.3 Сообщение SpliceComplete_Response

Сообщения SpliceComplete_Response отправляются в начале вставки и по окончании вставки. Это правило справедливо и для случая последовательных вводов. Например, при проигрывании двух частей контента возвращаются четыре сообщения

SpliceComplete_Response: одно - в начале первой части контента, одно - после завершения первой части контента, одно - в начале второй части контента и одно - после завершения второй части контента. Если вставка перестала работать, то Код Результата в заголовке должен указывать причину отказа для того, чтобы сервер мог принять необходимые меры. Вход в вставку и выход из нее являются отдельными событиями и должны обрабатываться как отдельные события. Сообщение SpliceComplete_Response отправляется непосредственно после отказа любого события вставки, не ожидая окончания вставленного контента.

Поле data() этого сообщения содержит структуру SpliceComplete_Response_Data, основные параметры которой приведены в таблице 8.

Таблица8 - Структура SpliceComplete_Response_Data поля data( ) сообщения вставки SpliceComplete_Response

Синтаксис Количество байтов Тип SpliceComplete_Response_Data { SessionID 4 uimsbf SpliceTypeFlag 1 1 uimsbf if (SpliceTypeFlag = 0) { time() } else { Bitrate 4 uimsbf PlayedDuration } Л_ 4 uimsbf

SessionID: ID Сеанса. Указывает, что используется сообщение Splice_Request.

SpliceTypeFlag: В этом поле устанавливается «0», чтобы указать на вход в вставку, и устанавливается «1», чтобы указать на выход из вставки.

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

Bitrate (Скорость передачи): Средняя скорость передачи для сеанса. Это поле определяется в битах в секунду (бит/с), включая непроизводительные потери пакетов для этого канала.

PlayedDuration: Число тактов системных часов на 90 кГц на интервале времени фактически воспроизводимых вставок (за исключением кадров перехода или BVMA).

5.6 Сообщения о состоянии (статусе) сплайсера

После завершения инициализации сервер может отправить сообщения Alive_Request, чтобы проверить готовность сплайсера к функционированию. Каждое сообщение сплайсера Alive_Response для сервера содержит оценку его состояния. Если соединение TCP/IP было не активировано в течении 60 с, сервер должен отправить сообщение Alive_Request.

5.6.1 Сообщение Alive_Request

Поле data() этого сообщения содержит структуру Alive_Request_Data, параметры которой приведены в таблице 9.

ГОСТ P 55715—2013

Содержание

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

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

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

4    Система вставки..........................................................................................................................5

5    Синтаксис API...............................................................................................................................8

6    Дополнительные структуры API.............................................................................................20

7    Синхронизация сервера и сплайсера....................................................................................31

8    Синхронизация в системе.......................................................................................................31

Приложение А (обязательное) Коды Результата...................................................................36

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

ГОСТ P 55715—2013

Таблица 9    - Структура Alive_Request_Data поля data() сообщения о состоянии (ста- _тусе)    слайсера Alive_Request___

Синтаксис Количество байтов Тип Alive_Request_Data { time() Л_

time(): Поле содержит текущее значение таймера UTC передающего устройства,

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

5.6.2 Сообщение Alive_Response

Поле data() этого сообщения содержит структуру Alive_Response_Data, параметры которой приведены в таблице 10.

ТаблицаЮ    -    Структура    Alive_Response_Data    поля    data() сообщения о состоянии (ста

тусе) слайсера Alive_Response

Синтаксис	Количество байтов	Тип
Alive_Response_Data {
State	4	uimsbf
SessionID	4	uimsbf
time()
}

State (Состояние): Поле описывает состояние выходного канала в соответствии с таблицей 11. ТаблицаИ    -    Сообщения    состояния    Alive_Response

Состояние выходного канала	Описание
0x00	Нет выхода
0x01	На основном канале
0x02	На канале ввода

SessionID: Идентификатор воспроизведения вставки в настоящее время. Его применение допускается только для состояния выходного канала, равного 0x02.

time(): Текущее значение таймера UTC передающего устройства на момент отправки сообщения. Синтаксис структуры time() приведен в подразделе 6.4 настоящего стандарта.

5.7 Сообщения расширенных данных

Данная структура определена для передачи от сплайсера на сервер детализированных данных о воспроизведении. После приема SpliceComplete_Response расширенные данные могут быть получены с помощью ExtendedData_Request. Идентификатор SessionID, используемый в этом сообщении, аналогичен SessionID, используемому при установке этого сеанса и в SpliceCompleteResponse.

5.7.1 Сообщение ExtendedData_Request

Поле data() этого сообщения содержит структуру ExtendedData_Request_Data, параметры которой приведены в таблице 12.

17

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

ТЕЛЕВИДЕНИЕ ВЕЩАТЕЛЬНОЕ ЦИФРОВОЕ ОБОРУДОВАНИЕ ЦИФРОВОЙ ВСТАВКИ (СПЛАЙСИНГА) РЕГИОНАЛЬНЫХ ПРОГРАММ В ТРАНСПОРТНЫЙ ПОТОК MPEG-2 ВЕЩАТЕЛЬНОГО ТЕЛЕВИДЕНИЯ Основные параметры

Digital Video Broadcasting (DVB).

Splicing equipment of regional programs in the transport stream of MPEG-2 broadcast television.

Basic parameters

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

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

Настоящий стандарт распространяется на оборудование цифровой вставки (сплайсинга) программ в транспортные потоки MPEG-2 вещательного телевидения.

Настоящий стандарт устанавливает основные параметры оборудования цифровой вставки региональных программ в транспортные потоки MPEG-2, размещаемого на головных станциях (центрах) формирования программ вещания. В состав оборудования цифровой вставки входят серверы и сплайсеры, которые используют для обмена данными прикладной программный интерфейс (Application Program Interface; API).

Прикладной программный интерфейс создает стандартизированный метод передачи между серверами и сплайсерами, обеспечивающий вставки контента в выходные данные мультиплекса MPEG-2 на выходе сплайсера. Этот API достаточно гибок, чтобы поддерживать один или более серверов, присоединенных к одному или более сплайсерам.

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

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

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

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

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

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

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

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

3.1.1    ввод последовательный (Back-To-Back Insertion): Ввод двух или более непрерывных (временно) сеансов без возврата к основной службе между сеансами.

3.1.2    видео-черное поле-видео (video-black-video; VBV): Режим монтажа видеопрограмм без использования видеовставки между кадрами.

3.1.3    вставка (сплайсинг, сращивание) (Splice): Процесс замещения основного канала каналом ввода; характеризуется точкой входа в вставку и точкой выхода из вставки.

3.1.4    вход в вставку (точка входа в вставку) (Splice-in): Точка начала вставки или время начала вставки, указанные в сообщении Splice_Request.

3.1.5    выход из вставки (точка выхода из вставки) (Splice-out): Точка окончания вставки или время окончания вставки. Ожидаемое время окончания вставки вычисляется добавлением к времени начала вставки продолжительности вставки, определенной в сообщении Splice_Request.

3.1.6    выходной канал (Output Channel): Канал, который формируется на выходе сплайсера.

3.1.7    выходной мультиплекс (Output Multiplex): Транспортный поток MPEG-2, произведенный мультиплексированием одного или нескольких выходных каналов.

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

3.1.9    интерфейс прикладных программ (прикладной программный интерфейс) (Application Program Interface; API): Набор программ, используемых приложением для управления системными процедурами.

3.1.10    кадр перехода (post black): Условное обозначение кадра на границе между основным каналом и каналом ввода.

3.1.11    канал (Channel): Синоним «Служба» в терминологии DVB или синоним «Программа» в терминологии MPEG.

3.1.12    канал ввода (Insertion Channel): Канал мультиплекса ввода, который заменяет основной канал на полном интервале вставки события или на части этого интервала.

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

3.1.14    мультиплекс (Multiplex): Один канал или совокупность нескольких каналов, которые могут включать сопряженную информацию о службе. Мультиплекс представляет собой транспортный поток MPEG-2 за исключением случая мультиплекса ввода.

3.1.15    мультиплекс ввода (Insertion Multiplex): Мультиплекс, содержащий канал ввода. Мультиплекс может быть произведен сервером (в ряде случаев с исключением программно-зависимой информации (Program Specific Information; PSI)), в таких случаях мультиплекс может быть несовместимым с транспортным потоком MPEG-2.

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

3.1.17    основной канал (основная служба) (Primary Channel): Канал основного мультиплекса, который заменяется полностью или частично каналом ввода. Единственный основной канал может порождать множество выходных каналов.

3.1.18    основной мультиплекс (Primary Multiplex): Источник основного канала или основных каналов.

3.1.19    протокол обнаружения слушателей (узлов) многоадресной передачи (Multicast Listener Discovery; MLD): один из протоколов в стеке протоколов IPV6. Описан в стандарте IETF [1].

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

3.1.21    последовательный ввод (Back-To-Back Insertion): Ввод двух или более непрерывных сеансов (на локальном интервале времени) без возврата к основной службе между сеансами.

3.1.22    поток битов DVB: Собирательный термин, относящийся к потокам, формируемым кодерами, совместимыми со стандартами DVB.

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

2

ГОСТ P 55715—2013

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

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

3.1.25    сеанс (Session): Вставка (ввод) контента. Каждый сеанс идентифицирован уникальным Session ID.

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

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

3.1.28    сервер (server): Устройство, которое порождает канал ввода (или каналы ввода) для вставки в основной канал (или в основные каналы). Сервер обменивается со сплайсером информацией о времени вставки конкретных каналов ввода.

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

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

3.1.31    сокет (socket): Нестандартный программный интерфейс между прикладной программой и стеком протоколов TCP/IP.

3.1.32    соединение API (API Connection): Соединение, устанавливаемое между сервером и сплайсером через TCP/IP сокет, для передачи сообщений API.

3.1.33    сплайсер (splicer): Устройство, которое вставляет каналы ввода в основной канал (или в основные каналы). Допускается работа сплайсера по сообщениям меток стандарта ANSI/SCTE [2]. Сплайсер обменивается с сервером информацией о времени вставки конкретных каналов ввода.

3.1.34    транспортный поток; ТП (transport stream; TS): Набор из нескольких программных потоков данных цифрового вещательного телевидения, сформированный из программных пакетов постоянной длины с коррекцией ошибок и независимым тактированием от своих источников синхронизации. Параметры транспортного потока определяются стандартом ISO/IEC [3] (2.4).

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

3.1.36    1-кадр черного поля и кадр «тихого» звука (black video and muted audio; BVMA): Кадры, отделяющие данные контента канала ввода отданных контента основного канала в точке выхода.

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

ВПР - время вещания, пригодное для размещения рекламы;

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

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

НТВ - ОАО «Телекомпания НТВ»;

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

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

ЭП (Elementary Stream, ES) - элементарный поток;

AAL (ATM Adaptation Level) - уровень адаптации ATM;

АС-3 (Dolby АС-3 audio coding system) - система кодирования аудио Dolby;

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

ASCII (American Standard Code for Information Interchange) - Американский стандартный код обмена информацией;

ATM (Asynchronous Transfer Mode) - режим асинхронной передачи;

AVC (Audio Video Coding) - стандарт кодирования H.264/AVC;

BVMA (black video and muted audio) - 1-кадр черного поля и кадр «тихого» (отключенного) звука;

CNN (Cable News Network) - сеть кабельного вещания США; Си-Эн-Эн;

CRC (Cyclic Redundancy Check) - циклический контроль по четности;

DTS (Decoder Time Stamp) - временная метка декодирования;

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

3

EAS (Emergency Alert System) - чрезвычайная система предупреждений;

ES (Elementary Stream) - элементарный поток; ЭП;

JPEG (Joint Photographic Experts Group) - Объединенная экспертная группа по фотографии (стандарт на алгоритм компрессии неподвижных полутоновых и цветных изображений);

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

IANA (Internet Assignned Numbers Auhority) - центр по присвоению имен в Интернете;

ID (Identifier) - идентификатор;

IGMP (Internet Group Management Protocol) - протокол управления группами в сети Интернет; версия протокола IGMPv3 определяется в соответствии со стандартом IETF [4];

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

IPV4 (Internet Protocol version 4) - Интернет протокол версия 4;

IPV6 (Internet Protocol version 6) - Интернет протокол версия 6;

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

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

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

GPS (Global Positioning System) - Глобальная система позиционирования;

МАС-адрес (Media Access Control) - уникальный идентификатор, присваиваемый каждой единице оборудования компьютерных сетей;

MLD (Multicast Listener Discovery) - слушатель (получатель) многоадресной передачи;

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

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

MPTS (Multi-Program Transport Stream) - многопрограммный транспортный поток;

MUX (Multiplexer) - мультиплексор;

NTP (Network Time Protocol) - Сетевой Протокол Системного Времени;

PAT (Program Association Table) - таблица ассоциации программ;

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

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

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

PNG (Portable Network Graphic) - переносимая сетевая графика;

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

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

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

PTS (Presentation Timestamp) - метка времени представления;

RAM (Ramdom Access Memory) - оперативное запоминающее устройство с произвольным доступом;

SCTE (Society of Cable Telecommunications Engineers) - общество инженеров кабельных телекоммуникаций;

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

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

SPTS (Single Program Transport Stream) - однопрограммный транспортный поток;

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

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

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

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

V2 - версия 2;

V3 - версия 3;

VBV (video-black-video) - видео-черное поле-видео;

VCI (Virtual Channel Identification) - Идентификатор Виртуального Канала;

VOD (Video on Demand) - видео по требованию;

VPI (Virtual Path Identification) - Идентификатор виртуального пути.

3.3 В настоящем стандарте применены следующие аббревиатуры: tcimsbf- дополнение до двух целого, старший бит следует первым; uimsbf- целое число без знака, старший бит следует первым.

4

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

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

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

В некоторых случаях на вход сплайсера может быть подключено либо несколько серверов либо несколько каналов в мультиплексе ввода. В этих случаях сплайсер будет связан с выходным каналом несколькими Соединениями API. Если в основном канале принимается сообщение метки стандарта ANSI/SCTE [2], то сообщение Cue_Request должно быть отправлено на серверы по всем Соединениям API, которые были выполнены для соответствующего выходного канала. Допускается передача сообщения Splice_Request для одной и той же вставки для выходного канала одновременно более чем через одно Соединение API.

4.2 Приоритеты вставки каналов ввода

При появлении на входе сплайсера одновременно нескольких каналов ввода возникает конфликтная ситуация, которая разрешается применением нескольких уровней доступа каналов ввода с уровнем приоритета от 0 до 9, что гарантирует использование корректного по уровню доступа канала ввода. Уровень доступа каналов ввода с уровнем приоритета 0 обладает самым низким приоритетом. Уровень доступа каналов ввода с уровнем приоритета 9 обладает самым высоким приоритетом, который может переопределить соединение с более низким приоритетом. Флаг OverridePlaying в сообщении Splice_Request определяет приоритет вставки в тот момент, когда сплайсер ставит канал ввода в очередь на вставку или выполняет вставку. Если флаг установлен в «1», то ввод с более высоким приоритетом может прервать или понизить приоритет канала ввода, который в настоящий момент проигрывается. Если флаг установлен в «0», сплайсер не будет заменять вставку, проигрываемую настоящий момент, даже если новый запрос будет иметь более высокий приоритет.

Сообщение Splice_Request должно быть отправлено не менее чем за 3 с до времени вставки (splice time()). Если это условие не выполняется, то стандарт не определяет последствия обработки сообщения Splice_Request данным API. Если несколько серверов инициируют запросы вставки в один и тот же интервал времени с одним и тем же приоритетом, сплайсер расположит приоритеты запросов в порядке поступления. Все другие запросы будут отвергаться, и ошибка коллизии будет отправлена в сообщении Splice_Response (если не установлен флаг OverridePlaying).

Например, на интервале времени, предшествующем инициированию вставки, могут иметь место следующие ситуации:

- если запрос с приоритетом 5 SpliceRequest получен одновременно с запросом приоритета 3 Splice Request, то фиксируется ошибка коллизии, которая возвращается в ответ на запрос приоритета 3;

-    если запрос с приоритетом 7 Splice Request получен позже запроса с приоритетом 5 в том же интервале времени, ошибка коллизии возвращается на запрос приоритета 5 и запрос приоритета 7 поставлен в очередь;

-    если второй запрос с приоритетом 7 получен с флагом OverridePlaying, установленным в 0, тогда второй запрос приоритета 7 примет ошибку коллизии.

Однако если флаг OverridePlaying установлен в 1 во втором запросе с приоритетом 7, первоначальный запрос с приоритетом 7 получит ошибку коллизии и будет переопределен.

На рисунке 2 показана диаграмма обработки запросов двух каналов ввода сплайсера. Затененные области на диаграмме обозначают каналы ввода, которые будут направлены к выходному каналу в указанные моменты времени.

6