Version 26.08

Flussonic 26.08: Catena переезжает с Flussonic v3 сама, а Watcher перестаёт молчать о пропавшем архиве

Почему Catena — это не «Flussonic с кластером»

Flussonic Media Server писался как софт для одного сервера. Всё в нём устроено вокруг машины: конфигурация лежит на ней, стрим принадлежит ей, архив пишется на её диски. Кластерные возможности появлялись позже и оставались ограниченными — по сути это набор договорённостей между отдельными серверами, каждый из которых по-прежнему живёт своей жизнью. Растёт такая инсталляция плохо: каждая новая машина — это ещё одна конфигурация, которую надо помнить, и ещё один сервер, на который надо зайти, чтобы понять, что там происходит.

Catena построена на Sapsan — новом стриминговом ядре Flussonic на Rust — и спроектирована cluster first. Единица управления здесь не сервер, а кластер, и это видно в каждой функции:

Второе, что отличает Catena, — интроспекция состояния на уровне, которого в наших продуктах не было никогда. Не «зайдите на каждый сервер и посмотрите логи», а один интерфейс, отвечающий на вопросы про всю установку: панель управления с графиками зрителей, трафика и тепловой картой ошибок; сессии поштучно — кто именно смотрит прямо сейчас и кто смотрел вчера; история решений лейаутера с причинами; диагностика источника и диагностика стримера.

Показательный пример — живой мониторинг резервных источников. Спросите себя: как вы сегодня узнаёте, что резервный вход у канала на самом деле мёртв? Обычный ответ — никак: пока основной источник в эфире, резерв никто не трогает, и его исправность остаётся вопросом веры ровно до момента, когда он понадобится. Catena проверяет резерв, пока он ждёт: карточка входа показывает «Готов» — проверен и способен принять нагрузку, — или «Не проверялся», и это видно на вкладке источников сразу, а не в момент аварии. Там же видно не только «есть кадры / нет кадров», но и деградацию: ошибки непрерывности MPEG-TS, падение битрейта, пропавший звук, качество таймлайна.

При этом управляющий контур не стоит на пути медиа: падение central — авария управления, а не эфира, стримы продолжают вещать.

И мы помогаем перейти. Мастер импорта забирает конфигурацию работающего Flussonic Media Server, показывает план до применения и отчёт после. Но инструмент — это только часть: расскажите нам про свою инсталляцию, и мы вместе спланируем переход — что переносим первым, как проверяем эфир и в какой момент переводим зрителей.

Вот что мы сделали для Catena

Переход с Flussonic v3 — мастером, а не руками. У клиента с работающим Flussonic Media Server до сих пор не было ни процедуры перехода, ни инструмента: перенос конфигурации означал перепечатывание сотен стримов с риском молча потерять настройку, о потере которой узнают уже на эфире. Теперь в консоли Catena есть мастер импорта: он читает конфигурацию источника по API и превращает её в стримы, секции шаблонов и бэкенды авторизации нового формата. Сначала показывается план — что именно переедет и что потеряется, — и только потом применение; после импорта вы получаете отчёт по категориям с причиной по каждому неперенесённому полю и счётчик реально поднявшихся стримов. Импорт проверен на конфигурации продового роутера. Вся процедура перехода целиком, включая перевод зрителей и откат, описана в Переходе с Flussonic Media Server.

Установка, после которой продукт работает. Раньше между apt install catena и работающим сервисом стояла стена ручной работы: пакет не создавал роль и базу PostgreSQL, не прописывал строку подключения, не заводил учётную запись оператора и не стартовал сервис на чистой установке. Теперь всё это делает пакет — быстрый старт доводит чистую машину до играющего стрима, а установка в продакшн разбирает состав поставки, секреты, внешний PostgreSQL и порты. Нода кластера ставится своим пакетом catena-streamer и спрашивает адрес central при установке; если адрес введён без схемы, вы увидите понятную ошибку, а не молчаливо не поднявшуюся ноду — как добавить стример в кластер. Коробка теперь называется своим именем: systemctl status catena. Для тех, кто разворачивает в докере, есть образы продуктов, собранные слоями, — обновление не тянет весь дистрибутив заново.

HTTPS без ручной раскатки сертификатов. В продукте появился встроенный ACME-клиент: стример заказывает и продлевает сертификат Let's Encrypt сам, включая сам central. Раскатывать сертификаты руками по 10–100 нодам больше не нужно, и чужих приватных ключей central не хранит. Заодно порт и TLS локальной ноды теперь правятся из консоли, а не редактированием YAML на коробке. Условия выписки, проверка TLS-ALPN-01 и разбор случаев «сертификат не выписывается» — в Сертификате HTTPS.

