Как не потерять ни одного пакета: ST 2022-7 в реальном live-вещании

Когда сеть подводит, эфир продолжается: ST 2022-7 в действии

Введение в технологию ST 2022-7

Стандарт SMPTE ST 2022-7, появившийся в 2013 году, был разработан как механизм повышения надёжности передачи медиаданных по IP-сетям. Его ключевая идея — бесшовное резервирование. Стандарт использует технологию Seamless Protection Switching, которая позволяет передавать одни и те же RTP-датаграммы одновременно по нескольким независимым маршрутам.

Зачем это нужно?

IP-сети по своей природе нестабильны: возможны потери пакетов, задержки, кратковременные обрывы. ST 2022-7 решает эту проблему за счёт дублирования потоков. Если один маршрут деградирует или выходит из строя, приёмная сторона продолжает получать данные по альтернативному пути и восстанавливать результирующий TS-поток без разрывов и заметных переключений. Для live-вещания это критично.

Такой подход часто применяется в профессиональной среде: в вещательном производстве и удалённом продакшене, где трафик проходит через разнообразные сети провайдеров, включая выделенные линии, спутниковые каналы и публичный интернет. ST 2022-7 используется и в contribution-системах — для доставки сигнала от полевых источников в центральные студии, а также в современных студийных IP-фабриках, где требуется стабильная обработка несжатого медиаконтента.

Сегодня крупные отраслевые организации, включая EBU, рассматривают ST 2022-7 как базовый элемент надёжной IP-инфраструктуры. В рекомендациях EBU, в документе Tech 3371, использование бесшовного резервирования по ST 2022-7 указано как обязательное требование для медиа-узлов, где критична непрерывность сигнала.

В частности, ST 2022-7 рекомендуется в качестве минимально допустимого требования резервирования источника для систем SDI over IP, описанных в стандарте ST 2110. Передача «сырых», несжатых данных требует постоянного и стабильного входного сигнала вплоть до окончания потока (EOS).

Рис. 1. Технологическая пирамида: минимальные требования к пользователям для создания и управления медиа-инфраструктурами на основе IP-технологий.
 

Принцип работы ST 2022-7

В основе ST 2022-7 лежит простой и эффективный принцип: создаются дублирующие потоки медиаданных, которые передаются одновременно по нескольким независимым маршрутам. Это позволяет существенно снизить риск потери пакетов. Пакеты синхронизируются по полям заголовков RTP, определённым в стандарте RFC 3550.

Подготовка потоков для передачи

На стороне источника ключевую роль играет сплиттер — отправитель (sender), который готовит избыточные потоки ST 2022-7. Он может быть реализован как отдельный компонент системы доставки сигнала или быть частью транскодера либо гейтвея.

Сплиттер генерирует как минимум два идентичных RTP-потока. Совпадают как RTP-заголовки, так и полезная нагрузка "payload". Благодаря этому приёмная сторона может выполнить бесшовную реконструкцию сигнала.

Каждый RTP-пакет далее может быть инкапсулирован в протокол передачи данных — например, UDP, SRT или RIST — и отправляется по разным сетевым маршрутам, чтобы избежать общей точки отказа.

Рис. 2. Схемы компонентов сплиттера для подготовки потоков по ST 2022-7.
 

Рис. 3. Web-интерфейс ПО Elecard CodecWorks с запущенными схемами для передачи потоков ST 2022-7 по протоколам SRT и RIST.
 

Приём и восстановление потока

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

Свитчер деинкапсулирует входящие пакеты, извлекая RTP-пакеты как полезную нагрузку "payload", и направляет их в отдельные буферы. Эти буферы предназначены для компенсации джиттера (jitter) и задержек.

В буферах пакеты сортируются по ключевым полям RTP-заголовка — sequence number и timestamp. Если один путь деградирует (например, из-за потери пакетов или задержки), в соответствующем буфере возникает «пробел» в данных. В этом случае свитчер автоматически переключается на буфер другого источника, содержащий соответствующий RTP-пакет. Переключение происходит незаметно и не влияет на выходной поток.

Рис. 4. Схемы компонентов свитчера для приема потоков, подготовленных по ST 2022-7.
 

Рис. 5. Web-интерфейс ПО Elecard CodecWorks с запущенными схемами для приема потоков ST 2022-7 по протоколам SRT и RIST.
 

Заголовки RTP, используемые в ST 2022-7

