-
-
手机阅读
在消费性媒体产品的开发中，音、视频编解码器所面临的软件开发挑战是最严峻的。算法需要消耗巨大的资源，人们对音、视频品质的要求日益提高，采用低价处理器带来许多限制，这一切都使得开发一个成功的媒体产品更加困难。仔细进行软件优化和测试，精心选择元件，这些才能帮助开发人员应对这样的软件开发挑战。
图1：消费性媒体产品的简化软件结构。
您在消费性产品的研制中是如何开发音视频软件的呢？本文中，两位专家将根据多年的实际经验给您提供一些指导性的意见。消费性媒体产品中的音、视频软件有时十分复杂，涉及实时信号处理、网络协议、复杂的I/O，以及精细的用户接口。本文探讨了在实现消费性产品中的音、视频(A/V)软件时需要考虑的几个重要方面，尤其是编解码器软件。文中介绍的方法都是在多年开发机顶盒、蜂窝电话、PDA、互联网设备等产品的音、视频软件的经验上总结出来的。
媒体设备的软件组成
消费性媒体设备通常是个复杂的系统，其中包含几个软、硬件子系统。图1给出了主要的软件子系统，其中有播放器、压缩算法(图中以编码器和解码器，即编解码器表示)、I/O模块和实时操作系统(RTOS)。RTOS主要为多任务实时应用提供关键的任务调度和任务切换服务。其中，编解码器是对计算能力要求最大的一部分，在设计这部分时，需要进行大量的软件优化工作。因此，我们在讨论软件优化时，主要讨论编解码器的优化，但我们所介绍的技术也可以用于其他类型的A/V软件。
编解码器软件设计
编解码器的作用是压缩音频和视频内容以便传输或存储，或者将压缩后的内容解压，以便播放。如今在消费性产品上应用的编解码器算法有很多种，表1中列出了几种常用的A/V编解码器算法。
MPEG-2视频算法是当前用得最多的视频压缩算法。MPEG-2标准于1994年发布，至今该算法已经在DVD电影、机顶盒和卫星电视(DSB/DVB)等应用中广泛使用。此外，微软的Windows Media Video和RealNetworks的RealVideo等视频压缩算法也很常用。
用于音频压缩的MPEG格式一般是MPEG-1/2 layer III，也叫“MP3”。Windows Media Audio(WMA)和 Dolby AC-3(也叫做Dolby Digital)在音频压缩上也用得很多。许多便携式数字音乐播放器都支持WMA，而几乎所有的DVD都采用AC-3音频压缩。
根据所选的算法不同，编解码器软件可以由编解码器创建者、芯片厂商或者独立的开发商提供。这些厂商在提供编解码器软件时可以选择多种方式，可以是可读性较高(但效率不高)的高级参考实现，也可以是针对某个特别的处理器进行高度优化的软件实现。虽然常用处理器都有一些现成的优化编解码器实现，但系统开发商往往还是需要针对特定的产品进行编解码器软件的实现、优化，甚至可能是定制。
图2：迭代优化过程。
软件优化
在消费性媒体产品的软件中，音、视频编解码器通常是对资源需求最大的一部分。现今的产品数据率高，采用的算法对计算能力要求也较高，并且常用价格较低(也可能是低功耗)的处理器，因此要想设计出具有竞争力的消费性媒体产品，往往需要对编解码器软件进行仔细优化。即便是在并非严格要求优化的情况下，优化仍是有益的。通过优化可以降低功耗，将处理器资源解放出来以便添加更多其他特性，或者方便较低价处理器的使用。
软件的效绩性能
编解码器软件的优化过程可以针对几个不同的性能方面进行，如软件运行速度、存储器使用情况、能耗大小以及音频/视频质量。有时，在对某个性能进行优化时，另一种性能也得到了优化，而有时不同性能的优化要求又会产生冲突。大多数情况下，开发商都会主要针对运行速度、存储器的使用和能耗这三个方面进行优化，而信号的音频和视频质量只需保持在一个足够的范围内即可。
为使设备具备实时性，通常需要针对软件实现的运行速度进行大量优化。之所以需要进行如此高级的优化，原因主要有二：一是压缩和解压算法(这些算法需要在很高的数据率下执行复杂的数学操作)对计算能力要求很高，二是产品中通常使用的是性能有限的低成本处理器。
优化过程
优化是一个迭代过程，如图2所示，首先进行软件剖析(profiling)，然后分析，接着再进行具体的优化实现，重复这个过程直到软件性能满足要求。
软件剖析
第一步是在功能一级剖析编解码器软件，得到每个子函数所需执行时间占处理器总执行时间的百分比，或者每个子函数被调用的次数。剖析结果通常都能够大致符合80/20规律，即20%的软件占用了处理器80%的执行时间，而剩下80%的软件只占用20%的执行时间。在表2中列出的三大类操作中，S-rate的一类操作通常都是处理器负荷的主要来源。
在表2这个分类表中，相邻级别的操作发生的频率相差2到3个数量级，因此，每一级别操作的执行成本也相差2到3个数量级。优化I-rate和K-rate操作通常不会对整个软件的执行时间产生什么影响，因为这类函数出现的频率相对较低。但对出现频率很高的S-rate操作就必须进行彻底的优化才能使软件的效率达到最佳。
信号处理函数中通常既有K-rate的操作也有S-rate的操作。根据80/20规律，编解码器软件中只包含相对较少的S-rate函数。利用这一特性，我们就能极大简化优化过程，因为所有函数中，只有很小一部分需要仔细地进行优化。
在媒体应用软件的优化中可以采用许多种优化技术。本文将这些技术分为两大类：处理器无关的软件优化技术和处理器定制的软件优化技术。
表1 常用的压缩/解压算法。
优化过程通常从剖析后认定的最耗时的函数开始，首先要对函数进行分析，然后才开始制定优化策略。常用的策略是首先考虑采用处理器无关的优化技术，因为这种技术能够保持软件的可移植性。如果还需要进一步优化，才采用处理器定制的优化技术进行高级语言优化，例如算法转换。后者尽管是针对某个特定的处理器进行的，但也不会完全破坏软件的可移植性，只是经过这样优化的软件在其他处理器上可能无法达到良好的性能。最后才考虑在汇编语言一级再进行处理器定制的优化。这种优化能够最大程度地提高软件的效率，但牺牲了软件的可移植性。
处理器无关的优化技术
第一种优化技术就是处理器无关的软件优化。大多数A/V压缩算法都是先用C来实现的，而且通常作者在初次编写一个编解码器软件时并没有考虑使软件效率达到最优。例如，有些参考实现就是以文档清晰而非软件效率为目的。因此，通过修改或者重写高级语言代码往往就很可能大大降低软件的处理和存储要求。例如，许多编译器都采用了一种叫做强度折减(strength reduction)的优化技术，采用这种技术后，就可能用简单的操作来取代那些耗费资源的操作。但有时编译器做得不够好，或者算法的有关信息不足以让编译器应用强度折减技术。这时一个好的程序员应该能够通过重写代码来避免这些耗费资源的操作。如果通过优化技术回避掉的是S-rate操作，那么带来的资源节省将十分可观。
另外还有一些处理器无关的优化技术，包括函数内嵌和存储缓冲的回收利用。通过内嵌函数来平化函数调用层次，将一些常用的低级操作限制在他们自己函数内部，能够大大加快软件的运行速度。回收存储缓冲主要用于减少存储器的使用，但因为这样同时也改善了存储系统的性能(例如提高缓存命中率)所以缓存回收有时也能帮助加快软件运行速度。处理器定制的优化技术
第二种优化技术是处理器定制的优化技术，可用于高级语言或汇编代码级的优化。
1. 算法修改和转换
顾名思义，算法修改就是修改算法的内部操作，以便更好的配合可用的硬件资源。在算法修改过程中，通常都要在使用存储器和进行计算之间作出权衡。例如许多算法都采用了大查找表，这样的查找表占用的存储器空间往往超过了目标系统中可用的存储器空间或者处理器的一级数据存储器(离处理器内核最近的存储器)能够有效提供的空间。这时，常用的方法是通过一些算法步骤来计算出表中原来记录的值，以计算来代替存储查找表。或者采用一种折中的办法，省略查找表中的一些值，将查找表缩小，然后用插值的方式得到从表中省略的那些值。这种方法对存储器的要求比单纯基于查找表的方法小，其执行时间又比单纯依靠算法的方法短。
再举一个经典的例子，比较基4蝶形算法实现的快速傅立叶变换与基2蝶形算法实现的快速傅立叶变换。二者所需进行的数学运算总次数(加法和乘法次数之和)类似，但其中加法与乘法次数的比值不同。基4的蝶形算法实现中，加法比基2 的算法多，乘法少一些。如果可用的硬件资源更适合进行加法运算，那么基4的算法实现在这样的硬件上运行，性能就会更好。与此类似，FIR(有限冲激响应)滤波算法有时也可以修改以便更好地与硬件资源匹配。例如，若将滤波系数在存储器中重新安排，那么滤波系数和滤波输入就可以使用一个共同的下标变量。有时，硬件直接支持对零值或负值循环计数寄存器进行分支测试，这时，降值循环(count-down loop)就比升值循环(count-up loop)效率更高。
2. 汇编语言编程
在汇编一级进行优化可以最大程度地提高软件效率。在仔细分析算法中最关键的部分和处理器结构的细节之后，汇编语言程序员通常能使编译器产生的代码的性能得到相当大的提高。例如编译器有时并未充分利用处理器的全套指令集，而且几乎从不利用诸如单指令多数据(具备该特性的处理器能够并行执行多个操作)等处理器特性。程序员使用汇编语言就可以全面利用处理器的所有性能。
存储器访问优化
A/V应用中常需处理大量数据，因此片上处理器和片外存储系统就成了这类应用性能的决定性因素。例如，许多价格较低的嵌入式处理器都只有很小的片上1级数据存储器，根本不足以存放音频和视频解压所需的重要数据和系数块。这时，1级数据存储器就成了处理器的性能瓶颈，处理器因此不太可能达到其峰值MIPS应有的性能水平。而在处理一个视频帧时通常又需要访问两到三个相邻帧的数据，这使存储器问题更加严重。此外，视频算法需要大量的代码来实现，所以指令存储器也可能成为性能瓶颈。
表2 根据调用次数进
行编解码器子函数分类。
通过对存储器访问进行优化，可以将存储器访问开销降到最低，从而大大提高整个软件的性能。例如，视频算法在进行处理时默认的处理单元是一帧，也就是说，算法先对一帧视频进行连续操作，直到整个处理序列进行完毕才开始下一帧的处理。而一帧数据通常都远大于处理器的1级存储器容量，因此若需处理一整帧，就必须将一帧分成几部分，每次向存储器中载入一部分，下一次再用新的部分代替旧的一部分数据，如此反覆进行直至整个处理序列全部完成。针对这一情况，可采用以下优化方法：将操作执行的基本单元从一帧改为一帧的一部分，大小刚好能够填满1级存储器。这样，在进行整个处理序列时，这一部分数据就能常驻1级存储器内而无需多次进进出出。这种优化方法减少了对外部存储器的访问，因此能够加快算法的执行时间并且降低功耗。
软件测试
对消费性媒体产品进行测试所需的的数据量太大，音、视频信号质量的评价中有很多主观因素，而且音、视频编解码器所支持的工作模式也很多，因此要进行彻底的测试十分困难。其中最难的就是测试所有硬、软件子系统的互操作性，以及这种互操作性对产品实时性能的影响。如果处理器本身能力有限，而软件优化程度又太高，就会使产品处于一个不稳定的平衡状态，从而影响其实时性能。也就是说，对编解码器进行仔细优化之后可以将系统性能提升到具备实时操作能力的等级，但这时哪怕是轻微的干扰都可能造成系统故障。因此，彻底的测试就显得尤其重要。
数据I/O要求较高
音、视频设备的数据吞吐量很大，因而对这类设备进行测试时，首先就要求测试设备能够接收很大的输入测试向量并能捕捉相应的输出数据流。终端用户访问的通常是数模转换之后的模拟输出数据流，而开发人员却需要捕捉数字模式下的输出数据才能进行测试。如何在硬件原型可用之前测试压缩算法的实现性能，这是一个十分重要的问题。由于测试中数据量太大，如果利用处理器的仿真模型进行测试，速度太慢，因此需要真正的硬件。用开发板测试音、视频软件时，必须确保大量经过压缩的数据和解压后的数字音、视频数据能够进出处理器。而对开发人员而言，这就意味着，如果能够选用具备足够I/O能力的开发平台进行测试，就会节约很多测试时间，并且在测试开始后减少很多麻烦。
音、视频信号品质
表1中给出的音、视频压缩算法都是“有损”的或者说“感性”的算法，这些算法利用人类视觉和听觉上的弱点来降低算法对存储和带宽的要求。这就造成了压缩和解压之后重建的输出并非对原始信号的准确还原。有损压缩技术使测试变得复杂，因为这时若继续采用诸如重建输出与原始输入的信噪比之类传统测试方法采用的指标来衡量，就会得到信号严重恶化的测试结果，但观众和听众却往往不会感到这种变化。有损压缩算法中利用了当前信号的上下文信息，而测量信噪比这样的传统测试方法没有提供这样的信息，因此对有损压缩算法必须采用其他测试方法。
在开发一个压缩算法时，结构化的视听测试能够为开发人员提供一些反馈信息，让他们知道算法能达到怎样的视、听觉品质。压缩算法完成之后，开发人员就要决定怎样测试这一算法的多种实现方式。实现方式测试通常依赖于一组特殊的测试向量和一个官方版本的“参考”编解码器来进行。这些测试向量和参考编解码器则往往由压缩算法的提供商或者由一个标准化组织给出。被测的算法代码实现与参考编解码器之间可容忍的误差随编解码器的不同而有所不同，但这一误差通常都很小，甚至为零。
必须注意的是，参考音频编解码器通常采用浮点算法，而考虑到成本因素，实际用于实现这些编解码器的嵌入式媒体设备往往采用定点算法。理想情况下，定点编解码器的输出和浮点参考编解码器的输出是匹配的，但实际上二者的匹配程度取决于算法定点实现的数字精度。若定点实现的编解码器质量较差，那么在音频内容较好时这样的编解码器还可以正常工作，一旦音频内容不是很好，它就会出故障。厂家提供的测试向量是针对浮点算法开发的，无法充分测试定点实现的缺陷。因此，要保证彻底测试一个定点实现，就必须获得或者创建一些测试向量，这些测试向量能够全面测试算法的整个潜在动态范围。
实时性能：消费性媒体设备必须具备的性能
很明显，消费性媒体设备需要具备实时性能，否则音频信号会变得结结巴巴，视频信号会出现停顿和跳跃。要想将系统在实时工作时的表现推到极限，开发人员通常需要对资源消耗最大的工作模式进行测试，例如比特率最高的模式、采样率最高的模式、视频分辨率最高的模式以及音频通道最多的模式。这是一个很不错的出发点，但并不能保证通过这种方法一定能够测试到最糟糕的情况。因为压缩算法常有一些由数据决定的执行通路，这时，处理器运行软件的通路在很大程度上由输入数据的特性决定。还有更复杂的情况，在某些处理器中，乘法等基本操作的循环执行次数也取决于输入数据。因此，要想成功地测试出系统在最坏情况下的实时性能，不但要在资源消耗最大的工作模式下测试，还应具备能够确保处理器选择最坏执行路径的输入数据流，而且对所有数据依赖定时的操作都灌以最坏情况的输入。
作者：Jeff Bie