Всем привет!
Наверное, ни для кого не секрет, что в последнее время облачные сервисы видеонаблюдения набирают популярность. И понятно почему так происходит, видео — это "тяжелый" контент, для хранения которого необходима инфраструктура и большие объемы дискового хранилища. Использование локальной системы видеонаблюдения требует средств на эксплуатацию и поддержку, как в случае организации, использующей сотни камер наблюдения, так и в случае индивидуального пользователя с несколькими камерами.
Облачные системы видеонаблюдения решают эту задачу — предоставляя клиентам уже существующую инфраструктуру хранения и обработки видео. Клиенту облачного видеонаблюдения достаточно просто подключить камеру к интернету и привязать к своему аккаунту в облаке.
Есть несколько технологических способов подключения камер к облаку. Бесспорно, наиболее удобный и дешевый способ — камера напрямую подключается и работает с облаком, без участия дополнительного оборудования типа сервера или регистратора.
Для этого необходимо, чтобы на камере был установлен модуль ПО работающий с облаком. Однако, если говорить про дешевые камеры, то у них очень ограничены аппаратные ресурсы, которые почти на 100% занимает родная прошивка вендора камеры, а ресурсов необходимых для облачного плагина — нет. Этой проблеме разработчики из ivideon посвятили статью, в которой говорится почему они не могут установить плагин на дешевые камеры. Как итог, минимальная цена камеры — 5000р ($80 долларов) и миллионы потраченных денег на оборудование.
Мы эту проблему успешно решили. Если интересно как — велком под кат
Немного истории
В 2016 году мы стартовали разработку платформы облачного видеонаблюдения для Ростелекома.
В части ПО камер на первом этапе пошли "стандартным" для таких задач путем: разработали свой плагин, который устанавливается в штатную прошивку камеры вендора и работает с нашим облаком. Однако, стоит отметить, что при проектировании мы использовали наиболее легковесные и эффективные решения (например, plain C реализацию protobuf, libev, mbedtls и полностью отказались от удобных, но тяжелых библиотек типа boost)
Сейчас на рынке IP камер нет универсальных решений по интеграции: у каждого вендора свой способ установки плагина, свой набор API для работы прошивки и уникальный механизм обновления.
Это означает, что для каждого вендора камер необходимо индивидуально разрабатывать объемный слой интеграционного ПО. И на момент старта разработки целесообразно работать только с 1-ним вендором, что бы сосредоточить усилия команды на разработке логики работы с облаком.
Первым вендором был выбран Hikvision — один из мировых лидеров на рынке камер, предоставляющий хорошо документированное API и грамотную инженерную техническую поддержку.
На камерах Hikvision мы и запустили наш первый пилотный проект облачное видеонаблюдение Видеокомфорт.
Практически сразу после запуска наши пользователи стали задавать вопросы о возможности подключении к сервису более дешевых камер других производителей.
Вариант с реализацией слоя интеграции под каждого вендора я отбросил практически сразу — как плохо масштабируемый и предъявляющий к железу камеры серьезные технические требования. Стоимость камеры, удовлетворяющий таким требованиям на входе: ~60-70$
Поэтому, я принял решение копать глубже — сделать полностью свою прошивку для камер любых вендоров. Этот подход существенно снижает требования к аппаратным ресурсам камеры — т.к. слой работы с облаком на порядок более эффективно интегрирован с video application, и в прошивке нет лишнего не используемого жирка.
И что важно, при работе с камерой на низком уровне есть возможность использовать аппаратный AES, который шифрует данные, не создавая дополнительной нагрузки на маломощный CPU.
В тот момент у нас не было вообще ничего. Вообще ничего.
Практически все вендоры не были готовы работать с нами на таком низком уровне. Информации о схемотехнике и компонентах — нет, официальных SDK чипсетов и документации сенсоров — нет.
Технической поддержки так же нет.
Ответы на все вопросы приходилось получать реверс инжинирингом — методом проб и ошибок. Но мы справились.
Первыми моделями камер, на которых мы набивали шишки стали камеры Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link и несколько сверх дешевых безымянных китайских камер.
Техника
Камеры на чипсете Hisilicon 3518E. Аппаратные характеристики камер такие:
| Xiaomi Yi Ants | Noname | |
|---|---|---|
| SoC | Hisilicon 3518E | Hisilicon 3518E |
| RAM | 64MB | 64MB |
| FLASH | 16MB | 8MB |
| WiFi | mt7601/bcm43143 | - |
| Sensor | ov9732 (720p) | ov9712 (720p) |
| Ethernet | - | + |
| MicroSD | + | + |
| Microphone | + | + |
| Speaker | + | + |
| IRLed | + | + |
| IRCut | + | + |
С них мы начинали.
Сейчас поддерживаем чипсеты Hisilicon 3516/3518, а так же Ambarella S2L/S2LM. Количество моделей камер — десятки.
Состав прошивки
uboot
uboot — это начальный загрузчик, после включения питания загружается первым, инициализирует оборудование и загружает ядро linux.
Скрипт загрузки камеры достаточно тривиален:
bootargs=mem=38M console=ttyAMA0,115200 rootfstype=ramfs mtdparts=hi_sfc:256K(boot),64K(tech),4096K(kernel),8192K(app),-(config) hw_type=101
bootcmd=sf probe 0; sf read 0x82000000 0x50000 0x400000; bootm 0x82000000; setenv bootargs $(bootargs) bkp=1; sf read 0x82000000 0x450000 0x400000; bootm 0x82000000Из особенностей — два раза вызывается bootm, подробнее об этом чуть позже, когда дойдем до подсистемы обновления.
Обратите внимание на строчку mem=38M. Да, да, это не опечатка — ядру Linux и всем-всем-всем приложениям доступно всего лишь 38 мегабайт оперативной памяти.
Так же рядом с uboot находится специальный блок, называемый reg_info, в котором находится низкоуровневый скрипт инициализации DDR и ряда системных регистров SoC. Содержимое reg_info зависит от модели камеры, и если оно будет не корректным, то камера даже не сможет загрузить uboot, а зависнет на самом раннем этапе загрузки.
Первое время, когда мы работали без поддержки вендоров, мы просто копировали этот блок из оригинальной прошивки камеры.
Ядро linux и rootfs
На камерах используется ядро Linux, входящее в состав SDK чипа, обычно это не самые свежие ядра из ветки 3.x, поэтому часто приходится сталкиваться с тем, что драйвера дополнительного оборудования не совместимы с используемым ядром, и нам приходится их бэк-портировать под ядро камеры.
Другая проблема — это размер ядра. Когда размер FLASH всего 8MB, то каждый байт на счет и наша задача — аккуратно отключить все не используемые функции ядра, что бы сократить размер до минимума.
Rootfs — это базовая файловая система. В нее включены busybox, драйвера wifi модуля, набор стандартных системных библиотек, типа libld и libc, а так же ПО нашей разработки, отвечающее за логику управления светодиодами, управление сетевыми подключениями и за обновление прошивки.
Корневая файловая система подключена к ядру как initramfs и в результате сборки мы получаем один файл uImage, в котором есть и ядро и rootfs.
Video application
Наиболее сложная и ресурсоемкая часть прошивки — приложение, которое обеспечивает видео-аудио захват, кодирование видео, настраивает параметры картинки, реализует видео-аналитики, например, детекторы движения или звука, управляет PTZ и отвечает за переключения дневного и ночного режимов.
Важная, я бы даже сказал ключевая особенность — каким образом видео приложение взаимодействует с облачным плагином.
В традиционных решениях 'прошивка вендора + облачный плагин', которые не могут работать на дешевом железе, видео внутри камеры передается по протоколу RTSP — а это огромный оверхед: копирование и передача данных через socket, лишние syscall-ы.
Мы в этом месте используем механизм shared memory — видео не копируется и не пересылается через socket между компонентами ПО камеры, тем самым оптимально и бережно используя скромные аппаратные возможности камеры.
Подсистема обновления
Предмет отдельной гордости — подсистема fault-tolerant онлайн обновления прошивки.
Поясню проблематику. Обновление прошивки — это технически не атомарная операция и в случае если посередине обновления произойдет сбой питания, то на флеш памяти будет часть "недозаписанной" новой прошивки. Если не предпринять специальных мер, то камера после этого станет "кирпичом", который нужно нести в сервисный центр.
Мы справились и с этой проблемой. Даже если камеру выключить в момент обновления, она автоматически и без участия пользователя скачает прошивку из облака и восстановит работу.
Разберем технику подробнее:
Наиболее уязвимый момент — перезапись раздела с ядром Linux и корневой файловой системой. В случае, если один из этих компонентов окажется поврежденным, то камера вообще не загрузиться дальше начального загрузчика uboot, который не умеет скачивать прошивку из облака.
Значит, нам нужно обеспечить гарантию наличия на камере работоспособного ядра и rootfs в любой момент процесса обновления. Казалось бы самым простым решением было бы постоянно хранить на флеш памяти две копии ядра с rootfs и в случае повреждения основного ядра загружать его из резервной копии.
Годное решение — однако, ядро с rootfs занимает около 3.5MB и для постоянной резервной копии нужно выделить 3.5MB. На самых дешевых камерах просто нет столько свободного места под backup ядра.
Поэтому для backup ядра во время обновления прошивки используем application партицию.
А для выбора нужной партиции с ядром как раз и используется две команды bootm в uboot — в начале пытаемся загрузить основное ядро и если оно повреждено, то резервное.
Это гарантирует, что в любой момент времени на камере будет корректное ядро с rootfs, и она сможет загрузиться и восстановить прошивку.
CI/CD система сборки и деплоя прошивок
Для сборки прошивок мы используем gitlab CI, в котором автоматически собираются прошивки под все поддерживаемые модели камер, после сборки прошивки автоматически деплоятся на сервис обновления ПО камер.
Из сервиса обновления ПО прошивки доставляются на тестовые камеры наших QA, а по завершению всех этапов тестирования и на камеры пользователей.
Информационная безопасность
Ни для кого не секрет, что в наше время информационная безопасность — это важнейший аспект любого IoT устройства, в том числе и камеры. По интернету гуляют ботнеты типа Mirai, поражающие миллионы камер со стандартными прошивками от вендоров. При всем уважении к вендорам камер, не могу не отметить, что в стандартных прошивках заложено много функционала, который не востребован для работы с облаком, однако содержит в себе много уязвимостей, которыми пользуются ботнеты.
Поэтому, весь не используемый функционал в нашей прошивке отключен, все tcp/udp порты закрыты и при обновлении прошивки проверяется цифровая подпись ПО.
И кроме этого, прошивка проходит регулярное тестирование в лаборатории информационной безопасности.
Заключение
Сейчас наша прошивка активно используется в проектах по видеонаблюдению. Пожалуй самый масштабный из них — трансляция голосования в день выборов Президента Российской Федерации.
В проекте было задействовано более 70 тысяч камер с нашей прошивкой, которые были установлены по избирательным участкам нашей страны.
Решив ряд сложных, а местами, даже на тот момент практически невозможных задач, мы, конечно, получили огромное удовлетворение как инженеры, но кроме этого, и сэкономили миллионы долларов на закупке камер. И в данном случае, экономия — это не только слова и теоретические расчёты, а результаты уже случившегося тендера на закупку оборудования. Соответственно, если говорить про облачное видеонаблюдение: есть два подхода — стратегически заложиться на низкоуровневую экспертизу и разработку, получив на выходе огромную экономию на оборудовании или использовать дорогое оборудование, которое, если смотреть именно на потребительские характеристики, практически ничем не отличается от аналогичного дешевого.
Почему стратегически важно принять решение относительно выбора подхода к способу интеграции как можно раньше? При разработке плагина, разработчики закладываются на те или иные технологии (библиотеки, протоколы, стандарты). И если выбран набор технологий только под дорогое оборудование, то в дальнейшем попытка перехода на дешевые камеры с большой вероятностью, как минимум, займет безумно большое время или вообще потерпит неудачу и произойдет возврат к дорогому оборудованию.
Комментарии (111)
olegator99 Автор
01.07.2018 17:17Обычно прошивка либо устанавливается вендором на заводе, либо приезжает через online сервис обновления.
Вот, например, апдейт для камер на hi3518: http://camera-updater.videocomfort.ru/agent/hi3518/prod/firmware/v1.0.1-155-gfe91e4a_hi3518_prod-b22307/firmware_v1.0.1-155-gfe91e4a_hi3518_prod-b22307.bin — (апдейты идут без uboot)
Вот, например, полный образ http://camera-updater.videocomfort.ru/agent/r2/prod/digicap_v0.9.8-89-gcf0ead1_hi3518_prod-b8641.dav для Hikvision VC1W
datacompboy
01.07.2018 17:18то есть можно уже имеющуюся камеру на hi3518 заменить?
olegator99 Автор
01.07.2018 17:24Не совсем. Камеры все же отличаются по железу (разные сенсоры, разные wifi модули, разные GPIO, разные DDR).
Поэтому, просто так установить не получится — необходимо, что бы прошивка знала специфику оборудования, и что бы в ней были необходимые дрова сенсора и wifi модуля.
erlyvideo
01.07.2018 19:05там всё очень грустно.
Конечно очень хочется сделать одну прошивку, которая будет работать под всеми 3518, 3516 и 3519, но пока, судя по всему, нет даже способа программно определить разные сенсоры. Т.е. прежде чем заливать прошивку, надо точно знать, какой там сенсор.
Это как если бы надо было точно знать, какой линукс скачивать под распаянный на материнке жесткий диск, учитывая, что нет програмного способа его сдетектировать.
Грустно.olegator99 Автор
01.07.2018 19:19Ну мы выкручиваемся так: код модели камеры зашита в разделе env, а в самой rootfs есть реестр поддерживаемых моделей и описание оборудования которое соотвествует этой модели.
А kernel+rootfs и application универсален для всего семейства чипов.
А так да, никакого плаг & плэй (
erlyvideo
01.07.2018 19:24вот да, только писать в env.
Я не оставляю надежду на то, что общением через i2c получится хотя бы косвенными способами угадать сенсор.olegator99 Автор
01.07.2018 20:43Иногда можно, но не всегда поможет.
Даже один и тот же сенсор может быть подключен по разному схемотехнически в разных камерах. А от этого зависят настройки режима захвата видео…
Кроме этого узнать к каким GPIO подключены светодиоды/кнопки/IRLed/IRCut — вообще не возможно впринципе...
Единственное — wifi чип можно опознать по USB vid/pid, и то если он подключен по USB, а не по SDIO.
userEqNewUser
02.07.2018 10:56Кроме этого узнать к каким GPIO подключены светодиоды/кнопки/IRLed/IRCut — вообще не возможно впринципе...
На самом деле GPIO возможно определить простым перебором, приходилось несколько раз такое проворачивать, когда вендор не давал даташит на плату.olegator99 Автор
02.07.2018 11:00У hisi 351x порядка 100 GPIO выводов.
Мы для поиска задействованных GPIO разработали специальную утилиту, которая умеет
а) выводить какие GPIO переведены в режим OUT, при запуске на стоковой прошивке, это сужает круг поиска выходов, к которым подключены светодиоды и IRCut
б) выводить состояния всех входов GPIO подключенных к процессору.
Во времена, когда не было поддержки вендоров — это очень помогало.
gorbln
02.07.2018 09:03Может, сморожу глупость, но всё-таки — сенсор — он же под стеклом? А нельзя просто посмотреть на этот сенсор через микроскоп? Там по-любому есть какие-нибудь «пасхалки» от производителя в виде номера модели или ещё чего. И по ним определить. Ну, как-то так.
olegator99 Автор
02.07.2018 11:01+2Ага, модель сенсора можно определить и по внешнему виду, и по составу стоковой прошивки.
Но в комментариях выше мы рассуждали, про авто-определение типа сенсора в рантайме, что бы наша прошивка могла сама определить какой на камере установлен сенсор. Вот с этим как раз и есть ряд сложностей.
scaldov
02.07.2018 11:31а разве там нигде нету файла device tree??
olegator99 Автор
02.07.2018 11:33У Hisilicon — обычно нет. Да и задачу создания "универсальной прошивки" он не решит, т.к. нет аппаратного идентификатора типа оборудования.
TheRaven
01.07.2018 18:16В традиционных решениях 'прошивка вендора + облачный плагин', которые не могут работать на дешевом железе, видео внутри камеры передается по протоколу RTSP — а это огромный оверхед: копирование и передача данных через socket, лишние syscall-ы.
Мы в этом месте используем механизм shared memory — видео не копируется и не пересылается через socket между компонентами ПО камеры, тем самым оптимально и бережно используя скромные аппаратные возможности камеры.
Т.е. RTSP вы убрали совсем и камеру иначе как с вашим сервисом использовать не получится?olegator99 Автор
01.07.2018 18:21Технически, RTSP у нас в прошивке есть, и в некоторых проектах он используется.
alexey115
01.07.2018 18:24С вашей прошивки на заводскую можно вернуться?
olegator99 Автор
01.07.2018 18:27У нас есть утилита, которая позволяет бэкапнуть, а в последующем восстановить родную прошивку.
Естественно, если бэкап не сделан, то вернуть на родную прошивку будет сложнее — прийдется искать такую же камеру с оригинальной прошивкой, что бы с нее снять бэкап.
erlyvideo
01.07.2018 18:41> как плохо масштабируемый и предъявляющий к железу камеры серьезные технические требования. Стоимость камеры, удовлетворяющий таким требованиям на входе: ~60-70$
…
> В традиционных решениях 'прошивка вендора + облачный плагин', которые не могут
> работать на дешевом железе, видео внутри камеры передается по протоколу RTSP — а это
> огромный оверхед
какие например? Очень интересно, как можно сделать _огромный_ оверхед на проксировании RTSP внутри камеры. У нас сделать огромный не получилось, наш агент для облака работает на камерах от $8 с шифрованием, проксированием и очень несложным процессом адаптации вендорской прошивки. По крайней мере он сильно проще, чем портирование целой прошивки под очередную комбинацию сенсор+чип+всё остальное.
>Наиболее уязвимый момент — перезапись раздела с ядром Linux и корневой файловой системой.
Угу. Поэтому её вообще часто не трогают никак. У вас прикольно получилось.olegator99 Автор
01.07.2018 19:12какие например? Очень интересно, как можно сделать огромный оверхед на проксировании RTSP внутри камеры. У нас сделать огромный не получилось, наш агент для облака работает на камерах от $8 с шифрованием, проксированием и очень несложным процессом адаптации вендорской прошивки. По крайней мере он сильно проще, чем портирование целой прошивки под очередную комбинацию сенсор+чип+всё остальное.
Ваш комментарий противоречит вашей же статье: https://habr.com/company/erlyvideo/blog/334912/,
в которой вы пишете, что работаете с железом напрямую, получая из железа кадры, и что сделали прошивку на Rust.
По существу: вендоров — огромное количество, адаптироваться под прошивку каждого с учетом осбенностей каждой модели — это очень ресурсоемкий процесс. Чипсетов намного меньше.
Про оверхед — когда всего 38МБ ОЗУ — любые лишнее буфера, которые требуются для "проксирования" — это существенный оверхед. Когда у процессора всего 400MHZ каждый syscall с копированием данных, да это существенный оверхед.
Угу. Поэтому её вообще часто не трогают никак. У вас прикольно получилось.
Т.е. rootfs на обновляют вообще? Как так — в ней находятся системные компоненты, типа dropbear, wpa_supplicant, busybox и т.д.
Что делать, когда в намертво прошитой версии wpa_supplicant или dropbear обнаружится уязвимость?erlyvideo
01.07.2018 19:28У нас есть два решения: наша прошивку, которая является заменой китайскому коду и агент — то, что мы ставим на камеры.
По нашему опыту поставить агента на 400 Мгц камеру с проксированием через TLS — не проблема. Ни с памятью, ни с процессором.
> Что делать, когда в намертво прошитой версии wpa_supplicant или dropbear обнаружится уязвимость?
по мнению длинного ряда производителей — забить длинный китайский болт на это и выпустить новую камеру, у которой телнет с беспарольным рутовым логином.olegator99 Автор
01.07.2018 20:49+1Ну тут такое. Такая конфигурация действительно работает (у нас тоже в варианте с наш плагин+прошивка вендора).
Но, если, например битрейт потока большой, и паралелльно захватывается и пишется на флешку другой поток, то проца и памяти уже может не хватить — и тут как раз вспоминаем про оверхед на RTSP.
Кроме этого в схеме без RTSP высвобождаются дополнительные ресурсы процессора, но более продвинутые аудио и видео аналитики, на которые с RTSP не хватало ресурсов.
erlyvideo
03.07.2018 16:07про аналитику — всё понятно. Нужны сырые данные, чего тут и говорить.
Вот только что перепроверил нашего агента на Hiwatch DS-I114:
Mem: 62076K used, 3092K free, 0K shrd, 5372K buff, 38344K cached
CPU: 10.3% usr 10.9% sys 0.0% nic 75.9% idle 0.0% io 0.0% irq 2.7% sirq
Load average: 11.81 8.36 3.98 1/149 736
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
327 1 admin S < 234m367.3 0 16.9 /home/davinci
728 323 admin S 1736 2.6 0 4.4 /home/peeklio -c /devinfo/peeklio_
603 2 admin SW 0 0.0 0 0.7 [RTW_CMD_THREAD]
39 2 admin DW 0 0.0 0 0.5 [kworker/u:1]
16 2 admin SWN 0 0.0 0 0.4 [ksmd]
порядка 4%
# cat /proc/cpuinfo
Processor : ARM926EJ-S rev 5 (v5l)
BogoMIPS : 218.72
Features : swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 5
Hardware : r2
Revision : 0000
Serial : 0000000000000000
64 MB памяти.
Основное потребление, которое может быть — сетевой буфер для компенсации колебания скорости сети.iTuneDVR
03.07.2018 21:14В той прошивке с агентом, что сделана была под меня, на одной камере раз в 30 минут сервис на камере падал и перезапускался, что отразилось в консольных логах. Что не хватало или был перелив — непонятно.
olegator99 Автор
03.07.2018 22:18Основное CPU time из за RTSP, думаю уходит на davinci, когда он пишет в сокет (write существенно прожерливее, чем read) — а davinci кушает 16% CPU.
R2 кстати не самая бюджетная платформа. У нее 3518С + 128 MB ОЗУ на внешнем DDR, что, кстати, заметно увеличивает стоимость.
Вот самый треш на 3518E, которые используются на бюджетных ezviz-ах и hiwatch — у них 64 MB ОЗУ, из которых 26 отдано под видеоядро.
На них davinci выедает практически всю память...
Stealch
01.07.2018 19:14А под Hiwatch DS-I220 имеется решение? Камера практически идентична Hikvision DS-2CD2042WD-I, модули взаимозаменяемы.
olegator99 Автор
01.07.2018 19:15На такой модели мы не пробовали. Но думаю никаких принципиальных проблем с ней быть не должно.
Stealch
01.07.2018 19:22Да я вообще сильно удивился, когда узнал что эта камера без поддержки ivideon. Столько раз они служили донорами запчастей для более дорогих 2042… честно считал их идентичными, но в ivideon считают не так. Было бы замечательно запилить поддержку для этих камер, ведь по характеристикам они идентичны 2042, за исключением модуля ivideon.
olegator99 Автор
01.07.2018 23:15Не могу дать точный ответит за коллег из ivideon, о причинах отсутствия поддержки.
Могу лишь предположить, что проблема в том, что с завода i220 идут с новой прошивкой, например 5.5.5, а ivideon еще не успел портировать плагин под эту прошивку…
А downgrade на более раннюю прошивку с плагином, которая бы заработала — заблокирован.
Stealch
01.07.2018 23:25Нет, у ivideon нету в списках поддерживаемых моделей этих камер и не было никогда. Про их идентичность и взаимозаменяемость модулей выяснено методом научного тыка. Процессор у i220 все же слабее, в остальном они полностью идентичны — совпадает размер флешки, CMOS, ик-подсветка, разъемы на модулях — любой модуль может быть поставлен на 2042, и будет работать (за исключением основного модуля — иначе получим Hiwatch на выходе). Даже корпус идентичен. Но эти камеры даже не позиционируются как полноценные Hikvision — они идут только с отсылкой — «HiWatch by Hikvision» и часто являются частью комплекта с видеорегистратором. Своего рода бюджетный вариант.
olegator99 Автор
01.07.2018 23:29А сколько у нее RAM? Насколько мне известно, для hikvision камер с 64MB ОЗУ интеграция способом 'прошивка вендора + плагин' практически не возможна, из за причин перечисленных в статье...
Stealch
02.07.2018 00:18К сожалению вытащить эту информацию из камеры у меня не выходит :( В характеристиках не указано (по крайней мере я с наскока найти не смог). В интерфейсе отсутствует кнопка диагностической информации. А вот hikvision DS-2CD2042WD-I отчиталась по-полной, привожу маленький кусочек:
dmesg
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.10.73+ (zhangjianzhong@Cpl-Frt-BSP) (gcc ?? 4.8.2 20130902 (prerelease) (crosstool-NG - Ambarella Linaro Multilib GCC [CortexA9 & ARMv6k] 2013.09) ) #12 PREEMPT Thu Jul 20 11:10:40 CST 2017
[ 0.000000] CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), cr=10c53c7d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine: Ambarella S2L (Flattened Device Tree), model: Ambarella S2LM Kiwi Board
[ 0.000000] dev type:0x0
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] Ambarella: AHB = 0xe0000000[0xe0000000],0x01000000 0
[ 0.000000] Ambarella: APB = 0xe8000000[0xe8000000],0x01000000 0
[ 0.000000] Ambarella: PPM = 0x00000000[0xdfe00000],0x00200000 9
[ 0.000000] Ambarella: AXI = 0xf0000000[0xf0000000],0x00030000 0
[ 0.000000] Ambarella: DRAMC = 0xdffe0000[0xef000000],0x00020000 0
[ 0.000000] Ambarella: DBGBUS = 0xec000000[0xec000000],0x00200000 0
[ 0.000000] Ambarella: DBGFMEM = 0xee000000[0xee000000],0x01000000 0
[ 0.000000] Ambarella: IAVMEM = 0x07000000[ ],0x09000000
[ 0.000000] On node 0 totalpages: 28160
[ 0.000000] free_area_init_node: node 0, pgdat 807d48f8, node_mem_map 80805000
[ 0.000000] Normal zone: 220 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 28160 pages, LIFO batch:7
[ 0.000000] CPU: All CPU(s) started in SVC mode.
[ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 27940
[ 0.000000] Kernel command line: console=ttyS0 KRN_PRT=pri
[ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Memory: 110MB = 110MB total
[ 0.000000] Memory: 103364k/103364k available, 9276k reserved, 0K highmem
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] vmalloc : 0x87000000 - 0xff000000 (1920 MB)
[ 0.000000] lowmem : 0x80000000 - 0x86e00000 ( 110 MB)
[ 0.000000] modules : 0x7f000000 - 0x80000000 ( 16 MB)
[ 0.000000] .text : 0x80008000 - 0x80502750 (5098 kB)
[ 0.000000] .init : 0x80503000 - 0x80793bd4 (2627 kB)
[ 0.000000] .data : 0x80794000 - 0x807dc690 ( 290 kB)
[ 0.000000] .bss : 0x807dc690 - 0x808002b0 ( 144 kB)
[ 0.000000] NR_IRQS:240
[ 0.000000] sched_clock: 32 bits at 54MHz, resolution 18ns, wraps every 79536ms
Подозреваю что У DS-I220 меньше 110 mb, но что либо утверждать не могу, попробую поискать прошивку по-свежее, может тогда она отчитается.olegator99 Автор
02.07.2018 11:36Судя по логу — это вообще R6, на базе чипа ambarella.
Stealch
02.07.2018 12:46Ну мне это практически ни о чем не говорит. В камерном железе я не силен, и единственное что понял — это что архитектура ARM. Я не встречал R6, а вот с камерами hikvision и hiwatch работаю постоянно. Все еще не смог вытащить лог с i220 — не хочет она делиться инфой, похоже придется цеплять ее по rs232, хоть я и слабо представляю как…
olegator99 Автор
02.07.2018 13:23R6 это название программно-аппаратнатной платформы камер Hikvision на чипах Ambarela S2LM.
Про i220 увы, подсказать не могу — не доводилось сталкиваться.Stealch
03.07.2018 05:00Ну как пишет
iTuneDVR
— это R2 серия. Судя по всему Ambarella тоже.
02.07.18 в 19:35
0
I220 — Hikvision R2 серии камер судя по прошивке DS-I114_I120_I122_I126_I128_I220_5.4.3_170316.zip с ftp.hikvision.ru
iTuneDVR
02.07.2018 19:35I220 — Hikvision R2 серии камер судя по прошивке DS-I114_I120_I122_I126_I128_I220_5.4.3_170316.zip с ftp.hikvision.ru
DS-2CD2042WD-I — Hikvision R6 серия камер.
Все разбирается по прошивкам и собирается ;)Stealch
03.07.2018 04:57Для меня тяжеловато будет собрать прошивку под незнакомый девайс с нуля при этом не окирпичив пару-тройку девайсов… что для меня непозволительная роскошь.
iTuneDVR
03.07.2018 13:26Кое-какие сторонние инструменты есть в сети, которыми можно сделать и ту и ту, а так да, с нуля сделать такой инструмент без подсказок и прочего очень не просто.
Цель-то по итогу какая, что туда внедрить какой свой модуль?Stealch
03.07.2018 13:34Цель — поддержка ivideon, ибо мы с ними давно работаем. Сейчас у нас много таких камер с демонтажа, если удастся запилить прошивку с ivideon для них — то на мелкие объекты их можно будет устанавливать без регистраторов и серверов. Судя по сабжу в статье — это вполне реализуемо, притом даже более эффективно, чем предлагают сами ivideon. Процессор на этих камерах все же слабее, так что данное решение очень заманчиво.
iTuneDVR
03.07.2018 21:03Все возможно, было бы желание у ivideon ;)
Слабо, там и ли нет, но на R2 таких работает spacecam и не жужжит, также надавно мне flusonic делал прошивку под подобную камеру с их агентом.
Они добавляют своего пользователя с хитрым паролем и он получает доступ к видео.
Раньше было проще, т.к. пароль в базе был в открытом виде и ivideon его юзал на R0 серии.
В свое время было сделано с костылями для новых R0 и R2 их клиенты.
Не знаю, что там предлагают в ivideon по этому поводу, но
если захотят и не будут ленится то сделают, но крови попьют, а раз ты привыкший то… ;)
Все технические нюансы можно решить. ;)Stealch
03.07.2018 21:37Они ленеивые и им это не выгодно — им лучше продавать свои камеры, чем обеспечивать поддержку дешевых. К тому же им надо и гибридные видеорегистраторы впаривать вместе с подобными камерами, коих у них еще не на одну распродажу на складах, например серия камер OcO, по сути аналогичных этой…
iTuneDVR
03.07.2018 22:16Обвинять их в том, что что им лучше зарабатывать деньги на более выгодном, чем впустую поддерживать чужие камеры, по сути ничего не зарабатывая… не вижу тут проблем, даже я ;)
Хотя есть же их софтовое сервер-приложение которое подключает любые камеры и транслирует, ну не мне объяснять…
В любом случае надо будет решить вопрос с лицензиями, а официально цена вопроса для обычных пользователей — волосатая…
Но, как и говорил, при определенных условиях и отсечение лишнего вполне возможно поднять встроенный сервис на R2 серии, но…
Тема не вчерашняя…
Stealch
03.07.2018 22:20Может ткнете носом где брать сырцы как прошивки, так и модуля ivideon? Попытаюсь собрать что-либо работоспособное… надеюсь не слишком много камер превращу в кирпичи =))
iTuneDVR
03.07.2018 22:37Чтобы не убить все камеры, надо работать только с одной, к тому же там загрузчики не затрагивается, поэтому сразу не убить ;)
Если не решен вопрос с лицензиями, то все остальное беЗполезно.
Почему не устраивает вариант iVideon Server?Stealch
03.07.2018 22:49Потому что сервер. На мелких объектах (1-2 камеры) лучше предлагать решение без доп. оборудования для занижения ценового барьера.
iTuneDVR
03.07.2018 23:11Сервер можно в на VPS засунуть и не держать на объекте.
Да, понимаю, что удобней будет сразу, и без лишних проблем и завязок, но я не встречал адекватных вариантов, хотя обращались многие по поводу изготовления или готовой прошивке, но у всех желание отбивала цена за лицензию ivideon.
В любом случае нюансов много, и получится так, что сделать можно, но прошивка старая и,… а на новой или специальной надо кое-что допиливать до полноценного.
Как написано выше, если есть много свободного времени, непреодолимое желание оптимизировать свои затраты и пристроить имеющуюся технику, то все возможно.
Сторонние инструменты не рекламирую, чтобы не породить вопросов, а как ими пользоваться. Своими пользуюсь сам и не задаю никаких вопросов. ;)
jonywtf
01.07.2018 19:26Хотелось написать обзорную статейку, но оставлю пока комментарий.
ZigFisher ведет работу над похожим открытым решением на базе openwrt!
zftlab.org/pages/2018020900.html
github.com/ZigFisher/chaos_calmer
github.com/ZigFisher/Glutinium
Группа общая по модификации прошивок: t.me/joinchat/FhtyHxDpQsv8HlRliQDgqw
Группа по разработке прошивки на базе openwrt: t.me/joinchat/FhtyHwrU0fwfQlAkvoeVJA
Пытаемся привести китайские ядра из sdk от разных чипов разных ревизий (hi3516c, hi3518e, hi3520d) к какому-то одному и вынести в конфиг то, что разработчики захардкордили через #define. А то собирать слишком много и долго) Инициализация библиотек сенсоров, конфиг драйвера ethernet, но пока с переменным успехом… Работа идет, но не хватает скилов, а еще больше времени!
Если кто-то хочет попробовать собрать и запустить, то подготовил сборку прошивки и ядер в докере: github.com/chertov/camopenwrt_docker
Очень буду рад если кто-то присоединится, поможет, проявит интерес)
На данный момент смогли запустить открытую прошивку, получили изображение в виде jpg, сжатые фреймы в h264, тестовый поток rtsp. Фактически просто причесали китайскую демку. Сейчас все это прилично глючит и факт успешного запуска на произвольной камере зависит от погоды на луне) Если интересно, то в группах могут подсказать конкретные бюджетные модели плат чип+сенсор+провода или целиком камер.
Исходники на базе китайской демки тут github.com/ZigFisher/Glutinium/tree/master/hisi-sample/src
А еще мы собрали gstreamer последней версии с поддержкой webRTC! Попробуем построить p2p стриминг видео на его базе сразу в браузер или на мобилки.
Авторы статьи молодцы, качественное решение в сфере видеонаблюдения давно необходимо!!! Это как раз одна из причин появления открытого проекта! Железо в камерах еще ничего, но софт просто ужасен… естественно очень бы хотелось посмотреть на Ваш вариант модификации кода загрузчика и ядра, код uboot и ядер вроде же под GPL, китайцы его поставляют в составе sdk.
Также в свободное время пилю небольшой сервис для проброса ethernet, uart, spi (для перепрошивки флеш памяти камеры) и gpio (управление питанием камеры) на машины разработчиков или в контейнеры CI через облако. А то (лично мне) с железом не очень-то и удобно работать, тем более когда камер много…
Хотелось бы дать возможность сообществу шарить свои камеры разработчикам и системе тестирования и т.д!erlyvideo
01.07.2018 19:31+2github.com/ZigFisher/Glutinium/blob/master/hisi-sample/src/ringfifo.c#L169
не надо так. Берите младшие 5 бит, у SPS номер 7, а не 67.
olegator99 Автор
01.07.2018 21:05+1Класс! Спасибо за ссылки на чатики сообщества.
Идея сделать универсальное ядро под hisi — огонь, но не представляю как его дружить с модулями отвечающими за видеозахват. Они в SDK идут без исходников, и ооооочень большая вероятность, что они просто не заведутся на свежем ядре.
Показать наши патчи ядра и uboot — не проблема (хотя они на самом деле минимальны — не думаю, что от них будет какая то польза )
Проект с удаленым доступом к железу — интересная история, мы тоже ± работаем над похожей задачей. Будет интересно посмотреть, что у вас получается.
ZigFisher
01.07.2018 21:29+1Версию ядра мы оставляем какая есть от Хайсиликона под конкретный чип (v1 = 3.0.8, v2 = 3.4.35, v3 = 3.18.20) но собираем всё в среде OpenWrt, что даёт свои преимущества.
На свежем ядре можно собрать универсальную прошивку, но толку от неё будет мало, т.к. действительно, имеющиеся только в бинарном виде драйвера для видео работать не будут.olegator99 Автор
01.07.2018 22:19+1Ага, еще есть 3.10.x на 3516A/D, но это уже отдельная история...
А с libc и gcc так же поступаете, или удалось привести к общему знаменателю?
ZigFisher
01.07.2018 23:18+1В OpenWrt — общий знаменатель, т.е. меняется только ядро и модули ядра к видео, остальное всё одинаковое.
RafaelRS
01.07.2018 22:52+4Неплохо. Один из тот случаев, когда справедливым оказывается тот факт, что выгоднее заплатить хорошую зарплату хорошему программисту пусть даже на миллион долларов, чем потратить гораздо больше в случае, когда его нет.
Надеюсь разработчиков не обидели ;)
geisha
01.07.2018 23:59И на момент старта разработки целесообразно работать только с 1-ним вендором, что бы сосредоточить усилия команды на разработке логики работы с облаком.
Дальше не читал потому что мои 2-ва глаза выпали.
reversecode
02.07.2018 10:01В 2016 году мы стартовали разработку платформы облачного видеонаблюдения для Ростелекома.
а вы это кто — ivideon?reversecode
02.07.2018 10:12ага увидел, videocomfort, кстати ссылки с сайта на иос и андроид ведут в космос, приложений нет
olegator99 Автор
02.07.2018 10:55Приложения сейчас называются "Умный дом ростелеком" и "Видеонаблюдение ростелеком". ссылки поправим — спасибо!
AlKozlov
02.07.2018 14:43Также на сайте нет тарифов, регистрация через ВК не работает, при регистрации через ФБ и создании пароля вылазит «Plan не может быть пустым». Сервис videocomfort как самостоятельный продукт не существует больше?
olegator99 Автор
02.07.2018 20:02Новых пользователей к Видеокомфорту больше не подключаем.
За багрепорты еще раз спасибо — поправим поведение в этом месте.
viktordenisenko
02.07.2018 12:10А вот такую камеру вы можете прошить? Она работает с приложением YCC365 www.alibaba.com/product-detail/Motion-detection-alarm-alert-cloud-storage_60740861286.html?spm=a2700.7724838.2017115.23.13b35390Z9KXEK
olegator99 Автор
02.07.2018 13:21Нет. Судя по описанию у нее чипсет Grainmedia 8135S, мы пока его не поддерживаем.
viktordenisenko
02.07.2018 14:31У нас такая проблема: изображение у китайских камер отстает от PTZ свайпа временами до 5 сек. Кроме того, у китайцев выскакивает реклама, а иногда сервис вообще не работает. Поэтому мы хотели сделать свой клиент и свой видеосервис и расположить его на хорошем сервере, чтобы задержку свести к минимуму. Но нет никаких данных о протоколах и как прошить в камеру IP адрес сервера, пароли, серийный номер. Китайцы SDK не дают.
Можете что-то подсказать? А если у вас получится и эту камеру перепрошить — обязательно сообщите, деньги заплатим :-)erlyvideo
02.07.2018 18:56погоня за дешевыми камерами тоже имеет свои пределы.
Имеется ввиду, что можно взять hikvision 3518 вместо аксиса и получить рабочее решение под определенные задачи.
Но есть сильное подозрение, что на GM (grainmedia) может и не получится сделать приличного решения под какую-либо задачу.viktordenisenko
03.07.2018 08:16К сожалению, у hikvision нет подходящих камер. Нужна маленькая, легкая, PTZ, с подходящим дизайном. Мы ее ставим на такого робота: boteyes.ru/ToTripRus.aspx.
erlyvideo
03.07.2018 10:02у нас что-то подобного плана валялось в офисе и вроде мы туда даже прошивались.
Было и на GM и на чем-то ещё. Посмотрю, чего есть.
olegator99 Автор
03.07.2018 10:22Хороший у вас робот — мне понравился :)
На ali есть широкий выбор недорогих и маленьких PTZ камер ± похожих по дизайну (например такая)[https://ru.aliexpress.com/item/Lintratek-HD-1080-P/32841830056.html]. Но по картинкам и спекам затрудняюсь сказать про то, на каком они чипсете, и насколько хороши.
viktordenisenko
03.07.2018 11:56Мы покупали у 7 китайских производителей камеры для тестирования. Для нас главное — чтобы задержка изображения была менее 1 сек, иначе получается, что робот уже поехал, а по изображению кажется, что он стоит на месте. Вот из этих камер только та, на которую я дал ссылку, самая хорошая. У нее облако на AWS Амазона, но приложение иногда посылает за обновлениями на левые ресурсы, показывает рекламу и камера подключается не сразу. А после обновления может вообще не работать.
olegator99 Автор
03.07.2018 22:34Посмотрите — есть ли среди них камеры на hisilicon. Это можно понять либо подключившись к UART — по логу загрузки, либо по маркировке чипа.
olegator99 Автор
02.07.2018 19:18Ну в данном случае перепрошить — означает разработать прошивку для этого чипсета. В это входит как портирование видеоприложения (наиболее сложная задача), так и подготовка системы сборки ядра/рутфс.
У нас вот пока таких планов нет — лично я не видел ни одной камеры на GM, которую было бы не стыдно предложить клиентам…
Если на GM появятся более менее приличные по потребительским свойствам камеры — то с удовольствием посмотрим на них более серьезно.
basmaxx
02.07.2018 19:13+100500 Сам несколько лет устанавливал такие камеры: За 1500 руб. получаешь PTZ, хорошую подстветку и двухстороннюю аудисвязь. + в 2 шага без танцев прикручиваются к NAS Synology. Рандомное исходное качество компенсируется низкой ценой. Но над софтом конечно надо поработать, к сожалению сам не осилил, максимум отвязал от китайских облаков.
viktordenisenko
03.07.2018 08:20«максимум отвязал от китайских облаков» — т.е. привязал к другому облаку? Это очень интересно. Можете поделиться идеями?
ZigFisher
03.07.2018 12:44Посмотрите пожалуйста вот тут — zftlab.org/pages/2018010500.html
Там у меня в ссылках была подборка различной инфо, в том числе о SDK и RTSP демоне на GitHub
kresh
02.07.2018 12:49А работаети ли вы с ip камерами с динамиком, приводами(по осям) и датчиками(освещенность, звук, температура)? Интересует возможность использования такой камеры для умного дома, но со своим приложением.
olegator99 Автор
02.07.2018 13:19Да, работаем. У нас есть поддержка динамика (Push-To-Talk) функционал. Есть поддержка PTZ (тут важна модель камеры, т.к. аппаратно механизм управления моторами сильно отличается от камеры к камере).
Датчик звука так же есть, это по сути "аудио-аналитика" — модуль в приложении, который мониторит уровень звука на микрофоне, и при превышении порога отправляет событие в облако.
ChemodaH
02.07.2018 13:34Не сочтите за рекламу.
Мы пользуемся облачным сервисом видеонаблюдения TRASSIR Cloud: cloud.trassir.com
С ним работaют камеры от 2990р. www.citilink.ru/catalog/photo_and_video/video_observation/cctv_cams/1030858
olegator99 будет ли ваша прошивка с этими камерами работать?
Кстати, и для камер HiWatch у них вроде тоже есть облачная прошивка: www.dssl.ru/support/tech/support_ip/cloud.phpolegator99 Автор
02.07.2018 19:38Значит ребята молодцы, и неплохо оптимизировали свой облачный плагин.
Если камеры на hisilicon (а по внешним признакам это похоже он), то не вижу больших сложностей портировать нашу прошивку на эти камеры...
Sat0shi
02.07.2018 19:20Xiaomi XiaoFang Smart Camera Wi-Fi (FullHD) 1451р + github.com/samtap/fang-hacks/releases (RTSP + печеньки) + ivideon = Profit
olegator99 Автор
02.07.2018 19:35Спасибо за ссылку.
Если я правильно понял, то что бы работать с ivideon нужна отдельная железка для запуска ivideon сервера
И итоговое решение будет стоит 1451р + (стоимость железки для запуска ivideon сервера)...
Sat0shi
02.07.2018 19:57Да, подойдёт Неттоп.
olegator99 Автор
02.07.2018 21:12Судя по яндекс маркету минимальная цена на неттоп — 5т.р. итого возвращаемся к решению за 5т.р.+ :)
divanus
03.07.2018 09:55-2Зачем в принципе использовать рт или иви для облака? Платить бешенные деньги, когда можно спокойно все своё реализовать — это дешевле. И да, видео писать надо по движению.
нафиг даже с серым IP все легко и просто решается и такие прокладки как говнодеон и его клон от рт нафиг не нужны. Лет 10 как своё все работает успешно:
любой говнороутер с прошивкой опенврт, любой опсососвский модем, пара аккумуляторов, бп и говнокамера любая. И всё отлично пашет. За доллар в месяц любой говнохостинг, на котором openSSH развернут. И всё.AllexIn
03.07.2018 10:49+1Вот смотрите.
У нас два дома рядом, без забора.
В одном — я, моя жена и ребенок.
В другом — мои родители, сестра, её муж и дети.
У нас общая локальная сеть. У нас общая система видео наблюдения.
НАстроен сервер на Linux + ZM. Проложены IP камеры.
Я слежу за этим хозяйством.
Завтра я уехал/умер.
Что будет?
Пол года, может год система проживет в лучшем случае без вмешательства. Дальше — гикнется один из винчестеров на сервере, или обновление уронит систему, или сервер отключат и не смогут включить.
И что делать?
Админа нанимать?
А с облачными камерами — работают и работают. В локалку их воткнул, по инструкции настроил и ОК. Если что-то сломалось — пишешь в саппорт. Решаешь проблему. Сломалась камера — выкидываешь, и ставишь новую вместо неё. Любой справится.
Orient
03.07.2018 11:59Могли бы вы объяснить как можно получить образ Linux свой кастомный (под определённое железо). Как получить 3.5 МБ размер? Есть какие-нибудь туториалы?
Craggy
03.07.2018 12:57+2Мы используем следующие хинты для уменьшения размера ядра:
1) Из конфига ядра убрано определённое количество фич в сравнении с конфигом от вендора, которые мы не используем, и которые не влияют на работоспособность.
2) Все shared libraries (и всё что можно безболезненно) мы стрипаем. Это также рекомендует linuxfromscratch:
www.linuxfromscratch.org/lfs/view/stable/chapter05/stripping.html
3) В само ядро мы включаем rootfs: урезанный busybox (дефолтная поставка тоже занимает место). Сама rootfs ужимается с lzma и подключается как initramfs, как написал Олег в статье.
gromka
03.07.2018 12:03Сорян, а зачем каждый раз покупать новые камеры на выборы? Что мешает использовать камеры с прошлых выборов или например с егэ? Отсутсвие отката?
olegator99 Автор
03.07.2018 22:39Тут такое — на самом деле во многих избирательных участках оставались старые ПАК (ноуты с вебкамерами, еще с выборов 2012 года). Они уже морально и физически устарели — сыпались по просту. Все же 6 лет прошло. В основном их меняли.
P.S. Ну вообще я за технику отвечаю, вопросы про закупки и прочее с этим связанное — это не ко мне.
Balagan
03.07.2018 13:53Можно ссылку на Ваш облачный сервис и список поддерживаемых камер?
olegator99 Автор
03.07.2018 22:24camera.rt.ru — на нем сейчас практически полный спектр моделей Hikvision
smarthome.rt.ru — тут сейчас только Hikvision vc1w, который достаточно дорогой и на запуске сервиса использовался вариант прошивка Hikvision + наш плагин, а сейчас мы их переводим на нашу прошивку.
В скором времени +9 моделей начиная от бюджетных моделей на 3518E, с 64MB ОЗУ
ZigFisher
03.07.2018 14:12Из интересных облачных сервисов в последнее время еще неплохо себя зарекомендовал ipeye.ru (не реклама, я там и на них НЕ работаю).
Ребята написали удачный миниатюрный плагин, при помощи которого интегрируют к себе на сервис камеры различных производителей железа (в том числе «отвёрточных») и по-этому процесс интеграции быстр, лёгок, а так-же может быть протестирован практически на любом железе путём записи плагина в RW раздел, в котором сохраняются настройки камеры. Прайсы этой компании я обсуждать не буду, но бесплатный тариф на просмотр видео с камеры, стоящей далеко и за NAT-ом, крайне радует меня и друзей-гиков. Родное встроенное китайское облако выключено и забыто как страшный сон.
Еще забыл выше упомянуть, что помимо экспериментов с OpenWrt потихоньку развивается тема и «моддинга» прошивок для XM, JVT, Topsee и прочих производителей видеокамер бюджетного сегмента.reversecode
03.07.2018 17:49Для подключения камеры к облачному сервису вам не нужно устанавливать специальное программное обеспечение
ни слова про миниатюрный плагин там нетZigFisher
03.07.2018 18:15Это если камеры брать у них или их партнёров-производителей, всё внутри.
Я-же говорю всего-лишь как это сделано технически (про плагин).
Ссылки на прошивки под популярные типы плат XM я привёл выше.
Покупайте плату на Алиэкспесс, заливайте прошивку — и в облака ;)reversecode
03.07.2018 18:20Я только хотел на мини плагин посмотреть, что то не нашел, как он называется в прошивке?
ZigFisher
03.07.2018 18:31Выполните ps в прошивке, он сразу запущен и на виду.
reversecode
03.07.2018 19:42Да зачем что то запускать, когда хочу только в прошивке посмотреть.
Нашел ipeye демон, vtund итд да уж…
Помню в детстве, когда был маленьким меня взрослые научили делать рацию, два спичечных коробка и между ними натягивается нитка
Эти облачные сервисы сделаны еще похлеще моей рации, webrtc укатается от смехаZigFisher
03.07.2018 20:31К проекту ipeye.ru имеет отношение только одноимённый демон, а vtund никакого отношения к ним не имеет.
Сильно язвить Вам, думаю, не стоит, так как скорее всего Вы даже не читали какие эксперименты проводятся и какие цели преследуются в этих тестовых сборках прошивок, а вот показать или рассказать присутствующим на Хабре о своих, как я понимаю более перспективных и взрослых разработках связанных с Webrtc, дело достойное не мальчика, но мужа…reversecode
03.07.2018 20:46про vtund я упомянул что бы дать понять что я нашел где оно все гуськом лежит
да я не только о вас, я озвучил свои мысли по поводу всего что я уже смотрел и наблюдаю в целом о этих облачных видео наблюдениях
— а где почитать по какие цели преследуете и эксперименты ставите?ZigFisher
03.07.2018 20:55Там не только ipeye и vtund, там есть mqtt, ssh/scp, ftp, curl, телеметрия и куча других мелких но полезных фишек интегрировано. Ссылка выше в комменте была моём про ipeye, если не увидели — слово «моддинг».
Вариантов облачных наблюдений сейчас уже мешочек разных на самом деле. Просто ipeye своим маленьким демоном гармонично вписался в подборку нашего проекта, а основная суть моего рассказа была в том, что его можно запустить даже не меняя родную прошивку на камере, вот и всё. Если есть возможность сменить прошивку — естественно, все эти разработки становятся ненужны автоматически.reversecode
03.07.2018 21:53да это все понятно,
где почитать по какие цели преследуете и какие эксперименты ставите?
или цели — это что то для себя
а эксперименты это всяческие сервисы которые туда понапихали в моддинг?ZigFisher
03.07.2018 22:18Если речь про моддинг — расширение функционала, который детально описан по ссылке выше. Там-же указана и группа в телеграме, в которой присутствуют как разработчики и сотрудники различных сервисов, гуру кодинга и embedded реверс-инжиниринга так и просто интересующиеся. Обмен опытом, поиск неисправностей и багов, обсуждение интересных програмных и аппаратных решений. А в параллельной ветке все наработки постепенно переводятся на OpenWrt рельсы.
zxweed
прошивка доступна?