Логотип RUSEON Core

RUSEON Core

Высокопроизводительная видеоинфраструктура и движок медиаконвейера для систем ИИ
Open-Source Медиасервер • RTSP-шлюз • WebRTC (WHEP) • fMP4 Видеоархив • NVR/VMS Бэкенд • gRPC Стриминг для ИИ

Статус CI Go Report Card Последний релиз Базовый бенчмарк Лицензия

Читать на других языках: English, Русский.

--- ## Что такое RUSEON? **RUSEON Core** — это высокопроизводительный open-source движок видеоинфраструктуры и медиасервер на языке Go, спроектированный для парков IP-камер, систем видеонаблюдения (CCTV), периферийных вычислительных узлов (Edge) и конвейеров компьютерного зрения. Он выступает единым легковесным бэкендом потокового видео: принимает видеопотоки H.264 и H.265 от IP-камер по протоколу RTSP (TCP/UDP) и напрямую в оперативной памяти мультиплексирует их в форматы с низкой задержкой WebRTC (WHEP), HLS (fMP4/TS), WebSocket (WebCodecs Canvas), непрерывный локальный видеоархив fMP4 и высокоскоростной gRPC-поток видеокадров для инференса моделей ИИ в реальном времени. ### Для кого разработан RUSEON? * **Инженеры видео- и медиаинфраструктуры:** Построение масштабируемых сервисов ретрансляции RTSP, WebRTC-шлюзов и низколатентной доставки видео. * **Разработчики VMS и NVR:** Создание собственных или облачных систем видеонаблюдения, бэкендов записи CCTV и платформ управления IP-камерами. * **Команды компьютерного зрения и ИИ:** Интеграция видеоаналитики в реальном времени, детекции объектов и конвейеров нейросетевого инференса с быстрым извлечением кадров. * **Архитекторы Edge- и IoT-решений:** Развертывание локальных (on-premise) узлов обработки видео и медиасерверов для встраиваемых Linux-устройств с жесткими ограничениями по CPU и памяти. ### Чем RUSEON отличается от обычных медиасерверов и NVR? Традиционные медиасерверы обычно ориентированы исключительно на ретрансляцию видеопотоков или требуют ресурсоемкого серверного транскодинга, сильно ограничивающего плотность потоков. Классические NVR/VMS системы нередко представляют собой монолитные решения, перегружающие CPU и страдающие от деградации системного дискового кэша ОС при непрерывной 24/7 записи. RUSEON Core работает строго на базе **трансмуксинга без транскодинга** и **неблокирующего кольцевого буфера единого распределения**, являясь инфраструктурным ядром для взаимодействия IP-камер с браузерами, дисковыми хранилищами и сервисами ИИ. --- ## Почему RUSEON? * **Архитектура трансмуксинга (без транскодинга):** Видеопакеты парсятся на уровне NALU и перепаковываются в контейнеры, запрошенные клиентами (fMP4, TS, RTP), напрямую в оперативной памяти без декодирования и попиксельной перекодировки на CPU. * **Неблокирующее распределение через единый буфер:** Входящие кадры записываются один раз в ограниченный lock-free кольцевой буфер каждого потока. Все потребители (паковщик HLS, модуль WebRTC, архиватор fMP4, экстракторы кадров gRPC) читают данные из буфера конкурентно без создания дублирующих копий кадров в оперативной памяти. * **Изоляция медленных клиентов (Slow Consumers):** Индивидуальные каналы чтения изолируют отстающих клиентов и сетевые просадки. Если потребитель не успевает считывать данные, кадры сбрасываются исключительно для этого клиента, не блокируя основной движок приема, других зрителей CCTV и процесс записи. * **Управление дисковым кэшем ОС при потоковой записи 24/7:** Встроенный архиватор fMP4 оптимизирует дисковые операции на Linux через системные вызовы ядра (`posix_fadvise(FADV_DONTNEED)` и скользящее окно `sync_file_range`), предотвращая вымывание системного дискового кэша ОС (Page Cache) при непрерывной записи видео. * **Отказоустойчивое фрагментированное хранилище fMP4:** Видеоархив сохраняется в виде независимых фрагментов MP4 (`moof` + `mdat`) с индексными файлами ключевых кадров (`.idx`). Незавершенные записи остаются полностью воспроизводимыми даже при аварийном отключении питания. * **Отказоустойчивое встроенное состояние:** Конфигурация, метаданные камер, папки, теги и учетные записи пользователей сохраняются во встроенной NoSQL-СУБД BadgerDB с синхронным журналом предзаписи (`SyncWrites = true`), а при старте сервера выполняется процедура восстановления незавершенных файлов архива (`RecoverCrashedFiles`). * **Синхронизация метаданных ИИ в реальном времени:** Видеокадры, передаваемые через серверный gRPC-стриминг, поступают во внешние воркеры компьютерного зрения (YOLO, кастомные сервисы инференса), а входящие метаданные детекций (bounding boxes, телеметрия) синхронизируются с таймлайном видео и транслируются клиентам через WebRTC DataChannels, дорожки HLS WebVTT, MQTT-брокеры и Webhooks. * **Прозрачная эксплуатация и мониторинг:** Нативная поддержка метрик Prometheus, детерминированные пробы `/livez` и `/readyz`, отражающие реальную готовность подсистем, и структурированное JSON-логирование. --- ## Сценарии использования (Use Cases) * **Бэкенд для self-hosted NVR и VMS:** Высокоплотный прием видеопотоков, непрерывная запись 24/7 во фрагментированный MP4, таймлайн-индексация и стриминг для собственных систем видеонаблюдения и управления IP-камерами. * **Шлюз RTSP → WebRTC для IP-камер:** Прием RTSP-потоков от парка камер и раздача живого видео с субсекундной задержкой напрямую в браузеры через WebRTC (WHEP) и WebCodecs (WebSocket). * **Периферийная видеоинфраструктура (Edge Video):** Легковесный локальный медиасервер для промышленных контроллеров, ARM-микрокомпьютеров и edge-серверов с предсказуемым потреблением CPU и оперативной памяти. * **Конвейеры компьютерного зрения и ИИ-аналитики:** Высокоскоростное извлечение кадров через gRPC (`StreamFrames`) для нейросетевых моделей (YOLO, TensorRT, PyTorch) с обратной синхронизацией метаданных детекций на клиенты. * **Архив видеонаблюдения и навигация по таймлайну:** Хранение надежного видеоархива с автоматической очисткой по сроку хранения, быстрый поиск по ключевым кадрам (`.idx`) и виртуальное воспроизведение HLS без дублирования файлов. * **Мультипротокольная ретрансляция потоков:** Параллельная раздача видеопотока клиентам HLS, зрителям WebRTC и плееру на Canvas/WebSocket с одновременной отправкой событий в брокер MQTT и вебхуки. --- ## Ключевые возможности * **Высокоплотный прием RTSP:** Прием потоков H.264 и H.265 по TCP или UDP с ограничением конкурентных подключений к камере, контролем keep-alive и механизмом переподключения с джиттером. * **Субсекундный WebRTC (WHEP):** Воспроизведение H.264 видео с ультранизкой задержкой на базе движка Pion WebRTC через единый UDP-мультиплексор с пакетной отправкой `sendmmsg`. * **Отдача HLS для прямого эфира и архива:** Потоковое вещание fMP4 и MPEG-TS с дедупликацией генерации master-плейлистов через singleflight и синхронизированными дорожками WebVTT. * **Низколатентный WebCodecs и WebSocket:** Передача бинарных NALU через WebSocket (`/stream/ws/:id`) для аппаратного рендеринга H.264 и H.265 на клиенте через WebCodecs и HTML5 Canvas. * **Архивация fMP4 и управление хранением:** Непрерывная сегментированная запись во фрагментированный MP4 с контролем Page Cache ядра Linux, автоматической очисткой архива и перемоткой по таймлайну через `.idx`. * **gRPC-конвейер для ИИ-видеоаналитики:** Серверный стриминг видеокадров (`StreamFrames`) и клиентский стриминг для приема аналитических метаданных (`PushMetadata`). * **Диспетчеризация событий и IoT:** Публикация событий детекций ИИ и телеметрии в брокеры MQTT (v3.1.1/v5.0) и отправка исходящих HTTP-вебхуков с защитой Circuit Breaker. * **Встроенный веб-интерфейс:** Дашборд на React 19 и TypeScript для просмотра мультикамерных сеток, управления камерами, тегами и навигации по архиву. * **Аутентификация и ролевая модель (RBAC):** Контроль доступа на базе JWT с разделением ролей (`Admin`, `Operator`, `Viewer`, `Service`) и изолированными токенами воспроизведения. --- ## Архитектура В RUSEON Core входящие RTSP-пакеты после демультиплексирования попадают в изолированный кольцевой буфер `RingBuffer`. Независимые воркеры конкурентно считывают кадры для обслуживания подключенных протоколов, модулей хранения и потребителей аналитики ИИ. ```mermaid flowchart TD CAM["IP-камеры / RTSP-источники
(H.264 / H.265)"] -->|RTSP TCP/UDP| INGEST["Движок приема RTSP
(gortsplib)"] INGEST --> NALU["Парсер NALU и демуксер"] NALU --> RING["Lock-Free RingBuffer
(Кольцевой буфер в RAM)"] RING --> HLS["HLS Муксер
Упаковка fMP4 / TS"] RING --> WEBRTC["Движок WebRTC
Pion WHEP / H.264 RTP трек"] RING --> WS["Движок WebSocket
Бинарный поток NALU"] RING --> RECORDER["fMP4 Архиватор
Потоковый ввод-вывод (Linux PageCache)"] RING --> GRPC["gRPC Сервер
Извлечение кадров (StreamFrames)"] HLS --> CLIENT_HLS["Браузеры и HLS-плееры"] WEBRTC --> CLIENT_RTC["Клиенты с низкой задержкой (WebRTC)"] WS --> CLIENT_WS["Плееры WebCodecs / Canvas"] RECORDER --> DISK["Локальное хранилище архива
(Сегменты MP4)"] GRPC <--> AI_WORKER["Воркеры компьютерного зрения
(Прием кадров и пуш метаданных)"] AI_WORKER --> BUS["Диспетчер метаданных"] BUS --> WEBRTC BUS --> HLS BUS --> MQTT_WH["Диспетчер MQTT и Webhooks"] ``` ### Поток данных ИИ-инференса и метаданных ```text RTSP-поток с камеры ↓ Прием RTSP в RUSEON ↓ Парсинг NALU и RingBuffer ↓ gRPC-стриминг кадров (StreamFrames) ↓ Внешний воркер компьютерного зрения / нейросеть (YOLO / TensorRT) ↓ gRPC-прием метаданных (PushMetadata) ↓ Диспетчер метаданных (Metadata Broadcaster) ↓ WebRTC DataChannels | HLS WebVTT | MQTT-события | HTTP Webhooks ``` Подробное описание архитектуры доступно в разделе [Архитектура и системный дизайн](https://docs.ruseon.tech/architecture/system). --- ## Результаты нагрузочного тестирования Приведенные показатели получены в ходе непрерывного **8-часового стресс-теста на стабильность** при высокой конкурентной нагрузке на 12-ядерном хосте. ### Воспроизводимый базовый профиль (8 часов непрерывного теста) | Подсистема | Метрика | Фактический результат | Эксплуатационные характеристики | | :--- | :--- | :--- | :--- | | **Входящий поток (Ingest)** | Суммарный FPS видео | **18 180.4 FPS** (1 342.9 Mbps) | 600 одновременных камер @ 30 FPS, `0` потерянных кадров (обработано 523.6 млн кадров) | | **Отдача HLS** | Отдано сегментов | **501.9 MB/s** (17 625 404 сегмента) | 1 800 активных зрителей, передано `15.1 ТБ` (`p50: 3.59 ms`, `p95: 211.2 ms`) | | **REST API Роутер** | Пропускная способность | **459.9 RPS** (13 244 819 запросов) | 10 воркеров, 100% OK (`0` ошибок, `p50: 0.59 ms`, `p95: 8.52 ms`, `p99: 28.74 ms`) | | **WebRTC (WHEP)** | Поток RTP-пакетов | **2 439 152 пакета** (2.83 ГБ передано) | 240 одновременных пир-соединений, `0` ошибок сессий (`p50: 390.3 ms` хэндшейк) | | **gRPC ИИ-конвейер** | Передача кадров и метаданных | **18 180.4 FPS** / **1 993.2 RPS** | 20 ИИ-воркеров, передано 523.6 млн кадров (`p50: 28.45 ms` задержка доставки) | | **EventBus** | Доставка событий | **11 042 761 событие** | `0` потерянных событий зафиксировано в ходе данного теста | | **Память процесса** | Системный футпринт | **707 MB RSS** (95 MB Heap Alloc) | 348 активных горутин на момент завершения (детерминированное освобождение воркеров) | | **Сборка мусора (GC)** | Паузы рантайма Go | **1.03 ms средняя пауза** (пик 7.69 ms) | 154 969 циклов GC за 8 часов при сетевом трафике свыше 500 MB/s | ### Методология бенчмарка и область измерений * **Конфигурация хоста:** 12-ядерный процессор (`num_cpu: 12`, архитектура x86_64). * **Длительность теста:** 28 800.12 секунд (8.0 непрерывных часов). * **Параметры нагрузки:** 600 синтетических RTSP-камер (720p @ 30 FPS, 2.24 Mbps на поток, GOP = 30), 1 800 HLS fMP4 плееров, 240 WebRTC WHEP сессий, 20 gRPC воркеров аналитики, 10 параллельных REST API воркеров. * **Режим диска:** Стресс-тест выполнялся с эмуляцией дискового ввода-вывода (`real_disk: false`) для изоляции и измерения производительности CPU, RAM, сетевого стека и трансмуксинга независимо от лимитов физических дисковых массивов. * **Совместное размещение (Co-Location):** Генератор нагрузки (`cmd/loadtest`) и сервер RUSEON Core работали совместно на одном 12-ядерном хосте через loopback (`127.0.0.1`), активно конкурируя за кванты планировщика ОС, пропускную способность памяти и сетевой стек ядра на протяжении всего теста. 👉 **[Полный отчет о нагрузочном тестировании и сырые данные](bench-results/bench-baseline.md)** --- ## Быстрый старт ### 1. Запуск в Docker Запустите контейнер RUSEON Core с постоянными томами для данных и записей (доступен в Docker Hub и GitHub Container Registry): ```bash # Из Docker Hub: docker run -d \ --name ruseon-core \ -p 8080:8080 \ -p 8555:8555/udp \ -p 50051:50051 \ -v ruseon_data:/app/data \ -v ruseon_recordings:/app/recordings \ rusegal/ruseon-core:latest # Либо из GitHub Container Registry (GHCR): # docker run -d ... ghcr.io/rusegal/ruseon-core:latest ``` При первом запуске RUSEON Core автоматически инициализирует базу данных, генерирует надежный пароль администратора и выводит его в журнал контейнера: ```bash docker logs ruseon-core | grep "INITIAL ADMIN PASSWORD" ``` ### 2. Вход в дашборд Откройте адрес `http://localhost:8080` в браузере. Данные для входа: * **Логин:** `admin` * **Пароль:** *(Пароль, сгенерированный в логах контейнера)* ### 3. Добавление IP-камеры через REST API Потоки камер регистрируются и настраиваются динамически в рантайме без перезагрузки сервера: ```bash # 1. Получение JWT-токена TOKEN=$(curl -s -X POST http://localhost:8080/api/login \ -H "Content-Type: application/json" \ -d '{"username":"admin","password":"ВАШ_ПАРОЛЬ_АДМИНИСТРАТОРА"}' | jq -r .token) # 2. Регистрация RTSP-потока камеры curl -X POST http://localhost:8080/api/cameras \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "id": "cam-front-door", "url": "rtsp://camera.local:554/live/ch0", "record": true, "retention_days": 7 }' ``` --- ## Системные требования * **Целевая среда Production:** Linux (`amd64` / `arm64`), рекомендуется Kernel $\ge$ 5.4 для поддержки системных вызовов `sync_file_range` и `fadvise`. * **Разработка и локальное тестирование:** macOS и Windows поддерживаются через стандартные драйверы файлового ввода-вывода. * **Среда выполнения:** Docker $\ge$ 20.10, либо бинарный запуск (компиляция на Go $\ge$ 1.24). * **Сетевые порты:** * `8080/tcp` — HTTP REST API, HLS-стриминг, сигнальный протокол WHEP, WebCodecs WebSocket, Web UI, Метрики. * `8555/udp` — мультиплексор медиапотоков WebRTC Pion (настраивается параметром `server.webrtc.listen_port`; если не задан, Pion использует стандартное динамическое выделение портов для ICE-кандидатов). * `50051/tcp` — интерфейс gRPC для ИИ-аналитики (настраивается параметром `server.grpc.port`). * **Дисковая подсистема:** Рекомендуется выделенный SSD/NVMe при непрерывной записи 50+ параллельных потоков. --- ## Эксплуатация в Production При развертывании RUSEON Core в промышленной среде рекомендуется следовать следующим практикам: * **Постоянные тома:** Смонтируйте `/app/data` на надежный диск (хранилище BadgerDB). Смонтируйте `/app/recordings` на емкий массив, оптимизированный для последовательной записи. * **Настройка WebRTC:** Задайте параметр `server.webrtc.nat_1_to_1_ips` с указанием внешнего IP-адреса хоста или балансировщика, и обеспечьте прямую доступность UDP-порта `8555` без симметричной трансляции NAT. * **TLS и Reverse Proxy:** Завершайте TLS-соединения (HTTPS) на внешнем прокси (NGINX, Envoy, Traefik) или настройте TLS в `config.yaml`. Безопасный контекст (`https://`) является обязательным требованием браузеров для работы WebRTC. Полное руководство по развертыванию доступно в [Руководстве по эксплуатации](https://docs.ruseon.tech/deployment/overview). --- ## Мониторинг и наблюдаемость (Observability) RUSEON Core предоставляет стандартные интерфейсы для мониторинга и интеграции с системами оркестрации: * **Проба живучести (`GET /livez`):** Подтверждает, что HTTP-сервер активен и обрабатывает сетевые запросы. * **Проба готовности (`GET /readyz`):** Выполняет проверку доступности базы BadgerDB, прав записи в каталог видеоархива и состояния менеджера потоков. Возвращает `503 Service Unavailable`, если ключевые компоненты не готовы. * **Метрики Prometheus (`GET /metrics`):** Экспорт метрик рантайма, битрейтов потоков, числа активных зрителей, потерь пакетов и дискового ввода-вывода. * **Профилирование Go (`GET /debug/pprof/*`):** Доступ к профилированию рантайма (активируется параметром `server.pprof_port`). --- ## Модель безопасности * **Аутентификация:** Все вызовы REST API и потоки защищены криптографически подписанными токенами HS256 JWT. * **Хранение учетных записей:** Пароли пользователей хешируются с использованием bcrypt перед сохранением в BadgerDB. * **Изоляция токенов:** Токены воспроизведения потоков (`?token=`) содержат клейм `stream_id` и строго изолированы от прав доступа к управляющему REST API. * **Ролевая модель доступа (RBAC):** Эндпоинты API проверяют роли пользователей (`Admin`, `Operator`, `Viewer`, `Service`) через middleware. * **Статический аудит:** Конвейер CI контролирует отсутствие замечаний `golangci-lint` и выполняет автоматическое сканирование уязвимостей через `gosec`. Правила сообщения об уязвимостях описаны в [SECURITY.md](SECURITY.md). --- ## Совместимость и поддерживаемые стандарты | Протокол / Компонент | Поддержка на приеме (Ingest) | Поддержка на отдаче (Clients) | Примечания | | :--- | :--- | :--- | :--- | | **RTSP** | H.264, H.265 (TCP / UDP) | — | Ограничение конкурентных подключений к источнику | | **HLS** | — | fMP4, MPEG-TS | H.264 / H.265 сквозная передача; воспроизведение зависит от поддержки кодека клиентом/браузером | | **WebRTC (WHEP)** | — | H.264 (`webrtc.MimeTypeH264`) | Субсекундное вещание через движок Pion WebRTC | | **WebSocket** | — | Бинарный поток NALU | Клиентский плеер WebCodecs / HTML5 Canvas (H.264 и H.265) | | **Хранилище архива** | — | Фрагментированный MP4 (fMP4) | Локальная файловая система с управлением кэшем POSIX | | **Интеграция с ИИ** | `PushMetadata` (gRPC) | `StreamFrames` (gRPC) | Серверный стриминг кадров и клиентский прием метаданных | | **IoT и события** | — | MQTT v3.1.1 / v5.0, Webhooks | Ограниченные асинхронные очереди с Circuit Breaker | | **Встроенная база данных** | — | BadgerDB v4 | Pure Go LSM-дерево с WAL (`SyncWrites = true`) | --- ## Документация Официальная документация проекта доступна по адресу **[docs.ruseon.tech](https://docs.ruseon.tech/)**: * [Руководство по быстрому старту](https://docs.ruseon.tech/guide/introduction) * [Справочник конфигурации](https://docs.ruseon.tech/reference/configuration) * [Архитектура и потоки данных](https://docs.ruseon.tech/architecture/overview) * [Настройка стриминга и WebRTC](https://docs.ruseon.tech/streaming/overview) * [Архивация и подсистема Smart I/O](https://docs.ruseon.tech/archive/overview) * [Спецификация REST API](https://docs.ruseon.tech/api/overview) * [Развертывание в Production](https://docs.ruseon.tech/deployment/overview) * [Диагностика и устранение неполадок](https://docs.ruseon.tech/troubleshooting/overview) --- ## Известные ограничения * **Отсутствие серверного перекодирования:** RUSEON Core работает исключительно по принципу трансмуксинга без декодирования видео. Если камеры вещают в кодеках, не поддерживаемых браузером клиента (например, H.265 в старых мобильных браузерах), воспроизведение выполняется через встроенный клиентский плеер WebCodecs/Canvas либо требует внешнего транскодера. * **Кодек отдачи WebRTC:** Отдача видео по WebRTC WHEP в текущей реализации поддерживает упаковку треков H.264. Потоки, принятые в H.265, могут воспроизводиться через HLS, WebSocket/WebCodecs или архивироваться в fMP4, но для вещания через WebRTC WHEP требуется входной поток H.264. * **Локальное дисковое хранилище:** Редакция Community Edition предназначена для работы с локальными дисками и массивами хоста. Интерфейсы хранилища (`BlobStore`, `StateStore`) формируют границы абстракции для будущих распределенных бэкендов. * **Ограниченные очереди метаданных:** Очереди публикации метаданных ИИ и сообщений MQTT являются ограниченными. При зависании внешних потребителей или брокеров переполненные очереди сбрасывают новые метаданные во избежание блокировки основного видеопотока. Дополнительные детали описаны в разделе [Известные ограничения](https://docs.ruseon.tech/reference/known-limitations). --- ## Статус проекта и коммерческая поддержка RUSEON Core Community Edition — это проект с открытым исходным кодом, распространяемый под лицензией MIT. Архитектура проекта определяет интерфейсы (такие как `BlobStore` и `StateStore`), рассчитанные на интеграцию дополнительных бэкендов хранения, аутентификации и отказоустойчивости. Коммерческие расширения и корпоративные внедрения развиваются отдельно. > По вопросам коммерческого внедрения, лицензирования и корпоративной поддержки: [rusegal.dev@yahoo.com](mailto:rusegal.dev@yahoo.com) --- ## Участие в разработке (Contributing) Мы приветствуем вклад сообщества в развитие проекта: 1. Ознакомьтесь с [CONTRIBUTING.ru.md](CONTRIBUTING.ru.md) перед началом работы (целевая ветка разработки — `dev`). 2. Соблюдайте [Кодекс поведения (Code of Conduct)](CODE_OF_CONDUCT.md). 3. Убедитесь, что все тесты и статические анализаторы проходят успешно: ```bash go test -v -race ./... golangci-lint run ./... ``` --- ## Лицензия RUSEON Core (Community Edition) распространяется под лицензией [MIT License](LICENSE).