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

Как мы прошли путь от разработки прошивок для каждой камеры до создания универсального SDK для вендоров камер

Блог компании РостелекомНастройка LinuxРабота с видеоРазработка под LinuxРазработка для интернета вещей
Всего голосов 15: ↑12 и ↓3 +9
Просмотры3.8KКомментарии 15

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

от каких объемов китайцы согласны использовать чужой sdk вместо своего?

Зависит от размера вендора. В среднем, как правило, на партиях от нескольких тысяч штук.

Не понял, зачем делать целый BSP, если вам надо только видеопоток забрать из камеры? Почему бы не послать китайцам ваше приложение, которое они бы просто добавили в свои собственные прошивки и всё?

Захват и трансляция видеопотока это далеко не единственная функция прошивки. Софт отвечает за настройку параметров аудио/видео, за обратный канал аудио, за видео- и аудио- аналитики (детекторы событий — например движения и анормального звука), управление PTZ и т.д. и т.п. Кроме этого. нужно реализовать механизм обновления прошивок.
Подстраиваться под API каждого вендора камер (которых намного больше чем используемыз SoC) никаких ресурсов не хватит. И это не говоря о поддержке и выпуске обновлений.


А еще во многих случаях китайские прошивки содержат дыры/бэкдоры и много ненужного функционала который с одной стороны снижает информационную безопасность, а с другой стороны увеличивает требования к железу.


О мотивации было подробнее в предыдущей статье — https://habr.com/ru/post/415841/

Я читал прошлую статью, там всё было понятно. Когда вы берёте камеры от производителей, которые с вами не сотрудничают, выбора нет.

Но теперь, производители с вами сотрудничают и даже стараются победить друг друга в тендерах, так почему не сделать приложение, пихнуть туда весь функционал (включая обновления) и предложить (записать в условия тендера) производителям самим сделать всё окружение так, чтобы ваше приложение работало хорошо. Поставить ограничение на минимальную версию ядра и всё такое. Чтобы упростить поддержку разных платформ, приложение можно на lua сделать

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


По опыту дешевле сделать поддержку в приложении работы напрямую с SoC. При наличии уже готового нашего видео-приложения и системы сборки — добавление поддержки нового SoC, быстрее чем тестирование/интеграция в прошивку вендора.

Китайские ODMы ничего не могут сделать с проблемами безопасности, потому что у них нет профильных специалистов, поэтому отдать туда разработку — гарантировать себе наличие проблем безопасности и\или бэкдоров.
в принципе, имея мастер-приложение, эти проблемы можно обойти несколькими способами:
  1. самое простое: запускать мастер-приложение как init
  2. устанавливать правила iptables, запрещающие всё, кроме нужного
  3. убивать всё что открывает сокеты
Ну вот тут у нас и остается один шаг до собственного SDK, раз уж мы решили так яростно вмешиваться в работу юзерспейса, что запускаемся там init'ом, контролируем сокеты и т.п. «Так долго боролся с драконами, что сам им стал».
один шаг? Приложение, запускаемое в качестве init, это всё ещё обычное приложение. Скрипт для iptables, который закрывает все порты на вход и выход кроме двух, умещается в 10 строчках.
SDK, описанное в статье, включает несколько версий ядра, несколько версий gcc, десятки патчей от разных вендоров. Тут очень много шагов от обычного приложения

Версии gcc/ядра/библиотек идут из SoC SDK, и вне зависимости от подхода надо будет их поддерживать в приложении.
У вендоров камер нет технической возможности нормализовать версии gcc/libc.


Скрипт для iptables, который закрывает все порты на вход и выход кроме двух, умещается в 10 строчках.

А софт вендора раз в 30 секунд будет их обратно открывать (да, это пример из реальной жизни) :)

Версии gcc/ядра/библиотек идут из SoC SDK, и вне зависимости от подхода надо будет их поддерживать в приложении.

Слинковать статически и ставить приложение как блоб? Тогда нужны будут только версии под разные архитектуры процессора. Хотя, в вашем случае, большеват блоб, наверное, получится.
А софт вендора раз в 30 секунд будет их обратно открывать (да, это пример из реальной жизни) :)

сочувствую

А вы можете сделать прошивку с минимальными задержками в передаче изображения и с интерфейсом GigE Vision? А также с честным WDR?

подскажите, как скачать/купить для домашнего использования?

Ваш «ИТ-кластер» — это стыд и позор. Имел «счастье» подключать видеонаблюдение Ростелекома, эпопея тянется две недели.

Приходят монтажники, протягивают Ethernet. Договор активировать не могут, т.к. у РТК в этот день ломается маршрутизация. Сайт rt.ru и onlime.ru можно открыть только через VPN в Германии, из России он не открывается. Телефон 8-800 не отвечает — соединение просто не устанавливается.

Когда спустя пару часов всё стало подниматься, и личные кабинеты стали открываться, попытка активации камеры завершалась такой вот высокоинформативной ошибкой:

image

Камера сканирует QR-код, на мгновение появляется в ЛК и пропадает. И всё, хоть ты тресни.

А дальше — две недели ада с дозвоном в абонентскую службу, закрытием тикетов с формулировкой «вы пришлите скриншотов пошагово» (уже прислал, Ростелеком их продолбал). Работа IVR — это треш (меня два раза робот спрашивает, из Москвы ли я, или из Подмосковья, я 10 минут выслушиваю про то, как WiFi плохо работает через стены).

Плата за камеру и за услугу при этом, конечно же, списывается исправно.

В процессе очень хотелось позвонить Диане Самошкиной и рассказать об этом дивном опыте в красках, но сдержался — видимо, зря.

P.S. Тикеты INC000012540123 и INC000012568045
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.