h.264优化笔记

目前 H.264编解码器的实现可以采用以下几种方式
Ø 采用奔腾 Pentium 四代机实现 H.264 编解码最早就是在 PC 平台上实现的 由于简单易开发 基于该平台的研究得到最多 JVT 的 JM 参考代码是就是基于 PC 平台的 此方案的优点是利用当前最新的 PC 资源 以及较强的软件工具 Intel 的 SSE2 和 MMX 提供了较完整的多媒体指令集和流水线 其缺点是占用资源多 通用性不强 不过随着计算机发展 速度越来越快 有它的成本优势
Ø 采用 ASIC 实现 美国 Broadcom 公司发布了可对 H.264 编码格式 HDTV 影像进行解码的 LSI BCM7411 2004 年 12 月国立台湾大学等发布能够以 H.264方式对 HDTV 影像进行实时编码的芯片 其他厂商 如科胜讯系统(ConexantSystems) 意法半导体(ST)和 Sigma Designs 等公司已经展开了激烈的竞争 在国内 芯华等企业也在进行 H.264 解码芯片的研发 此 ASIC 的优点是方便集成 利于应用 开发周期短 但其缺点也很明显 无法灵活升级和应用修改 而且对特殊环境缺乏应变力

Ø 采用多媒体数字信号处理器 DSP Digital Signal Processor 实现 Equator公司的 bsp-15 PHILIPS 的 Trimedia TI 的 DM642 都提供了极强大的多媒体流水线操作 而且往往具有强大的多媒体接口 开发包和必要资源也较多因此基于 DSP 平台的开发成为热点 2004 年 UBvideo 公司和 ATEME 公司陆续推出了基于 TI TMS320C64*数字媒体平台的优化的 H.264 main profile编解码器 加拿大公司 Cradle 推出了 30 帧/秒的 H.264 编解码器 该产品为全 CIF 30fps H.264 标准下的首个商业应用 它是基于 CT3400 DSP 阵列芯片的
实现平台blackfin533

其优点是集合多媒体与普通 MCU 的优势 较高的主频 较低的价格 尤其适用于功耗小 体积小 速度快的网络摄像机和无线手持设备中 其缺点是具体开发的成本和周期可能较大 而且由于本身接口不够强大以及支持不够有力 开发难度和具体成本也高。

Blackfin 系列 DSP 是美国模拟器件公司 ADI Anolog Device Instruments于 2003 年推出的新一代处理器 其性能是传统 DSP 和嵌入式处理器的两倍而功耗仅为它们的一半 Balckfin 系列具有业界一流的信号处理性能和微处理器(MCU)性能 并且支持嵌入式操作系统 以满足当今嵌入式音频 视频和通信应用对高速运算和低功耗的要求。
内核主要有以下特性:
Ø 两个 16 位 MAC 两个 40 位 ALU 和四个 8 位视频 ALU
Ø 支持 8 位 16 位 32 位整数和 16 和 32 位小数数据类型
Ø 同时读取一条指令和两个单独的数据单元
Ø 循环计数器 允许嵌套零开销循环
Ø 任意的位和位域操作 插入和抽取
Ø 两个 DAG Data Address Generator 单元 具有循环和位倒序寻址方式
Ø 统一的 4GB 内存空间
Ø 混合的 16 位和 32 位指令编码 具有最佳的代码密度
Ø 支持 OS 操作的内存保护
Blackfin DSP 体系结构在单周期内支持如下操作
Ø 在两个 MAC 或两个 ALU 上执行一条单指令运算
Ø 执行 2 x 32 位数据传送(2 读取或 1 读 1 写)
Ø 执行两指针更新
Ø 执行硬件循环刷新

BF533 EZ-KIT 是 ADI 公司的评估板 它为项目演示 算法仿真 原型制作和软件优化提供了完整的平台 板子上的主要器件有 ADSP-BF533 处理器 160针 BGA 封装 27 MHz 晶振输入 2MB Flash(512K 16 2chips) SDRAM 32MB16M 16bits 模 拟 音 频 接 口 模 拟 视 频 接 口 UART 扩 展 接 口

D S P 系统配置与移植EZ-KIT 板子有 USB 和 HPPCI 两种仿真形式 由于 HPPCI 速度快 通常采用该形式 JM 的参考代码是基于 PC 的 要移植到 DSP 平台上需要做系统配置和代码

