Сравнение процессоров IP-камер Hi3518E и Hi3518C

До появления ботнета Mirai только особо интересующиеся знали о том, что находится внутри обычных IP камер. В большинстве случаев там стоит обычный линукс, причем частенько с дефолтным рутовым паролем, а то и вообще без него: у нас в офисе стоит такая камера, с прошивкой от декабря 2016 года и беспарольным рутовым телнетом. Но что же дальше, какой софт запущен на этом линуксе? Есть несколько классных статей про поиск бага которого нет, есть ещё разрозненная информация, но в целом ситуация такая: на IP-камере стоит специально пропатченное ядро, которое дает доступ программе через специальную библиотеку к железу, выдающему сжатые видеокадры. Грустная реальность в том, что очень часто этот софт написан далеко не лучшим образом. Достаточно сказать, что большинство камер, которые висят на улице очень страдают из-за большого расстояния до сервера, потому что авторы их прошивки освоили мастерство потерь данных по TCP. Мы решили исправить эту ситуацию своей прошивкой, причем сделав ставку на Rust.

Условия работы

Нужно сделать пару пустяков: разобраться с SDK, написать код, который настраивает железо, принимает H264 кадры и отправляет их в сеть. Пара пустяков, особенно учитывая насколько легко и просто деплоиться на IP камеры и отлаживать это всё. Ну и оставшая мелочь: мы решили писать этот код на Rust. Rust в качестве эксперимента был выбран за его удивительное свойство: compile time гарантию целостности памяти вместе с отсутствием рантайма. Это означает, что мы можем ожидать возможность контроля за выделением памяти, что очень важно, учитывая стесненность по ресурсам. Почему не подойдет Go, Erlang или какая-нибудь Java/C#? Потому что на IP камере флешка на 8 мегабайт и 128 мегабайт памяти из которых половина отнята у ядра под нужды видео. Понятно, что камеры есть разные, но всегда стараются делать по минимуму, чтобы не поднимать стоимость без нужды. На одной камере мы видели флешку на 64 мегабайта, там конечно можно развернуться, но хватает и совсем крохотных флешек. Так, обычная картина на дешевой камере за 3000 рублей мы видим:

# free              total       used       free     shared    buffers     cached Mem:         60128      17376      42752          0       2708       4416 -/+ buffers/cache:      10252      49876 Swap:            0          0          0 # 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: hi3518 Revision: 0000 Serial: 0000000000000000 

В таких условиях паршиво написанный софт начинает очень сильно страдать уже от 3-4 подключений. Золотое правило при работе с IP камерами: вообще стараться больше одного подключения (или два, по одному на каждое качество) не делать и это связано не только с узким каналом до камеры, но ещё с тем, что четвертый клиент к IP камере зачастую делает невозможным просмотр у первых трех. Забегая вперед, скажу что у нас и на 50 клиентах проблем не возникло.

Как устроена камера

Прежде чем идти дальше, расскажу немножко о том устройстве камеры, с которым мы работаем на текущем этапе. На камеру напаяна SPI флешка. Это такая же флешка, как та, на которую прошивает себя в биос какой-нибудь локер. Содержимое этой SPI флешки можно прочитать, подцепившись клещами, можно записать (если повезет), с неё же считывает данные в память процессор и выполняет их. Бывает, что флешка не SPI, а NAND, тогда всё сложнее: просто так клещами не подцепишься — приходится быть ответственнее. В самом начале флешки находится uboot. Это загрузчик, используемый практически во всех встраиваемых устройствах: не только камеры, а роутеры и телефоны. Т.е. скорее всего можно утверждать, что экземпляров убута в мире побольше, чем экземпляров виндовса. У uboot открытые исходники, но в нём хранятся данные, специфичные для конкретной железки. Если скопировать флешку с камеры, сделанной фирмой XM на камеру, сделанную фирмой Hikvision, то есть большой шанс, что даже uboot не загрузится. Т.е. уже на этом этапе возникает увлекательный процесс ведения реестра известных камер, их учета, который очень здорово облегчается восхитительным умением наших соседей присылать ровно то, что ты заказал. В качестве хорошего примера можно привести свежую историю у наших клиентов (самый крупный национальный оператор страны), которые подписали контракт на 3 года о поставке камер конкретной модели и характеристик, после чего через неделю приехали камеры уже другой модели и с совершенно другими характеристиками. Но ничего страшного, всё это решаемый вопрос, двигаемся дальше. А дальше находится ядро линукса. Было бы слишком просто, если бы можно было одно ядро собрать для всех возможных камер и потом просто модули перетыкать. Нет, так нельзя, поэтому для разных версий чипсета нужны разные ядра: где-то 2.x.y, где-то 3.x.y. Почему так? Потому что к ядру идут закрытые модули. Где-то можно исхитриться, но всё равно унифицировать всё не получится. После этого идет обычный хозбытовой buildroot. Здесь всё как у людей. Дальше надо запустить хитрые скрипты, настраивающие железо через i2c (и возможно как-то ещё), загрузить правильные модули и стартовать специально написанный софт.

