Использование меток SCTE-104/35 в системах цифровой вставки программ. Часть 5. Применение меток SCTE для вставки региональных программ
Современные региональные центры ретрансляции программ (ЦРП) строятся как многоканальные системы класса MVPD (Multichannel Video Programming Distributor – многоканальный дистрибутор видеопрограмм), где общий массив регионального контента используется для вставки в программы от различных центров формирования программ (ЦФП). Каждый ЦРП, как правило, характеризуется уникальным набором аппаратно-программных компонентов, который находится в постоянном совершенствовании вслед за глобальными трендами в стратегиях доставки аудиовизуального контента и расширением спектра программно-аппаратных инструментов его обработки.
В ЦРП для каждого канала ретрансляции должны выполняться три базовые функции: прием и декодирование входящих сообщений SCTE-104/35; сплайсинг потоков основной и региональной программ; синхронизация брейков в сервере воспроизведения региональных программ.
Прием и декодирование входящих сообщений SCTE-104/35
Для этих целей существуют разнообразные программные и аппаратные средства от различных производителей. Например, аппаратный модуль TSD-100 (Transport Stream Detector) от Ross Video обрабатывает сообщения SCTE-35 во входящем транспортном потоке (ТП), модуль 7721DD4-HD (HD/SD-SDI Quad Data De-embedder) от Evertz обрабатывает сообщения SCTE-104 во входном сигнале SDI. Обе модели имеют выходы GPI, конфигурируемые для работы в статическом или динамическом режиме. В статическом режиме входящие сообщения переключают назначенный выход GPI независимо от содержания сообщения. В динамическом режиме сообщение декодируется, и в зависимости от его содержания переключается назначенный выход GPI. Универсальные модели совмещают функции инсертера/экстрактора, имеют интерфейсы передачи данных RS-232/422 и TCP/IP согласно спецификации SCTE-104. Примеры таких устройств были приведены в одной из предыдущих частей статьи.
Среди интегрированных приемников-декодеров (IRD) потоков MPEG-2 TS/ASI/IP есть модели, выполняющие обнаружение сообщений SCTE-35 во входном ТП, перенос данных сплайсинга в сообщение SCTE-104 в составе выходного сигнала SDI, формирование сигналов GPI для управления переключениями потоков и видеосервером. Сигналы GPI также могут формироваться в статическом и динамическом режимах.
Существуют методы простейшего контроля сообщений SCTE-35 во входящих ТП с использованием «подручных средств». К примеру, проверить наличие и содержание сообщений можно с помощью распространенных, в том числе и бесплатных, программных приложений. Для этого фрагмент ТП записывается в файл типа .ts с сохранением его оригинальной структуры. Далее потребуется узнать PID пакетов PES с сообщениями SCTE-35 в записанном потоке. Для этого подходят такие средства, как программа SL DVB Capture (www.streamlabs.ru) или DemuxToy Lite (www.altaisdigital.com). Следует отметить, что наличие в составе PMT информации о PID не означает, что в записанном фрагменте ТП будут фактически присутствовать пакеты с метками. Чтобы убедиться в наличии меток в ТП, записанный файл открывается каким-либо hex-редактором, например, Hex Editor Neo (www.hhdsoftware.com). Осуществляется поиск пакетов по значениям заголовка в формате шестнадцатеричных значений байтов вида 47 4<PID>. Так, если PID=500 (1 F4), то следует искать последовательность 47 41 F4. Если такие последовательности будут обнаруживаться с периодичностью, кратной 188 байтам, то результат поиска укажет на заголовки PES-пакетов, содержащие сообщение SCTE-35. В подавляющем большинстве случаев сообщение помещается в пределах одного пакета.
На рис. 4-1 показан пример байтовой структуры пакета, содержащего сообщение SCTE-35. Серым выделен заголовок пакета, где байт N – счетчик последовательности передаваемых пакетов с данным PID. Голубой цвет указывает на заголовок структуры Splice_info_section, где, в том числе, содержится и значение Section_length байтового размера полезной нагрузки сообщения SCTE-35, которое может иметь переменную длительность в зависимости от назначения и содержания передаваемого сообщения. Байт splice_command_type указывает код одной из шести возможных команд сплайсинга, в данном случае – Splice_insert на переход к региональному брейку, о чем указывает значение битового флага Out_of_network_indicator (OON)=1.
Далее следуют известные поля сообщения SCTE-35, выделенные красным. Поле Splice_time указывает на время переключения в единицах времени PTS (для байтов использовано обозначение YY, поскольку они разнятся для последовательных сообщений). После поля avails_expected следует обязательная структура Descriptor_loop, используемая для передачи дополнительной информации о событии сплайсинга. Значение двухбайтового поля Descriptor_length указывает на количество передаваемых дескрипторов. Если оно равно 0 (как в примере), то дескрипторы отсутствуют, и далее следует контрольная сумма PES-пакета (имеет переменное значение для каждого пакета, здесь обозначена байтами ZZ). После контрольной суммы пакет заполняется единичными битами стаффинга.
В поток пакетов с сообщениями SCTE-35 одного PID периодически включаются так называемые «пустые сообщения» с командой splice_null(), для которой байт splice_command_type равен 00. Такая команда не инициирует события сплайсинга, но может использоваться для передачи дескрипторов и для мониторинга цепи передачи (сообщение типа heartbeat message).
Расширенный функционал сплайсера
Условие бесшовной склейки в сплайсере требует согласования параметров сигналов регионального контента с параметрами различных входных потоков, что можно выполнить двумя способами.
При первом способе файл каждой воспроизводимой сервером региональной программы заранее формируется как фрагмент ТП, согласованный с характеристиками входного потока, в который он должен вставляться сплайсером. Способ характеризуется интенсивной работой программных файловых транскодеров в режиме off-line, поскольку содержание региональных программ постоянно изменяется, при этом одна и та же региональная программа должна быть представлена в отдельных файлах для вставки в различные входные потоки. Достоинством решения является относительная простота многоканального видеосервера (фактически – файлового плеера), который должен воспроизводить медиафайлы «как есть», без дополнительного транскодирования.
При втором способе поток для каждой вставки формируется путем воспроизведения в видеосервере медиафайлов с одновременным онлайновым кодированием в соответствии с параметрами входного потока. Для каждого входного потока назначается отдельный выход видеосервера, последовательность воспроизводимых медиафайлов задается отдельным региональным расписанием. Кодеки медиафайлов не зависят от характеристик входного потока, а степень компрессии может быть минимальной для обеспечения высокого качества изображения и звука. Достоинство решения – возможность вставки не только в режиме File-to-Live, характерном для выдачи рекламы, но и в режиме Live-to-Live при выдаче в региональный эфир местных выпусков новостей или иных живых передач.
В новых бизнес-моделях доставки ТВ-программ термин «Вставка» подразумевает несколько методов модификации основной программы: замещение (Splice), наложение (Overlay), совмещение (Squeeze). В каналах «Видео-по-запросу» (VOD) используется метод Insert, когда точки входа и выхода совпадают, а региональная программа на самом деле вставляется в основную программу без замещения ее фрагментов. В этой связи сплайсинг может происходить в нескольких режимах, выходящих за пределы базовых спецификаций SCTE, в том числе и с использованием перекодирования.
Перекодирование: Pro et contra
Спецификации SCTE по тематике DPI изначально позиционировались как стандарты, определяющие технические условия вставки программ непосредственно в MPEG-2 TS с фиксированной длиной коротких групп (12/15 кадров в системах на 25/30 кадр/с). Для таких ТП бесшовное переключение на границах GOP реально осуществимо. Новые кодеки H.264/AVC и H.265/HEVC используют длинные (до 250 кадров) группы. При этом опорные кадры в видеопоследовательности отстоят на такой же интервал времени, и требуется существенно больший объем буфера декодера, что затрудняет бесшовную вставку программ в ТП. Задача считается выполнимой в ориентации на конкретный набор декодеров, совместимых с эталонной моделью HRD (Hypothetical Reference Decoder), что на практике не всегда обеспечивается.
Спецификация SCTE 172 дополнительно определяет ограничения на кодирование в составе мультиплексов MPEG-2 элементарных видеопотоков SD/HD H.264/AVC, пригодных для бесшовного сплайсинга. Точки переключения связываются с кадром типа I или IDR, который является частью SRAP AU (SCTE Random Access Point Access Unit). Спецификация SCTE 215 определяет маркировку точки SHRAP (SCTE HEVC Random Access Point) в битовом потоке H.265/HEVC, где в принципе возможно бесшовное переключение. В любом случае различия в основных параметрах переключаемых видеопотоков (профиль кодирования, формат кадра, их частота, разрешение) неизбежно приводят к дефектам декодированного изображения и звука в окрестностях точек сплайсинга.
В настоящее время используются три способа цифровой вставки программ во входящие ТП. При этом в многоканальных системах различные способы вставки могут использоваться в приложении к различным входящим потокам.
Вставка без перекодирования – реализуется только метод замещения (Splice) на границах групп видеопоследовательности. Есть вероятность искажения звуковых сигналов в точках переключения. Нет гарантии, что все декодеры у конечных потребителей обработают склейку без аудиовизуальных дефектов. В связи с повсеместным переходом на потоки H.264/AVC и H.265/HEVC системы этого класса уступают место решениям следующего уровня.
Вставка с частичным перекодированием относится к классу рабочих процессов в рамках концепции end-to-end compressed domain, находящейся в активном развитии и представляет собой паллиатив – нечто среднее между решениями с полным перекодированием и без перекодирования для ТП AVC и HEVC. Основной аргумент в пользу решения – сохранение качества основной программы при обеспечении покадровой точности сплайсинга. Детали реализации в настоящее время не раскрываются полностью в общедоступных публикациях. Один из известных способов – изменение длины групп так, чтобы новая граница между группами попала в точку сплайсинга. Другой способ – транскодирование без потерь фрагмента входного потока между кадрами IDR, окружающими точку сплайсинга, в последовательность I-кадров. От входного кадра IDR на канал ввода сплайсера подается такая же последовательность кадров региональной программы, в точке сплайсинга производится переключение с покадровой точностью, затем на выходном кадре IDR происходит возврат к основной программе в ее исходном виде. Для маскирования возможных дефектов вводится понятие «почти бесшовной склейки» (near-seamless splicing), когда переключение потоков происходит в режиме V-Mix с переходом через черное поле по изображению и через «тишину» по звуку.
С учетом относительно большого интервала времени между кадрами IDR потребуется существенное увеличение времени pre-roll в сообщениях SCTE-35 – до нескольких десятков секунд. Решения требуют весьма тонких обработок входящего ТП, в одной из публикаций для них найден оригинальный термин – transport stream massaging. Подобные методы «массажа» используются при наложении графики (Overlay), когда перекодированию подвергаются только те элементы видеопоследовательности входного ТП, которые содержат модифицируемые области кадра.
Пример – решение TS Splicer (starfish.tv) сочетает функции декодирования сообщений SCTE-35, хранилища медиафайлов, сплайсера. Врезка в потоки H.264/AVC и H.265/HEVC может происходить на границах GOP или с кадровой точностью внутри групп без кодирования и повторного кодирования всего ТП. Другой пример – InStream (xylostream.com/products/instream.php). Компонент InStream Splice выполняет переключения File-to-Live и Live-to-Live. Компонент InStream Convert транскодирует файлы и согласует их с профилем потока в основном канале.
Ну а при вставке с полным перекодированием основная программа выделяется из входного ТП и полностью декодируется до сигналов видео и аудио, как правило, SD/HD-SDI. Доступны все методы вставки, функции сплайсера выполняют обычные аппаратные или программные компоненты коммутации/микширования сигналов изображения и звука, наложения графики и логотипов, создания спецэффектов. Видеосервер формирует поток регионального контента в виде сигналов SDI. Региональная программа повторно кодируется и включается в состав ретранслируемого мультиплекса. Качество перехода – безусловно высокое и по видео, и по звуку, но качество основной программы между точками сплайсинга – понижается.
К недостаткам решения обычно относят повышенный расход вычислительных ресурсов при программной реализации и пониженное качество основной программы. Здесь следует отметить, что многочисленные исследования по восприятию качества изображения и звука в системах с компрессией указывают на более высокую критичность артефактов переключения по сравнению с пониженным, но стабильным во времени качеством перекодируемой основной программы.