JM编码器的介绍

1、目录1 概述62 JM编码器的介绍72.1 JM编码器主要流程72.2 JM编码在VC中编译过程93 JM的编解码过程113.1 JM的编解码过程113.1.1 JM编码过程113.1.2 JM解码过程123.2 JM的输出文件格式133.2.1 基于比特流文件格式133.2.2 RTP文件格式153.3 JM的视频质量评估163.4 JM的文件接口174 问题解答184.1 JM能在linux下运行么？184.2 JM编码器对数据丢失的处理？184.3 在下载的flv中为什么会只有15fps？184.4 怎么设置JM输出为固定码速率？195 参考资料20图目录图 2-1 JM编码器主函数部分

2、8图 2-2 JM的Encode_one _frame函数部分9图 2-3 Project Setting10图 3-1 JM编码参数11图 3-2 JM编码结果112图 3-3 JM编码结果212图 3-4 解码结果13图 3-5 NAL内部防竞争机制14图 3-6 JM编码后数据-114图 3-7 基于比特流的文件格式14图 3-8 RTP的格式15图 3-9 RTP负载头部15图 3-10 PSNR求解结果16图 3-11 接口文件17表目录表 3-1 RTP的type值1520JM编码器关键词：JM编码器、JM安装、视频评估摘 要： 本报告主要对JM编码器做了比较详细的介绍，包括其主要

3、作用、安装和使用过程、编解码过程及其文件输出格式，并对其自带的视频的质量评估作一个简单的介绍，并对整个编解码的过程给出了实例分析。缩略语清单：缩略语英文全名中文解释CBRConstant bit rate固定比特速率FLVFlash videoFlash视频NALNetwork abstract layer网络抽象层NALUNetwork abstract layer unit网络抽象层单元PSNRPeak signal to noise ratio峰值信噪比RTPReal-time Transport protocol实时传输协议1 概述JM编码程序是H.264的官方测试源码，由德国hhi研

4、究所负责开发1。起始时间是2002年2月。JM实现了H.264所有的特性，几乎所有的学术研究的算法都是在JM基础上实现并和JM进行比较。但其程序结构冗长，只考虑引入各种新特性以提高编码性能，忽视了编码复杂度，其编码复杂度极高，不宜实用。本报告从JM编码器的安装和使用过程、JM的编码流程、JM的文件输出、JM中自带的视频评估策略等方面对JM编解码器进行了详细的介绍，并给出了实例分析。本报告的章节结构如下：第2章 JM编码器的介绍 介绍JM编码程序主要流程和在VC下编译过程。第3章 JM的编解码过程 结合实例对JM程序的编解码过程、文件输出格式、视频评估机制的介绍。第4章 参考资料 列出报告中引用

5、的参考资料。2 JM编码器的介绍JM编码器是H.264官方发布的测试源码，其实现了H.264建议的所有的特性，所以学术研究的算法都是在JM的基础上进行实现并和JM源进行比较，得出算法的优缺点。但是JM程序在编写的时候就没有考虑效率，只是考虑引入各种新特性以提高编码的性能而忽视了整个程序的复杂度，让JM的编码复杂度极高、运行速度相当慢。所以JM编码器只适用于学术研究，没有实用效果。2.1 JM编码器主要流程整个JM编码源就是一个总工程ject，其下面又包含两个子工程ject和ject。打开总工程tml.pjt中可以看到两个子工程，分别编译生成

6、lencod.exe和ldecod.exe两个可执行文件。当然ject和ject这两个子工程也是完全独立，各自包含各自的C文件、主函数文件、H头文件、配置文件，是可以独立进行编译的。JM编码器采用的是标准的C代码格式，可以在windows、linux、android等环境中进行编译，而且JM编码器的基本参数的选择采用配置文件格式进行提供，对编译好的JM程序进行参数修改时，只需要在配置文件中进行修改即可，不需要重新编译。JM提供了baseline、main、extended三种不同级别的配置文件，里面的基本参数的参考值也已经提供。详细的配置文件见附录A。下

7、面是JM编码器的主要的流程图：见图2-1、图2-2。图 2-1 JM编码器主函数部分注:1. 这里主函数部分省略了一些函数的调用和条件判断、释放空间，判断帧类型影响不大的部分。2. 率失真后的申请两帧图像的空间：一个是编码帧，一个是参考帧。3. 在快速运动估计后面的阈值是为了在运动估计时给出一个判断条件，小于阈值则进行快速运动估计，大于则放弃。图 2-2 JM的Encode_one _frame函数部分注：1. 因为JM可能采用率失真优化，所以在每一帧编码时，都要对量化参数进行更新。2. H.264支持NALU打包和RTP打包格式的。3. 在宏块级别编码的流程基本和x264程序一致。2.2 J

8、M编码在VC中编译过程1. 首先下载并解压JM源代码2. 在源代码的根目录下找到bin文件夹，新建一个backup文件夹，并将bin文件中的所有文件复制到backup文件夹中做好备份。3. 在源代码根目录下新建lencodtest文件夹，将编码过程中需要的配置文件（encoder.cfg）、待编码的视频序列（如foreman_qcif.yuv）等复制该文件夹中。4. 在源代码根目录下新建ldecodtest文件夹，将解码过程中需要的配置文件（decoder.cfg）、待解码的文件（例如test.264）复制到该文件夹中。5. 打开源代码根目录下的tml.dsw。6. 分别选择lencod和ld

