PMP/MP4播放器的设计和实现
摘要:研究设计了一种支持MPEG- 4 格式的便携式媒体播放器。系统采用Blackfin 的ADSP BF532 芯片, 底层驱动和应用程序都自行设计, 并对MPEG- 4 视频解码技术等算法进行了优化。该播放器支持多种格式的流媒体播放, 具有低成本、小型化、低功耗、稳定可靠、便于携带等特点。
关键词:便携式媒体播放器; 数字信号处理器; MPEG- 4 标准
实用设计
在MP3 风靡全球后, 目前半导体供应商讨论的一个热点话题就是具备视频播放功能的便携式媒体播放器( Portable Media Player, PMP) 能否再带动另一波消费狂潮, 从而刺激整个半导体产业迈向下一个高峰。PMP 是一种以播放多媒体文件为其核心功能的消费类娱乐产品, 其中的多媒体文件包括音频、视频、FLASH 动画、图片等。而且, 在此基础之上, PMP 可以扩展诸如视频录制、摄像/照相、数码相册、收音机、电子书、游戏、上网等丰富的功能, 成为一种个人信息和娱乐的便携式设备。
目前典型的几款PMP 解决方案
现阶段在市场上流行的PMP 设计方案大多是采用CPU 搭配DSP 的方式, 其中DSP 是负责Decode/Encode的工作, CPU 则是针对档案管理、存取, 以及使用接口、周边组件的掌控等进行处理。比较成熟的解决方案主要由Intel, TI 和SigmaDesigns 等公司提供。
采用Intel 芯片的方案
Intel 公司于2003 年底推出了PXA27x 嵌入式处理器, 最高频率可达624 MHz。配合嵌入式Linux 或WinCE操作系统, 理论上可以支持任何媒体格式, 并通过软件升级, 支持未来媒体格式, 但由于MPEG- 2 对硬件的极高要求, 单纯依靠PXA27x 处理器进行MPEG- 2 编解码是不现实的。Intel 公司于2004 年推出了
采用TI 芯片的方案
TI 作为嵌入式多媒体解决方案的领导者, 有一系列PMP解决方案, 包括TI DM270/DM275/DM320/DM342/OMAP2420 等平台。目前国内厂商采用最多的DM320 方案是利用DSP 进行音视频编解码处理, ARM处理器负责系统处理及提供外围设备接口。该方案支持的媒体类型丰富, 编解码能力强, 但由于必须配合ARM处理器, 成本与功耗都会提高, 而且软件解决方案有限, 需要客户做大量的软件编程工作。DM342 方案将C5409 与ARM926整合, 即CPU 与DSP 同时集成在DM342 核心内, 虽然在一定程度上节约了成本, 但由于处理器耗电量过大而导致热量上升, 势必要花费额外的研发成本于散热处理上。
SigmaDesigns EM851x 方案
SigmaDesigns 851x 处理器采用双核设计, 将200MHz 32 位RISC 处理器和MPEG 解码处理器集成于单芯片上, 在无需其它外围芯片支持的情况下, 完成系统所需各种接口的提供、系统处理以及流畅的MPEG- 4 和MPEG- 2 等视频解码。但是该方案无法播放网络视频格 式RM, RMVB 等, 主频仅200 MHz, 存储器只能接普通SDRAM, 不能接DDR2。
现有方案存在的问题
目前市面上还有其它几种非主流方案, 如Zoran 解决方案, 飞利浦( Philips) 的便携式多媒体Media Box 方案, Sunplus SPCA536 解决方案, AMD Alchemy Au1200解决方案和Freescale i.MX21 解决方案等。以上这些方案都存在着成本偏高、功耗不足、不支持网络视频格式及扩展功能有限的问题。
系统硬件设计
在进行系统硬件设计时一定要考虑产品整体成本,而不只是CPU, 而且在选择开发硬件时, 开发者同时也需要考虑源代码驱动和文档的易获取性。基于以上考虑,笔者选择了Blackfin 的ADSP BF532 芯片作为方案的核心。这是一款由ADI 与Intel 联合开发的体现高性能体系结构的首款第四代DSP 产品, 性能达到了400 MHz/800MMACS(Million Multply- Accumulates- per- Second) 。该芯片采用了由ADI 和Intel 公司联合开发的微信号架构(MSA) , 它将一个32 位RISC 型指令集和双16 位乘法累加(MAC) 信号处理功能与通用型微控制器所具有的易用性组合在了一起。芯片架构完全符合SIMD 标准, 包括多种用于加速视频和图像处理的指令, 极大地简化了硬件和软件设计实现任务。BF532 不仅具备丰富的外设接口资源, 而且采用了多种节能技术, 可在低至0.8 V 的电压条件下工作, 因而特别适合于需要延长电池使用寿命的便携式应用。
基于BF532 的硬件平台位于整个系统最底层, 硬件结构如图1 所示。音频输入输出模块由TI 的TLV320AIC23和BF532 的AC- 97/I2S Audio Code 共同完成。在视频输出方面, BF532 自带的视频解码功能可以输出基于CCIR- 656 标准的视频图像。显示屏采用320×240 的TFT 屏, Flash 为256 MB 的SAMSUNG K4S
系统软件设计
在基于ADSP BF532 的强大处理能力的基础上, 自行编写了系统底层和应用程序, 可提供强大的增值功能,实现对DivX 4.X/5.X 和MPEG-
内存管理
ADSP- BF532 支持一整套软件和硬件开发工具, 包括ADI 公司的仿真器和Blackfin DSP 开发环境下的VisualDSP++3.5。
对应于BF532, Visual DSP++提供4 个LDF 文件管理内存布局, 分别为ADSP- BF532.ldf, ADSP- BF532_c.ldf, ADSP - BF532_cpp.ldf, ADSP - BF532_ASM.ldf。每个.LDF 文件处理一系列命令, 允许通过提供少量命令行选项来把多种配置植入应用。通过在.LDF 文件中大量使用预处理器宏, 可以实现这种灵活性。宏作为一种标记,指示一种选择或另一种选择, 并作为.LDF 文件中的变量来保持选定文件的名称或其它链接时间参数。简单地说,通过在链接器命令行上定义预处理器宏, 可以选择不同的.LDF 文件配置, 可以从IDDE 的工程选项的Link 配置页或直接从命令行指定, 例如:
ccblkfn - proc ADSP - BF532 prog.c - flags - link -MDUSE_CACHE
在链接过程中, 上面的命令行定义USE_CACHE 宏,配置L1 指令和数据存储空间为CACHE。.LDF 文件为处理器上所有定义的空间指定存储区域, 但在.LDF 文件中, 并不是所有这些存储区域都被使用了, .LDF 文件提供两种基本的存储器配置:
1) 缺省配置规定只有内部存储器可用、不激活CACHE。因此, 没有指令或数据被映射到SDRAM, 除非明确说明放在那里, 所有可用的L1 空间被代码或数据使用。
控制输入显示屏视频编解码
2) USE_CACHE 选项选择替代配置, 可使指令和数据CACHE 被激活, 并使用外部SDRAM。代码和数据被映射到L1 上可用的空间, 但CACHE/SRAM区域是空的, 任何溢出指令段都放置在SDRAM的32 MB 区域。
文件系统的设计
在LDF 管理系统的基础上, 自行编写了FAT 文件系统来对文件操作进行管理。FAT 文件系统具体分为引导区、文件分配表、根目录区、数据区四部分。
1) 引导区存放代码所需的信息及最重要的文件系统信息。这些信息包括了Flash 存储器的类型、容量以及划分成多少个簇; 每个簇包含多少扇区、FAT 表数目、保留扇区数、根目录的首簇号及根目录入口数、版本信息等等。引导扇区是在格式化Flash 时生成的。
2) 文件分配表存放文件所占用的存储空间族链以及Flash 存储器的占用和空闲空间的情况。系统对FAT表的访问原理如下: 访问文件时先从目录中找到该文件的目录项, 从中读出首簇号。然后, 目录中找到该文件的目录项, 从中读出首簇号。然后在FAT 中找到从该首簇号开始的簇链, 簇链上的簇号即为文件在逻辑扇区中占用的扇区号链, 这样便可以进行数据读写了。
3) 根目录区是固定大小的紧跟在FAT 表后的区域, 记录了文件的文件名、文件属性、文件大小、文件创建的日期和时间以及文件在数据区中所占的首簇号。
4) 数据区存储文件的数据内容, 文件系统对数据区的存储空间是按簇进行划分和管理的。在系统中, 定义一个簇为32 个扇区, 一个文件总是占用若干个整簇。由此, 该FAT 文件系统提供文件的格式化, 文件的打开、删除、关闭, 文件的读写、查找等基本的功能。
在FAT 文件系统的基础上, 笔者基于LDF 内存管理采用了磁盘缓存管理来提高文件交换的效率。按照Blackfin 处理器的.LDF 文件定义, L1 存储器有附加的划分方法, 可以根据run- time 库的不同需要, 对存储器进行合适的分配。L1 指令存储器被分为代码和代码CACHE。L1 数据存储器Bank B 被分为数据和数据CACHE, 前者进一步分为常数数据和堆栈使用的空间。L1 数据存储器Bank A 也有CACHE/非CACHE 的划分。非CACHE 区域有可选择的256 B 用于命令行变量。
总的来说, 通过.LDF 文件, 可以在内存中定义一个Cache,Cache 的大小与一个Block 相同, 从文件读出的数据和写入文件中的数据都经过这个缓冲区。以写入硬盘文件为例, 中断处理程序把数据先收到Cache, Cache 对应于Flash 上的Block 逐个写入, 主函数负责把Cache 中的数据写到Flash, 具体什么时候这些数据要真正写入Flash,每次写入的数据是多少, 都不需要由文件系统本身负责。LDF 文件根据缓存里现有的内容以及磁盘簇的大小来实现该过程, 文件系统只用关心该系统自身的逻辑实现。
MPEG- 4 解码器
在几种开放源代码的MPEG- 4 解码软件中, 选择xvidcore
MPEG- 4 标准采用了基于对象的压缩编码技术, 在编码前首先对视频序列进行分析, 从原始图像中分割出各个视频对象, 每个对象都有自己的形状信息( shape) 、运动信息(motion) 、纹理信息( texture) , 然后再分别对每个视频对象的形状信息、运动信息、纹理信息单独编码。MPEG- 4 通过运动预测和运行补偿来去除连续帧之间的时间冗余。运动预测与运动补偿的精度可以为整像素、半像素或1/4 像素, 另外还增加了重叠运动补偿方式。与形状相关的算法有: 基于邻近信息的算术编码、水平和垂直填补、扩张填补等。与纹理解码相关的算法有: 离散余弦( 逆) 变换(DCT/IDCT) 、量化、DCT 系数的DC/AC 差分预测、Zig- Zag 扫描、游程编码、霍夫曼变长编码等。
视频序列按照视频对象层VOL (Video Object Layer)、视频对象平台VOP(VideoObject Plane) 、宏块MB(Macro Block) 视顺序编成一串码流。基于VOP 解码过程如图3 所示。程序首先从码流中解出VOL 和VOP 的头, 然后根据这些头信息以宏块为单位进行解码。MB 解码单独做成函数, 也是首先解出头信息, 据此判断出MB类型: 帧内MB( intraMB) 、帧间MB( interMB) 、帧间4VMB( inter4VMB) 。帧内MB 解码是以1 块为单位作纹理解码, 解出的纹理值最后存入宏块缓存区内; 帧间MB 解码是先解出运动矢量MV, 根据MV 进行运动补偿得到预测值存入宏块缓存区, 再以块为单位进行纹理解码, 解出残差值存入Block 中, 最后将Block 加入到宏块缓存区中得到最后结果。不同的是, 在解码MV 时intraMB 解出1个MV; 而inter4VMB 解出4 个MV。因此, 运动补偿时,一个按宏块做, 一个按块做。
系统优化
软件在实际DSP 中的应用, 需要做以下几方面工 作: 首先规划内存, 定义程序与数据空间; 其次对整体程序进行结构优化; 最后按照DSP 本身结构和指令, 考虑硬件结构的特点, 对各个部分进行针对性的程序改进和优化, 使系统资源能够极大地调动起来以节省大量的运算时间。
结构优化
ADSP BF532 片内数据存储空量只有84 KB, 由48KB 的L1 指令存储器SRAM、32 KB 的L1 数据存储器SRAM和4 KB 的L1 中间结果暂存器SRAM组成, 而图像处理的数据量非常大, 因此, 合理有效地分析存储空间是解码设计中的关键问题。笔者在内部32 KB L1 数据存储空间内开辟了一些空间用于暂存解码中常用的一些信息, 包括: 变长解码表( 4 906 B) , Zig- Zag 扫( 192 B) ,VOL, VOP 和MB 的头信息( 108 B) , DC/AC 预测和MB模式( 5 560 B) , MV 预测( 9 504 B) , 量化步长( 396 B) , 解码输出缓存区( 1 个宏块行8 448 B) , 共29.1 KB。将32KB 的L1 指令储存器设为压缩码缓存区, 解码时分批将数据通过DMA 方式复制到该缓存区, 解码后的视频序列存放在外部SDRAM中。同时在L1 数据储存器内缓存1 个宏块行, 每解完1 个宏块行后, 就用DMA 传输到外部SDRAM中。
代码优化
大多数DSP 程序设计都采用C 语言和汇编语言相结合的方式来完成。先写出C 代码并对其优化, 如果不能达到预期的运行效率, 则编写汇编代码来提高效率。C代码优化的步骤包括:
1) 使编码器代码线性化, 这样有利于DSP 的流水线满负荷运行, 更充分地发挥DSP 的数据处理能力。
2) 取消循环中的数据依赖。数据依赖是指后面指令的输入数据依赖于前面指令的输出数据。许多DSP 芯片都提供了硬件循环指令, Blackfin532 有两个硬件循环器, 可提供两层的硬件循环。硬件循环实现了零开销的循环判断, 能大大提高循环指令的执行速度, 然而数据依赖的存在会阻止硬件循环的使用。所以要尽可能消除循环中的数据依赖。
3) 将除法转化为乘法或查表方式。Blackfin532 提供了硬件乘法器, 但没有硬件除法器。执行除法指令会花费几十或上百个指令周期。将除法转化为乘法或查表, 能大
大减少这种开销。
4) 减少对片外存储器的访问次数。片外存储器相对于片内存储器是低速设备, 片外存储器的读取时间是片内存储器的几倍至十几倍。对于片外存储器的数据要做到一次读取, 完成多次计算。
Blackfin 芯片的开发环境Visual DSP++本身已经带有汇编器, 但由于种种原因, 对于某些运算量大、调用频繁的函数仍需要进行手动汇编优化。在项目设计中, 通过统计可以发现DCT/IDCT, SAD ( 绝对差值求和函数) 及YUV 到RGB 的转换指令被频繁调用, 消耗了大量的运行周期, 因此我们用汇编实现了DCT/IDCT, SAD 及YUV到RGB 的转换指令。此外, BF532 提供了求最大值、最小值、绝对值及大量视频专用指令, 通过使用这些指令, 能大大提高代码的执行速度。
测试效果
根据以上的硬件系统和软件结构, 在测试环境为VisualDSP++3.5, 测试软件ADSP- BF533 EZ- KIT Lite,ADI 仿真器JTAG ICE 14 排针, 外部独立电源的情况下, 对各标准视频序列进行解码, 输出图像分辨率为320×240(GIF) 。
如表1 所示, 对于序列News 和Silent 这些运动动作不太大的图像, 解码速率已远远高于实时的要求; 而对于Foreman 和Moblie 这些运动动作较大的图像, 解码速率也可以满足流畅播放的要求。
实验结果表明, 该方案不但显著降低了硬件成本, 同时具有底层架构灵活、便于进行软件升级和开发增值功能等优点, 并且相对同类产品有更佳的解码性能, 具备十分良好的应用前景。
相关推荐
