Известные ограничения и архитектурные компромиссы
Для обеспечения экстремально высокой плотности потоков, плоского расхода памяти и простоты единого бинарного файла в RUSEON Core заложены осознанные инженерные компромиссы.
1. Граница концепции Zero-Transcoding
- Ограничение: RUSEON Core не выполняет транскодирование пикселей на сервере (например, конвертацию H.265 в H.264 или даунскейлинг 4K в 720p).
- Обоснование: Декодирование пикселей на CPU сжигает вычислительные ресурсы и не позволяет обслуживать 600+ камер на стандартном сервере.
- Решение: Настройка мультипоточности на камерах (Основной поток для качественного архива; Дополнительный Sub-Stream для мультиэкранной сетки).
2. Поддержка кодеков в браузерах и фоллбек WebCodecs
- Ограничение: Некоторые браузеры не поддерживают нативный H.265 в WebRTC.
- Решение: RUSEON Core предоставляет бинарный WebSocket-стрим WebCodecs (
GET /stream/ws/:id), позволяющий декодировать H.265 на стороне браузера через аппаратный API WebCodecs.
3. Ограничения аудиопотоков
- Ограничение: Стандарт WebRTC требует аудио Opus или G.711. Устаревшие форматы G.726 или MP2 не воспроизводятся в браузере без транскодирования.
- Решение: Выбор формата AAC (48 кГц) или PCMA/PCMU (G.711) в настройках камеры.
4. Локальная база данных (BadgerDB v4)
- Ограничение: BadgerDB — локальная встраиваемая LSM-база данных, а не распределенный кластер.
- Решение: При масштабировании свыше 600 камер используется шардирование по камерам за единым балансировщиком Nginx/HAProxy.
5. Оптимизации ядра Linux
- Ограничение: Сброс страниц (
POSIX_FADV_DONTNEED) и сетевой батчинг (sendmmsg) используют системные вызовы ядра Linux. - Поведение на Windows / macOS: RUSEON Core автоматически переключается на стандартный буферизованный I/O и одиночные UDP-вызовы с сохранением полной функциональности.