Шаблоны стримов. «На третьем стриме меня уже утомило прокликивать настройки» — это дословная формулировка из тикета. В Catena вернулось понятие переиспользуемого умолчания: транскодер, архив, превью и таймауты источников настраиваются один раз в шаблоне, а однотипные каналы заводятся по нему. Правило разрешения простое и без сюрпризов: своя секция стрима побеждает шаблонную целиком.

Авторизация просмотра: и как во Flussonic, и быстрее. Бэкенды, написанные под Flussonic, работают с Catena без единой правки — тот же запрос, те же заголовки, как подключить. Переходить, переписывая свою витрину, не нужно. А тем, кому важна скорость старта, доступна вторая схема: витрина создаёт сессию до проигрывания и выдаёт зрителю билет, который стример проверяет локально, никуда не ходя. Ваш бэкенд перестаёт стоять на критическом пути: от него больше не зависят ни скорость переключения канала, ни надёжность старта. Охват билета задаётся тегом контента, поэтому билет «на 300 каналов» не таскает в себе список из 300 имён и не перевыпускается при изменении состава пакета. Обзор обоих способов — в Защите воспроизведения.

Приём MPTS: выбор программы и один захват на мультиплекс. Раньше MPEG-TS по UDP читался только как SPTS: номер программы отбрасывался, и кадры всех программ мультиплекса сливались в одну кашу — чёрный экран в HLS. Теперь у источника есть поле «Программа (PNR)», а несколько стримов могут захватывать один и тот же мультикаст: ствол приходит на сервер один раз, а не по разу на каждый канал. На типовом мультиплексе это экономит сотни мегабит входящего трафика. Как подключается мультикаст-источник — на отдельной странице. Плюс к этому разобран элементарный поток MPEG-2 — без него эфирные и спутниковые стволы просто не принимались.

MoQ: раздача по протоколу, на который переезжает индустрия. Media over QUIC — то, чем консорциум вокруг IETF заменяет связку «HLS для масштаба, WebRTC для задержки». Идея в том, чтобы получить обе вещи разом: задержку меньше секунды и при этом обычную кэшируемую доставку через сеть, а не отдельный peer-to-peer тракт под каждого зрителя. Catena раздаёт live по MOQT (draft-19, CMAF/CMSF): стример поднимает QUIC-листенер, браузер приходит по WebTransport и играет — без плагинов и без шлюзов. Внутри поток нарезается не целыми фрагментами, а теми же частями, что и в LL-HLS, поэтому низкая задержка получается по построению, а не подкруткой буферов. Это первая реализация и пока только раздача: приём по MoQ и relay-раскладка по кластеру — следующие шаги. Но попробовать на своём канале можно уже сейчас: включается листенером в конфигурации стримера.

RTP-пуш и отдача архива по RTSP. Пуш MPEG-TS теперь умеет RTP, а не только голый UDP: типовые аппаратные приёмники принимают именно его, и на сетях с потерями просят тоже его. Отдельно появилась отдача архива по RTSP с Range: clock= — это единственный стандартизованный способ, которым чужие системы («Безопасный город», ЕЦХД и подобные) читают чужой архив. Раньше такая интеграция была невозможна в принципе.

Субтитры из эфира — обычной дорожкой. Скрытые субтитры CEA-608/708, которые едут внутри картинки, теперь превращаются в WebVTT-дорожку, понятную всем OTT-плеерам. Абонент в вашем приложении видит те же субтитры, что зритель того же канала по кабелю, — а требования доступности (CVAA в США, European Accessibility Act в Европе) выполняются без второго входа и ручной работы. Многоязычие достаётся даром: вещатель часто кладёт в канал два-три языковых сервиса, и каждый становится отдельным пунктом меню субтитров. Подробно: Скрытые субтитры вещательного канала.

В эфире субтитры приходят разными способами, и мы сводим их к одной форме. Closed captions CEA-608/708 внутри видеокадров работают сейчас. DVB-субтитры приезжают картинками, поэтому текст из них достаётся распознаванием — DVB OCR выходит в следующей версии. Смысл всей работы в том, что на выходе форма одна: откуда бы субтитры ни пришли, зритель получает обычную WebVTT-дорожку, а вам не нужно ни второго входа, ни отдельного конвейера под каждый вещательный формат.

