Skip to content

Добавить потоки от стороннего транскодера

Иногда бывает так, что на старте проекта покупается какой-то транскодер, который выдает несколько качеств в UDP потоки и возникает вопрос: а как добавить эти источники в флюссоник так, чтобы на выходе получился хороший DASH/HLS с надежным переключением битрейта в плеере?

Простой ответ: никак, заменить транскодер.

Более подробный будет дан в этой статье вместе с инструментом для отладки.

В чём проблемы с MBR UDP транскодерами?

Самые частые проблемы, по которым нельзя собрать хороший DASH стрим из под таких транскодеров следующие:

  1. У разных качеств не одинаковые длины GOP-ов. Такая же проблема бывает и при захвате с RTSP камер двух качеств. Это фатально для большинства OTT IPTV плееров.
  2. Не синхронизированы ключевые кадры (кейфреймы). У разных качеств независимые транскодеры, поэтому один ставит кейфрейм на одном кадре, другой на другом. Если синхронизировать UDP источники по близко расположенным кейфреймам, то на выходе будет рассинхрон как видео друг между другом (будут пропадать или дублироваться кадры на переключении качеств), так и видео с аудио. Ведь аудио будет взято с первого источника, а видео со второго.
  3. Почти всегда не синхронизированы таймстемпы. С UDP MPEG-TS нормальная практика стартовать время с какого-то произвольного таймстемпа, поэтому чаще всего через пару дней работы с мультибитрейтного UDP транскодера льются потоки, на которых таймстемпы отличаются друг от друга на много часов: один рестартнулся и всё разъехалось. Частично выправляется автокоррекцией, но там см. п.2

Большиниство транскодеров на рынке работают с мультибитрейтом так: - Делают несколько независимых потоков из одного входящего - Отправляют в сеть по UDP, протоколу, не имеющего механизмов гарантированной доставки или подтверждения получения

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

Когда такое случается, софт на упаковщике должен принять решение: - Убрать из манифеста один из профилей, вообще не предоставляя клиентам эту дорожку. - Заполнить пустоту "нулями", пытаясь сохранить текущую структуру, в надежде, что данные на входе вновь появятся через мгновенние. Это приводит к артефактам и зависаниям.

Напоминаем, что все сегменты должны иметь одинаковые параметры: кодек, разрешение, идентичную GOP структуру, чтобы плеер не подвис при проигрывании. А это невозможно гарантировать, когда часть кадров теряется на входе упаковщика.

Потеря одного профиля в лайве может быть незамечена, особенно, когда нет клиентов, кто смотрел в тот момент этот профиль. Однако, потеря одного профиля испортит записи. Когда Media Server ведет архив для nPVR или Catch-up TV, он инициализирует запись для конкретного набора аудио и видео дорожек. Если один из профилей временно исчезнет, это нарушит целостность всего потока: будут пробелы в разных профилях, продолжительность записи высокого качества будет отличаться от записи низкого качества. По статистике, чаще повреждаются дорожки высокого качества, так как у них больше битрейт.

Поэтому мы не рекомендуем использовать MBR UDP в качестве источников. Лучше использовать протоколы, которые поддерживают мультибитрейт в одном контейнере и гарантируют доставку: M4F, SRT. HLS будет лучше, чем UDP, но у него есть свои особенности.

Как проверить?

В поставке идет утилита mbr_udp_analyze.erl, её надо запускать в командной строке и передать ей список адресов, которые надо проверить:

/opt/flussonic/contrib/mbr_udp_analyze.erl udp://239.150.12.1:1234 udp://239.150.22.2:1234 udp://239.150.12.3:1234
Synced 3 with shift 0.00
Synced 2 with shift 280.00
SYNC
Started stream analysis
Gop at 70228737.78 ERRORS:
#{error => not_starting_from_keyframe,input => 2,dts_shift => 40.0}

Gop at 70229737.78 ERRORS:
#{error => not_starting_from_keyframe,input => 2,dts_shift => 0.0}

Gop at 70230737.78 OK
Gop at 70231737.78 ERRORS:
#{error => not_starting_from_keyframe,input => 2,dts_shift => 0.0}

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

Вот как будет выглядеть хороший анализ на искуственно собранном потоке:

/opt/flussonic/contrib/mbr_udp_analyze.erl udp://239.150.12.1:1234 udp://239.150.13.1:1234 udp://239.150.14.1:1234
Synced 2 with shift 0.00
Synced 3 with shift 0.00
SYNC
Started stream analysis
Gop at 69999737.78 ERRORS:
#{error => not_starting_from_keyframe,input => 3,dts_shift => 40.0}

Gop at 70000737.78 OK
Gop at 70001737.78 OK
Gop at 70002737.78 OK
Gop at 70003737.78 OK
Gop at 70004737.78 OK
Gop at 70005737.78 OK

Что же делать?

Вряд ли вы купили какой-то волшебный аппаратный транскодер. На сегодняшний день такого практически не существует и под аппаратными решениями подразумевается максимум наличие какого-то ускорителя от Nvidia, Intel или пары других решений.

Скорее всего вы можете на этот компьютер поставить обычный Linux, на него поставить Flussonic и получить гарантированно работающий MBR транскодер