H.264视频编解码的代码移植和优化

基于DSP系统开发的视频编解码系统，国内几乎都是走的移植，优化的路线，并且移植的代码，都是开源的。毕竟花费大量的人力，物力去开发一套自己的代码，并不见得比一些成熟的开源代码效率更高，健壮性更好。更何况开发速度对于一个产品的发展而言，更是重要。

目前对于H.264而言，移植的代码主要有JM,x264和T264。移植的时候，就需要对各个代码进行测试，以确定要移植的代码。相对而言，JM的移植更容易，但效率比较差，如果基于科学研究，移植JM的比较多，多见于各高校的研究人员。对企业而言，考虑到实时性的要求，移植以X264和T264居多。

将视频编解码移植到DSP的时候，考虑到DSP系统资源的宝贵，主要考虑的因素是系统空间，包括程序空间和数据空间，所以需要对原始的C代码，进行评估，这就需要对于所移植的代码有一个比较详细的了解。代码空间一般可以通过map文件进行估算。数据空间的估计，需要计算程序中内存的使用情况，除了malloc申请的空间，还包括静态数组，主要是H.264标准中的各种表格数组以及一些全局变量等等。

准备好了这些，就可以开始移植了，移植，也是一个考验你的过程。

做好了移植的准备工作，就进入了开发过程的第一个重要阶段---移植。

