Steam многие годы приучал наших пользователей легально приобретать игры, а теперь все они отвернулись от нас. А вот вернуться обратно может быть не так просто, лично мое доверие потеряно на годы вперед. Перебьюсь и без мультиплеерок, теперь вообще легко. Пиратский флаг вполне себе справедливый ответ на их действия
Можно привязать сертбот к любому поддерживаемому веб-серверу, а полученные сертификаты копировать потом в нужное место. Я так делаю, чтобы получить сертификат на основной сайт на Apache, а после копирую его в cron'e (просто командой cp) на видеосервер и остальное, что висит на том же домене (на разных портах).
И получение сертификата по проверке через HTTP не единственная опция, сертбот также поддерживает проверку, например, по DNS-записям.
В конце концов, можно заказать платный сертификат у регистратора домена, если не хочется этим заниматься самостоятельно.
А motion умеет уходить "в сон", когда нет зрителей, прерывая захват потока с камеры? А если нужна поддержка аудио (в mjpeg ее нет)? Да и не проще он, строго говоря)
Кэш на диске и там интервала нет. При запросе снапшота, сервер смотрит свою папку data/capture. Если он не нашел там картинки, то делает захват с камеры. Если нашел, но судя по дате изменения файла она устарела (т.е. разница с текущим временем была более минуты, по умолчанию), то также сделает захват. Иначе просто отдаст имеющееся, как обычный ресурс. Поиск идет по GUID камеры, им именуются файлы снапшотов.
Касательно вашей проблемы, циклические снапшоты с помощью ffmpeg можно делать так (в этом примере делается снапшот каждую секунду, принимая fps потока равным 12 — настройте под себя):
Но храниться это будет не в оперативке, конечно же (как вариант RAM-диск?). Касательно "видео из снапшотов", то можно тем же ffmpeg превратить картинки в GIF, например так:
ffmpeg -f image2 -i img%03d.jpg out.gif
Правда эта команда склеит в GIF вообще все картинки из папки, поэтому придется отбирать последние 10 картинок скриптом на bash, и передавать список как аргумент в ffmpeg. Здесь не подскажу, плохо разбираюсь в bash.
Я точно не уверен, но вроде в последний раз, когда я его смотрел, он не умел «засыпать». Т.е. не гонять трафик с камеры впустую, если нет активных клиентов.
Да, тоже хороший вариант, видел ранее. Но сама идея открывать к камере доступ извне и отдавать ссылку на нее «чужому» сервису мне не понравилась, хотя впрочем, для моих текущих задач это приемлемо. Но это сугубо мое личное мнение.
Встроить плеер, понимающий протокол RTSP напрямую, можно, но сначала надо таковой найти. Мои поиски не увенчались успехом, если не считать Streamedian/html5_rtsp_player. Но и ему всё равно требуется серверная часть, заворачивающая RTSP-потоки в WebSocket. Впрочем, это решение тоже очень даже неплохо смотрится, но всё же, я пошел другим путем.
Keenetic Giga :)
А вот IPSec у меня на нем не зашел — бывали периодические обрывы, хотя вроде бы и настраивал все корректно. Вроде и коннект есть, а пакеты не идут, и так раз в пару-тройку дней на несколько минут. И тут Wireguard стал «глотком свежего воздуха».
Да, захват статичной картинки тоже весьма годная вещь, делал так до написания скрипта. Только формат ссылки от производителя к производителю различается, тут надо гуглить под конкретную камеру.
Да, среднестатистическая камера не тянет более 4 клиентов, и зачастую, ограничение это на уровне прошивки (и это правильно, иначе зависнет и будет только хуже). Если подключать через видеорегистратор, можно выжать больше. Типовой от Hikvision вроде ограничивает 128 клиентами, точно не скажу. Но если у вас действительно много одновременных клиентов на одну камеру, то тут мое решение не годится. Оно больше «домашнее». Я его использую для предоставления доступа сотрудникам и руководству к камерам на стройках компании (а также субподрядчикам, заказчикам). Примерную нагрузку понять несложно — она совсем невелика.
osmanpasha,
1. Ну, это продиктовано простотой. Мне было так проще и удобнее, подход себя оправдал на большом количестве камер разных моделей и марок (у меня около 50).
2. Все верно. Все тоже самое, как если дать доступ к камере напрямую, только проще для пользователя. Мои пользователи, например, уже испытывают серьезные сложности с открытием IE и установкой плагина камеры. Даже у меня периодически с этим проблемы, некоторые плагины работают некорректно под «современными» версиями IE. А на маках вообще не работает.
3. С HLS много пробовал, ничего толком не вышло. Оно хорошо, когда запустил, и пусть круглые сутки перекодирует поток, но трафик… Может MJPEG и костыль, зато удачно вписавшийся, ИМХО.
Это может показаться странным, но я до сих пор так и не пользовался гитхабом, если не считать режим readonly. Думаю, мне нужно этот момент наверстать в ближайшее время. Сервис очень уважаю, как и его сообщество, ежедневно делающее бесценный вклад в развитие ПО.
«очень прожорлив в плане размера выходного файла». Это вообще как? Своей командой ffmpeg вы тупо оборачиваете h264 поток в фрагментированный mp4. Разница между оригиналом и тем что на выходе в плане размера будет небольшой.
Речь шла о MJPEG, читайте внимательнее.
Так уменьшите размер фрагмента!
Размер фрагмента продиктован интервалом между ключевыми кадрами, лично я ставлю его побольше, потому как качество видео становится чуть выше. Тем более, что обходное решение уже найдено.
По поводу траты времени процессора. Я проводил наблюдения — нагрузка на самом деле небольшая, для рассматриваемых целей более чем приемлема. Зато просто и понятно. А вот конвертация на клиенте, уверен, выльется в большее количество кода и соответствующую сложность, плюс опять же проверять и подгонять под все браузеры. Просто нет времени.
Что касается мультикаста — также нет времени, плюс под мою задачу это было совершенно излишним. Но код открыт, любой может внести свои доработки, если есть желание и время.
Steam многие годы приучал наших пользователей легально приобретать игры, а теперь все они отвернулись от нас. А вот вернуться обратно может быть не так просто, лично мое доверие потеряно на годы вперед. Перебьюсь и без мультиплеерок, теперь вообще легко. Пиратский флаг вполне себе справедливый ответ на их действия
Можно привязать сертбот к любому поддерживаемому веб-серверу, а полученные сертификаты копировать потом в нужное место. Я так делаю, чтобы получить сертификат на основной сайт на Apache, а после копирую его в cron'e (просто командой cp) на видеосервер и остальное, что висит на том же домене (на разных портах).
И получение сертификата по проверке через HTTP не единственная опция, сертбот также поддерживает проверку, например, по DNS-записям.
В конце концов, можно заказать платный сертификат у регистратора домена, если не хочется этим заниматься самостоятельно.
А motion умеет уходить "в сон", когда нет зрителей, прерывая захват потока с камеры? А если нужна поддержка аудио (в mjpeg ее нет)? Да и не проще он, строго говоря)
Кэш на диске и там интервала нет. При запросе снапшота, сервер смотрит свою папку data/capture. Если он не нашел там картинки, то делает захват с камеры. Если нашел, но судя по дате изменения файла она устарела (т.е. разница с текущим временем была более минуты, по умолчанию), то также сделает захват. Иначе просто отдаст имеющееся, как обычный ресурс. Поиск идет по GUID камеры, им именуются файлы снапшотов.
Касательно вашей проблемы, циклические снапшоты с помощью ffmpeg можно делать так (в этом примере делается снапшот каждую секунду, принимая fps потока равным 12 — настройте под себя):
Но храниться это будет не в оперативке, конечно же (как вариант RAM-диск?). Касательно "видео из снапшотов", то можно тем же ffmpeg превратить картинки в GIF, например так:
Правда эта команда склеит в GIF вообще все картинки из папки, поэтому придется отбирать последние 10 картинок скриптом на bash, и передавать список как аргумент в ffmpeg. Здесь не подскажу, плохо разбираюсь в bash.
Да как-то само собой получилось на HLS, заинтересовал он меня, ну и пошло-поехало :) Возможно сделаю WebRTC в следующей версии
Завёл репозиторий проекта и добавил ссылку на него в конце статьи.
А вот IPSec у меня на нем не зашел — бывали периодические обрывы, хотя вроде бы и настраивал все корректно. Вроде и коннект есть, а пакеты не идут, и так раз в пару-тройку дней на несколько минут. И тут Wireguard стал «глотком свежего воздуха».
1. Ну, это продиктовано простотой. Мне было так проще и удобнее, подход себя оправдал на большом количестве камер разных моделей и марок (у меня около 50).
2. Все верно. Все тоже самое, как если дать доступ к камере напрямую, только проще для пользователя. Мои пользователи, например, уже испытывают серьезные сложности с открытием IE и установкой плагина камеры. Даже у меня периодически с этим проблемы, некоторые плагины работают некорректно под «современными» версиями IE. А на маках вообще не работает.
3. С HLS много пробовал, ничего толком не вышло. Оно хорошо, когда запустил, и пусть круглые сутки перекодирует поток, но трафик… Может MJPEG и костыль, зато удачно вписавшийся, ИМХО.
Размер фрагмента продиктован интервалом между ключевыми кадрами, лично я ставлю его побольше, потому как качество видео становится чуть выше. Тем более, что обходное решение уже найдено.
По поводу траты времени процессора. Я проводил наблюдения — нагрузка на самом деле небольшая, для рассматриваемых целей более чем приемлема. Зато просто и понятно. А вот конвертация на клиенте, уверен, выльется в большее количество кода и соответствующую сложность, плюс опять же проверять и подгонять под все браузеры. Просто нет времени.
Что касается мультикаста — также нет времени, плюс под мою задачу это было совершенно излишним. Но код открыт, любой может внести свои доработки, если есть желание и время.