9、ecod工程，鼠标左键选中 lencod (ldecod)工程打开 Project -> Settings -> Debug ，在 Working directory 选项中填写./encodtest (./ldecodtest)，在 Program arguments 选项中填写需要使用的编码配置文件（要与第3步所复制的文件同名），例如：-d encoder.cfg (-d decoder.cfg)，然后确定修改。见图2-3。7. 鼠标右键选中lencod (ldecod)工程，选择鼠标右键菜单 Set as Active Project。编译运行即可。图 2-3 Project

10、 Setting3 JM的编解码过程3.1 JM的编解码过程3.1.1 JM编码过程在JM编码器编译通过的基础上，首先打开tml.dsw，根据编码要求修改其中的encod.cfg文件，保存后退出。然后在cmd中找到JM的根目录中的bin文件夹，然后直接输入“lencod.exe”运行即可。下面进行实例介绍:编码参数为：编码级别为baseline，编码图像序列为football_cif_30.yuv，编码帧数为150帧，I帧周期为25，编码帧率为25fps，量化参数为28，图像输出文件为test.264，输出采用为NALU格式打包，输出重建图像文件为test_rec.yuv。见图3-1所示。图

11、3-1 JM编码参数编码结果如图3-2和图3-3：图 3-2 JM编码结果1图 3-3 JM编码结果23.1.2 JM解码过程在JM程序编译通过后，先将要译码的文件放入ldecodtest文件夹下，打开tml.dsw，根据自己的参数(主要是译码文件的位置等)要求修改decoder.cfg文件，完成后保存退出。然后再cmd中查找到JM根目录下的bin文件夹，输入“ldecod.exe decoder.cfg”即可。下面是对上面编码生成的test.264文件进行解码，解码结果见图3-4:图 3-4 解码结果3.2 JM的输出文件格式H.264的NAL单元定义了基于包(即RTP)和基于比特流(即.2

12、64文件)的基本格式，区别这两种格式的方法在于每个比特流传输层都有一个起始代码。RTP格式文件主要用于传输，而.264文件格式主要用于存储3。3.2.1 基于比特流文件格式H.264规定的基于比特流的文件主要用于数据存储，编码数据是储存在介质（如DVD光盘）上，由于NAL是依次紧密排列，解码器将无法在数据流中分辨每个NAL的起始和终止。H.264采用了一种简单而有效的方案来解决这么问题。当数据流是存储在介质上时，在每个NAL前添加起始码：0x000001同时H.264也定义了一个字节0x00为zero_type,在一般的情况下2，NAL单元起始码为0x000001，只有在下面几种情况下，会在N

13、AL起始码前加入zero_type，那样NAL起始码头部变为0x00000001。1. NAL单元的类型是PPS或是SPS时。2. NAL单元的类型是14-18。.3. 每一帧图像的第一个NAL单元即一个接入单元。4. NAL单元类型为SEI时。在这样的机制下，解码器在码流中检测起始码，作为一个NAL 的起始标识，当检测到下一个起始码时则标志当前NAL结束。H.264规定当检测到0x000000 时也可以表征当前NAL的结束，这是因为连着的三个字节的0中的任何一个字节的0要么属于起始码要么是起始码前面添加的0。如果NAL内部出现了0x000001时，则会发生混淆，H.264提出了“防竞争”。在

14、NAL内部出现0x000001时，则在最后一个字节前插入一个新的字节：0x03，从而变成图2-2所示。当NAL解码器遇到0x000003时，解码器丢弃0x03。图 3-5 NAL内部防竞争机制注:0x000000是NAL的结束，0x000001是NAL起始码，0x000002是H.264保留，0x000003是为了保证解码器正常。图 3-6 JM编码后数据-1上图是本报告3.1节中JM编码后的数据，三个被标记的0x00000001是NALU的起始码，67、68、65分别是NALU的头部信息，代表着第一个NALU是SPS信息，第二个NALU是PPS信息，第三个是IDR帧。从图3-6可以验证出基于

15、比特流的文件格式为：图 3-7 基于比特流的文件格式3.2.2 RTP文件格式RTP格式是H.264提供的适于网络传输的输出格式，RTP的文件格式如图3-8所示，其中RTP的头部信息在RFC 3550中有详细的描述4，包含1bit的标志位、7bits的负载类型、16bits的序列号和32bits的时间戳。对于RTP的负载，H.264规定了3种不同的负载结构，接收端可能通过RTP Payload的第一个字节即RTP负载头部来识别它们，而这个字节类似NALU头的格式，可以指出其代表的是哪种结构。这个字节的结构如图3-9所示：图 3-8 RTP的格式图 3-9 RTP负载头部其中F为禁止位，NRI为

