search

svpcom / wfb-ng

WFB-NG - the next generation of long-range packet radio link based on raw WiFi radio
https://docs.px4.io/main/en/tutorials/video_streaming_wifi_broadcast.html
GNU General Public License v3.0
904 stars 221 forks source link

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

Closed RD000000 closed 3 years ago

RD000000 commented 4 years ago

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 commented 4 years ago

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

  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 commented 4 years ago

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

RD000000 commented 4 years ago

Задержка у меня 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 commented 4 years ago

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

svpcom commented 4 years ago

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