Источники live stream и LSI¶

media.live.inputs

LSI (Live Source Input) управляет входами live stream. Он принимает медиа от выбранного источника, следит за его состоянием и организует восстановление при проблемах. Если у стрима настроены резервные входы, LSI оценивает их пригодность и выбирает, откуда продолжать приём.

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

Управление источниками встроено в пайплайн Sapsan:

• Контроль приёма выявляет отсутствие кадров и проблемы с отдельными дорожками.
• Оценка качества позволяет заметить повреждение потока до полного прекращения приёма.
• Проверка резервов даёт сведения об их работоспособности до аварии основного входа.
• Согласованное переключение подготавливает новый источник и передаёт его медиа дальше по пайплайну.
• Наблюдаемость показывает выбранный вход и причины решений, а также позволяет измерить время работы на резерве.

Что значит «источник работает»¶

Успешное сетевое подключение ещё не означает, что источник готов к эфиру. LSI учитывает поступление медиаданных и наличие точки, с которой можно начать их обработку. Для кадрового видеовхода такой точкой служит ключевой кадр; для источника только со звуком — аудиокадр. При приёме с сохранением готовых фрагментов используется граница фрагмента.

Состояние источника зависит от доступных для его протокола наблюдений и настроенных правил:

LSI различает отказ и ухудшение качества. При отказе продолжать приём с входа нельзя: например, превышен таймаут отсутствия кадров или настроенный таймаут видео. Такой вход закрывается, и начинается поиск альтернативы.

При ухудшении качества медиа продолжает поступать. Например, исчез звук или число ошибок непрерывности превысило допустимый порог. LSI ищет более подходящий источник, сохраняя текущий приём. Если исправного резерва нет, он продолжает использовать деградировавший источник: частично сохранившееся вещание остаётся доступным.

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

Как LSI выбирает источник¶

Несколько входов в inputs описывают альтернативные источники одного стрима. В обычном режиме дальше по пайплайну передаётся медиа выбранного входа. Приоритет по умолчанию следует порядку в списке; явный source_options.priority позволяет его изменить. Меньшее число означает более высокий приоритет.

Чистое окно — интервал без нарушений правил качества. Его длительность задаётся return_alive_secs, по умолчанию 15 секунд. При возврате на более приоритетный источник одного успешного подключения недостаточно: LSI должен увидеть устойчивый приём. Это защищает вещание от повторных переключений на источник, который восстанавливается ненадолго.

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

Неудачные подключения повторяются с растущей задержкой. Поэтому недоступный адрес не вызывает непрерывный цикл немедленных попыток. Подробные параметры приведены в резервировании источников.

Как проверяется резерв¶

LSI может проверить резерв, пока основной источник продолжает работать. Проверка принимает реальные медиаданные и оценивает их качество. Результат содержит состояние источника и время наблюдения; он доступен через API вместе со сведениями о дорожках.

Периодическая проверка задаётся recheck_secondary_inputs_interval: по умолчанию 900 секунд, значение 0 отключает её. Это интервал планирования фоновых проверок, а не обещание открыть каждый резерв ровно раз в 900 секунд. На момент проверки влияют текущая работа LSI и задержки повторного подключения.

Успешная фоновая проверка заканчивается закрытием резервного входа. Поэтому состояние working у невыбранного источника означает исправность при последнем наблюдении. Свежесть результата нужно оценивать по checked_at. Постоянный параллельный приём всех резервов здесь не подразумевается.

Способ проверки зависит от входа. Источник, к которому Sapsan сам подключается, можно временно открыть. При публикации соединение инициирует отправитель: LSI наблюдает приходящую публикацию, но не может открыть её вместо отправителя. Описанное чистое окно возврата относится к проверяемым входам; допущенная входящая публикация может быть выбрана уже на первом подходящем стартовом кадре.

Переключение и непрерывность вещания¶

При подготовленном переключении LSI сохраняет текущий приём до готовности замены. Например, стрим работает с резервного входа, а основной восстановился:

1. LSI открывает основной вход; медиа резервного продолжает поступать потребителям.
2. Основной проходит чистое окно.
3. На подходящем ключевом кадре или границе фрагмента LSI выбирает основной вход.
4. Пайплайн получает уведомление о смене источника и новые параметры медиа перед кадрами нового входа.

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

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

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

• Совместимость медиа. Согласуйте кодеки и состав дорожек. Проверьте также параметры видео и звука: изменение формата может потребовать перенастройки декодера.
• Синхронизация содержания. Два источника одного телеканала могут иметь разную задержку. Без согласования содержания при переключении возможен повтор или пропуск фрагмента передачи.
• Доступность стартовой точки. Длинный GOP увеличивает ожидание ключевого кадра. Входы с готовыми фрагментами переключаются на границе фрагмента.
• Характер аварии. При внезапном исчезновении текущего источника уже утраченные кадры нельзя восстановить одним переключением. На паузу влияют таймаут обнаружения и готовность резерва.
• Выходной тракт. Проверяйте переключение с реальными протоколами выдачи и плеерами, а при транскодировании — с выбранной конфигурацией транскодера.

