OSD实现原理介绍

OSD的主要实现方法和类型

    目前有两种主要的OSD实现方法：外部OSD发生器与视频处理器间的叠加合成；视频处理器内部

支持OSD，直接在视频缓存内部叠加OSD信息。

    外部OSD发生器与视频处理器间的叠加合成的实现原理是：由一个MCU内建的字符发生器及显示

缓存，利用快速消隐(Fast-Blank)信号切换电视的画面和OSD显示内容，使OSD的字符等内容叠加在

最终的显示画面上，在OSD和显示画面叠加处理过程中，通过调整两者之间的比例可以实现OSD的半

透明(Blending)效果。同时，对OSD信号中的红绿蓝信号进行重新编码，可以得到不同的OSD颜色效

果。

    另外一种实现方法是视频处理器内部支持OSD，直接在视频缓存内部叠加OSD信息。这一类视频

处理通常具有外部存储器或内部少量的行缓存，同时具有OSD发生器，OSD的合成和控制直接在视频

缓存内完成，同样具有上述的半透明和颜色控制功能。

    OSD具有字符型(Font-Based)和位图型(Bit-Map)两种类型。

    字符型OSD：为了节约显示缓存，早期及低成本的解决方案中使用字符型OSD发生器，其原理是

将OSD中显示内容按照特定的格式(12×18、12×16等)进行分割成块，例如数字0-9、字母a-z、常用

的亮度、对比度符号等，并把这些内容固化在ROM或Flash中，在显示缓存中仅存放对应的索引号，

这样的“字典”结构可以大幅度减少显示缓存的需求。

    同时，为了提供对每个字符的颜色等属性的控制，通常还具有一个与显示缓存一样大小的属性

缓存，其属性(前景颜色、背景颜色、闪烁等)对整个字符中的每个像素有效。为了弥补这种方式不

能为每个像素指定颜色的缺点，OSD发生器的设计者提供了采用多个显示缓存合并的方式呈现多色字

符的方案。其原理是每个显示缓存确定一种颜色方案，当两个甚至更多个显示缓存合并以后就可以

“拼凑”出超过两种颜色的多色字符。 

    字符型OSD优点是可以使用OSD内部较少的显示缓存，并且MCU只需要指定显示内容的索引即可显

示对应OSD信息，可以在比较低速的MCU上实现。但正是由于上述的显示信息和颜色编码方式不够直

观，会给字符型OSD的固件开发带来一些麻烦。通常液晶显示器、低成本的平板电视和CRT传统电视

上均使用这一类OSD，目前仍占据着市场主流地位。

    相较字符型OSD，位图OSD的处理原理较直观和简单：通过对最终显示内容上特定区域的每个像

素点进行改变，直接将OSD信息叠加到最终的显示画面上，其按像素进行控制的方式可以保证具有多

色及足够的表现能力。位图OSD发生器通常内建在视频处理器内部，并共享使用其主显示缓存。也有

独立在视频处理器之外的专业OSD位图发生器，如美信的MAX4455，通常这一类芯片需要外部SDRAM作

为显示缓存。

    位图OSD的显示效果理论上可以做到非常完美的程度，可以提供类似Windows中具有立体感的各

种物件，如具有阴影的按钮、颜色丰富的图形和文字等，其缺点是必须具有足够的OSD显示缓存，以

及按像素进行处理而对MCU带来的速度要求。通常在大尺寸的高端平板电视和专业显示器上会使用这

一类OSD。随着技术的不断发展和存储器的成本的不断下降，未来的OSD应该都是位图型的。

OSD的UI基本元素及定义

    显示OSD的目的是需要向用户表达信息，那么哪些信息需要表达呢？通常包括提示、警告信息、

控制参数的数值显示等。尽管无论其显示形状是什么，其本质都是一些字符或像素点的组合，但是

对于这些信息的分类和属性定义有助于固件开发人员的统一编码和代码处理。本文尝试分类，分析

这些元素并在下面给出统一的固件处理方法。

1. OSD基本概念

2. OSD包含的基本元素

    OSD信息中主要包括以下一些基本元素(可能本文的提法未必准确，希望读者可以体会到其意思)

：区域、标签、图标、文字、进度条、动画、数字、可选图标、导航信息等。下面分别给出这些元

素的定义、作用、属性和响应事件。

使用基于对象的方法处理OSD UI

    传统的处理手法是将特定场景下的OSD物件逐一用代码“画”出来，在遇到特定的UI事件时，再

利用一堆if else判断出特定场景和操作对象，并做相应的OSD处理。在OSD较简单的情况下，其不失

