Альтернативы multicast UDP для MBR-потоков
Экскурс в историю отраслевого стандарта
Сегодня многие поставщики в отрасли IPTV/OTT рекомендуют использовать multicast UDP для передачи видео от серверов транскодирования к HLS упаковщикам. В этой модели каждый профиль качества мультибитрейтного видеопотока отправляется в отдельной multicast-группе, а упаковщики получают все multicast-потоки для создания единого мультибитрейтного видео и преобразования его в unicast протокол. Этот подход зародился в мире IPTV, где multicast IP-сети используются для доставки MPEG-TS видео на телевизоры и приставки. Производители транскодирующего оборудования для линейного ТВ добавили в свои транскодеры функцию мультибитрейта, которая предполагает транскодирование исходного потока в 3-5 различных профилей с разными разрешениями и битрейтами. Эти устаревшие транскодеры уже имели возможность передавать видео в многоадресную сеть, поэтому производителям было легко отправлять каждый профиль как отдельный многоадресный поток.
У поставщиков программного обеспечения для упаковки не было другого выбора, кроме как адаптироваться к этой модели. Тем не менее, они выступили за стандарт под названием Adaptive Transport Stream, в котором каждый поток профиля должен иметь специальные встроенные маркеры EBP, указывающие на начало сегмента. Некоторые упаковщики требуют эти маркеры для синхронизации потоков.
Проблемы отраслевого стандарта
Мы в Flussonic считаем, что такой подход имеет несколько проблем. Для того чтобы упаковщик мог создать правильный манифест файл и чанки .ts или .mp4, все профили, поступающие от транскодеров, должны быть идеально синхронизированы по ключевым кадрам и временным меткам. Кроме того, все кадры для всех профилей должны передаваться от транскодера к упаковщику в режиме реального времени без падений и задержек.
Представьте себе ситуацию, когда транскодер подключен к упаковщику через отдельный мультикаст поток для каждого профиля. Имеется 4 профиля: 1080p, 720p, 576p, 360p. Если один из мультикаст потоков, допустим, поток 576p, выходит из строя, то упаковщик должен решить, как справиться с проблемой. Он может полностью исключить профиль из манифеста, заменить недостающие данные заполнителем (помня, что он должен иметь тот же кодек, разрешение и структуру GOP, что и оригинал, чтобы предотвратить зависание проигрывателей) или создать пустые чанки .ts, что также может привести к зависанию, визуальным артефактам или даже закрытию сессии воспроизведения.
С точки зрения вещателя, пострадают только те, кто в данный момент смотрит в качестве 576p. Однако проблема выходит за рамки непосредственного воздействия на этих зрителей. Когда упаковщик записывает видео в архив для nDVR или catchup TV, он сначала инициализирует архив для определенного типа потока MBR с определенным количеством профилей, аудиодорожек и видеодорожек. Если один из профилей временно пропадает, то целостность всего потока, включая все остальные профили, также нарушается, и нет смысла записывать оставшиеся профили на диск. Это также может вызвать проблемы с передачей видео в формате MBR на другие системы.
Решение от Flussonic
Очевидно, что текущий промышленный стандарт использования мультикаст UDP для передачи отдельных потоков для каждого профиля качества может привести к значительным проблемам, особенно в случаях, когда один из потоков не работает. Хотя этот подход может подойти для некоторых приложений, в случае OTT/IPTV может быть более уместен другой подход.
В связи с этим компания Flussonic приняла решение не поддерживать прием нескольких независимых UDP-потоков от транскодеров сторонних производителей. Вместо этого мы считаем, что лучше использовать один TCP поток, включающий все профили качества, субтитры, рекламные метки SCTE-35 и прочую метаинформацию.
Существует несколько альтернативных решений, которые можно использовать, чтобы избежать проблем, связанных с текущим отраслевым стандартом использования мультикаст передачи UDP для передачи отдельных потоков для каждого профиля качества:
-
Использовать Flussonic Media Server в качестве транскодера. В этом случае вам даже не придется устанавливать отдельные роли для транскодера и упаковщика, а если вам понадобится передавать видео между системами Flussonic, вы сможете использовать надежные и проверенные временем и миллионами пользователей протоколы Flussonic Cluster — m4f и m4s.
-
Прием MBR-видео от стороннего транскодера с использованием протоколов на базе TCP, таких как HTTP MPEG-TS. В этом случае сторонний транскодер может мультиплексировать несколько потоков в один MPTS, где каждый профиль является отдельной программой. Flussonic примет этот поток MPEG-TS и обработает его как мультибитрейтное видео.
-
В качестве альтернативы можно использовать другие, более надежные протоколы, такие как SRT, для передачи многобитрейтного видео между транскодером и упаковщиком. Важно тщательно оценить компромиссы и рассмотреть сильные и слабые стороны различных подходов, чтобы убедиться, что вы выбрали тот, который наилучшим образом отвечает вашим потребностям.
Заключение
В заключение еще раз отметим, передача мультибитрейтного видео по UDP — это устаревшая практика, которая имеет значительные проблемы. Несмотря на то, что вначале она может показаться простой и хорошо работать, она подвержена таким проблемам, как потеря передаваемых данных, трудности с синхронизацией профилей, а также проблемы с архивированием и транзитом сигнала. Компания Flussonic не поддерживает такой подход, поскольку он приводит к разочарованию клиентов, когда возникают проблемы, не зависящие от нас. Вместо этого мы предлагаем альтернативные решения, такие как использование Flussonic Media Server в качестве транскодера, прием MBR-видео от стороннего транскодера с использованием протоколов на базе TCP или использование более надежных протоколов, таких как SRT.
Если вы заинтересованы в интеграции Flussonic с существующими решениями транскодирования или полной их замене на Flussonic Transcoder, пожалуйста, свяжитесь с нашей службой технической поддержки и отделом продаж по адресу support@flussonic.com. Мы будем рады помочь вам и дать наилучшие рекомендации по достижению ваших целей.