1. 从一块驱动板说起画中画到底在解决什么问题很多人第一次接触显示驱动板卡时都会把注意力放在分辨率、刷新率、接口类型这些看得见的参数上而画中画Picture-in-Picture简称PiP往往被当成一个锦上添花的小功能。但真正做过显示系统集成的人会告诉你PiP处理能力恰恰是区分一块板卡是能用还是好用的分水岭。原因很简单多路信号同时输入、实时叠加、独立缩放、无缝切换这一整套流程对板卡的硬件资源和固件调度能力提出了远高于单路显示的要求。我最初接触这个方向是因为一个多屏协作的模拟项目。当时的需求很朴素——把两路视频信号同时显示在一块屏幕上主画面全屏副画面缩到角落。听起来像是软件层面几行代码的事但实际落地时才发现如果驱动板卡本身不支持硬件级PiP靠上层软件去合成延迟和撕裂几乎无法接受。这就引出了一个核心问题画中画处理到底是在哪个环节完成的它的原理是什么为什么有的方案流畅有的方案卡顿。这篇文章面向的是显示系统开发、板卡固件调试、以及需要做多路视频合成的工程人员。我会从驱动板卡的硬件架构讲起把PiP的数据流路径、缩放引擎、叠加混合、时序控制这几个关键环节拆开揉碎再结合我在实际调试中踩过的坑给出可复现的配置思路和排查方法。不管你是刚接触驱动板的新手还是已经做过几轮项目的老人应该都能从中找到对自己有用的部分。需要先说明一点画中画在不同厂商的文档里叫法不一样有的叫PiP有的叫PBPPicture-by-Picture画外画还有的归在多窗口合成这个大类别下。本文讨论的重点是一大一小、小窗叠加在大窗之上这种典型PiP形态PBP那种左右分屏的逻辑会在对比章节里简单带过。2. 驱动板卡内部的数据通路PiP信号从哪里来到哪里去2.1 输入采集与信号归一化要理解PiP首先得搞清楚一块显示驱动板卡的基本数据流。典型的板卡上信号从外部接口进来经过接收器Receiver解码变成板卡内部可以处理的像素流。这个像素流可能是RGB、YUV422、YUV444等不同格式分辨率、帧率、色彩深度也各不相同。PiP的第一步就是把这些五花八门的输入信号统一成内部处理引擎能吃的格式。举个具体的例子主通道走HDMI输入可能是1920x108060Hz的RGB888副通道走另一路输入可能是1280x72030Hz的YUV422。这两路信号在时序、色彩空间、像素时钟上完全对不齐。如果直接把两路数据往叠加模块里灌结果一定是花屏或者不同步。所以板卡固件里会有一个归一化阶段把副通道的信号先做色彩空间转换CSC再通过缩放引擎调整到目标尺寸最后写入一个内部帧缓冲。这里有个容易被忽略的细节归一化不只是格式转换还涉及时钟域的切换。主通道和副通道往往跑在不同的像素时钟下跨时钟域的数据搬运必须用异步FIFO来缓冲否则亚稳态问题会让画面出现随机噪点。我在调试一块早期板卡时副画面偶尔出现一条细小的竖向亮线查了很久才发现是FIFO深度不够在特定分辨率组合下发生了溢出。2.2 缩放引擎的工作机制缩放是PiP处理里计算量最大的环节。副画面从原始分辨率缩到小窗尺寸比如从1280x720缩到320x180缩放比是4:1。这个缩放如果做得粗糙画面会明显模糊或者出现锯齿。板卡里通常用硬件缩放器来实现常见的有两种架构多相滤波器Polyphase Filter和双线性插值Bilinear Interpolation。多相滤波器的质量更好它根据缩放比例动态选择滤波系数能有效抑制缩放带来的混叠。但它的硬件成本更高需要存储多组系数表。双线性插值实现简单资源占用少但在缩放比大的时候画面会偏软。实际选型时如果副画面尺寸不大、对画质要求不极端双线性插值通常够用如果要做大比例缩放且要求边缘锐利就得上多相滤波器。缩放引擎还有一个关键参数是缩放方向的处理顺序。水平缩放和垂直缩放谁先谁后对行缓冲的占用影响很大。一般先做水平缩放再做垂直缩放因为水平缩放后行宽变小垂直缩放需要的行缓冲深度也跟着变小能省不少片上内存。这个细节在资源紧张的板卡上往往是决定能不能跑起来的关键。2.3 叠加混合与Alpha通道两路信号都准备好之后就进入叠加阶段。叠加的本质是在目标像素位置上做一个选择或混合主画面该位置的像素、副画面该位置的像素二选一或者按比例混合。如果副画面是矩形硬边那就是简单的区域选择如果要做出圆角、阴影、半透明效果就需要Alpha混合。Alpha混合的公式很直白输出 副画面像素 × Alpha 主画面像素 × (1 - Alpha)。但硬件实现时Alpha值的来源有多种可以是固定的全局Alpha可以是每个像素自带的Alpha通道也可以是一张单独的Alpha掩膜图。全局Alpha最省资源适合做简单的半透明小窗逐像素Alpha最灵活但需要副画面数据本身带Alpha或者额外读取掩膜带宽开销更大。我在一个项目里做过带圆角和渐变阴影的PiP效果用的就是掩膜方案。掩膜图是一张和副画面同尺寸的灰度图白色区域完全显示副画面黑色区域完全显示主画面灰色区域按比例混合。这样圆角和阴影的过渡就很自然。代价是每帧要多读一份掩膜数据对内存带宽有额外压力所以掩膜图一般用低分辨率再放大使用平衡效果和开销。2.4 输出时序与帧同步叠加完成后的合成帧最终要按输出时序送到显示接口。这里最怕的是撕裂——主画面和副画面更新不同步导致画面上出现一条横向的分界线。避免撕裂的核心是帧同步合成操作必须在垂直消隐期VBlank内完成或者使用双缓冲机制让显示端始终读一个完整的帧缓冲写端在另一个缓冲上合成完成后切换。双缓冲的代价是需要两倍帧缓冲内存。对于1080p的合成帧一帧大约需要1920×1080×4字节≈8MB双缓冲就是16MB。如果板卡片上内存有限可能要用DDR外存那带宽和延迟又成了新问题。所以很多低成本方案会选择区域更新策略只更新副画面覆盖的那块区域主画面区域不动这样能大幅减少每帧的写入量。但区域更新对时序控制要求更高要精确计算副画面的位置和尺寸确保不越界、不遗漏。3. 硬件架构选型FPGA、ASIC还是SoC方案3.1 三种主流架构的取舍做PiP处理底层架构的选择直接决定了开发周期、灵活性和成本。市面上常见的方案大致分三类纯FPGA方案、专用ASIC方案、以及带显示处理单元的SoC方案。FPGA方案的最大优势是灵活。缩放算法、混合逻辑、缓冲策略都可以自己定义想改就改。缺点是开发周期长需要写Verilog或VHDL调试起来也麻烦。而且FPGA的片上资源有限做高分辨率多路PiP时Block RAM和DSP slice很容易不够用。我见过一个团队用中端FPGA做4路PiP最后因为缩放器资源不够只能把其中两路的缩放质量降级。ASIC方案是厂商把PiP功能固化在芯片里开发者通过寄存器配置来使用。优点是稳定、功耗低、成本低量大时缺点是功能固定想加点自定义效果基本没戏。很多电视芯片、监控解码芯片里的PiP就是这种配置几个寄存器就能出画面但你别指望它能做非矩形窗口或者自定义混合曲线。SoC方案介于两者之间。现在的显示SoC通常带一个显示处理单元DPU或者2D图形加速器能硬件加速缩放和混合同时又有CPU和可编程逻辑做灵活调度。这种方案开发难度适中适合需要一定定制化但又不想从零写RTL的团队。选型时我会重点看DPU的层数支持、缩放器的输入输出规格、以及内存带宽预算。3.2 内存带宽的估算方法不管选哪种架构内存带宽都是PiP方案能不能跑起来的硬约束。估算方法不复杂但很容易算漏。以1080p60Hz、双路PiP为例主画面读取1920×1080×60×4字节≈497MB/s副画面读取假设720p1280×720×60×4字节≈221MB/s缩放后副画面写入320×180×60×4字节≈14MB/s合成帧写入1920×1080×60×4字节≈497MB/s合成帧读出送显示1920×1080×60×4字节≈497MB/s加起来大约1.7GB/s。这还没算上如果做Alpha混合需要额外读取掩膜、如果做双缓冲需要额外写入的带宽。实际规划时我一般会在这个理论值上留50%余量因为内存控制器的效率不可能100%而且还有其他模块在抢带宽。如果板卡用的是DDR3理论带宽可能就8GB/s左右实际可用可能只有60%那1.7GB/s的PiP需求就占掉了三分之一还多留给其他功能的空间就很紧张了。3.3 缩放器资源的分配策略在多路PiP场景下缩放器往往是稀缺资源。一块板卡可能只有两个缩放器但你要做三路PiP怎么办常见的策略是主路不缩放副路缩放。主画面直接按原始分辨率送显示不经过缩放器副画面才用缩放器调整尺寸。这样两个缩放器可以支持两路副画面加上主路就是三路PiP。如果副画面数量更多还可以考虑时分复用缩放器在一帧的时间内缩放器先处理第一路副画面再处理第二路依次类推。这要求缩放器的处理速度足够快能在行消隐和场消隐期间完成多路切换。时分复用的代价是控制逻辑复杂而且每路副画面的更新率可能下降。我在一个监控模拟项目里用过这个策略四路副画面轮流用两个缩放器最终每路副画面的实际刷新率只有15Hz但监控场景对流畅度要求不高所以可以接受。4. 实际调试中遇到的典型问题与排查链路4.1 副画面闪烁从时钟域查到FIFO深度前面提到过副画面出现竖向亮线的问题其实闪烁是更常见的现象。我遇到过一次副画面每隔几秒闪一下闪的时候画面内容还是对的就是亮度突然跳变。排查过程大致是这样的第一步确认是不是信号源的问题。把副通道的信号直接接到显示器上画面稳定排除源端。第二步怀疑是缩放器的系数切换导致的因为多相滤波器在缩放比变化时会重新计算系数如果系数更新和像素流不同步就会产生瞬时错误。查了寄存器配置缩放比是固定的系数只在初始化时写一次排除。第三步用逻辑分析仪抓FIFO的读写指针发现写指针偶尔会追上读指针说明FIFO快满了。原来副通道的输入时序在特定帧会有微小抖动像素时钟偶尔偏快导致FIFO积累。把FIFO深度从512增加到1024问题消失。这个案例的教训是PiP的稳定性不只取决于算法还取决于跨时钟域缓冲的设计余量。输入信号的时钟抖动、板卡晶振的温漂、甚至电源纹波都可能让FIFO的余量被吃掉。设计时FIFO深度要按最坏情况估算不能只按标称时钟算。4.2 副画面位置偏移坐标系与对齐规则的坑另一个高频问题是副画面的位置和预期对不上。你配置的坐标是(1600, 880)期望小窗出现在右下角结果实际显示偏了几十个像素。这种问题通常出在坐标系定义上。显示系统的坐标系有几种常见约定有的以左上角为原点有的以左下角为原点有的坐标单位是像素有的是以2像素或4像素为步进。更麻烦的是缩放后的副画面尺寸可能不是整数比如1280缩到320正好是4:1但如果缩到300缩放比就是4.267:1实际输出的有效像素可能是299或301导致位置计算出现累积误差。我的做法是在配置寄存器之前先用一个已知图案比如棋盘格验证坐标映射关系。把副画面设到(0,0)看它实际出现在哪个角再设到最大坐标看边界在哪里。这样能快速确定坐标原点和步进规则。另外缩放后的尺寸尽量取整数比避免非整数缩放带来的对齐问题。如果必须非整数缩放位置计算要用缩放后的实际尺寸而不是理论尺寸。4.3 色彩偏差YUV与RGB转换的系数陷阱PiP合成时如果主副通道的色彩空间不一致就需要做CSC。CSC的系数矩阵如果配置不对副画面会明显偏色。我见过一次副画面偏绿查了半天发现是YUV到RGB的转换系数用错了标准。BT.601和BT.709的系数矩阵是不一样的前者用于标清后者用于高清。如果输入是720p但用了BT.601的系数绿色通道就会偏。排查这类问题最直接的方法是用标准彩条信号输入然后抓合成后的像素值和理论值对比。理论值可以按CSC公式手算也可以用一个已知正确的转换工具生成参考图。对比之后偏差在哪个通道、偏差多少一目了然。修正就是改系数寄存器但要注意系数的定点格式——有的芯片用Q15格式有的用Q12小数点位置搞错的话偏差会大得离谱。4.4 带宽不足导致的画面卡顿带宽不足的表现通常是副画面更新变慢或者主画面出现周期性卡顿。用带宽分析工具抓内存控制器的读写请求如果看到请求队列经常满那就是带宽瓶颈了。缓解带宽压力的手段有几个一是降低副画面的刷新率比如从60Hz降到30Hz带宽直接减半二是压缩副画面的色彩深度从RGB888降到RGB565带宽减少三分之一三是优化合成策略只更新副画面区域而不是全帧更新四是把帧缓冲从DDR挪到片上SRAM如果容量够的话。我在一个项目里同时用了前三个手段副画面30Hz、RGB565、区域更新把PiP的带宽需求从1.7GB/s压到了600MB/s左右板卡就稳了。代价是副画面色彩稍微差一点但那个场景下副画面只是用来监看画质要求不高所以可以接受。5. PiP与PBP、多图层合成的边界与选择5.1 PiP和PBP的本质区别PiP和PBP经常被混为一谈但它们的处理逻辑有本质区别。PiP是叠加副画面覆盖在主画面之上主画面被覆盖的区域不显示PBP是拼接两路画面各占屏幕的一部分互不覆盖。从硬件角度看PiP需要混合器BlenderPBP只需要裁剪和定位。这个区别影响资源分配。PBP不需要Alpha混合也不需要处理覆盖区域的像素选择所以带宽和逻辑资源都更省。如果应用场景只是左右分屏显示两路信号用PBP方案会比PiP更高效。但PBP的灵活性差不能做画中画那种小窗浮动的效果。实际项目中有些场景需要两者结合比如主画面全屏右上角一个小窗PiP底部一条状态栏另一个图层。这就涉及多图层合成比单纯的PiP更复杂。多图层合成需要图层管理器来分配层级、处理遮挡关系、管理每层的Alpha和位置。图层数越多带宽和逻辑资源消耗越大所以图层数通常有限制比如最多4层或8层。5.2 多图层合成的层级管理多图层合成的核心是从下往上逐层叠加。最底层是背景然后依次往上叠加各个图层每层只处理自己覆盖的区域。层级顺序由寄存器配置决定但要注意有些硬件不支持任意层级顺序比如固定背景在最下、OSD在最上中间层可调。层级管理的一个常见坑是层级冲突两个图层配置了相同的层级号硬件行为不确定可能显示其中一个也可能闪烁。排查时先检查层级寄存器有没有重复。另一个坑是透明区域处理如果上层图层的某些像素是透明的Alpha0这些位置应该显示下层内容。但如果透明判断逻辑有bug透明区域可能显示成黑色或上层图层的底色。验证方法是放一个带透明区域的测试图看下层内容是否正确透出。5.3 什么场景该用哪种方案选PiP还是PBP还是多图层取决于具体需求。如果只是主画面一个小监看窗PiP最直接。如果是两路对等显示PBP更合适。如果需要主画面多个信息层浮动窗口那就得上多图层合成。从成本角度PiP和PBP的硬件需求相对低很多中低端板卡都能支持。多图层合成对内存带宽和逻辑资源要求高通常只有中高端芯片才做得好。我在选型时的一个经验是先明确最多需要几层和每层是否需要独立缩放这两个问题决定了芯片的最低规格。如果层数少且不需要独立缩放选便宜的芯片就行如果层数多且每层都要缩放那就得选带多个缩放器的高端芯片成本会上去不少。6. 几个容易被忽视的实操细节6.1 副画面的边界处理副画面的边缘如果处理不好会出现黑边或者锯齿。黑边通常是因为缩放后的副画面尺寸和配置的窗口尺寸不一致多出来的区域没有填充。锯齿则是因为缩放算法在边缘没有做特殊处理导致边缘像素被截断。解决黑边的办法是确保缩放输出尺寸和窗口尺寸严格一致或者在窗口配置时留出几个像素的余量让黑边落在不显眼的位置。解决锯齿可以在缩放器的边缘处理里开启边缘扩展模式让边缘像素重复而不是截断。有些缩放器还支持边缘平滑在边缘几个像素内做渐变效果更好但资源消耗略高。6.2 动态切换时的过渡处理PiP的一个常见需求是动态切换副画面从一路信号切到另一路或者副画面的位置、尺寸动态变化。如果切换时不做过渡处理画面会突然跳变观感很差。过渡处理有两种思路一种是淡入淡出通过动态调整Alpha值让旧画面逐渐消失、新画面逐渐出现另一种是滑动让副画面从旧位置滑到新位置。淡入淡出实现简单只需要一个Alpha渐变计数器滑动需要每帧更新位置寄存器对控制逻辑要求高一些。我在做动态切换时踩过一个坑切换过程中如果新旧信号的时序不一致混合器会短暂输出错误像素。解决办法是在切换前先让副通道进入静音状态输出黑色或透明等新信号稳定后再恢复。这个静音期通常几帧就够了人眼几乎察觉不到。6.3 低延迟场景的特殊考量有些应用对延迟极其敏感比如实时监看、游戏画面叠加。PiP处理本身会引入延迟缩放需要缓冲几行像素混合需要等一帧合成完成双缓冲又要多等一帧。加起来可能十几毫秒甚至几十毫秒。降低延迟的手段包括减少缩放器的行缓冲深度代价是缩放质量下降、使用单缓冲加区域更新避免双缓冲的帧延迟、提高合成时钟频率让合成更快完成。但这些都是有代价的需要在延迟和画质/稳定性之间权衡。我的经验是如果延迟要求低于16ms一帧那PiP的缩放质量基本没法保证只能做最简单的像素复制缩放。6.4 调试工具与验证方法调试PiP问题光看最终画面往往不够需要能看到内部数据流。常用的手段有抓取内部帧缓冲的内容很多板卡支持把帧缓冲导出到文件、用逻辑分析仪抓关键控制信号、在固件里加计数器统计各模块的吞吐量。验证PiP功能是否正常我一般会准备一套测试图案棋盘格用来查对齐和缩放彩条用来查色彩渐变图用来查Alpha混合运动画面用来查撕裂和延迟。这套图案覆盖了大部分常见问题调试时按顺序过一遍基本能定位到问题环节。7. 写在最后的一点个人体会画中画处理看起来只是显示驱动板卡的一个小功能但把它做稳、做好涉及的环节从信号采集、格式转换、缩放、混合到时序控制几乎覆盖了显示通路的全部关键点。我做了几个相关项目之后最大的感受是PiP的难点不在算法本身而在资源约束下的取舍。带宽、内存、逻辑资源、延迟这几个指标互相拉扯你很难同时做到最好只能根据场景找平衡点。另外文档里写的参数和实际跑出来的效果往往有差距。厂商给的缩放器系数表可能是理想条件下的实际输入信号的抖动、板卡的电源噪声、温度变化都会让效果打折扣。所以我的习惯是任何PiP配置先在实验室常温下跑通再放到高温箱里跑老化最后在实际环境里连续跑几天。能扛过这三关的配置才算真正可用。