Захват видео

В захвате видео очень много подготовки железа. Если почитать спецификацию onvif и мануал по SDK IP камеры, то можно увидеть много общего — софтверный интерфейс отражает общую структуру большинства железяк и она следующая: видео снимается с сенсора, немножко обрабатывается, потом засовывается в энкодеры (аппаратные конечно) и потом в софтине можно забрать из определенного места в памяти готовые H264 NAL юниты. Для базового сценария осталось только приделать управление пользователями, настройки и какой-нибудь сетевой протокол. Для полноценной камеры ещё нужна поддержка всяких механизмов массовой настройки (discovery, onvif, psia, etc..) и аналитика.

А чего там про Rust

Вот как раз стример у нас ржавый. Целая пачка unsafe кода, автогенеренного из сишного кода SDK с помощью bindgen, подпатченый биндинг к libc (постараемся залить патч в апстрим) и дальше реализация RTSP на tokio. Даже уже есть возможность посмотреть видео с камеры в обычном браузере — это недостижимая роскошь для китайских камер, которые поголовно требуют установку ActiveX. Структура очень непривычна после эрланга: ведь тут нет процессов и сообщений, есть каналы, а с ними всё становится немножко по-другому. Как я уже выше писал, современно написанный код с правильной организацией дает возможность раздавать видео не 2-3 клиентам, а более 50 без какой-либо просадки производительности. Важный момент: за время разработки пока не случилось ни единого сегфолта. Пока есть стойкое ощущение, что Rust заставляет писать так, как в принципе пишут хорошие поседевшие сишники, повидавшие всякого нехорошего. Так что пока всё нравится. В течение августа есть планы закончить работу по базовому сценарию, так что есть вопрос к аудитории, который идет в опросе. Ну и задавайте вопросы, которые возникли.

про что интереснее почитать дальше

• 44,4%что умеет IP камера и как устроен SDK?
• 83,9%как делается такой embedded на Rust?

Проголосовали 279 пользователей. Воздержались 47 пользователей.

Сравнение процессоров IP-камер Hi3518E и Hi3518C

Подробности

Несколько дней назад новый клиент спросил меня: «Что лучше Hi3518E или Hi3518C?». Я ответил, что Hi3518E лучше, так как это более новый SoC процессор от Hisilicon. Подумав некоторое время спустя, я понял, что не знаю точную разницу между этими SoC процессорами. После поисков в Google, на веб-сайте я нашёл статью, где утверждается, что Hi3518C лучше, чем Hi3518E. Тогда я потратил ещё время, проведя более тщательный анализ, и пришёл к выводу, что Hi3518E всё же немного лучше, чем Hi3518C.

Hi3518E более новый, чем Hi3518C и Hi3518A

В 2012 году Hisilicon выпустил SoC процессоры для IP камер Hi3518A и Hi3518C, эти два процессора поддерживают кодирование потока видео 1080p 30 кадров в сек, технологию трёх потоков, а также группу технологий обработки изображения, включая 3D-шумоподавитель, цифровой WDR, антитуман и т.д. Из них Hi3518A уже снят с производства, Hi3518C ещё доступен и устанавливается во многие IP-камеры 720p/960p на рынке видеонаблюдения.

Hi3518E был выпущен Hisilicon в 2014 году, это новое поколение SoC (система на чипе) процессоров, которое обладает лучшими характеристиками по сравнению со своими предшественниками — Hi3518A и Hi3518C. Согласно спецификации, Hi3518E интегрируется с последними ISP (Image Signal Processor), улучшен алгоритм кодирования видео, использует формат сжатия H.264. Используя передовые технологии и архитектуру с низким энергопотреблением, Hi3518E является ведущим в аспектах низкой скорости передачи данных, высокого качества изображения и низкого энергопотребления. Стоимость EBOM (конструкторский состав изделия) для IP камеры на Hi3518E значительно снижается за счет интеграции DRAM, POR, RTC и аудио кодеков и поддержку датчиков различных уровней и тактируемых выходов. Подобно другим Hisilicon DVR и NVR SDK (комплект средств разработки), SDK на Hi3518E позволяет быстрое массовое производство и облегчает компоновку системы IP камер, DVR, и NVR.