Транскодер: плотнее и без швов. При MBR один входной кадр декодировался столько раз, сколько у вас выходных качеств: на связке FHD/HD/SD воркер шёл 0.7–0.8× реального времени, живой край отставал, плееры буферизовались. Теперь вход декодируется один раз, а декодированный кадр раздаётся всем энкодерам. Появилось кодирование на видеокарте: на NVIDIA уезжает весь видеотракт — декод, скейл и энкод, — а карта выбирается явно или автоматически, наименее загруженная. И перенастройка перестала быть разрушительной: транскодер больше не пересобирается на шум вроде измеренного битрейта, а когда перенастроиться действительно надо — например, источник сменил разрешение прямо в эфире — это проходит без потерянных кадров, форсированного IDR и разрыва DTS. Лестница качеств, правила аудио и пресеты — в Транскодировании и MBR.

Меньше артефактов у зрителя. Живой DASH разваливался через несколько секунд после включения транскодера: дорожки одного стрима резались по несогласованным сеткам, ошибка округления копилась, и кромка эфира гуляла в пределах секунды — теперь сетки согласованы. В LL-HLS разрывы нумеруются один раз и не перенумеровываются задним числом, так что hls.js больше не падает с discontinuity sequence mismatch; дорожка превью перестала порождать ложные разрывы, из-за которых плеер вставал с пустым буфером. Поток, у которого энкодер вставлял внеплановые IDR, больше не рассыпается на сегменты по 32–64 мс. Смена описания программы в PAT больше не роняет наполовину собранный кадр — раньше это давало внешне здоровый сегмент с дырой в GOP, остановку воспроизведения в Chromium и дыру в архиве навсегда. И многосекундные замирания звука после каждого переключения входа тоже исчезли.

Видно, что происходит. Панель управления отвечает на вопрос «всё ли в порядке» плитками, графиками зрителей и трафика и тепловой картой ошибок. Сессии видны поштучно: не «столько-то зрителей», а кто именно смотрит этот стрим прямо сейчас и кто смотрел недавно — история больше не теряется. Диагностика источника показывает не только «есть кадры / нет кадров», но и деградацию — ошибки непрерывности MPEG-TS, падение битрейта, пропавший звук; резервирование теперь возвращается на приоритетный источник только после чистого окна, а не по первому кадру. Если DVR-диск размонтирован или в пути опечатка, это видно в интерфейсе, а не только строчкой WARN в логе. И если стример не применил сохранённые настройки, причина доезжает до консоли — см. Диагностику стримера.

Тридцать тысяч зрителей с одной ноды. Это, пожалуй, главная цифра релиза. Flussonic на протоколах с низкой задержкой — HTTP MPEG-TS, RTSP — упирался примерно в тысячу-две одновременных клиентов на сервер: дальше начинались отвалы. Catena 26.08 держит на одной ноде 30 000 одновременных зрителей на тех же протоколах.

Дело было в учёте сессий. Все сессии ноды жили в одной таблице под общим замком, и в неё шли оба горячих пути сразу: сокетные сессии — а это как раз низколатентные протоколы — отчитываются о переданных байтах раз в секунду на каждую, а HTTP-зрители ищут свою запись на каждом запросе сегмента. На тридцати тысячах сессий это давало больше двадцати шести тысяч захватов замка в секунду. Сам замок при этом был занят полезной работой примерно на 13% — система стояла не от нехватки сил, а от очереди за собой же: ожидание доходило до секунды в среднем и почти до двенадцати секунд в пике.

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

Достижения не только в раздаче, но и в записи. Вторая половина той же работы — устойчивая запись 20 гигабит в секунду на сервер. В переводе на камеры это 10 000 камер среднего разрешения на одну машину, пишущихся непрерывно, — не пиковое значение на демонстрации, а режим, в котором сервер живёт. Для оператора это меняет арифметику проекта: там, где раньше на архив набиралась стойка, теперь хватает нескольких машин, а состояние дисков и то, чем занято место, видно по всему кластеру сразу.

Архив в кластере. У стрима на эдже появился кэш архива — отдельный выключатель, не требующий записи: origin пишет архив, а эджи ближе к зрителям держат у себя то, что реально смотрят, и чтения почти перестают доходить до дисков origin. Сколько кэш занял и какова доля попаданий — в разделе DVR кластера, который заодно отвечает на вопрос «куда ушло место» на инсталляции с десятками дисков. Зрителей по географии разводят CDN-зоны.

VOD стал кластерным. Раньше файловый VOD жил на уровне одной ноды: чтобы отдать ассет, надо было знать, на какой машине и в каком каталоге он лежит. Теперь каталог VOD ведёт central на весь кластер, а загружать файлы можно прямо из браузера — не выбирая ни ноду, ни диск: ассет уезжает на хранилище с наибольшим свободным местом, а байты идут напрямую на стример, минуя управляющий контур. Порталам для собственной заливки выдаются upload-токены. И две вещи, ради которых мигрирующие клиенты раньше перепаковывали контент, теперь работают как есть: MBR собирается из соседних файлов, а внешние субтитры подхватываются рядом лежащим файлом — movie.mp4 и movie.srt играются без конвертации.

