Если речь про детектирование движения на стороне хилого сервера, то только им и можно. В идеале конечно, хорошо бы, чтобы это делала камера на своей стороне, а на сервер передавала бы метаинфу о результатах детектирования. Но помню, что когда настраивал камеры в нашем ТСЖ, они хоть и декларировали такое умение через ONVIF, но реализовано через жопу с несоблюдением спеки из-за чего не работало ни с чем, кроме родной убогой китайской софтины под винду.
mjpeg я могу "малинкой" генерировать, а на h264 ее сил не хватит. У нее и так из-за обработки кадров нагрузка под 90%… А в браузерах те лет 5 назад, когда мне это нужно было, не было никаких возможностей показывать в реальном времени "видео" с экспозициями каждого кадра от 100мс до 10с, кроме как менять содержимое тега img. Возможно, сейчас с этим лучше - не знаю. Но пару лет назад, когда я думал найти достойную альтернативу, на SO мне ничего не подсказали - видимо, не было ее вообще. P.S. Да: я думаю, если бы в наше время была альтернатива mjpeg'у, то zoneminder ее бы использовал, а не гнал 100500 потоков mjpeg!
h264 по всем параметрам лучше чем mjpeg, если в железке есть хардварный блок кодирования. А сейчас такой хардварный блок есть почти везде (но не везде есть доступ к нему хорошо описанный).
В Raspberry PI пишут, что тоже есть такой хардварный блок.
Та я уже давным-давно от "малинок" отказался и перешел на более дешевые "апельсинки". А вообще, мне таки интересно было бы почитать, как вообще из отдельных картинок в реальном времени генерить видео h264 и показывать его в браузере? Фантастика какая-то! Почему в zoneminder так не делают? Таки есть у меня подозрение, что это просто невозможно.
Почему невозможно? Вообщето это стандартная задача для ip камеры.
Вот я жеж пользуюсь Maix III для машинки - она в реальном времени успевает и h264 (можно и h265) паковать в 2560x1440. Но мне этого не нужно, поэтому у меня железка. 1 - уменьшает изображение в 3 раза. 2 - убирает искажения "рыбий глаз". 3 - запускает TinyYolo5 нейросетку. И заодно работает http/ws сервером и позволяет смотреть видео по двум протоколам rtsp и ws (для показа напрямую в браузере).
А где почитать, как в реальном времени на стороне сервера жать видео, а на стороне клиента отображать? И чтобы никакой лажи не было (в плане, если клиент не успевает принимать 0.5 кадра в секунду, то даем ему 0.25 кадров в секунду и так далее). В общем, сдается мне, технологий до сих пор не существует! Ведь основная проблема - как гнать клиенту видео в реальном времени. Именно из-за этого и используются до сих пор mjpeg'и, т.к. больше не существует никаких способов вменяемой доставки видео в реальном времени, не требующие каких-то уж совершенно адовых извращений (скажем, на лету подкручивать качество видео или еще какие-то параметры - по вебсокетам), что при наличии хотя бы несчастного десятка клиентов превращается в смерть сервера!
На лету подкручивают качество без перепаковки в реальном времени. Т.е. есть несколько видеофайлов и между ними переключаются. Т.е. основная задача web сервера - это вовремя с нужного места передать кусок файла на клиент.
h264 поток данных десятикратно меньше, чем mjpeg. Соответственно серверу проще, если надо один стрим раздавать нескольким клиентам. Т.е для разрешения 854x480 поток h264 укладывается в 2 МБита/сек. Если-бы передавалось jpeg, то это были би картинки размером 100-150 КБ каждая. А это 25-30 МБит/сек. Т.е. WiFi канал моей машинки был-бы полностью забит!
H264 на порядок легче
Reply
Если речь про детектирование движения на стороне хилого сервера, то только им и можно. В идеале конечно, хорошо бы, чтобы это делала камера на своей стороне, а на сервер передавала бы метаинфу о результатах детектирования. Но помню, что когда настраивал камеры в нашем ТСЖ, они хоть и декларировали такое умение через ONVIF, но реализовано через жопу с несоблюдением спеки из-за чего не работало ни с чем, кроме родной убогой китайской софтины под винду.
Reply
А в браузерах те лет 5 назад, когда мне это нужно было, не было никаких возможностей показывать в реальном времени "видео" с экспозициями каждого кадра от 100мс до 10с, кроме как менять содержимое тега img. Возможно, сейчас с этим лучше - не знаю. Но пару лет назад, когда я думал найти достойную альтернативу, на SO мне ничего не подсказали - видимо, не было ее вообще.
P.S. Да: я думаю, если бы в наше время была альтернатива mjpeg'у, то zoneminder ее бы использовал, а не гнал 100500 потоков mjpeg!
Reply
h264 по всем параметрам лучше чем mjpeg, если в железке есть хардварный блок кодирования. А сейчас такой хардварный блок есть почти везде (но не везде есть доступ к нему хорошо описанный).
В Raspberry PI пишут, что тоже есть такой хардварный блок.
Reply
Reply
Reply
Reply
Да, всё не так уж и давно стало работоспособным.
Поставил Ubuntu 22 на Khadas VIM3 и там автоматом завелся Panfrost. https://docs.mesa3d.org/drivers/panfrost.html
Думаю на новых Raspberry PI всё аналогично работает.
Reply
А вообще, мне таки интересно было бы почитать, как вообще из отдельных картинок в реальном времени генерить видео h264 и показывать его в браузере? Фантастика какая-то! Почему в zoneminder так не делают? Таки есть у меня подозрение, что это просто невозможно.
Reply
Почему невозможно? Вообщето это стандартная задача для ip камеры.
Вот я жеж пользуюсь Maix III для машинки - она в реальном времени успевает и h264 (можно и h265) паковать в 2560x1440. Но мне этого не нужно, поэтому у меня железка. 1 - уменьшает изображение в 3 раза. 2 - убирает искажения "рыбий глаз". 3 - запускает TinyYolo5 нейросетку. И заодно работает http/ws сервером и позволяет смотреть видео по двум протоколам rtsp и ws (для показа напрямую в браузере).
Reply
В общем, сдается мне, технологий до сих пор не существует! Ведь основная проблема - как гнать клиенту видео в реальном времени. Именно из-за этого и используются до сих пор mjpeg'и, т.к. больше не существует никаких способов вменяемой доставки видео в реальном времени, не требующие каких-то уж совершенно адовых извращений (скажем, на лету подкручивать качество видео или еще какие-то параметры - по вебсокетам), что при наличии хотя бы несчастного десятка клиентов превращается в смерть сервера!
Reply
Где почитать - не знаю.
Но могу сказать пару моментов.
На лету подкручивают качество без перепаковки в реальном времени. Т.е. есть несколько видеофайлов и между ними переключаются. Т.е. основная задача web сервера - это вовремя с нужного места передать кусок файла на клиент.
h264 поток данных десятикратно меньше, чем mjpeg. Соответственно серверу проще, если надо один стрим раздавать нескольким клиентам. Т.е для разрешения 854x480 поток h264 укладывается в 2 МБита/сек. Если-бы передавалось jpeg, то это были би картинки размером 100-150 КБ каждая. А это 25-30 МБит/сек. Т.е. WiFi канал моей машинки был-бы полностью забит!
Reply
Leave a comment