慎选加速译码解决方案满足不同产品需求

H.264所内含的先进的编/译码技术，虽能大幅提升压缩率，同时保有视讯质量，对于高画质应用或是网络串流应用，都是相当大的优点，但它是透过复杂的算法完成，这对编/译码器或处理器效能是一大挑战。

其实相关厂商设计视讯压缩技术，大部分已相当有经验，毕竟这个产业并不算年轻，但是过去的经验未必能套用在H.264相关产品加速译码设计上。因为在压缩算法的复杂度上，H.264比目前主流MPEG4来得繁复许多，比起常见的MPEG2技术，则更要复杂近10倍。

这是因为H.264的开发重点，从一开始时即着重在于有效改善压缩效率，而不是去限制实现方案的复杂度，这和过去的视讯标准(MPEG1/2/4、H.261/262/263)在定位上就不一样，这在前章已经有仔细分析。因此H.264编码器的结构与压缩算法，就和以前大不相同。

以过去设计概念来看，流通性译码软件，是最低成本的设计方式，免除许多一分钱一分货的电路与零件，不过因为H.264压缩的复杂度，目前软件解决方案相当少，而且对大多数携带型视讯装置来说，资源需求亦不经济。

因此，最佳方式还是采用硬件最佳化演算架构，尤其是为可携设备提出更低功耗和小尺寸的解决方案，在强化视讯解压缩性能后，还保有体积小、性能稳定、电力消耗更少，甚至成本更低…等优势。

视讯装置包含组件太多 单一面向设计无法面面兼顾

产品被要求「俗又大碗」，是所有CE产品的共同宿命。因此，虽然H.264译码采用硬件加速，一定是最佳解决方案的道理相当简单，但实作起来可就不是这么回事，因为这不是单纯的技术考虑。

俗又大碗的设计概念放到产品内，通常是被要求设计出每1种功能都有，但又足以满足差异化的产品，也就是视讯译码功能够强，但其它能力也不能少。

看看目前典型的多媒体设备，所能实现的各种功能，就知道设计复杂度。首先必须满足多媒体，即各种视讯、音讯和影像编/译码标准，例如H.264、VC-1、MPEG2/4、AAC、MP3、JPEG…等，还有重要的无线连结和定位技术，包括天线、射频和基频处理在内的蓝牙、GPS、Wi-Fi、UWB、WiMAX…等。而在游戏导向或是高阶产品，还有3D绘图功能需求，此外语音识别技术也成为一些产品的功能。

这么多的功能，对于视讯播放为主力的产品来说，译码设计当然相当重要，但显然不是唯一。以上各种不同的技术，通常需要各种不同的处理能力以及不同的电路组件。

通常直觉的概念，是以个别零组件对单一任务，例如iPhone就使用多个MCU对应多个功能。但大部分情况下，如果以个别准备的方式来进行产品设计，会因为零组件过于庞杂，最终成品的外型可能相对过大，甚至可能因为组件间的阻抗问题，造成耗电量大增，而如果采用较精密的多组零件，成本又可能直线上升。因此，最佳答案几乎直指整合各种多媒体译码能力的SoC，就成了同时满足系统微缩与省电性能要求的必要手段。

可携式多媒体SoC中，支持所有视讯标准和内容类型，有3种可用方案：硬件加速处理器(H/W Accelerator)、视讯辅助处理器(Video co-processor)和通用处理器(DSP/RISC)。

硬件加速设计简单明了 除错难度高也较不具弹性

硬件加速是指，只执行1个特定单一标准的单一功能编码或译码，在设计上具有最高效率和较少的闸数，因为不需要考虑其它用途。但在开发后，不同SoC只有在功能完全相同时才能再使用，例如，当硬件加速器支持以VGA分辨率编码的MPEG4格式时，需要大约15万个逻辑闸，但是要同时具备H.264 Baseline Profile(D1)以及MPEG4译码能力的硬件加速设计，不但整个芯片架构必须重新设计，逻辑闸也会增加到35万。