Hi3518E интегрирован с облачным сервисом P2P

Так как облачный сервис становится все более и более популярным, последний Hi3518E интегрирован с облачной службой P2P (Danale), что значительно улучшило функцию «подключи и работай». Производителям камер безопасности больше не нужно разрабатывать свои собственные облачные службы и приложения для смартфонов. Последняя Hi3518E поставляется с бесплатным программным обеспечением для PC, бесплатным приложением для смартфонов, программным обеспечение разработчика, поддерживает удалённый просмотр P2P, Push уведомления, облачное хранилище данных и другие облачные сервисы. Если у вас есть IP камера на базе Hi3518E, вы можете использовать приложение Xmeye для получения доступ к камере через смартфон. Xmeye доступна для платформ iOS и Android.

Hi3518E имеет улучшенную обработку видео, чем Hi3518C

Ключевые характеристики Hi3518E из технической документации:

• Ядро процессора Hi3518E: ARM9 макс 440 МГц, 16 KB кэш инструкций и 16 KB кэш данных
• Протоколы кодирования видео: H.264 main profile, H.264 baseline profile, кодирование MJPEG/JPEG baseline
• Производительность кодирования видео: 720p@25fps H.264 + 720p@3fps JPEG потоки
• Диапазон Birate: от 16 кбит/сек до 20 Мбит/сек

Скачать спецификацию на Hi3518E Hi3518E.pdf

Ключевые характеристики Hi3518C из технической документации:

• Ядро процессора Hi3518C: ARM926 макс 400МГц, 16 KB кэш инструкций и 16 KB кэш данных
• Протоколы кодирования видео: H.264 main profile level 4.0, H.264 baseline profile, кодирование MJPEG/JPEG baseline
• Производительность кодирования видео: 720p@25fps H.264 + QVGA@30fps + 720p@1fps JPEG потоки
• Диапазон Birate: от 16 кбит/сек до 20 Мбит/сек

Скачать спецификацию на Hi3518C Hi3518C.pdf

Согласно спецификации на Hi3518E и Hi3518C, Hi3518E имеет немного лучшую обработку данных, чем Hi3518C. Hi3518E поддерживает два потока видео, а Hi3518C поддерживает три видеопотока. Диапазон скорости передачи данных одинаковый для обеих камер. К сожалению, первый сайт, по которому я ориентировался, предоставляет неверные данные. Я не знаю, почему в той статье содержатся недостоверные сведения, ведь пользователи могут легко найти эти данные в спецификации производителя.

<center></center>

Hi3518E имеет немного больше энергопотребление

Типовое потребление Hi3518E составляет 900 мВт, а типовое потребление Hi3518C составляет 700 мВт. Причина в том, в чип Hi3518E встроена память DDR2 16 бит 512 Mбит (64Мб), а в старом чипе Hi3518C её нет. (Примечание переводчика: в большинстве модулей на базе Hi3518C установлен отдельный чип DDR3 1Гбит (128Мб)). Кроме того, Hi3518E имеет гораздо больше периферийных интерфейсов, включая 3x UART, 2xSSP (синхронный последовательный порт), 4x PWM (широтно-импульсный модулятор). В двух словах, производители камер безопасности могут разрабатывать сетевые камеры на базе Hi3518E с более низкой стоимостью, а общее потребление будет ниже, чем у камер на чипе Hi3518C.

Мы поместили в список некоторые IP камеры на базе Hi3518C и Hi3518E, а также Hi3516C SoC процессоре.

<center>

</center>

В конце, вы можете найти статью, предоставляющую неверные данные здесь.

Перевёл статью Sonya, оригинал с сайта Unifore.

Добавить комментарий

Характеристики процессора Hi3518E V200