LSI не проверяет полную эквивалентность параметров кодирования перед каждым переключением. Сам факт наличия двух адресов в inputs не гарантирует незаметный переход. При проектировании системы нужно подготовить источники и проверить конечное воспроизведение. Если все входы недоступны, отдельная функция заставки позволяет подать подготовленный файл.

Пример настройки¶

Sapsan получает конфигурацию через API central. Ниже — YAML-фрагмент с двумя альтернативными UDP-источниками. Настройки lsi задают общую политику стрима, а source_options уточняют поддерживаемые параметры отдельного входа.

streams:
  - name: tv1
    inputs:
      - udp:
          host: 239.0.0.1
          port: 5000
        source_options:
          priority: 1
      - udp:
          host: 239.0.0.2
          port: 5000
        source_options:
          priority: 2
    lsi:
      source_timeout: 5
      video_timeout: 3
      audio_timeout: 3
      cc_errors_limit: 10
      return_alive_secs: 15
      recheck_secondary_inputs_interval: 900
      reconnect_initial_delay: 1500
      reconnect_delay_step: 5000
      reconnect_max_delay: 60000

В этом примере отсутствие любых кадров в течение 5 секунд либо видео в течение 3 секунд означает отказ входа. Отсутствие звука в течение 3 секунд означает ухудшение качества. Порог ошибок непрерывности — 10 за окно оценки; превышение порога ухудшает состояние источника. Для проверки возврата на основной требуется чистое окно в 15 секунд.

Таймауты и интервалы наблюдения в примере указаны в секундах. Параметры reconnect_* указаны в миллисекундах: начальная задержка 1500 мс, шаг увеличения 5000 мс, предел 60000 мс. Эти параметры повторных подключений задаются в lsi.

Значения таймаутов здесь выбраны для примера. Подбирайте их с учётом поведения источника и допустимого перерыва вещания. По умолчанию source_timeout составляет 60 секунд, а отдельные таймауты видео и звука не включены.

Что мониторить¶

API central позволяет увидеть состояние входов стрима:

curl -fsS -u "$ADMIN_USER:$ADMIN_PASSWORD" \
  http://central:8080/central/api-v4/streams/stats/tv1 \
  | jq '{name, inputs: [.inputs[] | {
      url, current, status,
      problems: (.problems // []),
      checked_at, error, failure_cause
    }]}'

Поле current показывает выбранный вход, а status — его состояние. Эти признаки независимы: текущий вход может быть degraded, а резервный — working. При аварийном поиске current ещё не подтверждает возобновление приёма: учитывайте status и реальное воспроизведение.

• unchecked — ещё нет результата наблюдения.
• starting — вход открыт, подходящая стартовая точка ещё не получена.
• working — по имеющимся наблюдениям источник исправен.
• degraded — медиа поступает с нарушениями правил качества.
• dead — источник недоступен или признан отказавшим.

problems сообщает обнаруженные нарушения, а error и failure_cause помогают разобраться в ошибке. checked_at содержит время наблюдения в UTC в формате RFC 3339; у ещё не проверенного источника его может не быть. Запрос статистики сам по себе не запускает проверку резерва.

Для эксплуатационного мониторинга полезны следующие сигналы:

• Ухудшение текущего входа — current: true вместе с degraded или отказом.
• Потеря резерва — резервный вход отказал или давно не имеет свежего подтверждения исправности, хотя текущая выдача ещё работает.
• Частые переключения — растёт input_switches; нужно проверить стабильность источников и настройки возврата.
• Продолжительная работа на резерве — растёт num_sec_on_secondary_input; восстановление основного требует внимания.
• Отсутствие медиа — растёт num_sec_no_data.

Подробные счётчики .input доступны в запросе статистики одного стрима к стримеру, который выполняет приём: /streamer/api-v4/streams/stats/tv1. Компактное состояние в central эту секцию не заменяет. Пример запроса и правила расчёта интервалов приведены в измерении времени на входах.

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

Как проверить резервирование перед вводом в эксплуатацию¶

1. Убедитесь, что выбран ожидаемый основной вход. Получите свежий результат проверки резерва и сравните inputs[].media_info: параметры входов должны соответствовать проекту системы.
2. Прервите основной источник контролируемым способом. Проверьте смену current и рост input_switches, одновременно наблюдая реальное воспроизведение.
3. Восстановите основной источник. Для входов, к которым подключается Sapsan, убедитесь, что во время проверки продолжает работать резерв, а возврат происходит после чистого окна.
4. Отдельно проверьте ухудшение качества без разрыва соединения, например потерю звуковой дорожки при включённом audio_timeout.
5. Проверьте отказ резерва при работающем основном: мониторинг должен обнаруживать потерю резервирования до аварии основного входа.

Что LSI даёт сервису вещания¶

FFmpeg предоставляет средства обработки медиа и умеет восстанавливать соединения — например, для HTTP доступны параметры повторного подключения. При построении сервиса вокруг команды FFmpeg управление жизненным циклом нескольких источников требует отдельного решения.

В Sapsan эта работа объединена в LSI. Оператор задаёт источники и политику; стример наблюдает за качеством и готовит переключения, а API даёт состояние для мониторинга. Так резервирование становится управляемой частью круглосуточного вещания: можно заранее проверить запасной маршрут, объяснить причину смены источника и убедиться, что основной восстановился устойчиво.