ST 2022-7 опирается на RTP-заголовок, описанный в RFC 3550. Ключевыми здесь являются два поля:

• Sequence number — 16-битное поле, отвечающее за нумерацию пакетов. Значение инкрементируется на единицу для каждого следующего пакета. Это поле используется для обнаружения потерь, упорядочивания пакетов и корреляции дубликатов между потоками.
• Timestamp — 32-битное поле, отражающее момент семплирования данных, например на основе внутренней частоты генератора. Этот параметр необходим, чтобы синхронизировать дублирующиеся потоки между собой.

Рис. 6. Схема инкапсуляции семи пакетов MPEG-TS в один пакет RTP/UDP/IP.
 

Ещё одна важная величина компенсации задержек — размер буфера. Он формируется на основе разницы между самым быстрым потоком, полученным свитчером, и потоками, пришедшими с самой большой задержкой.

Пример реализации механизма синхронизации потоков

Чтобы наглядно показать, как работает механизм синхронизации в ST 2022-7, рассмотрим типичный HD-видеопоток с битрейтом 6 Мбит/с (750 000 байт/с), упакованный по схеме 7 MPEG-TS-пакетов на один RTP-пакет, с размером полезной нагрузки "payload" 1316 байт.

Рис. 7. График формирования размера буферов в зависимости от задержки источников свитчера.
 

Для потоков с битрейтом 6 Мбит/с 101 RTP-пакет эквивалентен примерно 177 мс. В нашей реализации минимальный размер приёмного буфера — 101 RTP-пакет.

Как перевести количество RTP-пакетов в миллисекунды, зная битрейт потока?

1. Сначала рассчитаем общий объём данных в битах:
   V_bits = 101 [RTP-пакетов] × 7 [TS-пакетов] × 188 [байт] × 8 [бит] = 1 063 328 бит.
2. Затем длительность контента:
   T = 1 063 328 [бит] / 6 000 000 [бит/с] ≈ 0,177 с ≈ 177 мс.

На стороне отправителя (transmitter / sender) поток дублируется для передачи по независимым путям. Sequence number инкрементируется на 1 для каждого RTP-пакета. Timestamp отражает момент семплирования медиаданных. Оба поля полностью идентичны во всех дублирующих потоках.

При данном битрейте генерируется около 570 RTP-пакетов в секунду:
(6 Мбит/с / 8 бит) = 750 000 байт/с ÷ (7 × 188 байт) ≈ 570 пакетов/с.

На стороне приёма (receiver / switcher) пакеты из разных путей буферизуются и выравниваются по заголовкам:

• Sequence number (16 бит). Теоретически позволяет компенсировать разницу задержек между путями до ≈115 секунд:
  2¹⁶ ÷ 570 ≈ 115 с;
  где 2¹⁶ — количество возможных значений sequence number;
  570 — количество пакетов, сгенерированных за одну секунду при битрейте в 6 Мбит/с.
• Timestamp (32 бит). Обеспечивает однозначное сопоставление пакетов в пределах примерно 13 часов:
  2³² ÷ 90 000 ÷ 3600 ≈ 13 часов;
  где 2³² — количество возможных значений timestamp;
  90 000 — частота дискретизации (количество тиков/отсчётов) в секунду для видеопотока;
  3600 — количество секунд в одном часе для перевода итогового значения из секунд в часы.

Если разница задержек значительно больше 13 часов, то RTP-пакеты могут некорректно сопоставиться, а это приведет к артефактам при воспроизведении на конечном устройстве.

На практике размеры этих буферов не превышают пяти секунд.

Рис. 8. Пакет потока RTP over UDP, захваченный с помощью ПО Wireshark, на интерфейсе, принимающем один из потоков ST 2022-7.
 

Совместное использование sequence number и timestamp обеспечивает точную корреляцию идентичных пакетов из разных потоков. Благодаря этому приёмник может мгновенно выбирать корректную копию и поддерживать полную непрерывность вещания.

Это означает, что вы можете передавать два и более идентичных потока RTP over SRT или RTP over RIST через разных провайдеров или даже через разные типы каналов: оптоволокно, спутник, мобильные сети. Приёмник объединяет их в реальном времени и обеспечивает стабильную и надежную доставку даже при полном обрыве одного из подключений.

