Как стать автором
Обновить

Монтаж уличной ip-камеры и вывод изображения по RTSP (python, raspberry pi)

Уровень сложностиСредний
Время на прочтение6 мин
Количество просмотров23K
Всего голосов 17: ↑17 и ↓0+17
Комментарии33

Комментарии 33

Можно было с камеры напрямую поток RTSP смотреть: https://github.com/vladpen/cams

У меня к этому приложению все домашние камеры подключены, довольно удобно.

Вы правы. Но хотелось, что то свое поковырять, минималистичное=)

тогда https://github.com/vladpen/cams-pwa

минималистичное (но! ssl) нет flask, opencv и т.п.

или проще через ярлык в vlc смотреть

+ rtsp to jpeg

зы и в большинстве коробки на которую вы закрепили камеру на солнце гибнут! так можно и камеру потерять.

Спасибо за ссылки. Будет повод взять оттуда интересные идеи для своего проектика

Если камера на некоторое время пропала из сети, будет ли это приложение переподключаться к ней до бесконечности?

Если обработать этот момент и переподключаться при ошибке захвата кадра. На гитхабе, у меня сейчас, такая версия

А зачем надо было покупать дорогую PTZ-камеру, если управление поворотом и наклоном не используется?

я использую, просто другим не даю)

можно в полдень поворачивать камеру, делать скриншоты и клеить панораму в категорию "Фото дня" :)

хорошая идея?

Как с защитой от схода снега и льда с крыши в зимний период?

Думал сделать козырек, но вроде скидывают на противоположную часть дома. Ну если что торчащий кабель, заместо камеры, из коробки, будет уроком)

Перекинув файлы на распберри пай и запустив их, нагрузка составила

«Подъезжая к сией станцыи и глядя на природу в окно, у меня слетела шляпа» © Чехов А. П., «Жалобная книга»

Wiki://Анаколуф

Откройте для себя Frigate или Shinobi.

И да, внешние стены — общее имущество собственников. Формально для такого размещения нужно решение общего собрания жильцов (или более половины проголосовавших заочно за такое решение).

В чате дома негативных реакций не было. На следующем собрании можно и формально оформить?

а то у меня при посике "Shinobi" одни нинзя лезут в поиске:

Как же вы все ищете...

В свое время для того минимизировать нагрузки, просто ставили nginx и проксировали запрос на получение одиночного кадра, обычно в камерах это есть, который кешировали секунд на 15.

Вероятно, есть различные способы оптимизации, до которых я не дошел, ввиду текущей квалификации?‍♂️ Этот скрипт еще надо допиливать, для использование на другом сервере, так как оформлен отдельный процесс, за пределами приложения фласк. Для меня, это скорее плюсы, добавляет азарта ковыряния домашнего проекта)

Это немного разное. Тут и правда про «велосипеды» - эксперименты, домашний проект, питон и т.д.

эксперименты, домашний проект

ну и что. вам кто-то запретил экспериментировать на уровень выше ?

питон

питон самый тормозной скриптовый язык (после руби).

с другой стороны, люди делают серверы видеонаблюдения для винды, продают их за деньги и даже сертифицируют.

Обязательно дорасту до уровней выше, но что поделать, начал с питона?

А если предложу стриминг в telegram?

https://github.com/AlexxIT/go2rtc

Вроде неплохой проект на Go. Вообще, у меня была идея написать вариант, с отправкой кадров в WhatsApp. Скрипт из поста прост и возможностей для допиливания масса

Немного оффтоп. А как часто браузер перезпрашивает новый кадр? Вижу заголовок multipart для кадра, но какого-то регулятора/хинта для периодичности не вижу. Стало интересно как это на клиентской стороне разруливается.

Сейчас я попробую изложить свое понимание происходящего:)

При открытии страницы браузер начинает загрузку изображения с адреса /video_feed, но вместо того, чтобы получить одно статическое изображение, он продолжает получать новые кадры(благодаря стандарту multipart/x-mixed-replace), посылаемые сервером через тот же самый ответ HTTP, создавая эффект видеопотока.

Соответственно, в текущем скрипте, это происходит с частотой 15 раз в секунду(или реже, если кадр не обновился)

Ясно. Т.е. происходит удержание соединения, одни запрос на сервер при загрузке страницы и далее много ответов от него.

Изначально сложилось впечатление, что работает наоборот - клиент делает периодические запросы к серверу.

А websocket может ли справиться с данной логикой?

вроде flask, в стандартной поставке, не поддерживает websocket. Но думаю, с использованием других фреймворков, это возможно

Да, он как раз для таких задач хорошо подходит, когда надо от сервера на клиент что-то слать, не обязывая при этом клиента постоянно дёргать запросами сервер.

Оставлю ссылочку

https://github.com/deepch

А трансляцию видео с камеры можно лить сразу в YouTube? И хранить, и просматривать удобно (раздать всем ссылки)

можно. openipc это умеет прям с камеры...или банально ffmpeg на внешней железке.

Но опыт показал, что при потере потока ютуб с удовольствием завершит стрим и не заходя в студию перезапустить не выйдет(больше 2х недель стрим не жил)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории