最近在调一个1080p60帧的实时视频去雾项目，用的Xilinx Zynq，暗通道先验算法在PL侧实现时BRAM直接爆了。我知道分时复用行缓存可以省资源，但听师兄说还有用PS端DMA配合乒乓操作、或者把暗通道计算改成滑窗近似来降低缓存深度的做法。有没有大佬实际调过？BRAM不够时你们是优先改算法近似，还是硬上DDR3做帧缓存？哪个方案在实时性上更稳？
回答 6
我去年调过一个类似的项目，也是1080p60，暗通道先验，BRAM爆得死死的。你师兄说的那两个方向我都试过，结论是：想稳就别硬上DDR3做帧缓存。实时视频60帧，一帧1080p的暗通道图大约135KB，但你做去雾需要至少两帧的窗口，用DDR3做乒乓缓存的话，读写带宽压力很大，而且Zynq的PS和PL之间走AXI-HP口，延迟抖动在帧级缓存场景下容易导致偶尔的丢帧或撕裂。我后来走的是滑窗近似这条路——把暗通道计算从整帧统计改成局部块统计，比如用16×16的块，每个块只取最小像素值，然后做插值平滑。这样行缓存深度从一帧降到了几十行，BRAM刚好够用。代价是天空区域偶尔会有块状伪影，但加个小中值滤波就能压下去。风险在于如果你们项目对PSNR有硬指标，滑窗近似可能过不了验收。另外还有个骚操作：把暗通道里的最小值滤波改成形态学腐蚀的硬件实现，用移位寄存器代替BRAM，但只适合窗口很小的场景。你目前用的是哪个版本的Vivado？不同版本对BRAM的打包策略有差异，有时候换一下综合选项就能省出10%的BRAM。
DDR3帧缓存搞实时60帧，你调完时序会发现大部分时间都在等DMA，除非你用多通道AXI且优先级调得很激进。不如直接改滑窗近似，省下来的BRAM还能加点去雾强度自适应逻辑。
先说结论：在1080p60的实时约束下，我个人不建议直接用DDR3做完整帧缓存。原因有三。第一，暗通道先验的核心操作是最小值滤波，滤波窗口通常15×15到21×21，这意味着你真正需要的不是整帧数据，而是窗口高度对应的行数。如果窗口是15行，你只需要15行缓存，而一帧1080p需要1080行，差了72倍。用DDR3去缓存整个帧，等于为了取15行的数据而搬运1080行的带宽，AXI总线在60fps下很容易被占满，留给PS端CPU处理其他任务（比如白平衡或曝光控制）的带宽就很少了。第二，乒乓操作在PL侧需要两个帧缓存地址来回切换，这涉及地址生成逻辑和DMA描述符链的管理，调试起来很繁琐，而且一旦DMA传输和帧同步信号出现相位偏差，就会产生花屏。第三，从工程取舍角度看，暗通道先验本身是一个近似算法，它的数学基础是大气散射模型，但实际场景中大气光值和透射率的估计误差本来就很大。你花大量资源去精确缓存整帧数据，但算法本身只有80%的准确率，这性价比不高。我推荐的做法是：把暗通道计算改成基于块的滑窗近似，窗口大小取16×16或32×32，每个块独立算最小值，然后用双线性插值恢复逐像素的暗通道值。这样行缓存深度从1080降到16或32，BRAM占用从爆表降到60%左右。如果想进一步优化，可以把插值系数做成查找表存在分布式RAM里。实时性上，滑窗近似是纯流水线结构，延迟只有几十个时钟周期，比DDR3的几百微秒延迟稳得多。最后提醒一点：改算法近似之前，先拿几帧典型视频（有雾的田野、城市、室内）跑一下MATLAB模型，确认PSNR下降在可接受范围内，否则回头改硬件架构非常痛苦。你目前用的Zynq具体型号是7010还是7020？这两个的BRAM总量差了近一倍，如果是7010，那确实只能走近似路线了。
说个你们师兄可能没细讲的思路：把暗通道的排序统计直接换成位平面近似。1080p60下，最小值滤波本质上是找窗口内像素的最低值，你不需要精确到8bit，取高4位或5位做比较，窗口尺寸不变但比较器位宽砍半，BRAM里的比较树面积能降30%以上。代价是去雾强度在低灰度区域会偏弱，但人眼对暗部细节本来就不敏感，配合一个简单的伽马矫正就能拉回来。另一个方向是直接改算法拓扑：传统的暗通道先验是先算暗通道再估计大气光，你可以把这两个步骤合并成一个流水线——在行缓存填充过程中同时维护一个全局最小值寄存器，这样大气光估计就不需要额外帧缓存了。我去年在Artix-7上试过，1080p30能跑，60帧的话得把窗口从15×15缩到11×11，但视觉差异不大。重点在于：如果你坚持用DDR3做乒乓，一定要算清楚AXI-HP口的实际可用带宽——文档标的1200MB/s是理论突发值，实际在64位总线+非对齐访问下能跑到700MB/s就不错了，而一帧1080p RGB888的数据量约6.2MB，60帧就是372MB/s的写入再加等量的读出，已经超过700了，你留给PS端做其他处理的余量几乎为零。所以我的建议是：先试位平面近似+合并大气光估计，如果PSNR验收过不了再考虑上DDR3，但上DDR3的同时必须把暗通道计算拆成分块流水线，别整帧写完再读。你当前项目的BRAM具体剩多少？
个人觉得最骚的操作是直接用PL的LUT分布式RAM做滑窗，不用BRAM。1080p60下窗口15行，每行1920像素，RGB三个通道各8bit，你需要的只是窗口内所有像素的最小值，不是整帧。把滑窗状态机做成三级流水：第一级读当前行数据到LUT，第二级做列方向最小值比较，第三级做行方向比较。LUT资源够的话，窗口深度可以做到20行以内，BRAM完全空出来。代价是LUT利用率会飙到80%以上，布局布线容易出时序问题，需要手动加位置约束。如果你们项目允许用Vivado的智能编译，可以试试看。
别纠结BRAM了，直接上滑窗近似加中值后处理，效果比硬上DDR3稳得多。DDR3那套时序调完你会发现大部分时间都在和AXI握手信号打架。你师兄说的乒乓操作适合非实时场景，60帧下带宽根本不够你来回倒腾。
发表回答
登录后可在本页底部提交回答
游