183、安防NVR中8路1080P实时编码的ISP带宽与编码器协同——海思Hi3536D的DDR仲裁策略兄弟们，今天聊个老平台，海思Hi3536D。这芯片现在看性能不算猛，但当年在入门级NVR市场那是真出货王，8路1080P实时编码是它的招牌菜。可这招牌菜，做起来是真容易翻车。我当年接手一个项目，客户反馈说画面间歇性卡顿，不是网络卡，是本地预览都卡，而且一卡就是整机所有通道一起卡，像被人按了暂停键。用海思的mpp工具看编码帧率，每路都报30fps，但实际出帧时间戳间隔忽大忽小，最大能跳到80ms。这问题，典型不是编码器算力不够，是DDR带宽被抢了，或者仲裁策略没配好。先理一下这芯片的架构。Hi3536D内部，ISP、VENC（视频编码器）、还有那个负责图像缩放的TDE，以及CPU核，全部挂在DDR总线上。8路1080P，意味着8个ISP通道（或者通过MIPI虚拟通道扩展）同时在做3A统计、去噪、畸变校正，这些操作全是高带宽读写的。另一边，8路H.264编码器，每路1080P@30fps，码率如果设成4Mbps，那编码器不仅要读原始YUV数据，还要读参考帧做运动估计，写重建帧，写码流。这一进一出，DDR带宽压力直接爆表。我那次调试，第一件事就是查海思的DDR带宽配置。在Hi3536D的寄存器里，有个叫DDRC_CFG的东西，里面可以设置不同主设备的优先级。默认配置下，CPU和TDE的优先级是高的，ISP和VENC是低的。这看起来合理，CPU要跑系统，TDE要快。但问题就出在这，8路ISP同时工作，每路ISP在每一帧处理时，会有个瞬间的带宽峰值，比如在做3A统计时，要读整帧的亮度数据。如果此时VENC也在做运动估计，也在疯狂读参考帧，两