История версий

версия 2.0.0.206 Beta

25.07.2026

  • Meshwork (мультидомен) — несколько серверов объединяются в именованные домены, и домен служит границей изоляции: членство узлов, каталог ресурсов и аварии расходятся только внутри своего домена, между доменами не передаётся ничего. Узел может состоять сразу в нескольких доменах, не смешивая их данные. Подробно — Meshwork.

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

  • Распределённая библиотека ресурсов — выходы UDP, RTP, Pro-MPEG и RIST, multicast-входы UDP, RTP и RIST, а также связи PS1 и SRT публикуются в общем каталоге домена (/data/library): единый список multicast-групп, портов, VLAN, SSM-источников и связей точка-точка с указанием узла и потока. По каталогу видно, какие адреса и порты уже заняты, а новый вход подключается прямо из него — выбором потока, уже отдаваемого на другом узле домена, без ручного ввода адреса.

  • Обзор узлов домена — по каждому узлу видны статус, время последнего контакта, роль, регион, версия сборки, загрузка CPU, трафик по физическим интерфейсам и число потоков в эфире, а по каждой межузловой связи PS1 или SRT — битрейт, RTT, доля повторов и потерь и вердикт состояния.

  • Работа через NAT — узел за NAT участвует в домене полноценно и без проброса входящих портов: он подключается сам, публичная точка доступа достраивается по фактически видимому адресу и объявленному порту, а его состояние соседи ретранслируют на один хоп — узел виден и тем, кто не может обратиться к нему напрямую.

  • Автологин связей внутри домена — для PS1- и SRT-связей между узлами одного домена не нужно заводить логин и пароль на каждую связь: на вызывающей стороне (вход PS1, вход SRT, выход SRT в режиме caller) достаточно включить настройку «Meshwork peer auth», и авторизация выполняется по общему доменному секрету. Подтверждённый узел-партнёр и его поток видны в библиотеке ресурсов и в списке сессий.

  • Low-Latency HLS и MPEG-DASH на CMAF — новый режим раздачи «OTT / LL-HLS / DASH»: встроенный мультиплексор формирует фрагментированный MP4 (CMAF), поверх которого отдаются MPEG-DASH на /dash и Low-Latency HLS на /llhls; адаптивные наборы собираются и для этих форматов. Подробно — Режимы раздачи.

  • Малая задержка LL-HLS — медиаплейлист дробится на части, применяются блокирующая перезагрузка плейлиста и подсказка предзагрузки, поэтому плеер начинает воспроизведение, не дожидаясь готовности полного сегмента. Сегменты CMAF несут Producer Reference Time, манифест DASH объявляет UTCTiming и целевую задержку, а настройка «Целевая длительность LL-части (ms)» применяется на лету, без перезапуска потока.

  • HTTP/3 (QUIC) — HLS, MPEG-DASH, LL-HLS и MPEG-TS over HTTP отдаются поверх QUIC на отдельном UDP-порту, с необязательным 0-RTT; переход на QUIC клиент запрашивает параметром ?h3. Административные маршруты остаются только на TCP.

  • Выравнивание сегментов по IDR — сегментер различает IDR и обычный I-кадр: на источниках с closed-GOP каждый сегмент начинается с полноценной точки входа, поэтому плеер открывает поток с любого сегмента; на источниках с open-GOP границей служит ближайший I-кадр.

  • Защита контента (DRM) — OTT-раздачу потока можно шифровать: HLS AES-128 с ключом от самого сервера или от внешнего key-сервера и с необязательной ротацией по временным окнам, либо MPEG Common Encryption (ISO/IEC 23001-7) по схемам cenc и cbcs для CMAF и DASH. Шифрование выполняется один раз, в момент формирования сегмента, поэтому архив DVR хранится зашифрованным и воспроизводится через любое число смен ключа. Подробно — Защита контента (DRM).

  • DVR (сетевой архив) — каждый OTT-канал пишется на диск параллельно с раздачей, той же сегментацией и без отдельного рекордера; в режиме низкой задержки архив ведётся двумя линиями, MPEG-TS и CMAF, поэтому запись доступна в том же контейнере, что и живое вещание. Подробно — DVR.

  • Воспроизведение архива (VOD) — архив отдаётся по тем же HLS, DASH и LL-HLS URL, что и живое вещание: t=<время> включает режим VOD и задаёт начало окна, d=<секунды> — его длительность. Плейлист HLS при этом закрытый, манифест DASH статический, разрывы записи оформлены отдельными периодами; адаптивные наборы воспроизводят архив теми же параметрами.

  • Catch-up по EPG — вместо t и d достаточно передать epg=<время>: сервер сам находит на привязанном канале EPG передачу, идущую в этот момент, и берёт её начало и длительность как границы окна воспроизведения.

  • Субтитры в архиве — дорожки WebVTT пишутся на диск вместе с сегментами и воспроизводятся в VOD по тем же URL; окна без реплик места на диске не занимают.

  • Хранилища DVR — хранилищ может быть несколько, у каждого свой предел заполнения и свой порядок очистки. Глубина архива («Хранение (часы)», до 90 суток) и защищённый минимум задаются отдельно для каждого потока, а очистка по свободному месту не трогает ни защищённый минимум, ни окна открытых VOD-сессий.

  • Монитор DVR — отдельный экран показывает состояние и заполнение хранилищ, объём и глубину архива по потокам и задержки чтения и записи, а гистограмма покрытия (/data/dvrstat) отмечает не только дыры в архиве, но и их причину — обрыв входа, смену PMT, скремблирование, срабатывание очистки. Отсюда же стираются архив отдельного потока и каталоги удалённых потоков.

  • Алертер — новая служба оповещений: каждая авария становится инцидентом, который поднимается, обновляется и снимается автоматически, а дедуплицированный активный набор показывает только то, что происходит сейчас. Серьёзность задаётся единой шкалой — от информационной до требующей вмешательства администратора; такой инцидент снимается подтверждением оператора. Подробно — Оповещения (алертер).

  • Каталог кодов аварий — более пятидесяти типов инцидентов в одном списке: потоки и их входы и выходы, нарушения TR 101 290, ресурсы узла, хранилища и здоровье записи DVR, приём DVB и CI/CAM, транскодеры, OTT, сертификаты и узлы домена. Пороги срабатывания настраиваются в разделе оповещений.

  • Внешняя доставка оповещений — аварии уходят за пределы веб-консоли: письмом по SMTP (STARTTLS, implicit TLS, AUTH), сообщением в Telegram и запуском произвольной команды, которой инцидент передаётся переменными окружения и полным JSON на стандартный вход. У каждого канала свой выключатель и свой порог серьёзности.

  • Аварии всего домена — дежурный видит аварии любого узла с любого другого: активный набор расходится вместе с keep-alive и снимается сразу, как только исчез у источника, а у каждой строки указан узел-источник. Аппаратные и системные аварии по умолчанию остаются локальными и поднимаются до доменных отдельной настройкой.

  • Журнал в базе данных — сообщения сервиса пишутся в SQLite: типизированные записи с источником и уровнем серьёзности, свёртка идущих подряд повторов в одну строку со счётчиком, ограничение хранения по сроку и по объёму. В отличие от активного набора аварий журнал переживает перезапуск.

  • Монитор TR 101 290 — непрерывный контроль соответствия входного потока стандарту: единый вердикт («Норма», «Проблема», «Проверка…») и структурный отчёт по приоритетам 1, 2 и 3, где для каждого показателя указаны пункт стандарта, измеренное значение и предел. Мультиплекс MPTS оценивается целиком — по всем PID, программам и таблицам SI. Поток автоматически классифицируется как CBR или VBR, и проверки, осмысленные только при постоянном битрейте, на VBR-источнике не оцениваются и не дают ложных срабатываний. Подробно — Монитор TR 101 290.

  • Дрейф опорного генератора — систематический уход тактовой частоты источника измеряется линейной регрессией в ppm при допуске ISO/IEC 13818-1 ±30 ppm и выводится отдельной метрикой. Медленный уход отрабатывается плавными микросдвигами точки синхронизации («Компенсация дрейфа синхронизации», включена по умолчанию), поэтому на выходе нет рывков.

  • Модель буфера T-STD — анализ видеобуфера эталонного декодера по ISO/IEC 13818-1 со счётчиками переполнений и опустошений для MPEG-2, H.264 и HEVC; отсчёт ведётся по часам PCR, а скорость слива подстраивается под фактический битрейт видео. Включается настройкой «Анализировать видеобуфер T-STD».

  • Анализ для вставки рекламы — разбор секций SCTE-35 с событиями склейки, точки склейки транспортного уровня с настраиваемым упреждением и метки случайного доступа. Данные выводятся в статистике потока при включённом глубоком анализе.

  • Помощник для рекламаций — по потоку с устойчивыми нарушениями формируется готовое текстовое задание для AI-чата, по которому тот составляет формальное письмо-рекламацию поставщику потока: перечень устойчивых нарушений, измеренные значения, пункты стандарта и влияние на декодер. Задание отдаётся запросом GET /data/stream/<id>/ai-complaint-prompt; название потока и адрес источника в текст не включаются.

  • CI/CAM (EN 50221) — встроенный хост Common Interface: обнаружение модуля, чтение его имени и списка поддерживаемых CA_system_id, выбор программ для дескремблирования и передача CA_PMT по каждой из них. Модуль, совмещённый с DVB-приёмником, дескремблирует выбранные программы принятого мультиплекса инлайн, несколько одновременно; состояние слотов и вердикт по каждой программе видны в интерфейсе.

  • Программный дескремблер BISS-1 / BISS-E — применяется не только к приёму с DVB-карты, но и к любому входу потока: ключ задаётся на SPTS целиком или по программам мультиплекса и меняется на лету, без перезапуска входа. На приёме с DVB-карты результат дополнительно проверяется по самому потоку, поэтому неверный ключ не выглядит как успешное дескремблирование, а поднимает отдельную аварию.

  • Очистка условного доступа на приёме DVB — из мультиплекса, принятого DVB-картой, отдельной настройкой адаптера удаляются PID ECM и EMM, а из PMT — CA-дескрипторы открытых программ: дальше по тракту уходит чистый FTA-поток. При потере ключа разметка условного доступа возвращается, чтобы приёмник ниже по цепочке смог заново запросить доступ.

  • Телеметрия транскодера — по каждому энкодеру публикуется медиаинформация перекодированного выхода: формат кадра, кодек видео, набор аудиокодеков и текущий битрейт, а по каждому процессу — загрузка CPU и занятая память.

  • RTMP и RTMPS — канал публикуется на любой RTMP-приёмник, включая YouTube и Facebook: видео H.264 или HEVC (HEVC — через Enhanced RTMP) и одна дорожка AAC, для rtmps:// узел подключается как TLS-клиент. В обратную сторону вход сам забирает поток с источника rtmp:// или rtmps:// и ремультиплексирует FLV в MPEG-TS.

  • Бесшовное переключение источника — при смене активного входа на передатчике приёмные пиры PS1 не переподключаются: нумерация и метки времени остаются непрерывными, всплеск очереди гасится отбрасыванием самых старых пакетов, а пропуск добирается штатной ретрансмиссией.

  • Адаптивная ретрансмиссия PS1 — приёмник измеряет фактический RTT до передатчика и сам подстраивает под него интервалы повторных запросов; измеренный RTT, текущий интервал перезапроса и признак слишком малой задержки выведены в статистику связи. Задержка приёмного тоннеля задаётся напрямую в миллисекундах вместо прежнего множителя от RTT.

  • Состояния «Переподключение» и «Действие администратора» — потерявший источник вход или выход переоткрывается на месте и остаётся в состоянии «Переподключение» на всё время попыток, поднимая одно предупреждение на эпизод вместо сообщения на каждую попытку. Причину, которую повтором не устранить — занятый порт, отсутствующий интерфейс, данные не MPEG-TS, отказ SRT по шифрованию, — узел переводит в состояние «Действие администратора» с удерживаемым оповещением, а правка настроек применяется сразу.

  • MPTS-мультиплексор: исходная идентичность — программы могут сохранять свои исходные PID, а порядок программ в PAT, SDT и NIT задаётся вручную, поэтому мультиплекс переносится на Perfect Streamer без смены идентичности потока для приёмного оборудования. Программы с TS-скремблированием переносятся с исходными метками времени.

  • Интеграция с внешним биллингом — каждая зрительская сессия авторизуется во внешней биллинг- или CRM-системе, удерживается периодической ре-авторизацией и по завершении сообщается ей же: жизненный цикл Start / Interim / Stop в стиле RADIUS, отзыв подписки сбрасывает сессию посреди просмотра. Охвачены OTT, пиринг PS1 и выходы SRT, а сам биллинг подключается шаблонами запроса и разбора ответа, без доработки ПО.

  • Встроенный клиент ACME (Let’s Encrypt) — выпуск и автоматическое продление сертификатов для веб-сервера, HTTP/OTT-сервера и EPG-сервера: сертификат заказывается на каждое настроенное имя хоста, продление проверяется ежедневно, при неудаче поднимается авария. Поддерживаются произвольный удостоверяющий центр и внешняя привязка учётной записи, а новый сертификат применяется без перезапуска сервиса.

  • Новый веб-интерфейс — управление узлом переведено на новую консоль, которая открывается по адресу узла (путь /admin): обзор, потоки, мониторинг системы, DVB, DVR, транскодеры, клиенты, журнал, аварии и все настройки сервера. Отдельные схемы показывают топологию домена Meshwork и тракт выбранного потока от входов до выходов. Прежний интерфейс сохранён по адресу /classic. Подробно — Веб-интерфейс.

  • Обновление в реальном времени — узел отдаёт своё состояние потоком событий на /data/events: при подключении приходит полный снимок, дальше раз в секунду обновляются кадры потоков, системных ресурсов, клиентов и DVB-адаптеров, а аварии и смены состояния приходят событиями. Интерфейс и внешние панели работают без периодического опроса.

  • Контекстная справка — каждый экран и каждое важное окно нового интерфейса снабжены вызовом справки, который открывает раздел документации именно по тому, что сейчас открыто: общая кнопка справки — для экрана, кнопка «?» в заголовке окна — для этого окна. Раздел открывается на языке интерфейса.

  • Языки, темы и раскладки — интерфейс переведён на шесть языков (русский, английский, немецкий, французский, испанский, португальский), поддерживает светлое и тёмное оформление и сам подстраивает плотность раскладки под телефон, планшет, рабочую станцию и видеостену.

  • Прочие улучшения и исправления ошибок.