Одно из ключевых преимуществ нашей реализации — использование монотонно возрастающих значений (sequence number и/или других счётчиков) в заголовках транспортного уровня. Такой подход не зависит от особенностей RTP и может применяться в любых протоколах и контейнерах, где присутствуют монотонно возрастающие счётчики в заголовках пакетов.

Технология уже успешно адаптирована и внедрена для контейнера T2-MI. Разработанный нами механизм обеспечивает полноценное бесшовное резервирование потоков по нескольким независимым каналам: IP, ASI, спутниковым. Это гарантирует отсутствие даже кратковременных сбоев на выходе модулятора.

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

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

Преимущества и недостатки ST 2022-7 в рестриминге и транскодировании

Преимущества

Использование ST 2022-7 по сравнению с передачей без резервирования даёт ряд очевидных преимуществ:

1. Повышенная надёжность. Дублирование потоков по разным путям обеспечивает защиту от потерь пакетов и сбоев сети.
2. Бесшовное переключение. Обеспечивает автоматический выбор потока без заметных прерываний в продакшене.
3. Повышенная устойчивость в IP-сетях. Подходит для вещания, где требуется высокая доступность.

Наибольшая практическая ценность стандарта проявляется в live-вещании. Представим прямую трансляцию футбольного матча. Камеры на стадионе захватывают видео в формате HD/UHD и аудио, например, через SDI-интерфейс. Далее этот несжатый поток кодируется (AVC/HEVC видео и AAC аудио) и преобразуется в IP-потоки.

Чтобы избежать сбоев, например, из-за обрыва кабеля или сетевой перегрузки, используется ST 2022-7. Он дублирует RTP-поток несколько раз, оборачивает поверх RTP, например, RIST или SRT (где RTP выступает в роли полезной нагрузки "payload") и отправляет по двум независимым путям: основному (по оптоволокну) и резервному (по спутнику с bidirectional back-channel).

Без использования ST 2022-7 сбой пути может вызвать потерю сигнала на несколько секунд. А потеря даже одной секунды в эфире может стоить больших финансовых и репутационных издержек, особенно когда трансляцию смотрят миллионы зрителей. Технология ST 2022-7 сохраняет непрерывность вещания и снижает риски, особенно в удалённом продакшене с облачными сетями.

Недостатки

Как и любая технология, ST 2022-7 имеет свои ограничения:

1. Увеличение требуемой пропускной способности. Дублирование потоков означает увеличение трафика — как минимум в два раза.
2. Дополнительная задержка. Размер буфера устанавливается на основе компенсации задержки между потоками.

ST 2022-7 over RTP/UDP

За счёт прямого использования RTP/UDP и отсутствия дополнительных транспортных надстроек ST 2022-7 имеет минимальный overhead и легко интегрируется в существующие сети.

Отсутствие механизмов коррекции ошибок, таких как ARQ или FEC, делает этот подход особенно привлекательным там, где важна минимальная задержка. В контролируемых сетях с предсказуемым качеством передачи это позволяет добиться минимальной дополнительной латентности, которая включает задержку буферов свитчера (см. раздел «Пример реализации механизма синхронизации потоков»). Кроме того, ST 2022-7 over RTP/UDP хорошо масштабируется, легко работает с multicast и потребляет минимум вычислительных ресурсов.

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

Также стандарт не предусматривает шифрование и аутентификацию. Передача идет в открытом виде и уязвима к перехвату, анализу или подмене пакетов. В отличие от RIST и SRT, ST 2022-7 over RTP/UDP не адаптируется к изменениям в сети: здесь нет ARQ, FEC, динамического контроля перегрузки и восстановления пакетов. По этой причине этот вариант плохо подходит для публичных или нестабильных IP-сетей, где нет гарантий доставки и стабильности маршрутов. В таких сценариях он заметно уступает RIST и SRT по уровню надёжности.

ST 2022-7 over RTP/UDP — это оптимальный выбор для контролируемых IP-сетей внутри одного объекта, например стадиона, где требуется низкая задержка и гарантированная доставка без потерь.

ST 2022-7 over SRT и RIST

В ряде сценариев более эффективным оказывается использование ST 2022-7 в связке с SRT или RIST.

SRT

SRT разработан на базе UDT (UDP-based Data Transfer Protocol), адаптированного для медиапотоков. UDT предназначен для высокопроизводительной передачи данных поверх UDP и превосходит TCP в сценариях с высокой пропускной способностью.

