mqtt-ingest/app/VIDEO.md

Финальные требования и настройки у нас сейчас такие.

Финальный пресет чанкования ffmpeg (RTSP → MPEG‑TS → stdout)

Мы остановились на сценарии, где ffmpeg:

• тянет RTSP по TCP с камер,
• минимизирует внутреннюю буферизацию и время старта,
• не перекодирует видео (копирует H.264 как есть); если возникнут проблемы с нагрузкой на сеть, можно поискать варианты снизить; но на данном этапе важнее "накормить" видеобуфер воспроизведения хоть чем-нибудь;
• выдаёт результат в stdout (pipe:1), откуда его забирает mqtt транспорт.

Финальный набор аргументов:

[
  '-hide_banner',
  '-fflags', 'nobuffer',          // не буферировать при probe stream info
  '-flags', 'low_delay',          // включить low-delay на уровне декодера
  '-analyzeduration', '100000',   // ограничить анализ потока 100 ms (уменьшить стартовую задержку)
  '-probesize', '32768',          // зондировать только 32 KB (быстрее старт, меньше буфера)
  '-flush_packets', '1',          // сразу сбрасывать пакеты, не копить их внутри muxer'а

  '-rtsp_transport', 'tcp',       // тянуть RTSP по TCP (надёжнее на плохой сети)
  '-i', 'rtsp://admin:admin@192.168.0.11:554/live/sub', // sub-поток камеры

  '-an',                          // отключить аудио — нужен только видеофрейм
  '-c:v', 'copy',                 // не перекодировать видео, просто копировать кадры
  '-f', 'mpegts',                 // контейнер MPEG-TS для дальнейшего трансмультиплексирования
  '-mpegts_flags', 'resend_headers', // периодически повторять заголовки для надёжного декода
  'pipe:1'                        // выводить поток в stdout (дальше забирает твой транспорт)
]

Ключевые моменты:

• -c:v copy сохраняет оригинальный кадр и GOP камеры — минимум задержки и вычислительной нагрузки.
• -fflags nobuffer + -flags low_delay + -flush_packets 1 минимизируют буферизацию и увеличивают «прозрачность» для твоего транспорта.
• -rtsp_transport tcp это про вход (камера → ffmpeg), а pipe:1 — про выход (ffmpeg → mqtt).

---

Финальный пресет воспроизведения (mpegts.js + HTML5 video)

На клиенте мы на данном этапе определяемся работать как с «live‑видео с буфером», а не как с чистым real‑time:

• формат источника: MPEG‑TS/H.264 по WebSocket;
• плеер: mpegts.js, режим type: 'mpegts', isLive: true;
• буфер: небольшой stash + несколько секунд latency для сглаживания провалов.

Финальные параметры инициализации:

const wsUrl = 'wss://...';

const player = mpegts.createPlayer(
  {
    type: 'mpegts',         // MPEG-TS поток по WS
    isLive: true,
    url: wsUrl,
    hasAudio: false,        // видео без аудио
  },
  {
    enableWorker: true,

    // Включаем stash, чтобы сглаживать редкий / рваный поток
    enableStashBuffer: true,
    stashInitialSize: 512,              // немного увеличенный stash для накопления

    autoCleanupSourceBuffer: true,
    autoCleanupMaxBackwardDuration: 10, // держим минимум истории
    autoCleanupMinBackwardDuration: 5,

    // Разрешаем latency-chasing с «комфортной» задержкой
    liveBufferLatencyChasing: true,
    liveBufferLatencyMaxLatency: 5.0,   // целевая задержка до ~5 секунд
    liveBufferLatencyMinRemain: 2.0,    // оставляем ~2 секунды буфера после сброса

    liveSync: false,                    // не пытаемся мягко догонять — приоритет стабильности
    lazyLoad: false,
    deferLoadAfterSourceOpen: false,
  }
);

player.attachMediaElement(document.getElementById('v'));
player.load();
player.play();

Смысл этих настроек:

• Stash‑buffer включён: mpegts.js может аккумулировать некоторое количество данных, прежде чем кормить MSE (браузеру), что хорошо при «дырявом» канале.
• Latency‑chasing с MaxLatency ≈ 5 s: браузер допускает несколько секунд отставания, но не позволяет задержке расти бесконечно; при накоплении лишнего буфера он «подпрыгивает» ближе к live‑позиции, сохраняя MinRemain ~2 секунды запаса.
• liveSync: false — мы не гонимся за минимально возможной задержкой любой ценой, а принимаем небольшой «запас» как разумный компромисс.

При улучшении канала или выполнениии работ по снижению нагрузки на сеть (уменьшения битрейта, fps) нужно грамотно управлять буфером на стороне клиента (stash + latency).