为一个可行的方法。但在遇到OSD场景和模式较多的情况下，这个if else的结构会变得很大，而且

更为重要的是极易出错以及维护成本提高。

    随着OSD越来越复杂以及代码工作量的不断提高，人们意识到我们需要花费太多时间在这些“表

面文章”上，而真正重要的应用层和设备驱动层的开发时间会受到影响，进而影响新产品的开发进

度。固件工程师也不愿不断重复编写同样代码来满足不断改变客户的特定OSD需要。

    笔者早期也曾遭遇同样的困扰，面对部门里工程师毫无效率地做着同样的事情，感觉到开发一

个统一的OSD UI平台的重要性。现在对于上述OSD UI进行的分析，可以让我们开发出独立于特定数

字视频处理器平台和OSD发生机制的硬件环境的独立统一开发工具。

    事实上，平板显示芯片方案的重要提供者如Genesis、Pixelworks等为了加速其产品的开发和应

用速度，已经提供了具有这样功能的基于Windows的固件开发工具。本文试图探讨这一类工具的运作

原理，或许读者基于本文可以开发出自己所需要的工具，当然其应用具有更广泛的代表性。

    笔者在最近的液晶电视开发案例中使用了这样一个结构：

    这样的结构是为了描述一个OSD物件的基本属性及规定其对于动作的相应表现。利用这样的结构

将场景中的每个物件描述清楚，则一个特定UI场景的OSD内容就可以被确定，而同时被确定的还有其

上一个场景、下一个场景及动作响应特性等所有UI特性。这样的信息构成一个数组，由一个统一的

“解释平台”对其进行翻译和描述，从而将整个UI构造完成。

    这有点类似解释语言，而我们所需要做的就是编写这些“脚本”，对物件进行OSD“绘制”的工

作由“解释”平台去调用外部的OSD发生器的驱动代码来完成。当需要改变OSD发生器或基于不同平

面显示控制器平台时，只需要更新少量OSD部分驱动代码，从而实现UI系统“平台无关化”。

    我们需要构造相关物件的数据结构，以便“解释”平台识别物件类型并进行正确的绘制。例如

下面的结构完成了一个语言选项(文字物件)的描述：

    第一个数据RES_TXT向“解释”平台表明这个物件是文字，具有文字的数据结构。“解释”平台

依据这一点，按照事先约定的结构读取后继数据，第二个数据表明其文字内容的来源是STR_LAN_CHN

，第三个数据表明需要根据哪个变量来决定获取文字资源中第几个数据，而第四个数据表明，该物

件具有多少个可供选择的文字内容，最后一个数据规定了当该物件发生改变时需要做什么。这样，

“解释”平台获得了足够的信息去“绘制”这样一个语言选项，并可以在发生改变时去自动执行

UI_ChangeLan()这个函数，帮助程序员去完成语言改变所需要进行的操作。

    事实上，所有这些结构完全可以进行定制，只要与“解释”平台保持一致就可以了。

    利用这样一个OSD驱动结构，一旦“解释”平台构建完成，OSD开发人员需要做的就变成利用平

台支持的各种物件积木，进行摆放、堆积来构造OSD图形表现，而不必要重复编写实现代码和关心与

特定硬件平台相关的驱动代码细节。

    更进一步，甚至连这些积木的摆放和设计，我们可以设计一个直观的Windows应用程序来完成诸

如图形–>字符元件生成器、OSD图形界面设计，以及最终的资源文件和UI资料数组的生成，并与底

层的“解释”平台进行联接编译，得到最后的MCU代码。

    这样的OSD界面开发环境会摆脱抽象、枯燥和低效率，变得直观、有趣，甚至可以由客户自己设

计相关的OSD的界面，而完全不需要编程经验和对OSD底层驱动的了解。

    需要指出的是，相较传统的if else，结构化的OSD UI处理机制会带来最终程序体积的增加和运

行速度的变慢，但是这些缺点在MCU内部程序空间不断增加和支持的时钟频率不断提高的情况下是微

不足道的。所以，如果读者面对的案例是对MCU处理速度和程序存储器受限的情况下，可能并不适用

这样的方案。以笔者开发的液晶电视项目为例，在支持所有电视功能、图文、丽音及游戏、日历等

附加功能的情况下，基于MCS51的多任务系统的总程序小于32KB，而基于Myson MTV230的OSD+MCU处

理器的运行速度非常快，并不会感到任何延迟。而通常支持位图OSD的开发环境使用的是X86或更快

速的ARM等处理器，并具有大于2MB的程序存储空间。