• ARM9 @ Макс. 440 МГц, 16 Кбайт I-кеша и 16 КБ D-кеширование видеокодирования
• Основной профиль H.264
• Базовый профиль H.264
• Базовое кодирование MJPEG / JPEG Производительность кодирования видео
• Максимальное разрешение 2 мегапикселя для кодирования H.264
• Максимальная скорость кодирования в реальном времени потоков H.264 и JPEG: 720p @ 25 fps + 720p @ 3 кадра в секунду JPEG-снимок
• Многопотоковое кодирование
• Управление скоростью передачи битов в режиме CBR, VBR или ABR, скорость передачи в диапазоне от 16 кбит / с До 20 Мбит / с
• Кодирование восьми ROI
• Наложение OSD из восьми регионов до кодирования Интегрированная память
• Встроенная 16-разрядная DDR2
• Максимальная емкость Интеллектуального анализа видеоизображения 512 Мбит
• Интегрированный IVE, поддерживающий различные интеллектуальные аналитические приложения, такие как обнаружение движения, граница Безопасность и видеодиагностика Обработка видео и графики
• Предварительная обработка видео, включая 3D-шумоподавление, улучшение изображения, улучшение края и деинтерлейсинг
• Антибликовое изображение для видео и графики вывода видео
• Масштабирование видео от 1 / 16x до 8x ● 1 / 2x-2x Графическое масштабирование
• Предварительная обработка наложения экранного меню для восьми регионов
• Аппаратная графика накладывает постобработку для видео на двух уровнях (уровень видео и графический слой 1) ISP
• AE и AWB для настройки
• Выделяют компенсацию, компенсацию задней подсветки, гамма-коррекцию и улучшение цвета
• Коррекция пиксельных дефектов, шумоподавление и цифровой стабилизатор изображения
• Инструменты настройки ISP для ПК Аудиокодирование / декодирование
• Голосовое кодирование / декодирование в соответствии с несколькими протоколами с использованием программного обеспечения
• Протоколы G.711, ADPCM и G.726
• Эхоподавление Безопасность Двигатель
• Различные алгоритмы шифрования и дешифрования с использованием аппаратных средств, таких как AES, DES и 3DES
• Цифровые водяные знаки Видеоинтерфейсы
• Входные -8-, 10- или 12-разрядные входы RGB-байера, максимальная тактовая частота 74,25 МГц -BT. 601 и BT.656. Совместимость с основными HD-CMOS-датчиками, поставляемыми SONY, Aptina, OV и Panasonic. Совместимость с CCD-датчиками. Различные уровни поддерживаемых датчиков. Programmabl E сенсорный выход -Видео входы При 1080p при 30 кадров в секунду или 720p при 30 кадров в секунду
• Выходной интерфейс BT.1120 VO для подключения к внешнему HDMI или SDI, максимальная производительность 1080p @ 30 fps Аудиоинтерфейсы
• Встроенный аудиокод CODEC, поддерживающий 16-битные аудиовходы и выходы Периферийные интерфейсы
• POR и внешний сброс
• Один встроенный высокоточный RTC
• Один встроенный низкоскоростной АЦП с двумя каналами
• Три интерфейса UART
• Один ИК-интерфейс, один интерфейс I 2 C, один интерфейс ведущего / ведомого SPI, несколько интерфейсов GPIO
• Один интерфейс SDIO 2.0, поддерживающий SDHC.
• Максимум четыре интерфейса PWM.
• Один хост-порт USB 2.0.
• Режимы RMII и MII. 10/100 Мбит / с с полнодуплексным или полудуплексным режимом, синхронизирующим выходом PHY Интерфейсы внешней памяти
• Флэш-интерфейс SPI NOR для вспышки 1, 2 или 4 бит SPI NOR
• Загрузка из NOR flash SDK
• SDK на основе Linux -3.0.y
• Высокопроизводительная библиотека декодирования ПК H.264 Физические характеристики
• Потребляемая мощность — Типичная потребляемая мощность 900 мВт — Многоуровневый энергосберегающий режим
• Рабочие напряжения -1,2 В Напряжение на сердечнике -3,3 Напряжение VI / O и напряжение на входе 3,8 В -1,8 В внутреннего SDRAM -Операционная температура в диапазоне от 0 ° C (+ 32 ° F) до + 70 ° C (158 ° F)
• Пакет -RoHS, BGA220 — шаг шага 0,65 мм (0,026 дюйма) и размер корпуса 11 мм x 11 мм (0,43 дюйма х 0,43 дюйма)

Используемые источники:

• https://habr.com/post/334912/
• https://www.cctvsp.ru/articles/soc-protsessor-ip-kamer-hi3518e-protiv-hi3518c
• https://vstarcam.ua/technology/hi3518e-processor/