Раздача mjpeg-потока через nginx

Когда-то давно я решал подобную задачу при помощи кеширования потока через VLC. Т.е. VLC принимает поток через одно подключение, буферизирует, если нужно то перекодирует и отдает множеству клиентов. Возможно подобное можно реализовать на чистом ffmpeg.

Кроме размножения желательно ещё перекодировать mjpeg в что-то более эффективное, например x264. Это делается ffmpeg-ом со всякими обёртками разной степени сложности, как выше написали.

Спросим профессионала, sudo cast max_lapshin

один фиг втыкать нормальный стриминговый сервер, так что надо конечно не издеваться над живыми людьми, а проявить чуточку заботы, поставить рестример и гонять h264, который в 10 раз меньше весит.

mjpeg —  это что-то такое для тех мест, где пофиг на канал и на государственный бюджет для обработки видео.

А как я h264 открою в браузере? Я использую mjpeg только потому что могу его встроить в страницу без костылей.

mjpeg — это один большой костыль. Это реально в 10 раз больше трафика, чем h264.

h264 — это hls,dash,cmaf,ll-hls, websocket (всё это mse) или webrtc.

Вы предлагаете использовать что-то вроде https://github.com/AlexxIT/go2rtc#go2rtc-docker ?

У MJPEG есть киллер-фича — там один кадр никак не влияет на соседние, может пригодиться для передачи по плохому каналу или для покадрового анализа ситуации на видео. Но да, если ТСу это в явном виде не нужно, лучше взять кодек прсовременнее.

может пригодиться для передачи по плохому каналу или для покадрового анализа ситуации на видео

H264 прекрасно решает задачу покадрового анализа ситуации на видео, а MJPEG и плохой канал — это просто нелепо даже обсуждать рядом.

Ещё раз для невнимательных: MJPEG минимум в 10 раз жирнее аналогичного по качеству H264. В некоторых случаях разница может быть и в 100+ раз.

О каком плохом канале вообще может идти речь?

Единственная киллер фича mjpeg — это его примитивность.