采用硬件加速器具有的优点，包括整体规模小，因为只需执行固定作业，不包含任何指令处理(存取、译码)，也没有程序内存管理，因此闸数较少，再者因为闸数较少、存取效率高，通常功耗亦较小。在性能上，因为对应专门的硬件路线，所以处理效率也高，执行速度快。

但采用硬件加速的缺点是，例如视讯加速就只能处理视讯，因此如果用硬件视讯加速器时，多媒体中的音讯和语音部分必须由SoC中的其它部分来处理，通常是CPU或DSP，因此需要多零组件。内存方面亦然，在SoC中，加速器专用内存不易被其它组件存取，因此从成本和硅芯片面积的角度上来看，利用效率较低。

此外，多媒体设备不可能只有画面没有声音，因此影音间的同步处理，必须在CPU上进行，也因此增加CPU部分研发需求与整合难度。此外，可能会增加其它零组件的耗能，例如CPU通常需执行算法的信息编码(如CAVLC)，和后续处理(如解锁滤波器)，让CPU的功耗上升，因为又回到CPU并非专门路线的问题。

而在软件升级和除错修复方面，硬件加速器路线无法透过软件升级方法来隔离或修复缺陷，因此一有设计缺陷，通常会导致重新投产、从头来过。对新一代需求来说，在SoC中执行特定任务的硬件加速器，也无法重新利用。

当然，硬件线路加速器，可以设计成兼容多种解编码标准，必会面对前述的一些缺点，但是整合的功能愈多，芯片逻辑闸数量也会跟着飞涨，提高整体成本。

视讯辅助处理器支持较佳 然部分缺失仍待改良

视讯辅助处理器，以可程序化的方式支持不同视讯标准，即执行译码和编码处理。以视讯辅助处理器设计架构，整体规模通常比以硬件加速器模式要大，例如需要40~50万个逻辑闸，优点是视讯辅助处理器，在支持前述多种类视讯标准时，具有较大应变能力。

视讯辅助处理器通常有2种不同的设计模式，第1种为混合式架构，由专用的CPU(可程序化单元)和附加的影像处理硬件模块，一起构成视讯辅助处理单元，进行视讯加速功能。或是内建多种硬件固定单元，整合大部分影像编/译码单元所通用必备的功能，剩下的部分才以软件进行程序化的动作。这2种设计方式，都是混合式架构，前者支持度灵活但是最佳化效率较差，后者则相反。

第2种方式为支持多标准的专用视讯引擎，这样的的设计方式比混合型效率高，不过专门视讯核心自然没有任何CPU类型的功能，只能进行视讯处理，换句话说，在可程序化的程度略逊一筹。

采用视讯辅助处理器的主要优点，为可支持多标准的编/解碼格式，同一平台亦可支持不同的分辨率和讯框率，且因为可程序化的缘故，不需要太复杂的硬件路线。可升级性也比较好。而视讯辅助处理器整体设计规模中等，通常介于硬件加速和专用处理器间。修复错误能力部份，也可透过软件升级隔离或修正缺陷，不需透过高成本的重新投产模式，才能修正错误。

而视讯辅助处理器的缺点，也正由于专注于影像的处理工作，因此在音效方面也会面临与硬件线路单元相同的状况，需要另外的路线处理。此外，软件编程复杂，例如采用混合模型的系统，包括可能2个不一定是同类型的CPU，为了使2者能协同工作，在整合、数据串流及通讯协议…等都有复杂的程序系统协调问题。

再者，内存专用问题也会发生，由于视讯辅助处理器，需要为程序以及数据设计相对应的暂存内存，但在CPU部分，也需要专属的内存区块，在内存的读取控制会是相当大的问题，例如被视讯辅助处理单元所占据的内存，就无法移作他用，因此在 SoC设计中，内存的容量与配置设计方式，就需要特别注意。