Comments 36
"очень прожорлив в плане размера выходного файла". Это вообще как? Своей командой ffmpeg вы тупо оборачиваете h264 поток в фрагментированный mp4. Разница между оригиналом и тем что на выходе в плане размера будет небольшой.
Далее вы пишите, что приходится ждать несколько секунд. Так уменьшите размер фрагмента!
По существу в описанном вами способе есть только две проблемы:
- Трата процессора сервера на оборачивание h264 в fmp4. Погуглите что собой представляет fmp4. Там ничего сложного, а потому, вместо того чтобы конвертировать это на сервере — это можно конвертировать на клиенте и отдавать в тэг видео через Media Source Extensions. Не буду описывать весь процесс просто подумайте, погуглите и сами до всего дойдете.
- Как сервить h264 (в моем варианте) либо (fmp4) в вашем. Здесь и кроется главная проблема. Чем больше клиентов хотят смотреть камеру, тем больше нужно будет tcp соединений, тем больше нужно будет ресурсов на сервере чтобы все это работало. Короче был бы мультикаст udp (а может кто нибудь здесь отпишет по поводу multicast quic?), то можно было бы сделать свой Ютуб на серваке с 1гб ram )))
«очень прожорлив в плане размера выходного файла». Это вообще как? Своей командой ffmpeg вы тупо оборачиваете h264 поток в фрагментированный mp4. Разница между оригиналом и тем что на выходе в плане размера будет небольшой.Речь шла о MJPEG, читайте внимательнее.
Так уменьшите размер фрагмента!Размер фрагмента продиктован интервалом между ключевыми кадрами, лично я ставлю его побольше, потому как качество видео становится чуть выше. Тем более, что обходное решение уже найдено.
По поводу траты времени процессора. Я проводил наблюдения — нагрузка на самом деле небольшая, для рассматриваемых целей более чем приемлема. Зато просто и понятно. А вот конвертация на клиенте, уверен, выльется в большее количество кода и соответствующую сложность, плюс опять же проверять и подгонять под все браузеры. Просто нет времени.
Что касается мультикаста — также нет времени, плюс под мою задачу это было совершенно излишним. Но код открыт, любой может внести свои доработки, если есть желание и время.
почему не разместили на гитхабе?
Это может показаться странным, но я до сих пор так и не пользовался гитхабом, если не считать режим readonly. Думаю, мне нужно этот момент наверстать в ближайшее время. Сервис очень уважаю, как и его сообщество, ежедневно делающее бесценный вклад в развитие ПО.
Я понимаю, что здесь скрипт уровня «слепили на коленке за 5 минут», и ничего серьезного он в принципе не предусматривает. Большинство такое даже не публикует, т.к. это просто какие-то разовые решения.
Но если уж публикуешь код, не важно какого он уровня — без git это делать как минимум очень странно.
Без обид, но код без git не воспринимается даже минимально серьезно.
Потому что такой расклад гарантирует следующее:
-нулевой уровень поддержки. Автор вообще не заморачивается публикацией, и завтра-послезавтра о нем забудет.
-нулевую стабильность. Завтра автор изменит код и перезапишет архив, добавит новых ошибок, и никто с этим ничего не может сделать. Каждое новое скачивание несет в себе новую версию и новые сюрпризы, которые естественно никому не интересно разгребать.
-мертвый код. Трекера ошибок нет — сообщить об ошибке или выложить решение некуда. Хостинг для кода временный — завтра архив протухнет, послезавтра будет удален. Через 3 года наткнешься на ссылку, а она мертвая. И таких статей в сети с мертвыми ссылками — миллионы.
-проблемы с использованием. Даже если ты скачал код и самостоятельно его доработал, завтра автор выложит новую версию, не совместимую с твоей, и все твои наработки коту под хвост, а без git поиск расхождений и обновление кода — тот еще цирк. Да, можно тупо не качать новые версии, но что если там добавилась какая-то нужная фича?
Поэтому обязательно нужно завести аккаунт на github/gitlab, и публиковать свои решения через них.
И под каждый проект нужно делать отдельный репозиторий.
Только так может выйти хоть что-то
из подобных начинаний.
Да, многим кажется что все это фигня. Действительно — зачем какие-то лишние сервисы?
Но это ровно до того момента, как код захочет модифицировать кто-то другой.
Потому что в этом случае встает проблема синхронизации наработок нескольких человек.
И без git такую проблему разрешать крайне трудно и затратно. Уже после нескольких таких слияний захочется плюнуть на все это и забросить.
А git все это берет на себя, и настолько упрощает, что об этой проблеме практически забывают, вспоминая изредка при конфликтах, да и там это решается буквально за минуту.
Что касается отсутствия трекера ошибок — это вообще фатально.
Я сейчас пользую платным софтом, у которого несколько детских багов, которые устранить можно за пару часов, если о них станет известно разработчику. К сожалению этот софт разрабатывается на коленке, и не имеет трекера ошибок. А почта есть только менеджеров, которые работают через задницу, и не понимают в чем проблема. Поэтому эти баги уже пару лет там висят.
Для любого софта обязательно должен быть трекер ошибок, в котором пользователи как минимум могут сообщить о проблеме и описать её, а как максимум — предложить уже готовое решение или патч, облегчив жизнь для всех.
Зы не воспринимай это как критику. Это просто пояснение, почему стоит обязательно освоить git, если имеешь дело с кодом.
Но если уж публикуешь код, не важно какого он уровня — без git это делать как минимум очень странно.
Без обид, но код без git не воспринимается даже минимально серьезно.
Потому что такой расклад гарантирует следующее:
-нулевой уровень поддержки. Автор вообще не заморачивается публикацией, и завтра-послезавтра о нем забудет.
-нулевую стабильность. Завтра автор изменит код и перезапишет архив, добавит новых ошибок, и никто с этим ничего не может сделать. Каждое новое скачивание несет в себе новую версию и новые сюрпризы, которые естественно никому не интересно разгребать.
-мертвый код. Трекера ошибок нет — сообщить об ошибке или выложить решение некуда. Хостинг для кода временный — завтра архив протухнет, послезавтра будет удален. Через 3 года наткнешься на ссылку, а она мертвая. И таких статей в сети с мертвыми ссылками — миллионы.
-проблемы с использованием. Даже если ты скачал код и самостоятельно его доработал, завтра автор выложит новую версию, не совместимую с твоей, и все твои наработки коту под хвост, а без git поиск расхождений и обновление кода — тот еще цирк. Да, можно тупо не качать новые версии, но что если там добавилась какая-то нужная фича?
Поэтому обязательно нужно завести аккаунт на github/gitlab, и публиковать свои решения через них.
И под каждый проект нужно делать отдельный репозиторий.
Только так может выйти хоть что-то
из подобных начинаний.
Да, многим кажется что все это фигня. Действительно — зачем какие-то лишние сервисы?
Но это ровно до того момента, как код захочет модифицировать кто-то другой.
Потому что в этом случае встает проблема синхронизации наработок нескольких человек.
И без git такую проблему разрешать крайне трудно и затратно. Уже после нескольких таких слияний захочется плюнуть на все это и забросить.
А git все это берет на себя, и настолько упрощает, что об этой проблеме практически забывают, вспоминая изредка при конфликтах, да и там это решается буквально за минуту.
Что касается отсутствия трекера ошибок — это вообще фатально.
Я сейчас пользую платным софтом, у которого несколько детских багов, которые устранить можно за пару часов, если о них станет известно разработчику. К сожалению этот софт разрабатывается на коленке, и не имеет трекера ошибок. А почта есть только менеджеров, которые работают через задницу, и не понимают в чем проблема. Поэтому эти баги уже пару лет там висят.
Для любого софта обязательно должен быть трекер ошибок, в котором пользователи как минимум могут сообщить о проблеме и описать её, а как максимум — предложить уже готовое решение или патч, облегчив жизнь для всех.
Зы не воспринимай это как критику. Это просто пояснение, почему стоит обязательно освоить git, если имеешь дело с кодом.
Спасибо за такое простое, но ёмкое пояснение о необходимости git!
Завёл репозиторий проекта и добавил ссылку на него в конце статьи.
Завёл репозиторий проекта и добавил ссылку на него в конце статьи.
Всё хорошо, но последняя фраза выворачивает…
git — не синоним гитхаба и гитлаба! Треккер ошибок, поддержка, мёртвый код и т.д. — это всё же не про гит как таковой (и вы это сами прекрасно понимаете). Но каждый раз когда понятия подменяются, это вносит чуть-чуть путаницы и беспорядка.
- А почему вообще параметры подключения хранятся на веб-странице? Если камера одна, то ее адрес и пароль можно хранить где-нибудь в конфигах сервера, а если камер много — то тоже, и обращаться к серверу как camera.php?camera=1
- Я правильно понимаю, что два запроса к серверу приведут к двум подключениям к камере и создадут двойной трафик и два процесса ffmpeg будут грузить сервер одним и тем же?
- С mjpeg и mp4 прямо костыль какой-то.
Последние два пункта прямо заставляют искать другой подход. Например, запускать в фоне один ffmpeg и отдавать куски по HLS. Если при этом можно не перекодировать поток, как выше написали, то совсем хорошо
osmanpasha,
1. Ну, это продиктовано простотой. Мне было так проще и удобнее, подход себя оправдал на большом количестве камер разных моделей и марок (у меня около 50).
2. Все верно. Все тоже самое, как если дать доступ к камере напрямую, только проще для пользователя. Мои пользователи, например, уже испытывают серьезные сложности с открытием IE и установкой плагина камеры. Даже у меня периодически с этим проблемы, некоторые плагины работают некорректно под «современными» версиями IE. А на маках вообще не работает.
3. С HLS много пробовал, ничего толком не вышло. Оно хорошо, когда запустил, и пусть круглые сутки перекодирует поток, но трафик… Может MJPEG и костыль, зато удачно вписавшийся, ИМХО.
1. Ну, это продиктовано простотой. Мне было так проще и удобнее, подход себя оправдал на большом количестве камер разных моделей и марок (у меня около 50).
2. Все верно. Все тоже самое, как если дать доступ к камере напрямую, только проще для пользователя. Мои пользователи, например, уже испытывают серьезные сложности с открытием IE и установкой плагина камеры. Даже у меня периодически с этим проблемы, некоторые плагины работают некорректно под «современными» версиями IE. А на маках вообще не работает.
3. С HLS много пробовал, ничего толком не вышло. Оно хорошо, когда запустил, и пусть круглые сутки перекодирует поток, но трафик… Может MJPEG и костыль, зато удачно вписавшийся, ИМХО.
Вы не дадите доступ напрямую к камере, поскольку сервак который стоит в самой камере (и отдает h264 либо rtsp) просто умрет на количестве клиентов больше 3х — 4х
Да, среднестатистическая камера не тянет более 4 клиентов, и зачастую, ограничение это на уровне прошивки (и это правильно, иначе зависнет и будет только хуже). Если подключать через видеорегистратор, можно выжать больше. Типовой от Hikvision вроде ограничивает 128 клиентами, точно не скажу. Но если у вас действительно много одновременных клиентов на одну камеру, то тут мое решение не годится. Оно больше «домашнее». Я его использую для предоставления доступа сотрудникам и руководству к камерам на стройках компании (а также субподрядчикам, заказчикам). Примерную нагрузку понять несложно — она совсем невелика.
Мне кажется, HLS мог бы вам помочь в случае, если несколько клиентов одновременно смотрят одну камеру (если это распространенный юзкейс и в этом есть проблема, конечно). Там же суть в том, что куски видео сохраняются отдельными файлами, а произвольное число пользователей может их скачивать. Возможно, пришлось бы навелосипедить способ при первом запросе начинать весь этот процесс стриминга, а когда последний пользователь камеры уйдет, то завершать, чтобы не съедать траффик камеры.
В свое время тоже стояла такая проблема. Даже оплачивал сервер для реализации конкретно переформатирования и раздачи видео в подходящем формате для сайта.
Впоследствии, исходя из отсутствия надобности именно в видео, снизошли до статичных фоток (снапшотов) непосредственно с камеры. Они выдаются по такому формату без всяких перекодировок:
http://***.***.***.**:****/snap.jpg?JpegCam=0
Впоследствии, исходя из отсутствия надобности именно в видео, снизошли до статичных фоток (снапшотов) непосредственно с камеры. Они выдаются по такому формату без всяких перекодировок:
http://***.***.***.**:****/snap.jpg?JpegCam=0
Можете посмотреть мою статью
habr.com/ru/post/532424
И организовать доступ по ключам
Если отклик критически важен, можно организовать задержку в 0.5 секунды
habr.com/ru/post/532424
И организовать доступ по ключам
Если отклик критически важен, можно организовать задержку в 0.5 секунды
Кстати, лично у меня все камеры посредством VPN (я люблю Wireguard) связаны в одну сеть, все ссылки я прописываю с «серыми IP». Удобно, безопасно, радует.
а можно детали, на чём крутится wireguard?
Keenetic Giga :)
А вот IPSec у меня на нем не зашел — бывали периодические обрывы, хотя вроде бы и настраивал все корректно. Вроде и коннект есть, а пакеты не идут, и так раз в пару-тройку дней на несколько минут. И тут Wireguard стал «глотком свежего воздуха».
А вот IPSec у меня на нем не зашел — бывали периодические обрывы, хотя вроде бы и настраивал все корректно. Вроде и коннект есть, а пакеты не идут, и так раз в пару-тройку дней на несколько минут. И тут Wireguard стал «глотком свежего воздуха».
если вам не принципиально именно wireguard и секьюрность, а нужно хоть что-нибудь чтоб завернуть роутер с серым ip и камерами в его подсети в vpn, то можно так https://m.habr.com/ru/post/482864/.
если настроить bcrelay, то можно будет поднять на сервере еще socks / shadowsocks стучаться к камерам хоть по впн, хоть по прокси (шадоусокс имхо удобней впн с телефона).
Mjpeg over https выжирает раза в 3 больше трафика чем rtsp
А нельзя встроить в страницу плеер который понимает формат камеры? Он вам и буферизацию сделает и может ещё что полезное
с камерами идут облака как правило даже у китайцев
это понятно, но господин же не хочет по каким то причинам их использовать, поэтому предлагается просто сторонний плеер встроить в страницу
Встроить плеер, понимающий протокол RTSP напрямую, можно, но сначала надо таковой найти. Мои поиски не увенчались успехом, если не считать Streamedian/html5_rtsp_player. Но и ему всё равно требуется серверная часть, заворачивающая RTSP-потоки в WebSocket. Впрочем, это решение тоже очень даже неплохо смотрится, но всё же, я пошел другим путем.
Внесу и свои 5 копеек, несколько лет назад тоже стояла подобная задача. Сейчас уже всех деталей не вспомню, но точно в голове осталось, что использовал nginx-rtmp-module, насколько помню — там тот же ffmpeg внутри и очень он мне понравился. Сам бэкенд делал на nodejs. Вещал на любые браузеры/устройства (вроде HLS). Но, к сожалению, это была разовая задача и дальше не развивалась.
Не реклама.
Мы так же искали решения для размещения потокового видео на сайте, и в итоге остановились на rtsp.me
Не надо на серверах ни чего городить и легко ставится на сайте. Нет ограничений в виде рекламы и количества потоков на бесплатном аккаунте.
Мы так же искали решения для размещения потокового видео на сайте, и в итоге остановились на rtsp.me
Не надо на серверах ни чего городить и легко ставится на сайте. Нет ограничений в виде рекламы и количества потоков на бесплатном аккаунте.
Почему бы не использовать motion, который понимает камеры с rtsp
Однажды я собирал с 5 камер видео и сохранял на диск. Самый быстрым (по нагрузке на CPU) был способ через утилиту openrtsp, которая сохраняла поток в mp4 (вроде) как есть, и параллельно скриншоты делала.
Так как ПК был слабеньким (intel atom), то это было приемлемым решением, ПК особо не напрягался. А варианты, где дело было связано с пережиманием видео упиралось в производительность ПК. Короче, если можно получить готовые данные с камеры и не обрабатывать их, то лучше так и поступать.
Так как ПК был слабеньким (intel atom), то это было приемлемым решением, ПК особо не напрягался. А варианты, где дело было связано с пережиманием видео упиралось в производительность ПК. Короче, если можно получить готовые данные с камеры и не обрабатывать их, то лучше так и поступать.
Sign up to leave a comment.
Самый простой (для знающих Linux) и дешевый способ разместить IP-камеру на сайте для небольшой аудитории