1. 数据的输入输出和配置文件JM 

参考代码是以读文件的方式输入图像数据 文件格式为 YUV 4 2 0编码完成后码流输出到二进制文件中去 编码器可选项是通过文件 encoder.cfg配置的 ADI Blackfin 支持标准的 IO 库 支持读写文件的操作 但是通过仿真器从 PC 机上读写文件速度比较慢 尤其 VLC 后的码流输出十分频繁 那么 DSP就会频繁地在 Supervisor 和 Emulator 模式之间切换 执行效率比较低下 因此我们直接将原始图像数据填充到 SDRAM 中指定的地址 码流通过 DMA 方式输出到SDRAM 中指定的地址空间 这其中必须实现图像的.YUV 文件和 VisualDSP++支持的.dat 文件之间的相互转换 编码器的配置信息在程序中设定 通过上述改动虽然没有提高实际的编码速度 但是明显地提高了整个程序的执行时间。

2 Cache的配置

为了充分发挥 Cache 的作用 一方面应该恰当配置 Cache 映射的存储空间及其页面属性 另一方面是优化代码增加 Cache 的命中率 代码的优化的手段有把处理同一数据的函数存储在一起 合理组织数据结构 增加数据复用等
3 C语言的优化

宏的使用 程序跳转比较耗时 ，不是 DSP 所擅长的 。在 H.264 的代码中有些函数很短， 执行单一的功能 ，被调用的次数很多 把这些函数改为宏 ，节省了大量的程序跳转时间 。

循环的优化 函数尽量展开 ，尤其是最内核的部分 ，对多层的循环 ，内部循环的资源一定要用足 同时循环体中的语句可以进行并行优化 这样就降低了整个循环体总的执行指令数量 小的循环可以不要让它循环 另外还可以合并某些循环合并的前提是具有相同的循环次数并且循环体内数据的运算结果不会因为合并而改变 它节省了每次循环建立的时间和循环内相同变量重复寻址时间 提高了辅助寄存器的使用率
计算表格化 可以尽可能把一些运行时计算的参数做成查找的表格常数数值 。从而将运行时的计算转化为编译时的计算 这不仅适用于一些比较规整的参数表对于一些并不规整的运行时计算 特别是比较耗时的计算 也要尽可能使其表格化浮点数定点化 C 语言中既有整型数 又有浮点数 由于使用的定点 DSP 对浮点数的计算是非常耗时的 因此 在算法允许的范围内有必要把浮点运算改为定点运算。

减少判断转换 

BF533 采用了 8 级流水线 频繁的转移指令会使流水线难以发挥作用 通过对程序流的分析 许多判断转移可以用简单的条件组合来实现。

降低数组的维数

 在 C 语言程序中 对多维数组的寻址是非常耗时的 因此在设计中应当尽量降低数组的维数简单的数据结构 最好使用单层的数据结构 这样可以降低寻址开销 又可以减少 bank 之间的冲突 避免使用嵌套的结构体 而采用单层的结构体 即使结构体比较大也没有关系。

尽量静态分配内存 指针不知道实际的地址在哪儿 多级指针更加令 DAG 困惑最好采用静态分配 将寻址方式改为一维数组 全拿出来分配好内存 并且利用一维寻址是零开销的这一特点 比如对 QCIF 图像 DCT 变换单元为 4X 4 子块那么最好是采用一行行的顺序 一行用一个指针来指 地址每两行进行一次修改对 YUV 图像来说 一次可以取 32 位 把四个点取进来。

4 汇编语言的运用

虽然经过编译器选项的优化和 C 代码的优化, 我们仍然希望进一步提高代码的运行效率 直接把关键模块改用汇编程序是最直接的办法 

用533存在的优缺点

采用了 ADI 和 Intel 联合开发微信号结构 MSA 核 消除了多个不同处理器之间相联系的复杂性 表现了良好的性能。

H.264 算法复杂 BF533 还存在片内内存较小和计算能力较差的缺点

H.264 还有问题亟待解决 其一是码率控制算法目前 H.264 还没有一个令人满意的码率控制算法 这是因为 H.264 采用的 RD 模型和宏块级的码率控制算法十分复杂 其二是抗误码的问题 在无线信道和internet 信道上如何保证可靠地传输信息也是研究热点 另外如何在目前的硬件平台上实现实时通信也是一个挑战。