Watcher переезжает на технологию Catena

Главное про Watcher в этом релизе — не отдельная функция, а направление. Watcher начал переезд на то же ядро, на котором построена Catena: медиаслой перестаёт быть Flussonic Media Server и становится Sapsan. В 26.08 сделан первый видимый шаг — у медиаслоя появилось собственное имя: пакет и docker-образ watcher-streamer, за которым движок можно менять, не трогая команды установки, документацию и ваши плейбуки.

Зачем это вам. Sapsan написан на Rust и рассчитан на плотности другого порядка: устойчивая запись 20 гигабит в секунду на сервер — это 10 000 камер среднего разрешения на одну машину. По мере переезда мы ожидаем кратного снижения ресурсов под ту же инсталляцию: меньше машин под то же число камер, меньше стойки, меньше счёт за электричество и обслуживание. Плюс всё то, что уже описано выше в разделе про Catena, — интроспекция состояния и кластерная модель, которых у сегодняшнего медиаслоя нет.

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

Вот что мы сделали для Watcher

Регистратор больше не молчит, когда архив не пишется. Это самый неприятный сценарий из всех: в приложении камеры зелёные, живое видео есть, а архив днями не пишется — диск, DVR или запись встали. Клиент узнаёт об этом в тот момент, когда архив понадобился: после кражи, спора или «кто тут проехал». Отличие от «регистратор офлайн» принципиальное: офлайн хотя бы видно, а «онлайн, но записи нет» — это ложное чувство безопасности. Теперь Watcher за этим следит и предупреждает.

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

Видно, куда уходит архив и насколько он целый. По каждой камере на регистраторе теперь видно, сколько места занимает её архив: можно подтюнить сроки хранения вместо покупки дисков. И главное — видно состояние архива: «храним 30 дней» и «за эти 30 дней архив набрался на 25 с дырками» — это разные вещи, и теперь разница не прячется. Появилась индикация целостности архива, а глубина архива считается по каждому стриму отдельно.

Медиаслой Watcher получил своё имя. Появился пакет watcher-streamer и docker-образ flussonic/watcher-streamer. Это закрывает две вещи. Первая: на кластерных медианодах, которые ставились командой apt install flussonic, была открыта админка медиасервера — теперь она закрыта и в пакетной, и в докерной поставке. Вторая: для системы видеонаблюдения движок — деталь реализации, и её незачем произносить вслух в командах установки и плейбуках. Теперь у медиаслоя постоянное имя, за которым движок можно менять.

Первая установка перестала падать, а апгрейд стал проверяемым. Установка all-in-one падала на первом же apt install и требовала запустить установку второй раз — воспроизводилось стабильно на чистых Ubuntu 22.04 и 24.04. Причина найдена и исправлена. Отдельно мы взялись за миграции базы: цепочка выросла до 193 ревизий, первая установка на них уходила больше сорока секунд, а самое неприятное — апгрейд с реальными данными со старых версий не проверялся вообще ничем. Теперь чистая установка ставится из слепка схемы, а сами миграции покрыты тестами.

Ресурсы больше не утекают, а списки не тормозят. Метод получения списка стримов оставлял в PostgreSQL незакрытые транзакции: соединения залипали в idle in transaction, у клиента текла память, росла нагрузка на CPU и падал сервис — исправлено. Отдельно мы занялись скоростью интерфейса на больших инсталляциях: клиент с 1100+ камерами не мог долистать список, чтобы глазами проверить состояние камер по превью, — страница переставала отвечать. Ускорены список камер, открытие папок, прокрутка и поиск по папкам.

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

Новый плеер с дебаг-панелью. У нового плеера появилась панель отладки с графиками и таймлайном событий. Когда приходит жалоба «дёргается», больше не нужно верить на слово: видно, что именно происходило с воспроизведением.

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

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

Flussonic Media Server

В этом релизе для Media Server сделана одна правка, но полезная тем, у кого много камер: дебаунс повторных срабатываний детектора движения. Плохо настроенная камера — с завышенной чувствительностью или зоной на качающиеся ветки — умеет выдавать поток событий «движение началось» без остановки, и на большой инсталляции такие камеры вместе заваливали управляющий сервер тысячами событий, упирая его в процессор. Теперь повторные срабатывания схлопываются, и разбираться с настройкой отдельных камер можно спокойно, а не в авральном режиме.

И то, о чём стоит сказать прямо: фаза активного развития Flussonic Media Server завершена. Продукт остаётся в поддержке, мы продолжим выпускать минимальные обновления безопасности, но новых возможностей в нём не будет — вся разработка идёт в продуктах на новом ядре.

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