Видеонаблюдение и вещание
на ваших серверах
Для операторов связи, вещателей, интеграторов, предприятий и сервисов видеонаблюдения. Принимайте тысячи камер и потоков, показывайте их тысячам зрителей и храните архив — на своём оборудовании, без облака и без платы за зрителей. От 250 потоков на одно логическое ядро.
- IP-камеры по ONVIF и RTSP, в том числе за NAT — без белого адреса на объекте
- Видеостены в браузере, круглосуточный архив, выгрузка фрагмента файлом
- Доступ операторов к конкретным камерам и журнал всех действий
- Эфир с головных станций, студийных кодировщиков, камер и чужих раздач
- Зрителям на браузеры, телевизоры, приставки и телефоны — всеми протоколами сразу
- Архив эфира, видео по запросу и REST API для вашего кабинета и биллинга
- 250+ потоков
- на одно логическое ядро современного процессора
- до 50 Гбит/с
- трафика с одного сервера
- 10 протоколов раздачи
- из одной упаковки, включать по одному не нужно
- 96 мс
- доставка по RTSP до плеера, измерено
- 0 ₽ за зрителей
- лицензия — по одновременным потокам, зрители и архив не тарифицируются
- 1 сервер
- на тысячи потоков: раньше процессора кончаются сеть и диск
Плотность и полоса зависят от характеристик потоков: битрейта, разрешения и частоты опорных кадров. Доставка измерена на одном стенде и одном источнике — без буфера плеера.
Кому и что это даёт
Шесть типовых задач, под которые ставят платформу. Если ваша рядом, но не совпадает — напишите: скажем прямо, закрывается она продуктом или нет.
Операторы связи и IPTV
Раздать абонентам каналы с головной станции — на приставки, телевизоры, браузеры и телефоны.
Приём MPEG-TS по UDP и multicast или чужой раздачи HLS и DASH, выдача всеми протоколами сразу. Абоненты почти не нагружают процессор: рост аудитории упирается в сеть, а не в число серверов.
Streaming Server →Вещатели и видеоплощадки
Выпустить эфир к зрителям, сохранить его и собрать библиотеку видео.
Публикация со студийного кодировщика по RTMP(S) или прямо из браузера, LL-HLS для низкой задержки и HLS для CDN, архив эфиров и видео по запросу из обычного каталога файлов.
Streaming Server →Интеграторы
Поставить заказчику видео под ключ и связать его с существующими системами.
Камеры и регистраторы по RTSP и ONVIF, просмотр в браузере без плагинов, REST API со спецификацией OpenAPI на каждое действие, установка на серверы заказчика.
Оба продукта →Предприятия и объекты
Дежурная смена следит за территорией, происшествия разбираются по записи.
Видеостены в браузере, круглосуточный архив, переход по событиям и выгрузка фрагмента файлом. Видео и архив остаются в вашей сети.
CCTV →Видеонаблюдение как услуга
Подключать камеры клиентов и продавать им видеонаблюдение как услугу.
Организации-арендаторы с квотами на камеры и пользователей и полностью разделёнными данными. Камеры за NAT подключаются через агент; нагрузка растёт — добавляете узел.
CCTV →Города и управляющие компании
Много объектов, тысячи камер и десятки людей с доступом к разным из них.
Мозаики на пост охраны, доступ к конкретным камерам и действиям — эфир, архив, PTZ, экспорт — и неизменяемый журнал: кто выдал доступ и выгрузил архив.
CCTV →Две задачи — одно ядро
Обе системы построены на общем медиадвижке, поэтому ведут себя одинаково предсказуемо под нагрузкой и настраиваются одними и теми же приёмами.
Медиасервер Sirin Video Streaming Server
Принимает видео по любому распространённому протоколу и раздаёт зрителям всеми сразу. Архив на диск и в объектное хранилище, видео по запросу, REST API.
- Приём
- RTSP, HLS, DASH, MPEG-TS/UDP, RTMP, публикация RTMP и WHIP, файл
- Раздача
- HLS, LL-HLS, HLS-TS, DASH, MSE-WS, HTTP-TS, RTSP, RTMP, WHEP, multicast
- Архив
- Непрерывная запись на диск, холодная копия в S3, экспорт клипа файлом
- Видео по запросу
- Каталог с файлами MP4 играется сразу, без импорта и подготовки
- Масштаб
- Тысячи потоков и тысячи зрителей на одной машине
- Развёртывание
- Один исполняемый файл, один текстовый конфиг, кластер из нескольких серверов
Видеонаблюдение Sirin Video CCTV
Система видеонаблюдения на том же ядре: карточки камер, непрерывный архив, события, видеостены и разграничение доступа операторов.
- Камеры
- ONVIF с автоопределением профилей, прямой RTSP, камеры за NAT через агент
- Просмотр
- MSE-WS и HLS в браузере без плагинов, превью-кадры в списках и мозаиках
- Архив
- Запись на диски узла с глубиной по сроку или объёму, холодная копия в S3
- События
- Системные, ONVIF-события камер, интервальные эпизоды с вложениями
- Доступ
- Организации с квотами, три роли, гранты на камеру, журнал аудита
- Развёртывание
- Управляющий узел и медиаузлы по числу камер, видео идёт мимо управления
Разобрать один раз — раздать всем
Принятый поток разбирается и упаковывается один раз. Все протоколы раздачи читают одну и ту же упаковку, поэтому второй и третий протокол почти ничего не стоят.
- 01 Приём по схеме адреса Способ приёма задаёт схема в начале адреса источника: RTSP, HTTP, UDP, RTMP, публикация, файл.
- 02 Разбор один раз Поток разбирается на кадры один раз — сколько бы протоколов его потом ни отдавало.
- 03 Упаковка один раз Кадры складываются во фрагменты, готовые к отдаче. Перекодирования нет: меняется только контейнер.
- 04 Раздача 10 протоколов Все протоколы читают одну и ту же упаковку, поэтому включать «лишние» не вредно.
- Второй протокол почти бесплатен
- Он не добавляет работы по переупаковке — только отправку. Платить приходится за поток, а не за формат.
- Архив пишется из той же упаковки
- Отдельного разбора «для записи» нет: на диск дописываются уже упакованные фрагменты, без повторной упаковки.
- Медленный зритель не мешает остальным
- Индивидуальных очередей на зрителя нет, поэтому один медленный канал не задерживает остальных.
Приём · схемы источника
| rtsp:// · rtsps:// | Забор с камеры, видеорегистратора или кодировщика | Basic и Digest, транспорт TCP или UDP |
| http:// · https:// | Забор HLS, DASH или непрерывного MPEG-TS | Формат определяется автоматически |
| udp:// · multicast:// | MPEG-TS одноадресный или групповой | Головные станции, IPTV внутри своей сети |
| rtmp:// · rtmps:// | Сервер сам подключается к RTMP-источнику | Источник отдаёт только по RTMP |
| publish:// | Сервер ждёт публикации от источника | Кодировщики по RTMP(S), браузер по WHIP |
| file:// | Локальный файл MP4 по кругу в реальном темпе | Заглушка вместо камеры, проверка конвейера |
| demo:// | Встроенный тест-паттерн с часами | Проверка установки до появления камер |
| copy:// | Второй путь к уже принятому потоку | Ни второго сокета, ни второго разбора |
Раздача · 10 протоколов
| 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 — считаются тем же протоколом. Задержка в таблице — доставка до плеера; итог у зрителя определяет буфер плеера, он разобран ниже в разделе «Задержка».
Выбор протокола решает всё
Итог у зрителя определяет не столько доставка, сколько буфер плеера — запас против неровности сети. Сервер отдаёт поток всеми протоколами сразу, поэтому протокол выбирают под задачу: диспетчеру — доли секунды, массовой раздаче — совместимость и кэши.
- RTSP видеорегистраторы, диспетчерская доли секунды у зрителя · буфер задаёт клиент, обычно минимальный
- MSE-WS видеостены в браузере ≈1 с у зрителя · цель плеера 0,95 с, на Safari — 1,5 с
- LL-HLS массовая раздача с низкой задержкой ≈4 с у зрителя · цель плеера — запас ради плавности
- HLS совместимость и внешние кэши ≈8 с у зрителя · цель плеера — ≈3 сегмента от живого края
доставка до плеера — измерено запас плеера до его целевой задержки
Доставка измерена на одном стенде и одном источнике, настройки по умолчанию; интервал опорных кадров на камере влияет на неё сильнее любой серверной настройки. Итог у зрителя — целевая задержка нашего веб-плеера: она отсчитывается от живого края и уже включает доставку, слои не складываются. Запас выбран ради плавности вместо минимальной цифры и при необходимости снижается настройкой плеера. Шкала логарифмическая — иначе столбец HLS раздавил бы остальные.
- Реакция на событие RTSP · WHEP
- Пост охраны, диспетчерская, поворотная камера под управлением оператора: между действием и картинкой — доли секунды. Буфер задаёт клиент; в браузере ту же роль играет WebRTC.
- Стена в браузере MSE-WS
- Десятки плиток на одном экране без плагинов: обычный вебсокет и готовые фрагменты. У зрителя — около секунды: плеер держит небольшой запас против рывков сети.
- Массовая раздача HLS · LL-HLS
- Тысячи зрителей, любые устройства, кэширование на промежуточных узлах. У зрителя — около восьми секунд, и для этой задачи это норма; LL-HLS — отдельный адрес того же потока, вдвое ближе к эфиру.
- Звук с камеры в браузере WHEP
- Камеры отдают G.711, который браузер не декодирует обычными средствами. WebRTC несёт его штатно, но каждый зритель обходится дороже.
Сотни потоков на логическое ядро
Плотность потоков — то, ради чего платформу выбирают: расход предсказуем и линеен, тысячный поток стоит столько же, сколько первый.
до 50 Гбит/с
с одного сервера Верхняя граница трафика одной машины при достаточной полосе. Как и плотность, зависит от характеристик потоков.
Зрители обходятся почти даром
Вся тяжёлая работа привязана к потоку и не зависит ни от числа зрителей, ни от числа включённых протоколов. Зритель добавляет к ней только отправку байтов, поэтому рост аудитории почти не увеличивает расход процессора.
Отсюда правило подбора: тысяча зрителей одного потока обходится дешевле, чем сто зрителей десяти потоков. Дороже среднего — только шифрованная раздача, WebRTC и RTSP поверх UDP: там работа приходится на каждого зрителя отдельно.
Откуда это берётся
Ядро написано на Rust — современном высокопроизводительном языке. Дальше дело в качестве: выверенный и тщательно протестированный код и архитектура, спроектированная под эту нагрузку с самого начала.
Специальные платы и ускорители не нужны — достаточно сервера общего назначения на Linux x86-64.
Ядро вашего продукта
Кроме двух готовых систем есть третий путь: платформа становится медиаядром собственного сервиса. Приём, раздача, архив и разграничение доступа уже решены и управляются по REST API — вы строите продукт, а не медиасервер.
Собственный VSaaS
Видеонаблюдение как услуга под вашим брендом: подключение камер, запись и раздача уже решены, а кабинет и биллинг вашего сервиса работают поверх REST API.
Медиаядро для ВКС
Платформам видеоконференцсвязи — приём и раздача видео в реальном времени по WebRTC: публикация WHIP из браузера, просмотр по WHEP. Комнаты и логика конференций остаются на вашей стороне.
Стриминговый сервис
Вещание под вашим именем: публикация со студийных кодировщиков и из браузера, раздача HLS и LL-HLS, архив эфиров и библиотека видео по запросу.
Свой продукт
И другие задачи, где внутри сервиса живёт видео. Медиачасть платформа берёт на себя — вашей команде остаются логика, интерфейс и клиенты.
- REST API на каждое действие
- Всё, что делает панель, доступно по API со спецификацией OpenAPI: платформой управляет ваш код, а не руки.
- Встраиваемый плеер
- Готовая страница просмотра без внешних зависимостей встраивается в ваш интерфейс — свой плеер писать не обязательно.
- Метки под вашу модель доступа
- Токен выдаётся на метку, а смысл меток задаёте вы: права описываются словами вашего продукта — «клиент», «объект», «класс доступа».
- Плотность как экономика
- От 250 потоков на одно логическое ядро современного процессора: себестоимость медиачасти сервиса считается заранее и растёт линейно.
Что вы получаете
Комплект самодостаточен: ставится на чистый Linux и работает без внешних служб. Ничего не нужно докупать и нечего собирать из частей.
Обновление — установщиком новой версии: он заменяет исполняемый файл и оставляет конфигурацию, лицензию и архив нетронутыми.
- Исполняемый файл
- Один бинарный файл и юнит systemd. Ни базы данных, ни брокера, ни отдельного веб-сервера.
- Установщик с проверками
- Сверяет версию ядра, glibc, systemd и окружение; если что-то не сходится — останавливается и называет точную причину.
- Шаблон конфигурации
- Готовый рабочий файл и настройки сетевого стека хоста, которые установщик кладёт сам.
- Панель управления
- Веб-интерфейс на том же порту: потоки, сессии, конфигурация, хранилища, сертификаты, журнал.
- REST API и метрики
- Полноценный REST API: всё, что делает панель, доступно по API. Спецификация OpenAPI 3.1, метрики Prometheus, поток событий, журнал аудита.
- Доступ по меткам
- Токен выдаётся на метку, а не на список потоков: новый поток получает метку и сразу попадает под уже выданные политики.
- Встраиваемый плеер
- Страница просмотра без внешних зависимостей: ни библиотек с чужих сайтов, ни шрифтов, ни счётчиков.
- Документация
- Открыта целиком и до покупки: конфигурация, протоколы, доступ, архив, API, эксплуатация.
- Скрипт удаления
- Обратная операция для установщика: система удаляется так же предсказуемо, как ставится.
Своя установка или облачный сервис
Мы делаем только первое, поэтому сравнение — по существу, а не в свою пользу. Облачный сервис выигрывает, когда нет своей инфраструктуры и администратора; всё остальное ниже.
Подход проверен на себе: платформе почти семь лет, и до выхода на рынок она годами работала во внутренних установках группы компаний — история продукта.
| Что сравниваем | Установка на своих серверах | Облачный сервис |
|---|---|---|
| Где лежит видео | В вашем контуре: приём, хранение и раздача не выходят за периметр | У поставщика услуги, вне вашего управления |
| От чего зависит цена | От числа одновременных потоков; зрители и часы записи не тарифицируются | Обычно от трафика, часов хранения и числа зрителей |
| Связь с интернетом | Медиасервер работает и в сети без выхода наружу: лицензия проверяется файлом | Обязательна постоянно |
| Доставка видео | Один сетевой участок внутри вашей сети — измеренные 96 мс по RTSP | Плюс путь до внешней площадки и обратно |
| Кто владеет архивом | Ваши диски и ваше объектное хранилище, доступ по вашим правилам | Условия и сроки диктует договор с поставщиком |
| Что при отказе поставщика | Установка продолжает работать: обновления и поддержка отдельны от эксплуатации | Сервис прекращается вместе с договором |
Не только конфигурационный файл
Медиасервер этого класса обычно настраивают файлом, а проблемы разбирают по журналам. Файл никуда не делся — его любят администраторы и системы автоматизации, — но рядом есть полноценный интерфейс, в котором видно состояние и можно менять настройки.
Инцидент разбирается в браузере, а не по журналам, собранным с нескольких машин. Настройку можно поручить человеку, который не живёт в конфигурационных файлах.
Это встроенная диагностика конкретного сервера, а не система мониторинга предприятия: для внешнего сбора отдаются метрики Prometheus и поток событий.
- Состояние каждого потока
- Идёт ли приём, кодеки и разрешение, битрейт, время непрерывной работы, число переподключений и текст последней ошибки источника.
- Живые сессии зрителей
- Кто смотрит прямо сейчас, каким протоколом и сколько ему отдано.
- Ресурсы процесса и хоста
- Процессор и память — видно, во что упирается сервер, до того как это заметит зритель.
- Журнал с поиском
- Прямо в интерфейсе: разбор инцидента не требует захода на сервер по SSH.
- Правка с проверкой до применения
- Ошибочная правка не принимается и ничего не меняет — вместо того чтобы уронить службу.
- История конфигурации с откатом
- Видно, что и когда менялось, и можно вернуться к прежней версии.
Что спрашивают чаще всего
Девять вопросов, которые задают до покупки. Полные ответы — в разделах «Вопросы и ответы» обеих документаций.
- Нужны ли база данных, брокер сообщений или отдельный веб-сервер?
- Медиасерверу — нет: один исполняемый файл и один текстовый файл конфигурации. Управляющему узлу видеонаблюдения нужна PostgreSQL, и установщик ставит и настраивает её сам.
- Нужно ли включать протоколы раздачи по одному?
- Нет. Поток упаковывается один раз, и все протоколы читают одну и ту же упаковку, поэтому HLS, DASH, MSE-WS и RTSP доступны сразу. Отдельно включаются только варианты на основе MPEG-TS и групповая раздача.
- Сколько потоков потянет один сервер?
- От 250 потоков на одно логическое ядро современного процессора; на реальном стенде с пятнадцатилетним Xeon E5-2620 v1 — около ста на логическое ядро. Счёт на хост идёт на тысячи, и процессор среди ограничителей обычно последний: раньше упрётесь в лицензию, сеть или диск.
- Нужно ли перевыпускать токены, когда добавляется новый поток?
- Нет. В токене указывается метка, а не список потоков: новый поток получает нужную метку в конфигурации и сразу попадает под все уже выданные политики. Один поток может нести несколько меток и попадать в несколько политик сразу.
- Что происходит при обрыве связи с камерой?
- Сервер переподключается сам, зрители при этом не отключаются: и зрительские сессии, и запись переживают переподключение. Резервные источники задаются повторением строки в описании потока, переход между ними идёт без паузы.
- Почему у потока нет звука в браузере?
- Большинство камер выдают звук G.711, и ни один браузер не декодирует его через Media Source Extensions — это ограничение браузеров. Звук слышен по WebRTC, по RTSP вне браузера и в выгруженном из архива файле.
- Можно ли скачать кусок архива одним файлом?
- Да. Запрос интервала возвращает готовый MP4 без перекодирования, интервал может пересекать границы файлов записи — сервер склеивает их в один файл со сквозной шкалой времени.
- Правки через панель и правки в файле не поссорятся?
- Нет: панель и API пишут в тот же самый файл конфигурации — это один источник истины. Комментарии при этом сохраняются, а файл можно заблокировать от изменений через API.
- Что будет, если конфигурация окажется ошибочной?
- Работающий сервер продолжает раздавать видео: отвергнутое обновление не меняет ничего. Файл проверяется отдельной командой до перезапуска, а вернуться можно к любой из 32 последних версий.
Проверьте на своих потоках
По запросу выдаём демо-лицензию: ставите на своё оборудование, подключаете свои источники и снимаете показатели сами — до того, как примете решение. Помогаем с настройкой и разбираем результаты вместе.