SRT в первую очередь ориентирован на unicast (point-to-point) передачу с минимальной задержкой по ненадежным сетям. Этот протокол отличается улучшенным управлением потока и обработкой живого стриминга при низком уровне потерь пакетов в 10–12%. Шифрование (PSK) предоставляет приемлемый уровень безопасности для большинства сценариев. SRT легко настраивается и разворачивается даже в сложной сетевой инфраструктуре. При этом SRT не имеет нативной поддержки multicast. Сегодня этот протокол широко принят в индустрии и поддерживается большим числом производителей программного и аппаратного обеспечения.

RIST

RIST создан группой экспертов Video Services Forum (VSF) и RIST Forum на базе RTP/RTCP. Протокол оптимизирован для надёжной передачи видео по ненадежным сетям с поддержкой multicast (Point-to-MultiPoint). RIST хорошо адаптируется к узким каналам и к экстремально плохим сетям, сохраняя стабильность при потерях до 25–50% (с overhead 100–200%) благодаря эффективному управлению полосой. Он имеет продвинутые механизмы шифрования потоков (PSK/EAP) и полностью совместим с существующим RTP-оборудованием. Хотя RIST менее распространён, чем SRT, его высокая совместимость с профессиональным оборудованием позволяет внедрять его в существующие инфраструктуры без замены устройств на базе RTP/RTCP.

Комбинация ST 2022-7 + SRT

Связка ST 2022-7 + SRT эффективна в сценариях, где важны две вещи: минимальная задержка (обычно менее секунды) и устойчивость к нестабильной сети с низким уровнем потерь пакетов. SRT берёт на себя повторную передачу потерянных пакетов и автоматически подстраивается под текущие условия сети, сглаживая сетевые колебания без заметного роста задержки.

1. Такая комбинация оптимальна для point-to-point передачи через публичный интернет в сценариях удалённого продакшена.
2. Также может быть эффективна при передаче видеосигнала через нестабильные сети, включая мобильные (4G/5G, Wi-Fi), где возможны кратковременные потери и резкие изменения доступной полосы.
3. Хорошо подходит для прямых спортивных трансляций и новостного продакшена, где требуется максимально быстрая доставка сигнала с ультра низкой задержкой. Автоматическое переключение между резервными потоками и механизмы оптимизации SRT для прямых эфиров помогают сохранить непрерывность передачи.

Кроме того, такая связка целесообразна в экосистемах с широкой поддержкой устройств и программного обеспечения, совместимых с SRT, а также в сценариях, где важна простота настройки и быстрая интеграция, в том числе в open-source средах, где SRT уже широко распространён.

Комбинация ST 2022-7 + RIST

Связка ST 2022-7 + RIST ориентирована на масштабное распределение сигнала в операторских и корпоративных IP-сетях. Она особенно эффективна в сценариях point-to-multipoint, когда один источник обслуживает большое количество приёмников. Групповая передача (multicast) и оптимизированный обмен служебными сообщениями позволяют снизить нагрузку на сеть.

1. Хорошо подходит для мультивендорных сред, где важны открытые стандарты и совместимость оборудования разных производителей. Формализованные профили RIST и фокус на совместную работу решений упрощают построение единой IP-инфраструктуры без жёсткой привязки к одному вендору.
2. Эта комбинация также оптимальна в гибридных схемах с однонаправленными каналами (спутник, радиорелейные линии) и IP-резервированием, где требуется надёжное восстановление потерянных данных, в том числе в сценариях совместного использования спутниковых и IP-каналов. RIST обеспечивает это за счёт повторных запросов и адаптации потока.
3. Целесообразна в корпоративных и операторских инфраструктурах, где важно обеспечить целостность данных и соответствие требованиям корпоративных сетей, поскольку RIST поддерживает формализованные механизмы безопасности и аутентификации.

Выбор комбинации ST 2022-7 с тем или иным протоколом всегда зависит от конкретной задачи. Ключевыми факторами остаются требования к задержке, надёжности, безопасности и совместимости с существующей инфраструктурой.

Эксперимент и анализ поведения потоков

Цель эксперимента

Задачей было на практике показать работу бесшовного переключения между двумя каналами доставки транспортных потоков (TS) по технологии SMPTE ST 2022-7 в сочетании с протоколом доставки SRT. Испытания проводились в условиях реальной глобальной сети Интернет, включая маршруты US–CN и US–DE–CN, а также мобильные каналы 4G с искусственно созданными потерями пакетов. Ключевым критерием успеха было полное восстановление результирующего UDP-потока на выходе без потерь.

