1. 从一块驱动板说起：画中画到底在解决什么问题
很多人第一次接触显示驱动板卡时，都会把注意力放在分辨率、刷新率、接口类型这些"看得见"的参数上，而画中画（Picture-in-Picture，简称PiP）往往被当成一个锦上添花的小功能。但真正做过显示系统集成的人会告诉你，PiP处理能力恰恰是区分一块板卡是"能用"还是"好用"的分水岭。原因很简单：多路信号同时输入、实时叠加、独立缩放、无缝切换，这一整套流程对板卡的硬件资源和固件调度能力提出了远高于单路显示的要求。
我最初接触这个方向，是因为一个多屏协作的模拟项目。当时的需求很朴素——把两路视频信号同时显示在一块屏幕上，主画面全屏，副画面缩到角落。听起来像是软件层面几行代码的事，但实际落地时才发现，如果驱动板卡本身不支持硬件级PiP，靠上层软件去合成，延迟和撕裂几乎无法接受。这就引出了一个核心问题：画中画处理到底是在哪个环节完成的，它的原理是什么，为什么有的方案流畅有的方案卡顿。
这篇文章面向的是显示系统开发、板卡固件调试、以及需要做多路视频合成的工程人员。我会从驱动板卡的硬件架构讲起，把PiP的数据流路径、缩放引擎、叠加混合、时序控制这几个关键环节拆开揉碎，再结合我在实际调试中踩过的坑，给出可复现的配置思路和排查方法。不管你是刚接触驱动板的新手，还是已经做过几轮项目的老人，应该都能从中找到对自己有用的部分。
需要先说明一点：画中画在不同厂商的文档里叫法不一样，有的叫PiP，有的叫PBP（Picture-by-Picture，画外画），还有的归在"多窗口合成"这个大类别下。本文讨论的重点是"一大一小、小窗叠加在大窗之上"这种典型PiP形态，PBP那种左右分屏的逻辑会在对比章节里简单带过。
2. 驱动板卡内部的数据通路：PiP信号从哪里来，到哪里去
2.1 输入采集与信号归一化
要理解PiP，首先得搞清楚一块显示驱动板卡的基本数据流。典型的板卡上，信号从外部接口进来，经过接收器（Receiver）解码，变成板卡内部可以处理的像素流。这个像素流可能是RGB、YUV422、YUV444等不同格式，分辨率、帧率、色彩深度也各不相同。PiP的第一步，就是把这些"五花八门"的输入信号统一成内部处理引擎能吃的格式。
举个具体的例子：主通道走HDMI输入，可能是1920x1080@60Hz的RGB888；副通道走另一路输入，可能是1280x720@30Hz的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方案能不能跑起来的硬约束。估算方法不复杂，但很容易算漏。以1080p@60Hz、双路PiP为例：
- 主画面读取：1920×1080×60×4字节≈497MB/s
- 副画面读取（假设720p）：1280×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需要混合器（Blender），PBP只需要裁剪和定位。
这个区别影响资源分配。PBP不需要Alpha混合，也不需要处理覆盖区域的像素选择，所以带宽和逻辑资源都更省。如果应用场景只是左右分屏显示两路信号，用PBP方案会比PiP更高效。但PBP的灵活性差，不能做画中画那种"小窗浮动"的效果。
实际项目中，有些场景需要两者结合：比如主画面全屏，右上角一个小窗（PiP），底部一条状态栏（另一个图层）。这就涉及多图层合成，比单纯的PiP更复杂。多图层合成需要图层管理器来分配层级、处理遮挡关系、管理每层的Alpha和位置。图层数越多，带宽和逻辑资源消耗越大，所以图层数通常有限制，比如最多4层或8层。
5.2 多图层合成的层级管理
多图层合成的核心是"从下往上"逐层叠加。最底层是背景，然后依次往上叠加各个图层，每层只处理自己覆盖的区域。层级顺序由寄存器配置决定，但要注意有些硬件不支持任意层级顺序，比如固定背景在最下、OSD在最上，中间层可调。
层级管理的一个常见坑是"层级冲突"：两个图层配置了相同的层级号，硬件行为不确定，可能显示其中一个，也可能闪烁。排查时先检查层级寄存器有没有重复。另一个坑是"透明区域处理"：如果上层图层的某些像素是透明的（Alpha=0），这些位置应该显示下层内容。但如果透明判断逻辑有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配置，先在实验室常温下跑通，再放到高温箱里跑老化，最后在实际环境里连续跑几天。能扛过这三关的配置，才算真正可用。
