做视频监控的开发这些年Hi3519DV500 是我相当认可的芯片。第一次拿到这块开发板的时候我首先感受到的就是海思终于在“性能”和“成本”之间找到了一个非常舒服的平衡点。它不需要外挂额外的 AI 处理器就能跑轻量级模型自带 4K 编解码能力ISP 部分又做得非常扎实。对于想自己做一套 4K 智能监控系统、又不想被 NVR 端到端方案绑死的开发者来说这几乎是市面上最值得投入的方向。这篇文章不打算给你堆官方文档我会按照自己实际做项目时的完整流程从硬件选型、开发环境搭建、sensor 接入、ISP 调参到 AI 功能落地一步步讲清楚。尤其是 ISP 调试这是很多人被卡住的地方我尽量把我踩过的坑和有效做法都写明白。1. 开发板选型与整体方案拆解1.1 为什么偏偏选 Hi3519DV500在拿到这块开发板之前我对比过好几款方案瑞芯微的 RV1126 性价比不错但 4K 编码能力偏弱树莓派生态丰富但做视频监控产品级方案时H.265 编码和高清 ISP 处理能力都不够扎实。而 Hi3519DV500 的优势其实可以从核心参数上看出来它集成了双核 Cortex-A55主频跑到 1.0GHz 左右视频处理单元支持 4K 分辨率的 H.265/H.264 编解码同时内置了一个算力约 2TOPS 的 NNIE 加速单元。这个组合意味着单芯片就能完成“采集——处理——编码——AI 分析”这一整条链路。实际开发中还有一个很关键的点海思的 MPPMedia Process Platform平台成熟度非常高。你写代码的时候VI视频输入、VPSS视频预处理、VENC视频编码这些模块的接口设计得很清晰不会有那种“遇到一个 bug 要翻一星期代码”的情况。对于个人开发者来说选型看参数是一回事真正的生产力还是取决于工具链的顺手程度这一点海思做得确实不错。1.2 开发板硬件资源盘点我用的是第三方厂商做的核心板加载板方案。这里要提醒大家Hi3519DV500 是 BGA 封装直接手工焊几乎不可能所以尽量直接买成熟的开发板套件。我手上这套板子的主要资源如下处理器Hi3519DV500双核 A55内存1GB DDR4板载存储8GB eMMC预留 TF 卡座视频接口一个 MIPI CSI 接口支持 4-lane最高可接入 4K30fps 的 sensor显示输出HDMI 0 接口可以直接输出 4K 画面网络接口千兆 RJ45调试接口一个 UART 调试串口一个 USB 3.0AI 加速内置 NNIE支持 Caffe 模型转换这里特别提一下 MIPI CSI 接口做 4K 监控系统时sensor 输出的数据量非常大4-lane MIPI 在 4K30fps 下几乎是硬性需求。如果你选的是 2-lane 接口的板子通常只能跑 2K 或者 4K15fps那就不符合我们的目标了。所以不管你是自己画板还是买现成的第一件事就是确认 MIPI 通道数。1.3 我的系统分区规划搞嵌入式 Linux 开发分区规划很重要。我参考了海思 SDK 里提供的分区表同时也结合自己后续迭代的便利性做了调整最终是这样的分区名大小挂载点用途fastboot1MB-bootloader 第一阶段boot16MB-内核与 dtbrootfs512MB/根文件系统userdata2GB/userdata存放程序、配置文件、抓拍图片、录像tmpfs256MB/tmp临时文件这样规划的好处是系统升级时只烧写 boot 和 rootfs不会影响 /userdata 里的业务程序和数据。监控系统往往需要长时间运行日志、录像文件都在持续写入如果跟 rootfs 混在一起很容易撑爆 flash。我之前就吃过这个亏所以特别强调一下。2. 搭建交叉编译环境与系统烧写2.1 SDK 解压与环境变量配置海思 SDK 拿到手后第一步不是急着写代码而是把交叉编译环境搭好。SDK 包通常会包含一个toolchain目录你需要在 Ubuntu我用的 18.04兼容性最好上完成以下操作sudo apt-get install -y gcc make build-essential libncurses5-dev u-boot-tools tar -xzf Hi3519DV500_SDK_Vx.x.x.tgz cd Hi3519DV500_SDK_Vx.x.x source ./sdk.cleanup source ./sdk.unpack在安装交叉编译器时注意海思用的不是标准的 arm-linux-gnueabi而是针对 Cortex-A 系列优化过的工具链路径一般指向arm-v01c02-linux-uclibcgnueabi或者aarch64-v01c02-linux-gnu。因为我的应用主要跑在 64 位模式下所以我用的是 aarch64 版本。设置环境变量export PATH$PATH:/opt/hisi-linux/x86-arm/aarch64-v01c02-linux-gnu/bin export CROSS_COMPILEaarch64-v01c02-linux-gnu- export ARCHarm64这里要强调一下交叉编译工具链版本和内核版本不匹配的话编译过程中会出现各种奇怪的报错所以尽量使用 SDK 自带的、指定版本的那个工具链别自己到网上去乱下最新的。2.2 内核编译与分区镜像生成编译内核是流程中比较花时间的一步。进入 SDK 的 kernel 目录先加载默认配置make hi3519dv500_defconfig make -j8 uImage编译完成后你会得到uImage内核文件。接下来还需要编译设备树make hi3519dv500-emmc.dtb海思平台对设备树的依赖非常高你的 sensor 是接在哪个 MIPI 端口、用的是哪一颗芯片、GPIO 怎么复用全部都是在 dts 里面配置。以我用的 Sony IMX334 为例需要在 dts 的sensor节点里设置正确的 I2C 总线地址、复位 GPIO、MIPI 通道数以及时钟频率i2c2 { status okay; imx334: imx3341a { compatible sony,imx334; reg 0x1a; reset-gpio gpio4 1 GPIO_ACTIVE_LOW; pwdn-gpio gpio4 2 GPIO_ACTIVE_LOW; mclk 27000000; }; };很多新手第一次编译出来的镜像启动后检测不到 sensor十有八九是 dts 里的 I2C 地址写错了或者是 sensor 的供电时序没对上。IMX334 的 I2C 地址是 0x1a但有些厂商的板子因为地址线和电源接法不同可能变成 0x1b这个需要根据实际板子的原理图去修改。2.3 U-Boot 与镜像烧写镜像都生成好之后进入烧写环节。海思平台可以通过网口烧写到 eMMC也可以用 SD 卡烧写。我最常用的方式是通过网口 tftpsetenv serverip 192.168.1.10 setenv ipaddr 192.168.1.20 mw.b 0x42800000 0xff 0x1000000 tftp 0x42800000 uImage mmc write 0x42800000 0x800 0x2000这几个命令的意思是先把内核下载到内存的 0x42800000 地址然后写入 eMMC 的 0x800 块偏移为 1MB正好对上我之前的 boot 分区。烧完之后设置启动参数并保存setenv bootargs mem512M consolettyAMA0,115200 root/dev/mmcblk0p3 rootfstypeext4 rw setenv bootcmd mmc read 0 0x42000000 0x800 0x2000; bootm 0x42000000 saveenv这里root/dev/mmcblk0p3对应的是我分区表里的 rootfs如果你的分区规划不一样注意调整。烧写并重启后如果能顺利进入系统并看到海思启动 logo那环境这块就算打通了。3. 4K视频采集通路搭建从 Sensor 到编码3.1 为什么一定要先读懂 MPP 架构海思的 MPP 媒体处理平台是这套系统里最核心的软件框架。你要做的所有事情——采集视频、做缩放或者裁剪、叠加 OSD、编码输出——都是围绕它展开的。我先把几个关键模块的作用说清楚VIVideo Input负责接收 sensor 经 MIPI 传来的 RAW 数据做基本的时序处理。VPSSVideo Processing Subsystem对视频做缩放、帧率控制、去噪、锐化等操作。VPSS 可以输出多个通道每个通道可以输出不同分辨率的图像。VENCVideo Encoder把 VPSS 输出的 YUV 数据编码成 H.265/H.264 流。ISPImage Signal Processor负责 RAW 图到 YUV 图的转换同时完成自动曝光、自动白平衡、降噪、宽动态等工作。实际开发中sensor 的例程和 MPP 例程往往需要联动起来。在 sdk 的mpp/sample/sample_venc例程里通常会有一个完整的 VI→VPSS→VENC 链路。你只需要把 sensor 的类型改为自己的型号然后匹配好分辨率和帧率。3.2 一个最小可运行的 4K 采集编码流程我写了一个最小版本可以快速验证 4K 通路是否正常。核心流程分三步第一步初始化并启动 VI。VB_CONF_S vb_conf; memset(vb_conf, 0, sizeof(vb_conf)); vb_conf.u32MaxPoolCnt 2; vb_conf.astCommPool[0].u64BlkSize 4096 * 2160 * 2; // 4K YUV 存储块 vb_conf.astCommPool[0].u32BlkCnt 6; HI_MPI_VB_SetConf(vb_conf); HI_MPI_VB_Init();这里要注意4K 画面的 YUV 数据量很大如果你只给它分配 3~4 个 buffer运行之后很容易出现“获取视频帧失败”的情况。尤其是长时间运行内存碎片会让问题更明显。我一般按照 6 个 buffer 起步去分配。第二步配置 VI 通道参数。VI_DEV_ATTR_S stDevAttr; memset(stDevAttr, 0, sizeof(stDevAttr)); stDevAttr.enIntfMode VI_MODE_MIPI; stDevAttr.enWorkMode VI_WORK_MODE_1_MULTIPLEX; stDevAttr.enDataRate VI_DATA_RATE_X1; stDevAttr.enPixFmt PIXEL_FORMAT_RGB_BAYER_BGGR; stDevAttr.enBitWidth 12; stDevAttr.enCompressMode COMPRESS_MODE_NONE;IMX334 输出的 RAW 格式是 BGGR 排列的 12-bit Bayer 数据这块千万不能配错。如果 Bayer 顺序不对你后面看到的画面会是满屏错误颜色的条纹会误以为 sensor 坏了。第三步配置 VPSS 和 VENC。VPSS 组使能之后建立一个编码通道绑定到 VPSS 的输出端口。这里建议配置成 4K 主码流 1080P 子码流的方式。监控系统通常需要本地存储高清画面同时通过网页端或者 App 预览低分辨率画面这种双码流架构就是这个目的。VPSS_GRP_ATTR_S stGrpAttr; stGrpAttr.enPixelFormat PIXEL_FORMAT_YUV_SEMIPLANAR_420; stGrpAttr.u32MaxW 3840; stGrpAttr.u32MaxH 2160; HI_MPI_VPSS_CreateGrp(0, stGrpAttr); HI_MPI_VPSS_StartGrp(0); VENC_CHN_ATTR_S stVencAttr; stVencAttr.stVencAttr.enType PT_H265; stVencAttr.stVencAttr.u32PicW 3840; stVencAttr.stVencAttr.u32PicH 2160; stVencAttr.stVencAttr.enPixelFormat PIXEL_FORMAT_YUV_SEMIPLANAR_420; HI_MPI_VENC_CreateChn(0, stVencAttr); HI_MPI_VENC_StartRecvFrame(0);如果你是第一次在 4K 分辨率下跑编码心里预期要放低一点。IMX334 的 MIPI 输出配置比较复杂不是简单改一个寄存器就行。建议先从厂家提供的 sensor 驱动例程起步例程里通常有专门的 4K 时序寄存器序列。先跑例程能点亮画面再改分辨率。否则你自己从零调 MIPI 时序光看到全黑画面上飘着绿色噪点就够折腾两天。3.3 第一帧画面的检查要点通路搭好之后先不要急着调参。第一件事是把 VPSS 输出的一帧图像直接以 YUV 格式存到 SD 卡拿到 PC 上用 YUView 等工具打开确认画面是否正常。检查时重点看三点画面是不是整体偏绿或偏红。如果偏色很严重拿一张白纸放在镜头前如果白色区域明显偏红那么 Bayer 顺序很有可能配反了或者 ISP 里的白平衡增益没生效。有没有横向或纵向的条纹。这通常是电源纹波导致的也有可能是 MIPI 信号线布得太长信号质量下降需要检查 sensor 供电是否加了足够的去耦电容。是不是全黑或全绿。如果全黑先查 sensor 有没有退出 standby然后再查 MIPI 时钟是否输出。全绿就大概率是 sensor 的初始化寄存器序列有问题很多 sensor 的默认输出是黑场需要靠配置才能打开。4. ISP 调参4K 画质的关键4.1 拿到 ISP 调试工具后先做什么ISP 调参这环节很多从单片机转过来的开发者会很不适应因为它不是一个“写代码”的过程而是一个“拿着工具调数值”的过程。海思官方提供了一款 Windows 下的 PQ Tools通过网口或串口和目标板连接可以在线实时看到 VI 输出画面并直接拖动曝光、白平衡、降噪、伽马等参数查看实时效果。拿到 PQ Tools 之后第一步不是去拉饱和度或对比度而是先看三样东西帧率计确认当前实时帧率是否达到目标直方图看画面暗部和亮部的分布是否溢出3A 状态AE 自动曝光、AWB 自动白平衡、AF 对焦确认 auto 模式有没有正常收敛。如果帧率只有 15fps那先别管画质把 sensor 的输出时序和 MIPI 配置核对一遍帧率是硬指标。只有在 30fps 下做画质调整才有意义否则你调出来的参数会因为帧率不同而失去参考价值。4.2 AE 自动曝光调节实战AEAuto Exposure是影响监控画面观感最直接的参数。核心控制对象是曝光时间和增益。在海思 PQ Tools 的 AE 配置页面里有几个关键参数必须理解Target LumaAE 的目标亮度值。海思默认一般是 60 左右但在 4K 监控场景下我一般会下调到 50 到 55 之间。原因很简单监控画面最重要的诉求是“亮部不溢出”尤其在大白天强光场景下把目标亮度调低一点点能有效保住天空和白色墙面的细节。Max Exposure Time最大曝光时间。在 4K30fps 下单帧时间是 33.3ms曝光时间不能超过这个值。但实际不要顶满因为 sensor 输出本身还需要一点时间我一般设为 25ms 左右给处理留出余量。Max Gain最大增益。这个决定暗光下的画面亮度上限但增益太大会产生明显噪点。我通常限制在 8 倍左右超过这个值就靠补光解决而不是继续拉增益。SpeedAE 收敛速度。这个参数很像自动驾驶里的 PID 调节。收敛太快画面会来回跳变一会在亮处曝光过度一会在暗处过度收敛太慢画面又会有明显的“迟钝感”。实际调项目时一个最容易犯的错误是为了夜景效果把 Max Gain 拉得很高结果白天场景下整个画面像蒙了一层雪花。正确做法是设置合理的增益上限同时把 AE 的Compensate参数调到合适档位让系统在不同光照条件下平滑过渡。我来分享一组可以试的起点参数参数推荐值说明Target Luma52偏保守利于保高光Max Exposure25ms30fps 下的安全上限Max Gain6x暗光下仍然可控AE Speed中等偏快适应监控场景的快速光照变化4.3 AWB 白平衡的坑与正确打开方式白平衡调参属于那种看起来简单、做起来让人头疼的环节。室内混合光源白炽灯加自然光下的偏色问题几乎每个做监控的人都会遇到。海思 ISP 的 AWB 模块内置了多种色温下的参考值在 PQ Tools 里可以看到 R gain 和 B gain 的变化。如果你发现画面偏暖黄橙色通常是因为 R gain 和 B gain 的比值不合适需要手动调整。这里分享一个非常实用的经验不要只看屏幕上的白色墙来做白平衡校准。屏幕本身的色温不标准墙体反射也有环境色。正确做法是用标准的灰卡或者白平衡卡放在画面中央确保灰卡充满测光区域然后触发 AWB one-push 校准。校准完成后把各个色温段下的 R gain 和 B gain 保存下来生成新的校准曲线。另外海思的 AWB 页面一般有个Reference Luma参数它规定了 AWB 统计时使用的亮度阈值。如果这个值设得过高暗部区域的色偏就完全不会被统计画面暗部就会偏绿。我的实测数据是在 2900K 白炽灯下B gain 大约是 1.6R gain 接近 1.2在 6500K 日光下R gain 会升到 1.4而 B gain 降到 1.0 左右。当然这个数值因 sensor 而异但调整趋势是对的大家可以参考。4.4 降噪与宽动态调节监控系统里降噪NR和宽动态WDR是画质的另外两个核心维度。海思的 ISP 通常提供 2DNR 和 3DNR 两种降噪。2DNR 是单帧空间域降噪3DNR 是多帧时域降噪。3DNR 降噪效果更好但会产生拖影尤其是在有运动物体的场景。调参时有一个平衡点静止场景可以把 3DNR 强度调高运动场景必须降下来。我的做法是把 3DNR 强度控制在 60%~70% 之间然后通过Spatial NR和Temporal NR两个参数做细分调整。如果发现运动的车尾灯有拖影就把 Temporal NR 往下拉一点。WDR 在逆光场景下尤其重要。典型场景是楼道口外面太阳光强室内相对暗如果只做普通 AE逆光下人脸基本是黑的。开启 WDR 后ISP 会通过多帧曝光融合来提升暗部细节。不过 WDR 有个代价就是会降低分辨率和帧率尤其在 4K 下更明显。如果你是 7x24 小时连续录像的监控场景我不建议长时间开启强 WDR 模式会更推荐开启Intelligent Backlight Compensation或者Local Tone Mapping这些更温和一些。4.5 一组可直接参考的 4K 户外参数调参是件很主观的事但作为起点我可以分享一套在户外自然光下实测效果还不错的参数组合模块参数设置值AETarget Luma52AEMax Exposure25msAEGain Limit6xAWB色温范围2500K - 7500K2DNR强度503DNR强度60WDR模式关闭开启 Local Tone MappingGamma曲线默认但亮部微降饱和度全局55这套参数的风格是“保守、干净、偏真实”。如果客户反馈画面不够鲜艳可以适当把饱和度提到 65但我不建议超过 70否则监控画面会显得假人脸肤色也会失真。5. 4K 智能监控功能的应用实现5.1 RTSP 推流视频通路和 ISP 调通之后就要开始做业务功能了。对于监控系统RTSP 推流基本上是最重要的功能它决定了你能否把 4K 画面流畅地推到局域网或公网观看。海思 VENC 编码出来的码流默认只输出 H.265 裸流。如果你直接把裸流发给播放器播放器是无法直接识别的。你想让 VLC、PotPlayer 这类播放器能够直接播放就需要把裸流包装成 RTSP 协议格式。最简单的做法是直接移植海思 SDK 里的rtsp例程它会创建 RTSP server并把编码后的 H.265 数据打包发送。如果例程版本老了你会发现市面上很多 rtsp 例程只测过 H.264跑 H.265 时会有花屏问题。这里有个细节H.265 码流包含了 VPSVideo Parameter Set、SPSSequence Parameter Set和 PPSPicture Parameter Set等关键参数集。RTSP 的sprop-parameter-sets字段必须把这些参数集转成 Base64 字符串填进去播放器才能正确解码。海思的编码通道创建后必须显式调用HI_MPI_VENC_GetH265Vps、HI_MPI_VENC_GetH265Sps、HI_MPI_VENC_GetH265Pps获取这些数据然后拼进 SDP 描述里。我实测时用 VLC 拉流延迟大约在 300ms 到 800ms 之间已经足够满足局域网预览需求。如果要进一步降低延迟需要调整 VENC 的GOP结构和码控策略。5.2 基于 NNIE 的人形检测与区域告警Hi3519DV500 的核心竞争力不只是 4K 视频而是内置的 NNIE 加速单元。这颗 NPU 虽然跟 PC 上的 GPU 没法比但在嵌入式端跑轻量级检测网络已经绰绰有余。后端模型我建议直接用 Caffe 训练因为海思的nnie_mapper工具对 Caffe 的兼容性远好于 TensorFlow 和 PyTorch。如果你习惯用 PyTorch那就先把模型导出成 ONNX再想办法转成 Caffe 模型或者使用官方支持度更好的模型结构。我自己的做法是使用 yolov3 的轻量版或者 MobileNetV2-SSD在 NNIE 上运行可以达到接近实时的效果。模型转换过程中我遇到最大的坑是层类型不支持。NNIE 对某些 OP 支持度很差比如 sigmoid 层在新版工具里需要手动配置否则转换时会直接提示不支持。我当时查了很多资料才找到原因需要修改模型的 prototxt 文件把 sigmoid 层拆解成InnerProduct Sigmoid并把激活函数放到额外实现的 C 层中。代码层面NNIE 推理的主流程是HI_MPI_NNIE_LoadModel(model_path, model); HI_MPI_NNIE_CreateHandle(handle, model); HI_MPI_NNIE_Forward(handle, input_data, result);对于 4K 画面如果直接把整帧送入 NNIE计算量会非常大帧率上不去。正确做法是先从 VPSS 输出一个 D1 分辨率720x576的通道把这一路小分辨率的画面送进 NNIE 做检测。检测到人形后再通过坐标映射回 4K 大图上用于绘制告警框。坐标映射的公式很简单int x_4k x_d1 * 3840 / 720; int y_4k y_d1 * 2160 / 576;5.3 轻量级 Bird View 双码流布防策略实际工程项目里还有一个常用技巧就是把智能分析跟主码流、子码流做策略分离。主码流 4K 用于录像1080P 子码流用于预览另外再造一个 720P 或者 D1 的智能码流专门做区域检测和人形抓拍。这样做的好处是AI 分析不占用主码流带宽主码流可以保持高码率保证画质而分析帧因为分辨率小NNIE 负担很小可以做全帧率检测。建通道时VPSS 可以绑定多个通道每个通道输出不同分辨率。你可以这么做VPSS_CHN_ATTR_S stChnAttr[3]; stChnAttr[0].u32Width 3840; // 主码流 stChnAttr[1].u32Width 1920; // 子码流 stChnAttr[2].u32Width 720; // 智能分析流三条流各自接到对应的编码通道或者 NNIE 处理模块。这个“三码流”架构在商业监控项目中几乎是标配我觉得这也应该是做 4K 监控系统的基本功。6. 常见问题与排查技巧实录6.1 常见故障速查表我在开发过程中踩过不少坑整理成一张速查表帮助你快速定位问题现象可能原因解决思路上电后串口无输出boot 启动参数不对或 boot 镜像损坏重新烧写 fastboot检查 bootargs 里的 console 参数检测不到 sensordts 中 I2C 地址错误或复位 GPIO 配置冲突对照原理图确认地址检查 GPIO 是否被其他外设占用画面全绿或偏色Bayer 顺序配置错误在 VI 设备属性中修改enPixFmt为正确的 Bayer 排列画面有横纹干扰电源纹波大或 MIPI 信号质量差检查 sensor 供电去耦尝试降低 MIPI 时钟速率编码帧率只有 20fpsVENC 码控与码率配置不匹配检查目标码率是否设得过低或者在 4K 下开启 CBR 模式NNIE 转换失败模型包含不支持的层检查 prototxt替换或拆解不支持的层RTSP 播放花屏SPS/PPS/VPS 参数集缺失或更新不当在 SDP 中正确填充参数集关键帧间隔内要重复发送eMMC 启动后文件系统变为只读文件系统未正常卸载检查执行sync启用日志型文件系统比如 ext46.2 我最想强调的五个开发习惯第一操作寄存器之前同步读出来对比。海思寄存器有一些是只读的或者写入后不断自清零如果你直接写不会报错但功能没有起作用。调试时可读回确认。第二对 ISP 参数的修改一定要平台化梳理。做 PQ Tools 调参时可以热拔插但一旦确定某个参数是最终版本的一定要同步更新代码里的初始化数组。不然每次上电都是出厂默认状态所有调参会白费。第三注意电源管理的坑。Hi3519DV500 支持动态调频调压但如果 DVFS 配置不当高负载时 CPU 会降频导致编码帧率波动。我通常在监控业务里把 CPU 频率固定到最高档尽量减少帧率抖动。第四一定要看 log。海思 MPP 层提供了比较细致的错误码不通的时候打开调试打印并且对错误码逐一翻译能节省不少时间。第五4K 编码的码率设置别太贪心。我之前为了追求画质把 4K 码率拉高到 40Mbps结果局域网推流一卡一卡本地写入 SD 卡速度也跟不上。后来调整到 16Mbps 的 H.265肉眼几乎无法区分画质差异但整个系统的稳定性能好非常多。7. 后续还可以扩展的内容这套系统跑起来之后你会发现 Hi3519DV500 的潜力远不止于此。比如 4K 下的多目标抓拍比如配合 PTZ 云台实现自动跟踪再比如在端侧跑 OCR 做车牌识别这些都是在这套基础上可以逐步加进去的。如果未来有精力我还会做两件事一是把本地告警事件通过 MQTT 协议推送到云端平台实现“端—云”联动二是接入 WebRTC 或者 SRT 协议把延迟进一步压到百毫秒以内。不过这些都是扩展了核心在于先把底层的视频通路和画质调顺。硬件底子打好了上层能玩的花样非常多。我自己是从传统 MCU 开发转过来的刚开始面对海思这套 MPP 和 ISP 体系时也花了很多时间啃文档。但一旦把底层框架吃透后面做任何视频类产品都能事半功倍。希望这篇文章能让你少走点弯路顺利完成自己的 4K 智能监控系统。