Тестовая инфраструктура

В облачной инфраструктуре AWS (регион Калифорния) была развернута вещательная система на базе операционной системы Ubuntu 22.04. Она включала в себя локальный медиасервер и программный шлюз CodecWorks Gateway.

Рис. 9. Web-интерфейс ПО Elecard CodecWorks с запущенными схемами для передачи потоков ST 2022-7 по протоколам SRT и RIST.
 

В ходе эксперимента осуществлялось формирование и ретрансляция двух транспортных потоков (TS) с использованием технологии ST 2022-7. Передача потоков в глобальную сеть Интернет через единый сетевой интерфейс выполнялась последовательно с применением протоколов SRT и RIST, при полностью неизменных параметрах сетевой конфигурации и аппаратных ресурсов.

Приёмная часть была развернута в Китае (Пекин) на локальном физическом хосте под управлением Windows 10, также с использованием CodecWorks Gateway.

Рис. 10. Web-интерфейс ПО Elecard CodecWorks с запущенными схемами для приема потоков ST 2022-7 по протоколам SRT и RIST.
 

Приём TS-потоков осуществлялся по двум независимым каналам операторов мобильной связи. Чтобы гарантировать передачу TS-потоков по разным маршрутам, один из каналов проходил через VPN-туннель в Германии. Для обоих протоколов условия приёма и обработки потоков оставались полностью идентичными. Восстановленный результирующий транспортный поток передавался по UDP на интерфейс localhost.

Рис. 11. Схема доставки TS-потоков.
 

Ухудшение сетевых условий

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

Чтобы создать более сложные и показательные условия, сеть была нагружена по обоим мобильным каналам. Первая линия была подключена к сети по Wi-Fi, что ощутимо повлияло на количество потерянных пакетов, а вторая по Ethernet кабелю к 5G роутеру. Для усиления эффекта и снижения общей задержки передачи данных для обоих протоколов была установлена минимально рекомендуемая задержка — 120 мс. Это минимально рекомендуемая задержка для SRT, такое же значение использовалось и для RIST.

В Китае хорошо развита мобильная сеть 5G, и её скорость в отдельных районах на практике достигает 200–400 Мбит/с. Перевод обеих линий на стандарт 4G ограничил пропускную способность каждой до примерно 98 Мбит/с. При использовании VPN-туннеля на второй линии скорость снизилась примерно до 50% от исходной, составив около 50 Мбит/с.

Длительность эксперимента составила около 20 минут.

Результаты

Комбинация SMPTE ST 2022-7 + SRT

Согласно рекомендациям по настройке SRT-соединений, задержка восстановления потерянных пакетов TsbPd Delay должна составлять 3–4 значения RTT. Эти рекомендации приведены в техническом обзоре SRT (SRT_Protocol_Technical_Overview).

• RTT (Round Trip Time) — это время, за которое пакет данных проходит путь от отправителя к получателю и обратно.
• TsbPd Delay (Time-stamped Banked Packet Delivery Delay) — это фиксированная задержка буферизации, которую SRT добавляет для синхронизации потока.

Статистика SRT Line 1