移植开发的时候，最好准备两个版本，一个纯C代码，在VC下编译,运行,另一个是VDSP下的版本(ccs同理），VC版本主要是验证代码运行是否正确，VDSP版本就是移植以后的版本，两个版本同步更新，即尽量保持两个版本的一致性，但能够同时在VC和VDSP下运行。在移植过程中，一般会遇到的问题如下：

1.头文件的不同，一般问题都是linux下的头文件，在VDSP中没有存在。最典型的就是inttypes.h 和 stdint.h，这种头的作用主要是定义了8字符，16字符，32字符，64字符的数据类型，移植的时候，可以自己建一个头文件或者直接在其他的头文件中把这些数据类型的定义加进去，这样的话，就不会出现问题。其他的类似，要么找相应的头文件替换，要么干脆自己定义。

2.Int64_t和Uint64_t 的问题, 在第一步中,其实也存在这个问题, 不过我最初是用long和Unsigned long 来代替，不过这样的话，编译是可以通过，但仔细分析，其实是有问题的。一般来讲，64位数的用途有两个，第一种是这个数字可能比较大，当累积到一定的程度，可能超过32位，这种情况下，可以用32位代替，不过最好加上注释，告诉自己这个数可能越界，在后面调试的时候，要提示自己注意一下。另一种用途，是开发者为了速度的要求，对一些变量复制的时候，使用了强制性的指针赋值，这种情况下，就不能直接该成32位数据了，那样的话，虽然编译通过，后面运行，肯定有错误的。这种情况下，可以使用32位数据类型，分两条语句对变量赋值，当然，这是个时候要千万注意，不要把地址搞错了。

3. Inline的问题，移植以后，编译的时候Inline经常会报错。虽然有编译选项可以去掉错误，不过你如果和我一样不熟悉的话，直接去掉 Inline关键字，到后面随着对VDSP熟悉以后，如果有优化的需要，再按照VDSP的语法，为自己想要嵌入的函数增加Inline关键字。

经过上面的修改，一般情况下，编译就没有问题了，当然，这只是移植的第一步。距离成功，还很远！

代码可以编译了以后，你可以尝试着运行，一般情况下，都会出错，并且，链接都会有问题，所以，还需要进行一下工作。

1. 配置LDF文件。因为刚移植的代码，往往数据和程序都非常大，所以，SRAM里面肯定是放不下的，这个时候，链接就会有问题。刚开始的时候，最好把所有的程序和数据都放在SDRAM里面去，这样的，链接就不会有问题了。Stack和heap情况类似，开始的时候，都先放到SDRAM。开始的时候，你需要的是一个可以运行正确的程序，速度倒在其次。

2.Malloc的问题。DSP下的开发，malloc都是一个需要解决的问题。动态申请内存，就算可以运行，结果往往也是不对的。所以，最好进行静态分配，用数组的形式分配，这样做的好处是可以方便自己管理，那些数组多大，放在那里，自己都很清楚，因为优化的时候，有一些是要放在SRAM中，另外一些特别大的才放在SDRAM中，这样才能取的比较好的效果，另外，静态数组也稳定性一些，不需要记着去释放。

3.文件操作。在VDSP的SETTING下，有一个STDIO的开关，其实可以支持文件操作，但是我调试的时候发现，有些情况下是有问题的。比如我在一个循环中使用fread，但是他只有第一次的读取是有效的，但有些时候，它好像又可以。所以，你调试的时候，如果发现结果和VC下运行的不同，可以重点看看，是不是这里出了问题。

4.调试跟踪。经过上面的准备，程序已经可以运行了。你可以在Simulator下仿真，或者板子上直接仿真。在SI下，速度会很慢，不过Sesion里面，有一个blackfin family那个sision，速度还可以，当然，有板子会更好。我们开发的时候，我使用板子的时间总共不到两个月，所以浪费了很多时间，现在回头看看，好心痛。

调试结果OK了的话，说明移植已经成功了。就可以进入下一个最主要的阶段---优化了。

移植搞好了以后，就可以进行优化了，优化是一个长期的，枯燥的，但很有挑战性的工作。做优化，你要熟悉blackfin的汇编指令，熟悉H.264标准，熟悉你所移植的代码结构，在优化过程中，的确是很枯燥的，需要你很有耐性，经常会因为一个小小的错误，让你跟踪几天甚至几星期，但是，当你看到随着你工作的不断进展，程序需要的cycle数越来越少，还是很有成就感的。

在blackfin上做优化，最主要的工作可以分为：

1.系统结构优化。

2.汇编优化。

3 cache和DMA优化。

一个好的优化程序，这几个方面肯定都会涉及。至于各自所起的作用，我没有详细测试。系统结构优化和汇编优化可以先进行。等做到一定程度了，再进行cache和DMA的优化。

H.264视频编解码的代码移植和优化相关推荐

H.264视频编解码的FPGA源码分析（二）帧内预测1
目录帧内预测算法原理基于论文的普通介绍硬件实现亮度块与色度块的划分 4×4亮度预测模块如何产生预测像素与残差像素? 垂直模式`INTRA4x4_V` 水平模式`INTRA4x4_H` 直流模 ...
H.264视频编解码的FPGA源码分析（一）输入数据分析
目录概要输入数据宏块概要本文的源码基于复旦大学的开源芯片-开源H.265/H.264视频编码器项目,本文的工作主要是在梳理源码的同时学习H.264视频编解码的原理及其硬件实现. 输入数据 C ...
数据压缩12 | 实验8 | H.264视频编解码
目录一.实验准备 1. H.264编码过程 2. 调试和编码(参考JM Reference Software Manual (JVT-AE010)) 3. 编码参数(参考JM Reference S ...
音视频编解码技术（一）：MPEG-4/H.264 AVC 编解码标准
一.H264 概述 H.264,通常也被称之为H.264/AVC(或者H.264/MPEG-4 AVC或MPEG-4/H.264 AVC) 1. H.264视频编解码的意义 H.264的出现就是为了创 ...
解析H．264视频编解码DSP实现与优化
引言基于互联网的数字视频产业前景看好,而3G的规模部署,也会推动移动视频通信成为现实.但数字化后的视频图像具有数据海量性,给图像的存储和传输造成较大的困难.数字视频产业,是指数字内容中以数字视频形态 ...
H.264及编解码调试
H.264及编解码调试 H.264是国际标准化组织(ISO)和国际电信联盟(ITU)在2002年12月共同提出的继MPEG-4之后的新一代数字视频压缩格式,其具有更高的编码效率,并注重对移动和IP网络 ...
AIR 3实现iOS下对H.264视频硬件解码
本帖最后由 nextria 于 2011-10-9 11:27 编辑在此之前,AIR开发的应用程序在iOS下是不可能实现对H.264视频硬解码的, 也许是以一个多比特率的方式传送. 我知道,是吧? ...
【ffmpeg for wince】音视频编解码多平台移植（for window/wince）
from: http://www.cnblogs.com/windwithlife/archive/2009/05/31/1492728.html 终于完成了了第二个Client side原型(for ...
H.266视频编解码标准（H.266的新技术介绍）
H.266多功能视频编码编解码器标准,新的H.266 /VCC编解码器在保持清晰度不变的情况下,数据压缩效率获得极大提高,数据量减少了50%. 新标准的公告中指出,由于改进了压缩技术,H.266将减少 ...

H.264视频编解码的代码移植和优化

H.264视频编解码的代码移植和优化相关推荐

最新文章

热门文章