概要
做显示系统，比如电视 或者 机顶盒，都会遇到一些业务上常见难以解决的问题，或者典型实现方案下存在使用约束，以及部分常见的芯片约束。比较零散，以此记录自己设计开发维护过程中遇到的通用性经验问题。 比较零散。
一、常见的问题场景
1 输入源信息的不准确
问题）：显示系统通过解码模块对码流的马流头解析出帧信息，比如 宽高、逐隔行、帧率、颜色空间等等，显示系统也是根据这些信息进行对应的播放策略，但是很多码流本身填写的源信息就不准确，典型的比如逐隔行信息错误、或者部分信息如颜色空间的full/limit缺省。此时就会引入一些显示策略问题。
标准）：此类问题，常见一些问题码流。客户的评价标准 往往是和友商的平台 或者 电脑PC上播放 进行比对，如果此类问题码流在其他平台能够正常播放，而你的平台无法正常显示，就会变成问题。。。本质上虽然是输入源信息不准确，也衍生为兼容性的能力需求。
常见的解决方案）：1、软件上对信息做检查矫正策略，典型常见 比如超过FHD分辨率 我们认为隔行码流可能性非常小，可以对隔行标志进行修正。通过帧信息的pts解析计算进行做帧率的矫正。2、对缺省值做最适当的默认值，举个例子，当color space的limt/full填写信息缺省时，如果默认为limit，当源是full时 超过limit范围会clip掉，显示时会引起细节的丢失，而如果默认为full，当源实际为limit的时候，会出现比如黑不够黑的边界不够的问题，相比之下细节丢失更容易引起客户认为是问题。3、通过逻辑或者软件算法对帧数据进行检测识别，来矫正帧信息（这个是相比下最准确的，也不会引起按某个固定策略矫正遇到特殊情况把正确的信息修改错误的情况，但是成本也是最高的）。
2 音视频同步精度不够
3 视频图形匹配不同步
视频和图形的匹配是显示系统中重要的一环，在android手机上或者一些简单的显示设备，往往不会区分 视频数据通路和图形数据通路，视频和图形的数据都是往一个buffer进行叠加后统一显示，这种方式是最简单的，由于视频图形统一叠加控制，匹配度完全没有问题。
但是针对一些对图像质量相对要求跟高的系统，由于视频的数据和图形的数据处理方式差异比较大，需要分成视频通路和图形通路进行单独效果处理 然后硬件在线叠加显示，在这种系统下 图形往往是GPU绘制，视频是单独的控制通路，两者之间的数据通路长短和通路中数据buffer缓存数量，引起视频和图形的叠加就很难完全同步。
4 系统带宽不足，模块间优先级不合理，瞬时带宽分配问题
1、系统带宽约束
任何一个系统都会有系统带宽的约束，一个系统在发布的时候会描述对于规格的约束，比如支持那些输入数据格式，分辨的码率 分辨率 帧率的大小。但是 约束永远无法限制完整，很多不可见的细节变化也会产生冲击。举例：
1）随着APP的更新，图形UI变得更复杂。随着图形的复杂度提升，GPU的绘制和叠加次数的上升都会影响带宽。但你无法约束，也无法给出明确的约束 到底支持到多复杂的UI，客户也无法控制APP升级后设计的复杂度。特别时一些认证场景，很常见的会构建一些复杂的测试。
2）随着客户市场的扩大，业务出现了变化。原本不会同时出现的AB场景，需要同时存在，并且逻辑实现上是可行的 但是性能面临约束。
2、模块间优先级不合理
在显示系统中，多个模块都在同时访问DDR抢占总线带宽，几个典型的模块就是：
1）解码模块 从DDR访问视频码流进行解码解出帧存，特点时访问量大切密集，只要逻辑有空闲而且当前有足够的buffer可写入 就持续访问。
2）GPU 往DDR回写图像数据，和具体的场景相关 需要看当前的图形变化是否密集，GPU刷新率往往是随实际需求变化的
3）图像显示模块 图像显示模块的特点是刷新率固定 和 当前设备输出刷新率相关，比如FHD60hz输出，访问DDR带宽相对是稳定的，但是对瞬时带宽优先级要求非常，比如解码如果抢占不到带宽结果是先hold住等待总线空闲，但是显示模块瞬时带宽不足够那就无法保证正常显示 引起显示异常。
更具各个模块的访问特点 来定义每个模块的有限级，甚至通过专有通路来保证对瞬时带宽要求高的模块。
5 通路延时不够低
一个显示系统的延时是一个重要的指标，比如从HDMI输入端口开始接受数据，到画面上看到第一行数据，这个过程为通路的延时。通路中的延时引入 基本包括了 采集模块的采集时间，中处理模块的配置处理时间，显示模块的配置显示时间，通路中各个位置的buffer缓存，通路中buffer的调度时间。
1）极限延时方案-输入输出在线送数据（依赖逻辑方案）：
对延时有极高的要求，显示效果提升需求低，对音视频同步无需求，比如作为显示设备对接游戏机时 对延时非常敏感。可以选择 放弃所有中处理模块，放弃buffer缓存，放弃同步，采集模块 逻辑上 和 显示模块直连，数据送进来直接输出显示，这种显示通路整个延时只有几行（逻辑内部的行缓存数据），通路约束是输入输出数据比例需要严格匹配（基本无法进行缩放、显示区域调整、多帧算法参考处理等）。
2）超低延时方案-输入和输出同时访问一块buffer，2个buffer轮转（依赖逻辑方案）：
输入往DDR写这块buffer的时候就把buffer提前送到显示模块（不需要写完），显示模块逻辑决策是否的访问这块buffer，通过计算输入数据量和输出数据量来得出一个启动安全距离，显示模块需要显示新时帧时看一下采集模块是否已经写到安全距离了来决策是否要切换到这个buffer，整个过程完全由逻辑控制，一般情况下延时能做到一帧以内，n行数据的延时。
3）低延时方案-输入模块提前送buffer
如果没有逻辑方案上的支持，如何降低延时呢，典型的方案就是通过计算 显示模块收到一帧后配置显示最短的时间 做一个提前送的安全余量，让采集模块在没有写完这一帧的时候 就开始送给到显示模块。
6 基于中断业务 系统中断响应不及时 的影响
7 基于线程业务 系统线程调度不及时 的 影响
8 用户态进程异常kill后 内核对应资源的释放处理
9 变分辨率变帧率的网络码流显示质量
10 同步调整的平滑设计问题
11 场景切换的体验 设计问题
二、常见方案约束或问题
1 多实例/多进程多实例/跨进程实例共享 的设计遗漏
2 帧级别的策略响应 设计 问题
3 不合理的串行设计 引入的性能问题
4 粗暴的配置策略 引入的效率问题
5 不合理的硬件抽象引入的 通用性问题
6 贫乏的调试手段引入的 维护效率问题
7 并发保护问题
8 不合理的业务划分，引起多个模块之间复杂交互
三、常见逻辑约束或问题
1 逻辑IP的对齐约束
很多逻辑IP存在对数据处理时的宽度或者高度存在部分对齐约束，比如2对齐、4对齐、甚至8对齐，并且这些对齐特性可能随着通路中一些整数倍的缩放被进一步放大，引起整个显示通路的对齐约束被放大。而这些在一些对控制精度要求较高的系统中不满足客户需求，或者会引入很多方案纠正对齐的策略，引入复杂度设计。
2 逻辑IP（降低成本）复用 引入复杂度
逻辑设计往往时处于成本优先的，无论软件复杂度如何增加，芯片面积降低下去了看上去成本就降低下去了，此时方案的复杂度提升从项目的角度往往时默认可接受的。方案人员需要在其中找到一个平衡点，识别出那些变化对方案存在巨大影响，避免这些出现在逻辑调整过程中。
一种常见的降低成本的方法 就是 IP复用。
1）绑定复用策略 比如在两个逻辑模块之间 或者 多个数据层之间 通过设置绑定位置 来复用部分IP，要么A使用，要么B使用，这增加了方案设计上的模块间的耦合，特别时切换场景的设计。
2）子模块拆分组合复用 比如算法A和算法B，本来是两个逻辑IP A和逻辑IP B来实现，通过分析算法A和算法B某一部分是相同的，那么可以条通过设 逻辑a\b\c三部分，组合起来a+b=A b+c=B。这个时候逻辑上这两个算法模块相当于完全耦合在一起。增加设计复杂度。
3）分块处理策略 另一种常见的将成本策略就是分块处理，比如逻辑A原来处理能力是一次能处理完一帧4K图像，那么可以把A设计为只能处理FHD、每帧4K图像处理4次、每次处理不同区域，这是一种时间换带宽和芯片面积的方式，用于那些处理性能较宽松的逻辑模块。
3 配置生效点 即时生效\触发生效 混用引入的方案约束
特别是显示系统，由于图像是按帧输出的，为了保证方案上整个一帧的显示时间都是可以对逻辑进行访问配置，同时从显示效果上不希望显示一帧过程中某个算法使能状态突然变化，逻辑配置生效点必然会做成在一帧的消隐区某个点。这样相当于配置不是即使生效的。
这样的设计是合理的。但是如果出现一种场景，当摸个算法依赖的逻辑配置存在即时生效的寄存器，又存在非即时生效的寄存器，方案设计就会极为复杂。
4 逻辑IP的性能约束引入复杂度
一个逻辑一次能处理的性能是有限的，往往能够使用的逻辑IP也是确定的。显示系统对于显示质量要求非常高的时候，会针对一些特殊场景进行选择IP使用，当性能一定的时候是选ABC还是BCD组合，或者按ABC顺序做还是按BAC顺序，在设计开发阶段往往无法给出明确的结论，效果往往是主观的，这个时候就会出现 需要非常灵活的支持算法的组合和排序的方案设计。伴随这算法IP之间的耦合特性，方案复杂度更会增强。
5 逻辑IP之间的关联特性引入的复杂度
常见的逻辑IP关联有：1）A使能，B不能使用；2）A使能a模式，B必须工作在b模式；3）B必须配置输入大小，并且的输入来源size与A的输出源size。4）B的配置依赖A会写到DDR的数据；
6 逻辑IP可调式性设计缺乏引入的效率问题
1、逻辑IP的设计人员在一些正向分析“看上去没问题”的数据通路没有添加调试手段，出了问题后面临黑盒调试。
2、当多个逻辑关联性很强的时候，整个数据通路的异常设计不统一，没有站在系统的层面分析。在设计阶段没有清楚的分析出 输入会面临什么样的问题，是否能在输入端屏蔽或纠正所有问题 避免更多模块做异常处理？哪些问题要放到哪一级做处理？应对异常的方式是什么，是纠正后还能处理还是完全不处理这类数据？（兼容性）
3、逻辑的异常状态是否软件方案能够很友好的使用。比如 当异常来的时候上报，异常结束时马上异常状态被拉低，这类软件通过中断查询或者线程轮询可能都无法捕捉到，尽量保持一些异常状态上报 通过类似清楚中断状态的方式 让软件能够查看到任何一次错误。是否有异常计数可以读取，出现异常的一些关键状态能否保存记录下来。
7 逻辑IP版本之间弱继承性 引入的设计复杂度
如果逻辑IP版本之间完全没有继承性，每一版都如同推翻从来，软件方案设计也很难有延续性。站在方案的角度最理想的状态 时 需求不变 逻辑呈现给软件的配置接口完全不变（内部可以变），出现新增功能的时候能以扩展的特性做，这样原来的部分可以保持设计流程。实际上 这一点往往很难保证。需要软硬件共同来协调。
8 逻辑IP之间 设计统一性差 引入的设计复杂度
通常逻辑IP设计的时候都会统一设计语言，比如使能、去使能、透传、demo模式等，但是由于不同IP的开发者不同，就会形成设计语言不通的的情况。比如IP A的使能和B的使能 名称描述上有差异，或者概念用法上不同，都会对使用和方案设计带来额外的工作。
9 规避逻IP bug 引入的难以理解的方案设计
没有人可以保证自己写的代码没有bug，逻辑开发人员也是一样，即使芯片由于二次修改成本极高因此完备性测试比软件要严格许多倍。当芯片出现bug的时候，第一选择就是通过规避方案 引入来尽可消除或能降低损失，这个时候就变成 想法设法“凑出来”，甚至时利用一些IP的异常特性，此时的方案由于并非设计阶段正向的分析设计，往往从方案层面很难理解。