Ниже приведена статистика приёма данных по SRT Line-1. Эта линия обеспечивала передачу данных между Пекином (CN) и Калифорнией (USA) по Тихоокеанским магистралям (см. https://www.submarinecablemap.com/).

Рис. 12. Статистика приёма данных по SRT Line-1.
 

Несмотря на то, что значение TsbPd Delay примерно в два раза меньше RTT, примерно через 17 минут работы показатели Lost packets и Dropped packets имеют примерно равное значение. Причина — нестабильное Wi-Fi-соединение. Значительная часть повторно запрошенных пакетов терялась на участке между Wi-Fi-передатчиком и приёмником. При этом показатель Retransmitted packets подтверждает, что часть пакетов успешно восстанавливалась за счёт повторных запросов, несмотря на локальные потери.

Статистика SRT Line 2

Представленные ниже данные отражают приём трафика на линии SRT Line-2, соединяющей Пекин и Калифорнию через территорию Германии и Атлантический океан. (https://www.submarinecablemap.com/)

Рис. 13. Статистика приёма данных по SRT Line-2.
 

Благодаря стабильному соединению между 5G роутером и приемным хостом, значения Lost packets и Dropped packet намного ниже, чем для SRT Line-1. TsbPd Delay в несколько раз меньше RTT, что указывает на более длинный путь относительно SRT Line-1, и влияние задержки на потери в сети доставки. Показатель Retransmitted packets аналогично подтверждает частичное восстановление потерянных пакетов.

Статистика свитчера

Сложная сеть доставки привела к нестабильности обоих SRT-каналов. Именно это и позволило на практике наглядно продемонстрировать работу бесшовного восстановления UDP-потока по технологии SMPTE ST 2022-7.

Рис. 14. Статистика свитчера.
 

Ниже приведены ключевые параметры JSON-статистики восстановленного потока:

1. selectedStreamID — идентификатор активного буфера, из которого свитчер в данный момент передает данные на выход: 0 (SRT Line-1) и 1 (SRT Line-2).
2. outputPackets — общее количество переданных пакетов на выходе.
3. Switches — суммарное количество переключений между источниками.
4. bufferedPackets — количество пакетов в очереди каждого буфера.
5. losses — количество потерянных (пропущенных) пакетов на выходе свитчера.
6. bufferedDuration — объем накопленных данных в каждом буфере (мс).
7. sequenceErrors — количество нарушений последовательности (пропущенных пакетов) во входящих потоках для каждого буфера.
8. delays — величина задержки входящих потоков относительно потока с минимальной задержкой (мс).

Из статистики видно, что задержка между потоками (delays) составляет около 0,5 секунды. Это напрямую влияет на итоговую задержку всего тракта доставки. Значение sequenceErrors указывает на недостаточное значение задержки TsbPd Delay для эффективного восстановления входящих потоков. В качестве примера значение "TsbPd Delay" = 120 мс могло бы быть установлено, чтобы снизить общую задержку передачи данных в соответствии с определенными требованиями проекта.

И наконец, ключевой показатель: losses = 0. Для конечных пользователей технологии бесшовного резервирования именно этот показатель имеет решающее значение: он подтверждает, что результирующий TS-поток полностью восстановлен без потерь на выходе.

Статистика Elecard Boro восстановленного UDP потока

Анализ восстановленного UDP потока в режиме реального времени, полученный с помощью системы мониторинга live-вещания Elecard Boro, показал высокое качество и полную целостность на протяжении всего теста.

Рис. 15. График битрейта восстановленного UDP потока.
 

Рис. 16. График задержки между приходящими пакетами.
 

Задержка между приходящими пакетами: Maximum Inter-packet Arrival Time (IAT) стабилен (~3,8–4,2 мс).

Потери TS пакетов за секунду: Media Loss Rate (MLR) = 0 — полное отсутствие потерь.

Рис. 17. Ошибки целостности в восстановленном UDP потоке.
 

Ошибки целостности: Continuity Counter Errors и Timestamp Discontinuity не зафиксированы на всём интервале, что подтверждает отсутствие пропущенных пакетов и нарушений последовательности.

Рис. 18. График громкости звука восстановленного UDP потока.
 

Аудио: Уровень громкости стабилен в диапазоне [-23; -40] LUFS без отклонений и прерываний аудиосигнала.

Рис. 19. Журнал событий по завершению эксперимента.
 

События: поток быстро стабилизировался после старта задачи мониторинга (видео H.264 1920x1080 25 fps, аудио AAC), в конце теста — BadSource (No signal) после завершения передачи. Иных событий в журнале Task Events не зафиксировано.

Вывод

Технология ST 2022-7 + SRT обеспечила идеальное бесшовное восстановление результирующего UDP-потока — без единой потери пакета и без ошибок СС на выходе, несмотря на проблемные условия в нестабильных каналах источников.

Заключение

Внедрение стандарта ST 2022-7 в процессы рестриминга и транскодирования дает ощутимые преимущества с точки зрения надёжности и качества доставки медиаконтента.

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

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

• Elecard CodecWorks Gateway — программный продукт для переключения протоколов прямого вещания, необходимый для адаптации видеопотока к различным типам сетей
• Elecard Boro — многофункциональное программное решение для контроля качества потокового вещания в UDP, RTP, HTTP, HLS, DASH, SRT и RTMP и отслеживания QoS и QoE параметров в распределенной сети с централизованным доступом к статистике и генерацией регулярных отчетов