移动影音的质量方面开始逐渐被重视的现在，研发人员若仍采用过去的硬件设计架构，肯定逐渐有力不从心的感觉，为了迁就分辨率，势必要牺牲流畅度；或者为了流畅度，画质就被降级！那么，没有1个两全其美的方法吗？其实有的，但是这样的产品在开发上，或制造成本考虑上，又有可能超出预期规划，因此在面临微利化的数字产品设计与销售方面，想要面面俱到，其实是相当困难的一件事。
视讯编译码应用成为了移动多媒体设备的主要功能之后，相关设计方案也逐渐被提出，在厂商争鸣的情况下，设计者可以轻易得到符合功耗、性能、功能等不同要求的产品架构，但是产品最终仍要以消费者的需求为依归，因此慎选架构几乎就是决定1款产品的成败关键。
图说：移动影音的需求已经逐渐被重视。
虽然说多媒体处理包含了声音、影像以及视讯几个部分，在嵌入式移动应用方面，音效以及影像编译码几乎都可以完全靠应用处理器的通用运算来解决，然而视讯编译码却无法单纯以软件方式进行，会造成此种结果有下列几个原因。
首先，音效的编译码标准变动非常小，且复杂度并不会随着时间而增加，举例来说，MP3规格是在1995年所发明，时至今日，虽然有其它诉求更高音质或更高压缩比的规格出现，但无一能取代MP3，即便是不同音效压缩规格，其编码复杂度也相差不大，一般来说，音效的流量要比编码压缩规格本身对音效质量的影响来得大，但是流量本身也不能无限上纲，毕竟声音的分辨率只要高到一定的程度，人的耳朵就无法分辨非压缩原音与压缩后音效的差别。
而视讯方面就完全不是这么一回事了，人的眼睛相较起耳朵而言，是非常敏感且精细的器官，不论是对颜色，对分辨率或者是流畅度，都具有非常敏锐的辨别能力，视讯的压缩要考虑的要素比之于音效要复杂上许多，以常见的NTSC视讯规范为例：NTSC(National Television Standard Committee)是众所周知的522线制，其中480行被用于画面表现上。如果现在将NTSC模拟讯号转成数字化数据，4:3的横纵比率意味着每行有640个像素。如果以每张图像640*480，那么一张24位的全彩NTSC位图的大小为640 x 480 x 3Bytes = 921600Bytes，约0.9MB；另外，NTSC电视系统每秒显示29.97张画面，换句话说，当电视讯号以数字化方式呈现时，每秒大约会有29.97 x 0.9MB = 26.973MB的数据流量。
如果想要在计算机上播放该视讯，计算机将需以每秒约27MB的速度将数据由储存装置读取出来之后再显示到屏幕上；另外每小时27MB x 3600 = 97200MB =97.2GB的视讯容量储存需求是十分惊人的。如此庞大的数据储存及传输量直到近几年硬盘技术才追赶上这样的需求。至于现在市面上已上市的数字化影音储存装置(CD、DAT、MD、VCD/DVD…等)，若非传输速度不够，便是储存容量不足。由此可见，数字化的数据处理虽有其好处，然而对于多媒体数据来说，未经压缩处理的原始数据(Raw data)，光是数据存储便是极大的问题，而在架构微缩，频宽有限的移动装置上，亦无法肩负起如此庞大的流量需求，因此必须借助各种有效的实时压缩/解压缩手段，借以节省储存空间，并且大幅降低视讯串流所造成的频宽冲击。
视讯编码标准的演进
为了解决数字视讯储存与传输的问题，1992年制订出了MPEG-1压缩标准，随后则是MPEG-2，而到MPEG4出现后，真正移动影音的未来才逐渐明朗化。MPEG-4与之前的视讯编码标准有着相当大的不同，传统的MPEG-1、MPEG-2等视讯压缩技术中，压缩方式是以1张张个别的影像画面为主体来进行压缩。因此，整张影像画面上的所有图形与文字都采用相同的压缩方式，产生出来的数据量也就比较大。MPEG-4则采用新一代的压缩理念，将影像画面上的文字、背景及图形视为不同对象，并制定以对象为基础的方式来压缩影像画面，借以达到最有效率的压缩方式。
MPEG-1与MPEG-2的压缩算法只是将视讯间的多余数据予以删除，然而MPEG-4则提出不一样的压缩技术，此技术称为以内容为基础之视讯压缩。MPEG-4的压缩技术可依照需求，将视讯内容分割成数个视讯对象平面，再将这些视讯对象平面分别编码、储存和传送，之后再于译码端依不同的应用来重组、删减或是替换所需的视讯对象平面。
在此一概念中，我们将动态影像序列中的每1个场景，看成是由不同的视讯对象平面所组成。而同一对象的连续视讯对象平面，则称为视讯对象。视讯对象可以是动态影像序列中的人物或景物，如电视新闻中的主播，也可以是电视画面中的1辆汽车。对于输入的动态影像序列，经过分析后可将其分割成数个视讯对象，而每个视讯对象再对其中所组成的视讯对象平面进行编码。
视讯对象平面的编码包括对运动(采用移动预测与补偿)及纹理(采用数字离弦转换编码)的编码，其基本原理则与MPEG-1、MPEG-2极为相似。
但因视讯对象平面可能是各种不同的形状，因此，MPEG-4要求编码时，必须处理视讯对象平面的形状和其透明度等信息。这跟只能处理矩形影像序列的视讯编码标准(MPEG-1与MPEG-2)则形成了鲜明的对照。
在MPEG-4中，矩形区块可被认为是视讯对象平面的1个特例，这时编码系统不用处理视讯对象平面形状信息，而以类似MPEG-1、MPEG-2的传统编码方法，来对矩形区块的视讯对象平面进行编码，因此，MPEG-4能与现有标准(MPEG-1和MPEG-2)兼容。
MPEG-4标准衍生出许多标准与非标准的影音压缩格式，目前最为热门的H.264即为其中一例。H.264是ITU-T以H.26x系列为名称命名的标准之一，同时AVC是ISO/IEC MPEG一方的称呼。因此这个视讯压缩标准，通常被称之为H.264/AVC (或者 AVC/H.264、H.264/MPEG-4 AVC及MPEG-4/H.264 AVC)，明确的说明该标准出自两方面的开发者。
采用H.264是移动影音装置的必走方向
H.264/AVC项目最初的目标是希望新的编译码器能够在比相对以前的视讯标准(比如MPEG-2或者H.263)低很多的流量(一半或者更少)下提供合理的视讯质量；同时，尽可能减少复杂编码工具的使用，因此使得硬件难以实现。另外1个目标是可适应性，即该编译码器能够在1个很广的范围内使用(比如说，既包含高码率也包含低码率，以及不同的视讯分辨率)，并且能在各种网络和系统上(比如电视、DVD储存、RTP/IP封包网络、ITU-T多媒体电话系统)工作。以目前来看，H.264除了在高流量的应用占有主要的地位以外，低流量的应用更是发光发热。
Youtube的在线视讯几乎全数转成H.264格式，而目前可播放视讯的移动装置，也几乎都以H.264为标准格式，毕竟H.264规范完整，目前有许多IC设计厂商都已经针对H.264设计出几乎可完全硬件化的解压缩流程方案，相较起过去的软件解压缩方式，硬件化解压缩除了有助于降低处理器负载，同时也能有效降低系统功耗。
至于其它在移动影音装置上常见的视讯标准来看，就缺乏了完全以硬件进行译码的方案，比如说网络上流行的Divx、Xvid、Real等，都完全没有硬件解压缩方案出现，很难在不影响系统本身功耗或工作负载的前提下，达到高质量视讯的播放，因此不论从功耗方面、播放质量方面，采用以上影音压缩格式的产品其实都不甚出色。
微软的VC1虽然在高画质影音也占有一席之地，但是在低流量应用方面少之又少，如此也更确定了H.264确定了在高画质影音与移动影音的主流地位。
移动影音装置的设计方向
先看看我们最常用的手机。现在的手机基本上采用1个ARM处理器加1个DSP的架构，由ARM处理器完成基频处理工作，由DSP对数字化的射频讯号进行处理。也有一些处理器采用了2个ARM核心，如德州仪器的双核心OMAP850处理器由2个不同的CPU组成，1个ARM926负责PDA功能，另1个ARM7负责GSM电话功能。有些手机的处理器采用了2个处理器加DSP的架构，2个处理器分别用做基频处理器和应用处理器，以便提供更好的影音编解碼处理能力。
图说：TI的OMAP850应用处理器，多媒体性能不错，但是通用计算性能相当贫弱，采用此处理器的移动产品一般应用程序响应速度相当迟缓。
再看看iPhone上发生的情况。iPhone的热销说明了这样1个趋势，将来的手机将成为手机终端、娱乐终端和网络终端的综合体。在正常的通话功能之外，手机还要具有娱乐和多媒体功能，支持MP3、MP4、H.264、VC1等多媒体标准，支持移动电视、数字广播、在线交易等各种无线业务，支持Wi-Fi、WiMAX、蓝牙等无线通信标准，还要支持GPS这样的功能，不但可以做导航之用，在意外发生时还能够提供紧急的位置服务。
要保证这些功能的实现，首先是要有足够的处理能力。现在的iPhone使用了5个ARM处理器，是把各个任务分解到多个处理器上。这样做的结果是功能丰富了，但成本也提高了。如果能把多个处理器的功能整合到1个处理器中，无疑将显著降低成本，也有助于降低功耗。将来不论是利用SoC方式将所有核心整合为单一芯片，或者是使用内建更多、更强大处理单元的处理器，都是可参考的开发方向。
图说：iphone所内建的处理器数目可说是目前手机之冠，其将多媒体能力列为主要卖点，也获得了极大的成功。
至于在移动电视或者是诸如PMP等移动影音产品，通用运算的要求并不高，因此可以将眼光放在更节省功耗、以及具备更强大视讯译码能力的架构设计上。以下提出几种常见的硬件设计体系，可供应用在具备多媒体视讯处理能力的各种移动装置上：
以SoC方式实现，此亦可称ASIC或ASSP，ASIC/ASSP内会用上嵌入式的处理器(或控制器)核心，甚至是嵌入式的数字信号处理器(Digital Signal Processor；DSP)，或硬件线路式的影音编译码核心。数字讯号处理器具备了相当强大的向量数学运算处理能力，刚好可以切合视讯编译码的计算需求，而如果将部分通用的视讯编译码流程化为硬件线路，其它部分则以通用运算处理器或DSP来计算，其实也是相当均衡的方式。
使用多媒体处理器来实现，例如NXP的TriMedia或者是Sigma Designs的Media Processor等，此类型的处理器多半具备VLIW架构，可加速多媒体视讯的运算。而NVIDIA的GoForce及ATI的Imageon也有类似的功效，不过这2款处理器都着重于视讯处理，不具备通用运算能力。
使用双处理器(或双核)设计，除了使用1个通用(General)的32-bit微处理器(或微控制器)外，会再额外搭配1颗数字信号处理器，影音编解碼运算的部分就由DSP负责，微处理器/微控制器(uP/uC)则负责一般性的控制工作及一般性的应用程序执行，TI的OMAP方案即是此中的代表。而ARM的MPCore也可视为解决方案之一，但是MPCore仅具备通用处理能力，要具备更有效或更高画质的多媒体编译码能力，建议整合第3方，如ARC的多媒体串流处理单元，或者是在移动装置上内建诸如NVIDIA GoForce等独立处理芯片。
一样使用1个通用的32-bit微处理器、微控制器，但另1个搭配芯片则是1个已将音视讯编译码运算加以硬件线路化的编译码芯片，此一般称为CODEC芯片，如果只考虑播放功能，则只需要译码运算硬件线路化的芯片，此称为译码芯片(Decoder)；如果在播放外也希望能拍照、录像，那么就必须用上「编译码芯片，CODEC」。这样的方式可达到相当高的功耗控制能力，但是缺乏可程序化能力，也不具备新增支持未来新视讯标准的能力。
只使用单纯的通用嵌入式处理器、微控制器芯片，所有的多媒体编译码运算一律以软件方式实现，这种方式弹性最高，但是程序撰写与最佳化更为复杂，而且通用处理器在功耗表现上，往往不如一般特定用途的加速器(如DSP或VLIW处理单元)。因此要使用这类处理器，首先要考虑到处理器本身是否有针对特定多媒体应用设计的指令集或处理单元，否则将难以负担未来逐渐走向高质量的移动影音解碼需求。
