1. 为什么选RV1126B一颗适合端侧AI视觉的SoC1.1 算力、功耗和接口先看这三张牌做AI视觉硬件选型我习惯先看三件事算力、功耗、接口丰富度。RV1126B在这三项上的表现恰好卡在了一个非常舒服的位置。它的NPU算力大约在2TOPS左右听起来不如动辄几十TOPS的旗舰芯片唬人但在实际做IPC网络摄像机和端侧视觉产品时这个算力跑分类、检测、人脸抓拍这类模型非常够用。原因很简单摄像头端的AI任务大多是单路或两路视频流不需要做大规模训练推理模型通常也已经被裁剪到很小的尺寸。功耗方面RV1126B的典型功耗控制得比较低配合合适的PMU方案整板功耗能做到3W到5W级别这对做电池供电或者PoE供电的设备非常友好。接口上它提供了MIPI CSI接sensor、Ethernet百兆或千兆、USB、UART、I2C、SPI等常用接口基本覆盖了摄像机产品需要的全部外设。我在实际项目里用到最多的组合是MIPI接一颗500万像素sensor百兆以太网做RTSP推流USB接一颗麦克风阵列板卡整套系统跑下来稳定可靠。对比同系列稍高端的RV1126RV1126B在封装和部分外设上做了精简成本更低也更适合量产。如果你做的事情是把一颗摄像头变成具备AI能力的智能终端RV1126B这个定位非常精准。1.2 内存颗粒选择DDR3 1GB够不够用标题里提到了RV1126B可用的DDR3内存1GB有哪些这个问题我在选型时也纠结了很久。直接说结论RV1126B支持DDR3和DDR3L1GB容量在绝大多数场景下够用但颗粒型号必须选对否则连boot都过不了。我实测过几款颗粒列在下面供参考颗粒型号容量实测结果南亚NT5CC128M16JR-EK12Gb x4共1GB稳定推荐海力士H5TQ2G63GFR-PB2Gb x4共1GB稳定推荐镁光MT41K256M16TW-1072Gb x4共1GB稳定推荐三星K4B2G1646F-BYK02Gb x4共1GB稳定推荐但供货波动大选内存的坑在于RV1126B的启动流程对DDR初始化时序非常敏感SDK里默认的DDR频率是1056MHz或更高如果颗粒品质不好跑压力测试时会随机出现死机或重启。我的做法是拿到颗粒后先烧SDK里的DDR压力测试固件连续跑12小时以上确认无误再画板量产。另一个建议是别为省几块钱选没听过的国产杂牌颗粒调试成本远高于省下的物料成本。1.3 开发环境搭建与SDK编译RV1126B的SDK基于Rockchip官方Linux SDK整体结构包含u-boot、kernel、buildroot、rknn-toolkit等几个大块。首次编译时我建议按官方文档走一遍默认配置流程先把系统跑起来再逐步裁剪。我的开发机是Ubuntu 18.04或20.04交叉编译链SDK里自带不需要额外装。编译的基本流程是# 进入SDK根目录 cd sdk # 第一次编译需要先选择配置文件 ./build.sh lunch # 选择rv1126b对应的配置根据自己板子的defconfig选择 ./build.sh这里有个比较重要的细节SDK的build脚本会检查编译环境和依赖库缺少ncurses、libssl等库时会在中间阶段报错。我习惯先把这些基础依赖装齐sudo apt-get install libssl-dev libncurses5-dev device-tree-compiler \ u-boot-tools mtools zip python2 python3编译完成后生成的固件在output/目录下烧录工具用Rockchip的RKDevToolWindows下或者upgrade_toolLinux下。烧录时注意选择正确的烧录分区通常包括uboot、kernel、rootfs、resource设备树等分区。2. sensor接入与底层图像处理先把“眼睛”调到最清楚2.1 从sensor型号到镜头模组的选型匹配相机画质的好坏一半在sensor一半在镜头和ISP调校。RV1126B本身集成了不错的ISP支持3AAE自动曝光、AWB自动白平衡、AF自动对焦以及HDR、降噪、增强等功能。sensor选型上市面上常见的500万像素sensor如SC5005、OV5647、GC5035等都可以通过MIPI接口直连。我的经验是选sensor时除了看像素数和帧率还要关注它的像素尺寸、感光度、动态范围等参数。比如做室内监控对低照度性能要求高就选大pixel size的sensor做室外强光场景就需要动态范围大的sensor配HDR功能。镜头方面焦距决定视场角光圈决定进光量接口类型必须匹配sensor的封装常见的有M12、CS接口等。如果你是自己画板子建议先把sensor模组的引脚定义和时序图拿到手核对MIPI通道数、mclk频率、reset/gpio等引脚是否和SoC的GPIO复用冲突。2.2 I2C配置与初始化调试的实操记录sensor接入最常见的问题就是不上电或I2C通信失败。我调试SC5005时代码里走到i2c_transfer就报-6ENXIO错误排查了一天最后发现是sensor的reset引脚被复用成了其他功能GPIO电平一直拉高导致sensor处于复位状态。针对这类问题我的排查顺序是确认sensor供电电压AVDD、DVDD、DOVDD是否正确用万用表实测。确认MCLK时钟是否输出频率是否在sensor要求的范围内常见为24MHz或27MHz。检查I2C地址是否正确有些sensor的I2C地址可以通过引脚配置修改。确认reset/power down引脚的默认电平很多sensor要求上电时序先供AVDD再供DVDD再用GPIO拉高reset。用i2cdetect工具在板子上扫I2C总线看能否探测到设备地址。调试时我习惯在kernel的dts里先把I2C节点配好然后通过i2c_dev设备节点直接读写寄存器验证通信是否正常。等通信通了再挂sensor驱动。这样能快速定位是硬件问题还是软件问题。2.3 HDR等图像增强手段怎么落地HDR技术是这类相机项目中画质提升的关键。RV1126B的ISP支持多帧曝光合成HDR通过sensor输出不同曝光时间的帧ISP合成以及单帧HDRsensor本身支持DOL HDR。实际项目里我用的是sensor的DOL模式通过RKHDR工具或tuning工具配置sensor曝光时间和增益组合再在ISP的tuning server里调节HDR合成的强度。底层图像增强通常包括几块内容3AAE/AWB/AF要依据场景做策略调整比如室内灯光下AWB容易偏黄需要设置合适的色温范围。降噪包括2D/3D降噪参数太大容易拖影和涂抹感我用的时候会结合帧率来定在25fps下3D降噪强度不要超过阈值不然运动物体会出现鬼影。边缘增强和对比度用ISP的sharpen和gamma曲线来调但过犹不及边缘增强太强会出现振铃现象。宽动态HDR对逆光场景很有用参数调整后要看高光不过曝、暗部不死黑。这套调校是经验活我的建议是先用Rockchip的Tuning Tool抓raw图离线调好一组基础参数再烧进板子里做实景验证按室内-室外-夜间-逆光几个典型场景分别保存参数系统运行时按场景自动切换。3. RTSP推流搭建光有画面还不够还得传得出去3.1 基于GStreamer的RTSP服务方案RTSP是整个项目的核心输出方式意味着把实时视频流以标准协议发出去让VLC、大华NVR、海康平台或者Web端都能拉流播放。RV1126B的SDK里集成了GStreamer框架用起来很顺。我最终采用的方案是基于GStreamer的rtspclientsink或rtsp-server库把摄像头采集的MIPI数据经过ISP转成NV12或者直接编码成H.264再封装成RTSP流。一个典型的GStreamer管线大致是gst-launch-1.0 rkisp device/dev/video0 io-mode4 \ ! video/x-raw,formatNV12,width2560,height1440,framerate25/1 \ ! mpph264enc \ ! rtph264pay namepay0 pt96 \ ! tcpserversink host0.0.0.0 port8554这些参数里最容易被忽略的是io-mode4它表示使用DMA buffer方式传递数据能减少内存拷贝延迟更低。如果设置成io-mode1性能会差一截。用rtsp-server库编写服务的好处在灵活控制可以实时动态切换码流参数、添加多个sink。我会在应用层用一个配置文件管理各路视频流的分辨率、码率和帧率运行时通过IPC消息动态修改GStreamer管线参数。这样做的好处是无需重新编译固件满足现场调参的需求。3.2 推流的地址格式与客户端拉流RTSP推流地址没有强制标准但行业内遵循一定的约定。我见过很多平台包括大华NVR、WVP对地址解析有各自的规则常见的格式有rtsp://IP:8554/live/ch0rtsp://IP:8554/stream1rtsp://IP:8554/realmonitor?channel1subtype0这里有个坑如果用NVR对接时拉不到流先检查地址格式是否匹配平台的约定。WVP平台对接国标流时更倾向于走GB28181会把RTSP地址当作一个普通取流地址来解析。如果你是自己写客户端拉流VLC、FFmpeg、PotPlayer都可以测试FFmpeg拉流命令是ffmpeg -rtsp_transport tcp -i rtsp://192.168.1.100:8554/live/ch0 -c copy output.mp4注意-rtsp_transport tcpUDP模式在跨网段或者丢包环境下经常花屏TCP模式更稳定。不过TCP拉流也有代价就是延迟会略高一点局域网内实测大约多20-40ms可以接受。3.3 稳定性和断线重连的处理RTSP最容易被吐槽的就是不稳定。我遇到过的典型问题有三种第一种是长时间运行后推流线程崩溃或RTSP服务端卡死。这类问题多半是内存泄漏或某个buffer没释放。排查时我先把GStreamer的debug日志开起来GST_DEBUGrtsp*:5 ./my_rtsp_server观察日志中是否有WARNING或者ERROR重点看bins和buffers相关的提示。修复方向通常是检查是否在动态调整分辨率或码率时没有正确触发pipeline状态切换。第二种是网络闪断导致客户端推流断开但服务端不自知。解决思路是一方面定时发送RTCP keep-alive包另一方面在RTSP服务端实现回调检测到连接断开后主动清理资源并继续监听新连接。第三种是码率波动太大导致客户端播放卡顿。根因通常是编码器码控参数没调好I帧间隔和码率上限设置不合理。我用的参数是GOP设为50即2秒一个I帧目标码率按分辨率设定1080p约4Mbps720p约2Mbps最大码率不超过目标码率的1.5倍。同时打开码控的rc-mode在场景剧烈变化时让编码器自动提高帧内宏块比例保证画面不糊。4. AI视觉模块接入图像到结构化数据的关键一跳4.1 模型转换RKNN工具链踩坑RV1126B的AI能力来自NPU模型必须先转成RKNN格式才能部署。Rockchip提供了rknn-toolkit和rknn-toolkit2两个工具链RV1126B对应的是rknn-toolkit1.x版本pyTorch、ONNX、Caffe的模型都支持。转换流程非常简单pip install rknn-toolkit # 写一个转换脚本 from rknn.api import RKNN rknn RKNN() rknn.config(target_platformrv1126b, mean_values[[0,0,0]], std_values[[255,255,255]]) rknn.load_onnx(modelmodel.onnx) rknn.build(do_quantizationTrue, datasetdataset.txt) rknn.export_rknn(model.rknn)do_quantizationTrue表示做INT8量化能大幅提升推理速度但会损失一点精度。量化数据集最好选几百张和真实场景接近的图片不要在训练集里随便抽几张否则量化后精度崩了很难查。我试过用500张现场图片做量化mAP掉点控制在0.5%以内速度提升接近一倍。4.2 推理结果如何与RTSP码流联动AI视觉不只是把模型跑通还要把结果和视频流联动起来。典型的做法有两种一种是云端联动NPU识别到目标后把结果比如检测框、分类标签、置信度封装成JSON通过MQTT或者HTTP POST发到后端平台视频流继续走RTSP。这种方式适合中心化的监控平台平台负责存储、报警和展示。另一种是端侧联动直接在板端把检测结果叠加到视频帧上用opencv画框写字再交给编码器。RV1126B的CPU画框性能完全可以承受但要注意不能让画框操作阻塞编码线程。我的做法是把推理放到一个独立线程结果通过队列传给编码线程编码线程只在等到新结果时才更新叠加层等不到就继续用旧结果这样即使AI线程偶尔卡一下RTSP视频流也不会断。推理线程的框架代码大致是这样while (run) { // 从码流队列里取一帧或直接把sensor输出帧作为输入 frame queue_pop(); // NPU推理 rknn_inputs_set(ctx, input); rknn_run(ctx, NULL); rknn_outputs_get(ctx, 1, output, NULL); // 解析结果画框 parse_and_draw(frame, output); // 把处理帧投递给编码器 encoder_enqueue(frame); }画框的颜色、线条宽度、字体大小都要根据预览分辨率调我之前用1440p分辨率时字体太小客户端放大后根本看不清后来改成根据图像高度动态计算字体大小才解决。5. 帧率、码率与延迟工程上的平衡术5.1 关键参数整理与推荐值做这套系统我踩过最大的坑是看起来每个模块都正常但整体就是卡。问题的根源往往在帧率和码率没有统一协调好。我整理了一张推荐配置表供参考。场景分辨率帧率目标码率最大码率备注室内监控1920x108025fps2.5Mbps4Mbps画面变化少码率可以压低室外逆光2560x144020fps6Mbps9MbpsHDR开启码率要留余量电池设备1280x72010fps1Mbps1.5Mbps帧率低省电省带宽运动场景1920x108030fps5Mbps8Mbps高运动场景必须提高码率5.2 多路接入和上云场景怎么办单设备的RTSP推流搞好之后多路接入和上云是必然面对的问题。多路接入有两种典型的做法一种是一台板子接多路sensor每路sensor输出单独的RTSP流这时要注意SoC的编码器性能上限。RV1126B支持几路1080p同时编码我没实测过极限但建议主码流加子码流的方案主码流1080p用于本地存储或平台预览子码流720p或更低的CIF用于移动端预览或AI分析。这样可以显著降低带宽和编码压力。另一种多路接入是一台NVR拉多台摄像机这时NVR端用RTSP拉流即可。需要提醒的是如果NVR拉流花屏或卡顿优先检查摄像机端的码率上限和I帧间隔很多NVR要求摄像机的I帧间隔固定比如50帧才能正常解码。另外大华NVR对接时建议直接把子码流地址配给NVR做预览主码流配给存储实现预览不占主码流带宽的效果。上云场景我目前采用的是边缘节点云端转发的架构板端推RTSP到本地边缘网关网关转成RTMP推给云端流媒体服务器比如WVP或SRS云端再做RTSP/FLV/HLS分发。转流最常用的命令是FFmpegffmpeg -rtsp_transport tcp -i rtsp://192.168.1.100:8554/live/ch0 \ -c:v copy -c:a aac -f flv rtmp://your_server/live/stream1这么做的好处是云端不用直接面对大量摄像机边缘网关可以做缓存、断线续传和按需拉流。如果你的平台只支持GB28181编码器要切换成PS封装输出这个在SDK里也有现成的例子改动GStreamer的封装层即可。6. 项目复盘我踩过的坑和可以复用的经验6.1 常见问题速查表做完整套方案后我整理了一份自己项目里遇到的高频问题和解决办法分享给大家。现象可能原因排查和解决板上电后串口无输出电源/时钟/内存初始化失败检查各路电源电压、晶振波形用DDR压力测试固件排除内存问题sensor不出画I2C或复位时序不对用i2cdetect扫地址量MCLK、reset、power down引脚电平画面偏色严重AWB参数不对或sensor色彩矩阵错误抓raw图离线调AWB重新确认sensor的color matrixRTSP隔一段时间就断流编码器线程崩溃或网络丢包开GStreamer debug日志定位检查TCP keep-alive客户端画面马赛克码率上限太低或I帧间隔太长提高最大码率至目标码率的1.5倍缩短I帧间隔目标检测框和画面错位推理输入分辨率与编码分辨率不一致RG推理输入和编码输入统一用相同分辨率或按比例缩放检测框电池方案续航太短一直是25fps满码率跑改成事件触发推送空闲时降到5fps唤醒后才切回25fps6.2 后续扩展建议这套平台跑通后换sensor、换模型、换平台对接都是增量工作。如果你要继续扩展我建议在三个方向上发力一是把音频加进来。RV1126B的I2S接口可以直接接音频编解码器GStreamer里用audioconvert和faac或opusenc把音频封装进RTSP流这样客户端VLC打开就能听到声音。音频和视频时间戳同步在rtph264pay和rtpL16pay/rtppcmapay的时候注意一下即可。二是做视频存储。板端挂TF卡或SATA硬盘通过USB转SATA用GStreamer的filesink或者MP4 muxer把码流落盘。这样做的好处是断网时本地有录像恢复后平台还可以补传。补传逻辑要处理好当前时间和录像结束时间之间的关系否则重传会乱套。三是做设备管理平台。板端通过MQTT上报在线状态、固件版本、信号强度等信息平台下发参数配置码率、帧率、AI开关等这能把一套能跑的方案变成可维护的产品。RV1126B跑MQTT client很轻松使用开源库如Mosquitto client大概200行代码就能搞定。做这个项目最深的体会是硬件选型决定了下限软件调优决定了上限。RV1126B这台芯片本身的基础能力不差但真正让RTSP推流稳定、画面清晰、AI识别准确的还是背后一次次的现场调试和参数迭代。如果你正在做类似的视觉产品希望这篇文章能帮你少走几步弯路尤其是内存颗粒、sensor上电时序和RTSP码率控制这几个环节都是我自己交过学费的地方。