16、重要等级位，TYPE的值为24-31，区别H.264中类型字段。RTP的type值的含义见表3-1所示：表 3-1 RTP的type值TYPE 值类型解释24STAP-A单一时间的组合包25STAP-B单一时间的组合包26MTAP16多时间组合包27MTAP24多时间组合包28FU-A分片的单元29FU-B分片的单元30-31没有定义H.264规定的3中结构为单一的NAL单元模式、组合封包模式、分片封包模式。1. 单一的NAL单元模式：即一个RTP包仅由一个完整的NALU组成，这种情况下RTP的负载头字段和H.264的NALU类型字段是一样的。对于NALU的长度小于MTU大小的包，一般采用单一

17、NAL单元模式。分装时，只需要将原始的H.264 NALU单元的起始码去掉，然后将剩余的数据封装成RTP包即可。2. 组合封包模式：即可能是由多个NAL单元组成一个RTP包，分别有四种组合方式STAP-A、STAP-B、MTAP16和MTAP24，其类型值分别为24、25、26和27。STAP-A和STAP-B只含有一个NALU时间戳，多个NAL单元共享一个NALU时刻。MTAP16、MTAP24均含16bits的无符号解码顺序号、一个或多个多时刻聚合单元和16bits或24bits的时间戳位移。3. 分片封包模式：用于将一个NALU单元分装成多个RTP包，存在两种类型FU-A和FU-B，其类

18、型值分别为28和29。当NALU的长度超过MTU时，就会对NALU进行分片封包，每一个分片由整数个连续的NAL单元字节组成。相同的NAL单元分片必须使用递增的RTP序号连续顺序发送，同样NAL单元必须按照RTP顺序号的顺序装配。3.3 JM的视频质量评估JM编码器中自带的视频质量评估机制包括PSNR（包括Y、U、V和总体的PSNR）、bit rate等。图像的PSNR是指原图像和处理图像之间均方误差相对于的对数值。其计算公式如式（3-1）:(3-1)在JM中对于在求解PSNR时，先设定一个参考文件（一般是解码前或传送前的那个文件），然后与解码后的文件进行比较才能得到相应的PSNR。在一般情况下

19、，PSNR按照式（3-1）进行计算，但下面两种情况PSNR的值将会设定为0。1）你没有指定有效的参考文件；2）解码的文件与参考文件完全相同。若在丢包后计算PSNR，就必须先进行错误隐藏才能计算。Bit rate也是评估视频质量的重要方面，在图像质量相同的前提下，实现bit rate越低也是实现视频压缩率高低一个重要体现。从图3-4可以看出，其PSNR值为0，是用编码后的数据直接解码，没有任何的丢失和错误，解码文件和参考文件完全相同。图 3-10 PSNR求解结果见图3-10所示，图中PSNR为解码后的图像和重建图像之间的求解值。4 问题解答4.1 JM能在linux下运行么？JM是标准的C文件

20、，是可以在在linux系统里面，直接用GCC等译码器直接进行编译运行的，同时JM工程里自带makefile文件，所以只需要调用makefile进行编译就好了。4.2 JM编码器对数据丢失的处理？1. JM编码器对于数据的丢失不支持比特级错误的处理，只支持对于包丢失的处理，在JM接收到数据包的丢失的时候，因为包的序号不连续，解码器一旦检测到包序号不连续就会将不连续的地方的所有宏块的标记ei_flag = 1，然后进行错误隐藏。2. gaps_in_frame_num_value_allowed_flag这个句法元素等于1时，表示允许句法元素frame_num可以不连续。当传输信道堵塞严重时，编码

21、器来不及将编码后的图像全部发出，这时允许丢弃若干帧图像。在正常情况下每一帧图像都有依次连续的frame_num值，解码器检查到如果frame_num不连续，便能确定有图像被编码器丢弃。这时，解码器必须启动错误掩藏的机制来近似地恢复这些图像，因为这些图像有可能被后续图像用作参考帧。当这个句法元素等于0时，表不允许frame_num不连续，即编码器在任何情况下都不能丢弃图像。这时，H.264允许解码器可以不去检查frame_num的连续性以减少计算量。这种情况下如果依然发生frame_num不连续，表示在传输中发生丢包，解码器会通过其他机制检测到丢包的发生，然后启动错误掩藏的恢复图像。3. JM对

22、于错误隐藏功能是默认打开的。4.3 在下载的flv中为什么会只有15fps？帧速率：帧速率是每秒显示的图像数。标准影片(NTSC) 是29.97帧第秒(fps)，电影是每秒24fps。欧洲标准是(PAL)25帧fps。如果你对你影片的尺寸不是太注重的话，保留默认的Current选项。这将会使你制作的影片的帧速率和源文件一致。不管怎样，如果你想降低带宽和CPU的占用，你可以选择一个低的帧速率。高的帧速率拥有高的品质的，但文件尺寸也更大。如果你选择的帧速率低于你的源文件的帧速率，一些帧将被删除。如果你选择的帧速率比你的源文件高的话，已有的帧将被重复(不推荐，因为增加了尺寸，但品质没有提高)。如果你选择的帧速率低于你的源文件的帧速率，使用一个你当前