Porting to Hi3516/3518 IP Camera - is it possible ?

[RD000000]

Hi svpcom,
is it possible to port your solution to HiSilicon Ethernet IP camera board ?

Typically it is Hi3516 / Hi3518 / XM530AI SoC single board cam, capable of H264 or H265 RTSP stream 1080p 25fps 2000...8000 kbps with 200ms latency on GStreamer, sample - https://yadi.sk/d/cq1j5vs-Bw3HKQ

Typical specs are :
Two core ARM Cortex A7 440 MHz,
64M DDR RAM,
8M flash for firmware image,
Ethernet, UART, USB 2.0, some GPIO, audio in/out
Linux (don't know version, sorry),
single app "Sofia" doing all the video related tasks, from image grabbinng to RTSP streaming.

Firmware supplied in very readable form (set of cramfs images wrapped into u-boot images ), look at the unpack/repack sequence - https://habr.com/ru/post/213411/

SDK and toolchain are available, here is the sample of custom firmwares with support for additional USB adapters too - https://zftlab.org/pages/2018010700.html

We discuss it for last couple of days on RCDesign - http://forum.rcdesign.ru/f90/thread515083-64.html , maybe you rejoin the thread ?

[svpcom]

В теории оно конечно возможно, но тут есть несколько подводных камней:

1. Кривое и/или старое ядро. В старых ядрах (до 4.x) нужно было накладывать патчи на wifi стек для поддержки нормального инжектирования пакетов. Если в sdk нет полных исходников ядра и/или toolchain'ов для его сборки, то это может стать проблемой
2. Проблемы с аппаратным кодеком h264. Нужно будет глубоко разбираться с его API. Так как там всего 8M flash, то gstreamer туда не воткнуть и придется еще и самому делать нарезку на RTP пакеты. Ничего не известно про его latency. Я проверял latency RTP потока с камер hikvision (ds-2cd2042wdi) и оно было около секунды.
3. Как туда заводить телеметрию? Отключать консоль ядра от единстенного UART'а?
4. Ну и главная проблема - стоит ли это всего экономии на десяткок грамм веса NanoPI NEO2? В котором уже будет нормальный linux и хоть какие-то гарантии, что их производство завтра не прекратится (они вроде обещают LTS для данной модели) и все усилия не пропадут даром.

Еще не все аппаратные кодеки одинаково хорошго сжимают видео. Например кодек внутри Odroid C1 (Amlogic S805) намного хуже кодека внутри RPI и Logitech c920. То есть при одинаковом качестве получается намного больший bitrate видеопотока.

[svpcom]

В текущей ситуации с железом я склоняюсь к использованию или USB камер (Kurokesu C1) или охранных камер через ethernet (при условии, что найдется модель с приемлемым latency). А в качестве бортового компьютера использовать что-то типа NanoPI NEO2 или Nvidia Jetson (если нужно на борту делать какой-нибудь анализ видеопотока).

[RD000000]

Задержка у меня 200 мс на ноутбуке с GStreamer'ом, выкладывал картинки на rcdesign. UART там не на консоли, его использует Sofia под поворотку. Мне, правда, до /dev/tty пока достучаться не удалось даже с убитым процессом Sofia, access denied. RTSP streamer коллега на rcdesign уже написал. Картинка со своей дешевой камеры на XM530 мне нравится, H265 1080p 25fps при 5300 kbps.

Вот про ядро да, ничего сказать не могу.

Хорошо, а если ничего не портировать, а использовать ее как Ethernet камеру - то можно вместо NanoPI использовать Orange Pi Zero, или не хватит ?

[RD000000]

А, могу сказать про ядро. Вот OpenWrt под эти камеры, включая H264 стример - https://github.com/ZigFisher/chaos_calmer

[svpcom]

Orange Pi Zero хватит, но он конечно слабоват (cortex a7) по сравнению с neo2 (cortex a8)

[svpcom]

It seems that packet injection in this kernel is bad. If you have kernel sources you might try to debug it

[svpcom]

1. Check that there are no other processes (NetworkManager, wpa_supplicant, dhcp-client, etc) accessing to wifi adapter used by WFB
2. Check that video bandwidth < 0.5 of radio bandwidth (i.e. for MCS#1 max video bandwidth is ~7 mbit/s)
3. Check that selected wifi channel is free (in urban area all 2.4 GHz channels are polluted, use 5.8 GHz instead)
4. Use 20Mhz channels instead of 40MHz