Не могу дать точный ответит за коллег из ivideon, о причинах отсутствия поддержки.
Могу лишь предположить, что проблема в том, что с завода i220 идут с новой прошивкой, например 5.5.5, а ivideon еще не успел портировать плагин под эту прошивку…
А downgrade на более раннюю прошивку с плагином, которая бы заработала — заблокирован.
Идея сделать универсальное ядро под hisi — огонь, но не представляю как его дружить с модулями отвечающими за видеозахват. Они в SDK идут без исходников, и ооооочень большая вероятность, что они просто не заведутся на свежем ядре.
Показать наши патчи ядра и uboot — не проблема (хотя они на самом деле минимальны — не думаю, что от них будет какая то польза )
Проект с удаленым доступом к железу — интересная история, мы тоже ± работаем над похожей задачей. Будет интересно посмотреть, что у вас получается.
Ну тут такое. Такая конфигурация действительно работает (у нас тоже в варианте с наш плагин+прошивка вендора).
Но, если, например битрейт потока большой, и паралелльно захватывается и пишется на флешку другой поток, то проца и памяти уже может не хватить — и тут как раз вспоминаем про оверхед на RTSP.
Кроме этого в схеме без RTSP высвобождаются дополнительные ресурсы процессора, но более продвинутые аудио и видео аналитики, на которые с RTSP не хватало ресурсов.
Иногда можно, но не всегда поможет.
Даже один и тот же сенсор может быть подключен по разному схемотехнически в разных камерах. А от этого зависят настройки режима захвата видео…
Кроме этого узнать к каким GPIO подключены светодиоды/кнопки/IRLed/IRCut — вообще не возможно впринципе...
Единственное — wifi чип можно опознать по USB vid/pid, и то если он подключен по USB, а не по SDIO.
Ну мы выкручиваемся так: код модели камеры зашита в разделе env, а в самой rootfs есть реестр поддерживаемых моделей и описание оборудования которое соотвествует этой модели.
А kernel+rootfs и application универсален для всего семейства чипов.
какие например? Очень интересно, как можно сделать огромный оверхед на проксировании RTSP внутри камеры. У нас сделать огромный не получилось, наш агент для облака работает на камерах от $8 с шифрованием, проксированием и очень несложным процессом адаптации вендорской прошивки. По крайней мере он сильно проще, чем портирование целой прошивки под очередную комбинацию сенсор+чип+всё остальное.
Ваш комментарий противоречит вашей же статье: https://habr.com/company/erlyvideo/blog/334912/,
в которой вы пишете, что работаете с железом напрямую, получая из железа кадры, и что сделали прошивку на Rust.
По существу: вендоров — огромное количество, адаптироваться под прошивку каждого с учетом осбенностей каждой модели — это очень ресурсоемкий процесс. Чипсетов намного меньше.
Про оверхед — когда всего 38МБ ОЗУ — любые лишнее буфера, которые требуются для "проксирования" — это существенный оверхед. Когда у процессора всего 400MHZ каждый syscall с копированием данных, да это существенный оверхед.
Угу. Поэтому её вообще часто не трогают никак. У вас прикольно получилось.
Т.е. rootfs на обновляют вообще? Как так — в ней находятся системные компоненты, типа dropbear, wpa_supplicant, busybox и т.д.
Что делать, когда в намертво прошитой версии wpa_supplicant или dropbear обнаружится уязвимость?
У нас есть утилита, которая позволяет бэкапнуть, а в последующем восстановить родную прошивку.
Естественно, если бэкап не сделан, то вернуть на родную прошивку будет сложнее — прийдется искать такую же камеру с оригинальной прошивкой, что бы с нее снять бэкап.
Не совсем. Камеры все же отличаются по железу (разные сенсоры, разные wifi модули, разные GPIO, разные DDR).
Поэтому, просто так установить не получится — необходимо, что бы прошивка знала специфику оборудования, и что бы в ней были необходимые дрова сенсора и wifi модуля.
Эта статья выглядит как пропаганда цензуры, скрытой за "якобы беспристрастным описанием фаервола в китае".
Технической информации нифига нет. Странно видеть общие слова про DNS/блокировки, без всяких технических деталей — это же хабр, а не первый канал ТВ. Где тех-подробности, а?
В статье понятие цензуры подменено понятием "информационной безопасности", об этом уже много писали в комментах. Авторы, будьте честными, хотя бы сами с собой!
Однобокое представление информации — ни слова об отрицательном влиянии "китайского файрвола", однако в заключении статьи авторы пытаются доказать, что "цензура — это не страшно"
По памяти — минимальный, практически не виден на приборах. По скорости работы зависит от хоста, примерно так:
На Linux включение профайлинга кучи в tcmalloc снижает скорость работы приложения в среднем раз в 5-10.
На OSX (и возможно на BSD) — снижение скорости в 1.5 — 2 раза.
Про tcmalloc:
В комплекте с pprof это очень мощный инструмент, который позволяет прямо в RUNTIME в любой момент следить за всей памятью выделенной приложением, даже tcmalloc на вашем хосте не умеет leak detection.
Выглядит как то так:
pprof --inuse_objects http://127.0.0.1:9088/debug/pprof/heap
Using remote profile at http://127.0.0.1:9088/debug/pprof/heap.
Fetching /pprof/heap profile from http://127.0.0.1:9088/debug/pprof/heap to
/Users/ogerasimov/pprof/reindexer_server.1524898743.127.0.0.1.pprof.heap
Wrote profile to /Users/ogerasimov/pprof/reindexer_server.1524898743.127.0.0.1.pprof.heap
Welcome to pprof! For help, type 'help'.
(pprof) top
Total: 976926 objects
269535 27.6% 27.6% 446325 45.7% reindexer::IndexUnordered::Upsert
263687 27.0% 54.6% 263687 27.0% reindexer::make_key_string
139063 14.2% 68.8% 139063 14.2% __hash_table::__construct_node_hash
138999 14.2% 83.0% 138999 14.2% reindexer::PayloadValue::PayloadValue
110115 11.3% 94.3% 330296 33.8% reindexer::IndexStore::Upsert
35548 3.6% 98.0% 37827 3.9% btree::btree::rebalance_or_split
11212 1.1% 99.1% 11212 1.1% reindexer::h_vector::reserve
1041 0.1% 99.2% 39690 4.1% btree::btree::internal_insert
1008 0.1% 99.3% 28663 2.9% reindexer::IdSet::Add
960 0.1% 99.4% 960 0.1% leveldb::::HandleTable::Resize
Что бы это работало, в свое приложение надо добавить весьма тривиальную обработку вызова нескольких http методов для pprof
Посмотрите на современные инструменты. Например, мы для автотестов C++ кода используем набор из Gitlab CI + ASAN + TSAN + gcov + gtest + gbenchmark.
Если проект большой и давно живет, а автотестов в нем нет совсем, то дешевле всего его обмазать внешними, тестами — они позволяют приложив минимум усилий, дать максимум уверенности, что все работает так как надо. (следующий шаг это unit тесты c gtest/gbenchmark, они дадут более информативную диагностику, но их внедрить сильно дороже)
Объем инфраструктуры который требуется:
виртуалка(-и) для Gitlab (наверняка у вас уже есть)
виртуалка(-и) для запуска GitLab CI runner-ов
Для небольших команд ~10 человек — вся эта инфраструктура спокойно влезет на 2 виртуалки работающие на 1-м физическом сервере.
Общий подход примерно такой:
в билд системе добавляете target-ы для сборки нескольких вариаций инструментированного бинаря:
Делаете набор мок сервисов (например, на том же python, изображающих реальные сервисы, с которыми работает ваше ПО).
Делаете тестовое приложение, которое изображает из себя клиента, и содержит набор тест кейсов (типа в такой то — последовательности сходить в методы API тестируемого ПО/и проверить результаты). В качестве инструмента подойдет тот же python, для него есть ряд фреймворков для этой задачи.
В gitlab-ci добавляете pipeline тестов, в которых рядом запускаются мок сервисы+тестируемое ПО+в том же раннере запускаете по очереди тест кейсы.
По завершению тестов шлете приложению SIGTERM.
Конечно, шаги 2) и 3) потребуют вложить заметное количество усилий, но они себя очень быстро окупят.
Что имеем на выходе:
1) проверка что, ничего не утекло (после выхода бинарь инструментировнный ASAN выдаст список того, что утекло)
2) убедимся, что не было рейсов (TSAN сборка в этом поможет)
3) сможем посмотреть глазами, какой процент кода оказался покрыт нашими тестами (gcov инструментарий даст общий % покрытия и подробный репорт, и покажет в какие строчки попадало управление, а в какие нет). На основании этой информации расширяете покрытие тестами.
И это все работает в весьма скромной аппаратной инфраструктуре.
На практике, в нагруженных системах запросы, даже по ID не пропускают в БД сразу, а отдают из in-memory кэша, например как было у ivi. А это вызывает необходимость поддерживать консистентность данных сразу в трех местах: БД, кэш, Sphinx 2.x.
Не могу дать точный ответит за коллег из ivideon, о причинах отсутствия поддержки.
Могу лишь предположить, что проблема в том, что с завода i220 идут с новой прошивкой, например 5.5.5, а ivideon еще не успел портировать плагин под эту прошивку…
А downgrade на более раннюю прошивку с плагином, которая бы заработала — заблокирован.
Ага, еще есть 3.10.x на 3516A/D, но это уже отдельная история...
А с libc и gcc так же поступаете, или удалось привести к общему знаменателю?
Класс! Спасибо за ссылки на чатики сообщества.
Идея сделать универсальное ядро под hisi — огонь, но не представляю как его дружить с модулями отвечающими за видеозахват. Они в SDK идут без исходников, и ооооочень большая вероятность, что они просто не заведутся на свежем ядре.
Показать наши патчи ядра и uboot — не проблема (хотя они на самом деле минимальны — не думаю, что от них будет какая то польза )
Проект с удаленым доступом к железу — интересная история, мы тоже ± работаем над похожей задачей. Будет интересно посмотреть, что у вас получается.
Ну тут такое. Такая конфигурация действительно работает (у нас тоже в варианте с наш плагин+прошивка вендора).
Но, если, например битрейт потока большой, и паралелльно захватывается и пишется на флешку другой поток, то проца и памяти уже может не хватить — и тут как раз вспоминаем про оверхед на RTSP.
Кроме этого в схеме без RTSP высвобождаются дополнительные ресурсы процессора, но более продвинутые аудио и видео аналитики, на которые с RTSP не хватало ресурсов.
Иногда можно, но не всегда поможет.
Даже один и тот же сенсор может быть подключен по разному схемотехнически в разных камерах. А от этого зависят настройки режима захвата видео…
Кроме этого узнать к каким GPIO подключены светодиоды/кнопки/IRLed/IRCut — вообще не возможно впринципе...
Единственное — wifi чип можно опознать по USB vid/pid, и то если он подключен по USB, а не по SDIO.
Ну мы выкручиваемся так: код модели камеры зашита в разделе env, а в самой rootfs есть реестр поддерживаемых моделей и описание оборудования которое соотвествует этой модели.
А kernel+rootfs и application универсален для всего семейства чипов.
А так да, никакого плаг & плэй (
На такой модели мы не пробовали. Но думаю никаких принципиальных проблем с ней быть не должно.
Ваш комментарий противоречит вашей же статье: https://habr.com/company/erlyvideo/blog/334912/,
в которой вы пишете, что работаете с железом напрямую, получая из железа кадры, и что сделали прошивку на Rust.
По существу: вендоров — огромное количество, адаптироваться под прошивку каждого с учетом осбенностей каждой модели — это очень ресурсоемкий процесс. Чипсетов намного меньше.
Про оверхед — когда всего 38МБ ОЗУ — любые лишнее буфера, которые требуются для "проксирования" — это существенный оверхед. Когда у процессора всего 400MHZ каждый syscall с копированием данных, да это существенный оверхед.
Т.е. rootfs на обновляют вообще? Как так — в ней находятся системные компоненты, типа dropbear, wpa_supplicant, busybox и т.д.
Что делать, когда в намертво прошитой версии wpa_supplicant или dropbear обнаружится уязвимость?
У нас есть утилита, которая позволяет бэкапнуть, а в последующем восстановить родную прошивку.
Естественно, если бэкап не сделан, то вернуть на родную прошивку будет сложнее — прийдется искать такую же камеру с оригинальной прошивкой, что бы с нее снять бэкап.
Технически, RTSP у нас в прошивке есть, и в некоторых проектах он используется.
Не совсем. Камеры все же отличаются по железу (разные сенсоры, разные wifi модули, разные GPIO, разные DDR).
Поэтому, просто так установить не получится — необходимо, что бы прошивка знала специфику оборудования, и что бы в ней были необходимые дрова сенсора и wifi модуля.
Обычно прошивка либо устанавливается вендором на заводе, либо приезжает через 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
Эта статья выглядит как пропаганда цензуры, скрытой за "якобы беспристрастным описанием фаервола в китае".
А вот были таки мысли. Время только найти бы на это
По памяти — минимальный, практически не виден на приборах. По скорости работы зависит от хоста, примерно так:
На Linux включение профайлинга кучи в tcmalloc снижает скорость работы приложения в среднем раз в 5-10.
На OSX (и возможно на BSD) — снижение скорости в 1.5 — 2 раза.
deleted
Про tcmalloc:
В комплекте с pprof это очень мощный инструмент, который позволяет прямо в RUNTIME в любой момент следить за всей памятью выделенной приложением, даже tcmalloc на вашем хосте не умеет leak detection.
Выглядит как то так:
Что бы это работало, в свое приложение надо добавить весьма тривиальную обработку вызова нескольких http методов для pprof
По существу, про C++ все так и есть. По форме — имхо стоит быть терпимее к просчетам других людей.
Посмотрите на современные инструменты. Например, мы для автотестов C++ кода используем набор из Gitlab CI + ASAN + TSAN + gcov + gtest + gbenchmark.
Если проект большой и давно живет, а автотестов в нем нет совсем, то дешевле всего его обмазать внешними, тестами — они позволяют приложив минимум усилий, дать максимум уверенности, что все работает так как надо. (следующий шаг это unit тесты c gtest/gbenchmark, они дадут более информативную диагностику, но их внедрить сильно дороже)
Объем инфраструктуры который требуется:
Для небольших команд ~10 человек — вся эта инфраструктура спокойно влезет на 2 виртуалки работающие на 1-м физическом сервере.
Общий подход примерно такой:
Конечно, шаги 2) и 3) потребуют вложить заметное количество усилий, но они себя очень быстро окупят.
Что имеем на выходе:
1) проверка что, ничего не утекло (после выхода бинарь инструментировнный ASAN выдаст список того, что утекло)
2) убедимся, что не было рейсов (TSAN сборка в этом поможет)
3) сможем посмотреть глазами, какой процент кода оказался покрыт нашими тестами (gcov инструментарий даст общий % покрытия и подробный репорт, и покажет в какие строчки попадало управление, а в какие нет). На основании этой информации расширяете покрытие тестами.
И это все работает в весьма скромной аппаратной инфраструктуре.
На практике, в нагруженных системах запросы, даже по ID не пропускают в БД сразу, а отдают из in-memory кэша, например как было у ivi. А это вызывает необходимость поддерживать консистентность данных сразу в трех местах: БД, кэш, Sphinx 2.x.