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基本概念

UI语言：指OSD内容中的文字部分使用的语言类型。

UI模式：指OSD内容适用的环境，例如不同的信号源(电视、DVD、PC)带来的模式变化，其作用主要区分不同的环境下OSD的不同表现。

UI场景：特定语言模式下及较多信息页面情况下，当前OSD适用的特定页面。

UI事件：用户利用输入设备向UI系统提供的操作命令。

UI动作表：指在特定UI场景中，对于UI输入的命令进行对应处理的索引表。

OSD画布：指整个OSD呈现的区域，通常为一个矩形区域。

OSD位置：通常指在OSD画布中，相较左上角原点的相对位置。

OSD物件：呈现在画布上，表达特定信息，具有特定属性的像素组合。

2. OSD包含的基本元素

OSD信息中主要包括以下一些基本元素(可能本文的提法未必准确，希望读者可以体会到其意思)：区域、标签、图标、文字、进度条、动画、数字、可选图标、导航信息等。下面分别给出这些元素的定义、作用、属性和响应事件。

a. 区域

定义：在OSD画布中，以特定的属性(颜色、闪烁、大小等)标示出的矩形或任意形状的区域。

作用：对OSD内容进行分类或标示，例如标题区域，内容区域等。

属性：位置、颜色、闪烁特性等。

响应事件：作为固定的信息内容，通常对UI输入的控制无响应。

b. 标签(Label)

定义：固定不变的文字信息，可以是一行或多行。

作用：对OSD内容进行必要的文字说明。

属性：位置、颜色、闪烁特性、语言类别、大小写、对齐方式等。

响应事件：作为固定的信息内容，通常对UI输入的控制无响应。

c. 图标(Icon)

定义：以特定的字符或像素组合构成形状，以表达可识别的信息。

作用：对OSD内容进行形象的提示，如播放、禁止等特定符号。

属性：位置、颜色、闪烁特性等。

响应事件：作为固定的信息内容，通常对UI输入的控制无响应。

d. 文字(Text)

定义：相较标签，其同样为文字信息，但是可以随用户的操作而改变。

作用：以随选择而改变的文字内容，提供关于用户选择的文字提示。

属性：位置、颜色、语言类别、大小写、对齐方式等。

响应事件：用户的选择，通常为上一个或下一个选择。

e. 进度条(Bar)

定义：矩形条状的物件，随其数值的不同而改变相关特性，未来也许会有其它形状的此类物件，

如油量表状等，但它们都具有同样的属性。

作用：以形象的图形界面，给出关于某项数值的图形说明。

属性：位置、颜色、上下限、当前值、类型、大小、是否显示数值等。

响应事件：数值的改变。

f. 动画(Movie)

定义：随时间而改变的图标组合。

作用：以活动的图形使OSD界面更生动，提高信息的表达效果。

属性：位置、颜色、具有的图标数目、变化速度等。

响应事件：作为固定的信息内容，通常对UI输入的控制无响应。

g. 数字

定义：随有关参数或用户选择改变而改变的数字组合，可以为十进制或其它进制，亦可以是百分比或其它数值形式。

作用：直观地给出关于某项参数的数值量化指示，通常与进度条联合使用，以达到直观与形象的双重效果。

属性：位置、颜色、上下限、当前值、进制选择等。

响应事件：对应参数的数值的改变。

h. 可选图标(Option)

定义：随有关参数或用户选择改变而改变的图标组合。

作用：用户选择的图形化表达，例如选择、未选择、开启、关闭等信息的图形化表达。

属性：位置、颜色、闪烁、选择数目等。

响应事件：对应参数的选择改变。

i. 导航信息

定义：呈现在OSD画布上，对当前UI场景中的用户操作进行提示的信息。

作用：指引用户操作相关按键，进行OSD内容操作。通常具有可用按键的指示以及必要的文字说明，通常作为OSD提示信息的完善和人机界面友好化的措施。

属性：位置、颜色、闪烁等。

响应事件：UI场景、按键的改变。

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

传统的处理手法是将特定场景下的OSD物件逐一用代码“画”出来，在遇到特定的UI事件时，再利用一堆if else判断出特定场景和操作对象，并做相应的OSD处理。在OSD较简单的情况下，其不失为一个可行的方法。但在遇到OSD场景和模式较多的情况下，这个if else的结构会变得很大，而且更为重要的是极易出错以及维护成本提高。随着OSD越来越复杂以及代码工作量的不断提高，人们意识到我们需要花费太多时间在这些“表面文章”上，而真正重要的应用层和设备驱动层的开发时间会受到影响，进而影响新产品的开发进度。固件工程师也不愿不断重复编写同样代码来满足不断改变客户的特定OSD需要。笔者早期也曾遭遇同样的困扰，面对部门里工程师毫无效率地做着同样的事情，感觉到开发一个统一的OSD UI平台的重要性。现在对于上述OSD UI进行的分析，可以让我们开发出独立于特定数字视频处理器平台和OSD发生机制的硬件环境的独立统一开发工具。事实上，平板显示芯片方案的重要提供者如Genesis、Pixelworks等为了加速其产品的开发和应用速度，已经提供了具有这样功能的基于Windows的固件开发工具。本文试图探讨这一类工具的运作原理，或许读者基于本文可以开发出自己所需要的工具，当然其应用具有更广泛的代表性。

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

typedef struct
{
    byte mode;//UI场景适用的模式
    byte lan; // UI语言
    byte scene; // UI场景
    byte last; // UI上个场景
    byte next; // UI下个场景
    byte sel; //UI 当前场景对物件的选择
    byte sel_total; //UI当前场景中选择项的总数
    byte *info; // UI的物件指针
    byte pos_v; // 物件垂直方向位置
    byte pos_h; // 物件水平方向的位置
    byte col_f; // 物件的前景颜色
    byte col_b; // 物件的背景颜色
    byte att; // 物件的其它显示属性
    ACT_Struct (*act)[]; // 该物件的响应动作表指针
    byte *note; // 导航说明信息
}UI_Struct;

这样的结构是为了描述一个OSD物件的基本属性及规定其对于动作的相应表现。利用这样的结构将场景中的每个物件描述清楚，则一个特定UI场景的OSD内容就可以被确定，而同时被确定的还有其上一个场景、下一个场景及动作响应特性等所有UI特性。这样的信息构成一个数组，由一个统一的“解释平台”对其进行翻译和描述，从而将整个UI构造完成。这有点类似解释语言，而我们所需要做的就是编写这些“脚本”，对物件进行OSD“绘制”的工作由“解释”平台去调用外部的OSD发生器的驱动代码来完成。当需要改变OSD发生器或基于不同平面显示控制器平台时，只需要更新少量OSD部分驱动代码，从而实现UI系统“平台无关化”。我们需要构造相关物件的数据结构，以便“解释”平台识别物件类型并进行正确的绘制。例如

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

void UI_ChangeLan()
{
    UI_Lan=VAL_Lan;
    ReDraw();
}

code byte *STR_LAN_CHN[]=
{
    “中文”,
    “英文”,
    “法文”,
    “西班牙文”,
};

code word TXT_LAN_CHN[]=
{
    //文字物件的标志 对应的文字资源 对应的变量 具有的可选项目总数 当该物件被改变时的执行动作

    RES_TXT,STR_LAN_CHN,VAL_LAN,sizeof(STR_LAN_CHN)/sizeof(byte *),UI_ChangeLan
};

第一个数据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的程序存储空间。