Архитектура

Обзор

ForgeVis забирает поток с каждой камеры один раз и раздаёт его всем потребителям через broadcast-архитектуру. По умолчанию без перекодирования: видео с камеры записывается и раздаётся как есть. Перекодирование включается, только когда зритель выбирает 720p в HLS.

Основные компоненты

┌─────────────┐
│   Камера    │ RTSP/H.264
│  (source)   │────────────┐
└─────────────┘            │
                           ▼
                    ┌──────────────┐
                    │  StreamHub   │
                    │  (broadcast) │
                    └──────────────┘
                           │
                ┌──────────┼──────────┐─────────┐
                ▼          ▼          ▼         ▼
           ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
           │Recorder│ │  RTSP  │ │  RTSP  │ │  HLS   │
           │        │ │Client 1│ │Client 2│ │Client 1│
           └────────┘ └────────┘ └────────┘ └────────┘
               │          │
               ▼          ▼
           ┌────────┐ ┌────────┐
           │  Disk  │ │  HLS   │
           │ (fMP4) │ │Client 2│
           └────────┘ └────────┘

StreamHub

Назначение: Одно подключение к камере, broadcast всем потребителям

Ключевые возможности:

• Одно RTSP подключение на камеру
• Внутренний буфер кадров для плавной раздачи
• Ленивое подключение: старт при первом подписчике
• Idle timeout: отключение через N секунд без подписчиков

Поток данных: Камера → StreamHub → Несколько потребителей (Recorder + RTSP клиенты)

Recorder

Назначение: Запись видео кадров в fMP4 сегменты

Ключевые возможности:

• Фрагментированный MP4 формат
• Настраиваемая длительность сегмента (по умолчанию: 900с = 15 минут)
• Автоматическое переподключение при таймауте/ошибке
• Шаблоны путей с плейсхолдерами

Процесс:

1. Подписка на StreamHub
2. Ожидание ключевого кадра для начала записи
3. Запись видео данных в файл
4. Создание нового файла сегмента каждые N секунд
5. Финализация сегмента при таймауте или ручной остановке

RTSP Сервер

Назначение: Рестриминг камер RTSP клиентам

Ключевые возможности:

• Полная поддержка RTSP протокола
• TCP транспорт для надёжности
• Автоматическая фрагментация пакетов для сетевой эффективности
• Поддержка main + substream (/camera_001 и /camera_001/sub)

Как работает:

• Клиент подключается по RTSP протоколу
• Сервер подписывается на StreamHub для этой камеры
• Видео кадры упаковываются и отправляются клиенту
• Соединение закрывается автоматически при отключении клиента

Поток данных

Путь записи

Камера (RTSP)
  → StreamHub (broadcast)
  → Recorder (подписка)
  → Диск (файлы fMP4 сегментов)

Путь рестриминга

Камера (RTSP)
  → StreamHub (broadcast)
  → RTSP Server (подписка)
  → Клиент (VLC, ffmpeg и т.д.)

По умолчанию без перекодирования

Видео с камеры записывается и раздаётся как есть.

Запись и рестрим:

• ✅ Чтение потока с камеры
• ✅ Запись в файл и раздача клиентам
• ✅ Упаковка для сетевой передачи и в контейнер MP4
• ❌ Декодирование, обработка и кодирование видео
• ❌ Изменение битрейта, разрешения и качества

Результат: минимальная нагрузка на CPU, обработка тысяч камер

Ступень 720p в HLS

Перекодирование включается, только когда зритель выбирает 720p в HLS. Ступень кодирует отдельный процесс ffmpeg с RTSP-рестрима этого же узла, так что запись и остальных зрителей она не касается. Кодер работает, пока ступень смотрят, и одновременно их не больше transcodeMaxConcurrent. Подробнее — в разделе Выбор качества.

Параллельная обработка

• Асинхронная архитектура: Неблокирующие операции для максимальной эффективности
• Задачи на камеру: Каждая камера работает независимо
• Broadcast распространение: Эффективное распределение кадров между потребителями
• Неблокирующий I/O: Сетевые и дисковые операции не блокируют другие камеры

Использование памяти

На камеру (~10 МБ):

• Буфер кадров для плавного распространения
• Минимальные буферы пакетов
• Краткосрочный буфер записи

Для 1000 камер: ~10-12 ГБ RAM всего

Масштабируемость

Узкие места:

1. Сетевой I/O (4 Гбит/с для 1000 камер @ 4 Мбит/с)
2. Дисковый I/O (500 МБ/с запись для 1000 камер)
3. File descriptors (1 сокет на камеру)
4. Память (10 ГБ для 1000 камер)

Решения:

• Несколько 10G NIC или сетевых интерфейсов
• NVMe SSD или RAID для записи на диск
• Увеличить ulimit: ulimit -n 100000
• 32-64 ГБ RAM

Разделение записи и раздачи

Запись и раздачу зрителям можно разнести по разным серверам: камера по-прежнему подключена один раз, а нагрузку от зрителей несёт отдельный сервер.

Сервер записи (origin)

• Подключение к камерам (RTSP)
• Запись на диск (fMP4)
• RTSP-рестрим для сервера раздачи

Сервер раздачи (edge)

• Забирает поток у сервера записи, как у обычной камеры
• Раздаёт зрителям по RTSP, HLS и WebRTC

Преимущества:

• Одно подключение к камере
• Отказоустойчивость (сервер раздачи может падать независимо)
• Масштабируемость (добавление серверов раздачи)

В кластере то же самое делают роли узлов recorder и streamer — см. Кластер.

Пример конфигурации

Сервер записи:

rtsp:
  enabled: true  # для внутреннего рестрима
  port: 8554

cameras:
  camera_001:
    source: "rtsp://camera-ip/stream1"
    record: true  # включить запись

Сервер раздачи:

rtsp:
  enabled: true  # для клиентов
  port: 8554

cameras:
  camera_001:
    source: "rtsp://origin-server:8554/camera_001"  # поток с Origin
    record: false  # только рестриминг