Видео тысячам зрителей
с ваших серверов
Медиасервер для операторов связи и IPTV, вещателей и команд, которые строят свой видеосервис. Принимает эфир с головных станций, кодировщиков и камер и отдаёт его на браузеры, телевизоры, приставки и телефоны — всеми протоколами сразу, с архивом и видео по запросу. Лицензия — по числу потоков: рост аудитории не меняет её цену и почти не нагружает процессор.
- 250+ потоков
- на одно логическое ядро современного процессора
- до 50 Гбит/с
- трафика с одного сервера
- 10 протоколов раздачи
- браузеры, телевизоры, приставки и телефоны — одновременно
- 96 мс
- доставка по RTSP на стенде разработки
Кому он нужен и что даёт
Четыре типовые задачи, под которые ставят сервер. Одна установка может закрывать несколько сразу — например, эфир для зрителей и камеры для собственной службы.
Операторы связи и IPTV
Раздать абонентам каналы с головной станции на любые устройства.
- Приём MPEG-TS по UDP и multicast, забор чужой раздачи HLS и DASH
- Приставки, телевизоры, браузеры и телефоны — всеми протоколами одновременно
- Абоненты почти не нагружают процессор: поток упаковывается один раз, на зрителя приходится только отправка
Вещатели и видеоплощадки
Выпустить эфир к зрителям, сохранить его и собрать библиотеку видео.
- Публикация со студийного кодировщика по RTMP(S) или из браузера по WHIP
- LL-HLS, когда важна задержка, и HLS — для совместимости и CDN
- Архив эфира и видео по запросу из обычного каталога с файлами MP4
Интеграторы
Вывести камеры и регистраторы заказчика в браузер и в его систему.
- Забор RTSP с камер, видеорегистраторов и кодировщиков
- Просмотр в браузере без плагинов и встраиваемый плеер
- REST API со спецификацией OpenAPI на каждое действие панели
Разработчики видеосервисов
Построить свой VSaaS, стриминговый сервис или платформу ВКС, не разрабатывая медиасервер.
- Приём, раздача, архив и права доступа уже решены и управляются по API
- Доступ по меткам: права описываются терминами вашего продукта
- WebRTC для реального времени: публикация по WHIP, просмотр по WHEP
Задача рядом, но не совпадает? Опишите её — скажем прямо, подходит сервер или нет.
Что умеет сервер
Всё перечисленное входит в один исполняемый файл и включается директивами конфигурации — отдельных модулей, сборок и дополнений нет.
Приём видео
RTSP (TCP и UDP), HLS, DASH, MPEG-TS по UDP и multicast, RTMP(S), локальные файлы, синтетический источник для проверки.
Приём публикации
RTMP(S) от кодировщиков и WHIP из браузера — когда к источнику нельзя подключиться снаружи.
Раздача
HLS в fMP4 и TS, LL-HLS, DASH, MSE-WS, HTTP-TS, RTSP, RTMP, WHEP, групповой MPEG-TS и превью-кадры.
Архив
Непрерывная запись на локальные диски и в S3-совместимое хранилище, глубина по времени и объёму, экспорт фрагментов файлом.
Видео по запросу
Раздача готовых файлов из каталога с перемоткой — теми же протоколами, что и живое видео.
Кластер
Несколько серверов как один: размещение потоков, единый список сессий, переадресация зрителя на узел с нужным потоком.
Мониторинг
REST API, метрики в формате Prometheus, поток событий SSE, журнал с поиском прямо в панели, журнал аудита.
Разграничение доступа
Токены и JWT на просмотр и публикацию, внешняя служба авторизации, отдельные токены на API.
Упаковать один раз
Принятый поток разбирается на кадры и упаковывается во фрагменты один раз. Все протоколы раздачи читают одну и ту же упаковку, поэтому второй и третий протокол не добавляют работы по переупаковке — только отправку.
- 01 Приём по схеме адреса Способ приёма задаёт схема в начале адреса источника: RTSP, HTTP, UDP, RTMP, публикация, файл.
- 02 Разбор один раз Поток разбирается на кадры один раз — сколько бы протоколов его потом ни отдавало.
- 03 Упаковка один раз Кадры складываются во фрагменты, готовые к отдаче. Перекодирования нет: меняется только контейнер.
- 04 Раздача 10 протоколов Все протоколы читают одну и ту же упаковку, поэтому включать «лишние» не вредно.
Из той же упаковки ведётся и запись архива: отдельного разбора для архива нет.
- Перекодирования нет
- Кадр, принятый от камеры, доходит до зрителя байт в байт — меняется только контейнер. Кодек и разрешение выбираются на источнике.
- Плотность потоков
- От 250 потоков на одно логическое ядро современного процессора. Число зрителей на расход почти не влияет.
- Обрыв не рвёт сессии
- Упаковка, зрительские сессии и запись переживают переподключение к источнику: ни один зритель не отключается.
- Режим по требованию
- Поток можно поднимать с первым зрителем и останавливать через заданное время после последнего — это экономит трафик до камеры.
Приём и раздача
Способ приёма полностью определяется схемой в начале адреса источника — отдельной директивы «тип источника» нет. Раздача по HLS, DASH, MSE-WS, RTSP и WebRTC поднимается автоматически, включать её отдельно не нужно.
Приём
| Схема | Что это | Когда применять |
|---|---|---|
| rtsp:// · rtsps:// | Забор с камеры, видеорегистратора или кодировщика | Basic и Digest, транспорт TCP или UDP |
| http:// · https:// | Забор HLS, DASH или непрерывного MPEG-TS | Формат определяется автоматически |
| udp:// · multicast:// | MPEG-TS одноадресный или групповой | Головные станции и IPTV внутри своей сети |
| rtmp:// · rtmps:// | Сервер сам подключается к RTMP-источнику | Источник отдаёт только по RTMP |
| publish:// | Сервер ждёт публикации от источника | Кодировщики, браузер, источник за NAT |
| file:// | Локальный файл MP4 по кругу в реальном темпе | Заглушка вместо камеры, проверка конвейера |
| demo:// | Встроенный тест-паттерн с часами | Проверка установки до появления камер |
Публикацию принимают RTMP(S) от кодировщиков и WHIP из браузера — для источников, к которым нельзя подключиться снаружи. У потока может быть несколько источников в порядке приоритета: при отказе сервер сразу переходит к следующему, а позже возвращается к основному.
Раздача
| Протокол | Доставка | Где применять |
|---|---|---|
| HLS fMP4 | несколько секунд | Браузеры, мобильные, телевизоры, CDN |
| LL-HLS | доли секунды | Тот же HLS, когда важна задержка |
| HLS-TS | несколько секунд | Приставки и телевизоры без поддержки fMP4 |
| DASH | несколько секунд | Встраиваемые плееры и устройства под DASH |
| MSE-WS | доли секунды | Видеостены и панели наблюдения в браузере |
| HTTP-TS | доли секунды | Потребители, читающие непрерывный поток по HTTP |
| RTSP · RTSPS | десятки миллисекунд | Видеорегистраторы, стороннее ПО, диагностика |
| RTMP · RTMPS | доли секунды | Передача в сервисы, принимающие RTMP |
| WHEP (WebRTC) | доли секунды | Самая низкая задержка в браузере и единственный путь для звука G.711 |
| Multicast MPEG-TS | доли секунды | Раздача внутри своей сети без запроса от клиента |
Плюс превью-кадр и встраиваемый плеер: это адреса раздачи, но не протоколы. Варианты поверх TLS — RTSPS и RTMPS — считаются тем же протоколом. Все адреса HTTP обслуживает один слушатель: отдельного медиа-порта нет. В колонке «Доставка» — путь до плеера; итог у зрителя определяет буфер плеера, он разобран в блоке ниже.
Задержка: доставка и итог у зрителя
Два слоя: доставка — путь кадра через сервер до плеера, измеренный на стенде, — и итог у зрителя: целевая задержка нашего веб-плеера, которая уже включает доставку. Протокол выбирают под задачу: диспетчеру — доли секунды, зрителю архива — совместимость.
Доставка измерена на стенде разработки: синтетический источник, настройки по умолчанию. Запас плеера выбран ради плавности — чтобы неровность сети не оборачивалась подвисаниями — и при необходимости снижается настройкой плеера. Реальные значения зависят от источника, сети и плеера: сохраняется порядок величин, а не точное число.
- RTSP доли секунды у зрителя · буфер задаёт клиент, обычно минимальный
- MSE-WS ≈1 с у зрителя · цель плеера 0,95 с, на Safari — 1,5 с
- LL-HLS ≈4 с у зрителя · цель плеера — запас ради плавности
- HLS обычный ≈8 с у зрителя · цель плеера — ≈3 сегмента от живого края
доставка до плеера — измерено запас плеера до его целевой задержки
Какие кодеки доходят до какого зрителя
Перекодирования нет, поэтому кодек источника определяет всё дальнейшее. Несовместимая дорожка не вызывает ошибку — она просто не создаётся: зритель получает исправное видео без звука, а не сломанный поток.
| Раздача | Видео | Звук |
|---|---|---|
| HLS fMP4 и LL-HLS | H.264 · H.265 · AV1 | AAC и Opus |
| MSE-WS | H.264 · H.265 · AV1 | AAC и Opus |
| DASH | H.264 · H.265 · AV1 | AAC и Opus |
| HLS-TS | H.264 и H.265 | только AAC |
| HTTP-TS | H.264 и H.265 | только AAC |
| Multicast MPEG-TS | H.264 и H.265 | только AAC |
| RTSP · RTSPS | H.264 · H.265 · AV1 | AAC · Opus · G.711 обоих законов |
| WHEP (WebRTC) | H.264 · H.265 · AV1 | Opus · G.711, но не AAC |
| RTMP · RTMPS | H.264 и H.265 | только AAC |
- RTMP несёт только AAC
- Поток со звуком Opus или G.711, отданный по RTMP, уходит без звука — молча, без предупреждения клиенту.
- WHEP не несёт AAC
- Если у источника звук AAC, ответ WHEP вообще не содержит звуковой дорожки: AAC не согласуется в WebRTC.
- Всё на основе MPEG-TS — это H.264/H.265 плюс AAC
- AV1, Opus и G.711 не имеют стандартного отображения в MPEG-TS, поэтому их там нет и быть не может.
Запись и перемотка
Запись ведётся из той же упаковки, что и раздача. Фрагменты складываются в хранилище и индексируются по времени; глубина ограничивается временем, объёмом или обоими сразу.
Запись — факт конфигурации, а не команда: поток пишется, пока в его блоке есть строка архива. Это исключает «случайно выключенную» запись.
- Два вида хранилищ
- Дисковое — каталог на локальной файловой системе, единственная цель записи. S3-совместимое — холодная копия уже записанного.
- Глубина по времени и объёму
- Одна строка в описании потока: «хранить 14 дней или 500 ГиБ — что наступит раньше». При заполнении тома старые записи вытесняются.
- Просмотр тем же протоколом
- Плеер получает обычный плейлист HLS, только описывающий не последние секунды, а запрошенный интервал: отмотка назад, момент по времени, закрытый интервал.
- Экспорт фрагмента файлом
- Запрос интервала к маршруту архива возвращает готовый MP4 с заголовком выгрузки — отдельной задачи подготовки нет.
Файлы играются сразу
Каталог с готовыми MP4 объявляется библиотекой — и файлы играются в браузере как обычное потоковое видео, с перемоткой по всей длительности. Ни перекодирования, ни этапа импорта: плейлист и куски синтезируются на лету при первом обращении, исходные файлы не меняются.
Механизмы независимы: библиотека живёт без единого пишущего потока, а архив — без единой библиотеки. Записи архива — тоже корректные файлы: они играются через библиотеку.
| Архив | Видео по запросу | |
|---|---|---|
| Откуда материал | Сервер записывает живой поток сам | Файлы кладёте вы |
| Единица | Непрерывная лента времени | Отдельный файл |
| Как адресуется | Поток и интервал времени | Путь к файлу |
| Что со старым | Вытесняется по глубине архива | Лежит, пока вы его не удалите |
Сотни потоков на логическое ядро
Плотность потоков — то, ради чего сервер выбирают: расход линеен и предсказуем, тысячный поток стоит столько же, сколько первый.
до 50 Гбит/с
с одного сервера Верхняя граница трафика одной машины при достаточной полосе. Как и плотность, зависит от характеристик потоков.
Зрители обходятся почти даром
Вся тяжёлая работа привязана к потоку и не зависит ни от числа зрителей, ни от числа включённых протоколов. Зритель добавляет к ней только отправку байтов, поэтому рост аудитории почти не увеличивает расход процессора.
Отсюда правило подбора: тысяча зрителей одного потока обходится дешевле, чем сто зрителей десяти потоков.
Откуда это берётся
Ядро написано на Rust — современном высокопроизводительном языке. Дальше дело в качестве: выверенный и тщательно протестированный код и архитектура, спроектированная под эту нагрузку с самого начала.
Специальные платы и ускорители не нужны — достаточно обычного сервера общего назначения на Linux x86-64.
Не только конфигурационный файл
Медиасервер этого класса обычно настраивают файлом, а проблемы разбирают по журналам. Файл никуда не делся — его любят администраторы и системы автоматизации, — но рядом есть полноценный интерфейс, в котором видно состояние и можно менять настройки.
Инцидент разбирается в браузере, а не по журналам, собранным с нескольких машин. И настройку можно поручить человеку, который не живёт в конфигурационных файлах.
Это встроенная диагностика конкретного сервера, а не система мониторинга предприятия: для внешнего сбора отдаются метрики Prometheus и поток событий. Вход в панель — администраторский; роли и разграничение операторов живут в системе видеонаблюдения.
- Состояние каждого потока
- Идёт ли приём, кодеки и разрешение, битрейт, время непрерывной работы, число переподключений и текст последней ошибки источника.
- Живые сессии зрителей
- Кто смотрит прямо сейчас, каким протоколом и сколько ему отдано.
- Ресурсы процесса и хоста
- Процессор и память — видно, во что упирается сервер, до того как это заметит зритель.
- Журнал с поиском
- Прямо в интерфейсе: разбор инцидента не требует захода на сервер по SSH.
- Правка конфигурации с проверкой
- Проверка идёт до применения: ошибочная правка не принимается и ничего не меняет — вместо того чтобы уронить службу.
- История конфигурации с откатом
- Видно, что и когда менялось, и можно вернуться к прежней версии.
- Предпросмотр любым протоколом
- Поток открывается прямо в карточке — HLS, LL-HLS, MSE-WS, DASH, WebRTC — без сторонних плееров.
- Обновление на лету
- Показатели меняются сами, перезагружать страницу не нужно.
Во что обходится нагрузка
Нагрузку можно посчитать заранее — арифметика простая. Ниже — что дороже обычного, сколько нужно диска и как считать ёмкость, чтобы не ошибиться.
Что дороже обычного
| HTTPS · RTMPS · RTSPS · WSS | дороже | Шифрование каждого исходящего байта и рукопожатие на каждое соединение. |
| WebRTC (WHEP) | дороже | У каждого зрителя своё шифрование и свой поток пакетов — общей отправки нет. |
| RTSP поверх UDP | дороже | Отправка отдельными RTP-пакетами вместо крупных фрагментов. |
| Запись архива | дёшево | На диск дописываются уже упакованные фрагменты, без повторной упаковки и копирования. |
| Второй протокол раздачи | почти бесплатно | Переупаковки нет — только отправка: все протоколы читают одну упаковку. |
Сколько нужно диска под архив
| 100 камер × 2 Мбит/с 7 суток | 2 × 10,8 × 7 × 100 | ≈ 15,1 ТБ |
| 500 камер × 1 Мбит/с 30 суток | 1 × 10,8 × 30 × 500 | ≈ 162 ТБ |
| 8 камер × 4 Мбит/с 14 суток | 4 × 10,8 × 14 × 8 | ≈ 4,8 ТБ |
Один мегабит в секунду записи — это примерно 10,8 ГБ в сутки. Отсюда и формула: битрейт × 10,8 × глубина в сутках × число потоков.
- Ориентир — сотни потоков на логическое ядро
- От 250 потоков на логическое ядро современного процессора и около ста — на логическом ядре пятнадцатилетнего Xeon E5-2620 v1. Точное число зависит от характеристик потоков, поэтому на пилоте его подтверждают на своих источниках.
- Сеть кончается раньше процессора
- Две тысячи зрителей по 4 Мбит/с — это уже 8 Гбит/с исходящего трафика. На реальной установке ограничением обычно становятся полоса и диск, а не ядра.
- Планируйте загрузку не выше 70 %
- Установившаяся загрузка рабочих ядер выше этого порога не оставляет запаса на всплески: переподключения камер, волну зрителей, продление сертификатов.
Порты по умолчанию
Отдельного порта у API, панели и метрик нет: всё это обслуживает тот же слушатель, что и медиа. Выключенный протокол не занимает порт и не открывает сокет.
Слушатели открываются на всех интерфейсах. Для WebRTC нужен ровно один UDP-порт — диапазона портов открывать не нужно.
| Директива | Протокол | По умолчанию | Что обслуживает |
|---|---|---|---|
| http | TCP | 8080 | HLS, LL-HLS, DASH, MSE-WS, HTTP-TS, превью, плеер, REST API, панель, метрики |
| https | TCP | выключен | То же поверх TLS; в примерах — 8443 |
| rtsp | TCP | 8554 | Раздача по RTSP |
| rtsps | TCP | выключен | RTSP поверх TLS; в примерах — 8555 |
| rtmp | TCP | выключен | Приём публикации и раздача по RTMP; в примерах — 1935 |
| rtmps | TCP | выключен | То же поверх TLS; в примерах — 1936 |
| webrtc | UDP | выключен | Медиа WebRTC: WHEP и WHIP. Нужен ровно один порт; в примерах — 40000 |
Панель и REST API
Всё, что делает панель управления, доступно по REST: панель не имеет ни одной привилегии, недоступной вам из командной строки. API живёт на том же слушателе, что и панель, плеер и медиа, — отдельный порт поднимать не нужно.
Всё, что делает панель, — под /api/v1
Полный жизненный цикл потока, зрительские сессии со счётчиками и принудительным отключением, чтение и применение конфигурации с журналом версий и откатом, хранилища, сертификаты, шаблоны настроек, обслуживание архива, состояние кластера.
Весь API описан машиночитаемой спецификацией OpenAPI 3.1: по ней генерируется клиент на вашем языке, без ручного разбора документации.
- Аутентификация
- Потоки
- Сессии
- Конфигурация
- Хранилища
- Сертификаты
- Шаблоны
- VoD
- DVR
- Система и метрики
- Кластер
Три вида доступа
- Сессия администратора
- Любой маршрут и любой метод
- Статический токен записи
- Все методы /api/v1 и метрики
- Статический токен чтения
- Только безопасные методы и метрики
Метрики и журналы
Метрики в формате Prometheus, поток событий SSE, операционный журнал и журнал аудита — теми же учётными данными, без отдельного агента на хосте.
Доступ зрителей — отдельный уровень: токены и JWT проверяются один раз при установлении сессии, дальше каждый сегмент подтверждается коротким билетом. Проверку можно делегировать внешней службе авторизации.
Один файл, один конфиг
Исполняемый файл и текстовая конфигурация — этого достаточно. Нескольких строк хватает, чтобы поток с камеры принимался и раздавался по HLS, RTSP, MSE-WS и WebRTC одновременно.
Действующая лицензия нужна для раздачи: без неё панель и API отвечают, но кадры не отдаются. Ограничение снимается само, как только лицензия появляется.
- Linux x86-64
- Ядро 5.1 и новее, glibc 2.31, systemd. Оборудование общего назначения.
- Без внешних зависимостей
- Ни базы данных, ни брокера сообщений, ни отдельного веб-сервера.
- Изменения на ходу
- Потоки, источники, архив и авторизация применяются перезагрузкой конфигурации; сессии незатронутых потоков не рвутся.
- TLS без прокси
- Сертификаты выпускаются автоматически по ACME. HTTP-слушатель сам отдаёт панель, API и медиа.
- Проверка до перезапуска
- Отдельная команда разбирает конфигурацию и печатает ошибку с номером строки, ничего не запуская.
- Лицензия по числу потоков
- Предел одновременно работающих потоков. Активация онлайн по коду; для закрытого контура — подписанный файл лицензии.
Метка вместо списка
Обычно в каждом токене перечисляют потоки, к которым он допущен. Отсюда две беды: добавили поток — перевыпускай удостоверения, а сама политика расползается по десяткам выданных токенов, и никто уже не помнит, у кого что.
Метки переворачивают порядок. Потоку в конфигурации назначаются произвольные метки, а в токене указывается метка, а не поток. Политику доступа настраивают один раз — и дальше каталог потоков меняется без единого касания уже выданных удостоверений.
- Токен выдаётся на метку
- В удостоверении указывается не список потоков, а метка. Появился новый поток — достаточно поставить ему нужную метку, и он сразу попадает под все уже выданные политики.
- Права в терминах задачи
- Политика описывается словами предметной области — «объект», «клиент», «класс доступа», — а не списком путей.
- Несколько меток на поток
- Один поток может нести сразу несколько меток и попадать в несколько политик одновременно.
- Смысл задаёте вы
- Сервер внутрь метки не заглядывает: он не навязывает ни иерархии, ни схемы именования.
Что спрашивают чаще всего
Десять вопросов из тех, что задают до внедрения. Полный список — в разделе «Вопросы и ответы» документации.
- Сколько потоков держит один сервер?
- От 250 на одно логическое ядро современного процессора; на реальном стенде с пятнадцатилетним Xeon E5-2620 v1 — около ста на логическое ядро. Зрители расход почти не увеличивают: поток упаковывается один раз, раздача добавляет только отправку байтов.
- Нужно ли перевыпускать токены, когда добавляется поток?
- Нет. В токене указывается метка, а не список потоков: новый поток получает нужную метку в конфигурации и сразу попадает под все уже выданные политики.
- Можно ли перекодировать поток на сервере?
- Нет. Нужные профили готовятся на камере или кодировщике: обычно камера отдаёт основной и дополнительный поток, и они заводятся как два источника.
- Кодировщик умеет только сам отправлять поток. Как его принять?
- Источником указывается publish:// и включается слушатель RTMP. Из браузера тот же поток публикуется по WHIP, без установки программ.
- Можно ли раздавать один принятый поток под несколькими именами?
- Да, схемой copy:// — без второго подключения к камере и без повторной упаковки. У такого потока нет своей записи, а права он наследует у оригинала.
- Можно ли не держать камеру подключённой постоянно?
- Да, режимом «по требованию»: поток поднимается с первым зрителем и останавливается через заданное время после последнего. На потоках с записью режим не действует — архив с дырами не имеет смысла.
- Куда девается архив, когда заканчивается место?
- Архив ограничивают три порога: срок хранения, предельный объём на поток и заполненность диска. Самая свежая запись каждого потока не удаляется никогда.
- Я задал пароль администратора. Видео теперь закрыто?
- Нет. Это два независимых замка: пароль закрывает панель и API, а доступ к видео настраивается отдельно. Пока он не настроен, поток смотрит любой, кто знает его имя.
- Можно ли поставить сервер за обратным прокси?
- Можно, но не обязательно: сервер сам умеет HTTPS и автоматический выпуск сертификатов. Если прокси всё же стоит, обязательно перечислите его адреса — иначе все клиенты выглядят как один.
- Как обновить сервер?
- Установщиком новой версии: он заменяет исполняемый файл и оставляет вашу конфигурацию, лицензию и архив нетронутыми.
Проверьте на своём железе
По запросу выдаём демо-лицензию: ставите сервер на своё оборудование, подключаете свои источники и замеряете нагрузку сами. Помогаем с конфигурацией и разбираем цифры вместе — решение вы принимаете по собственным замерам.