调试X264--基础编译部分(转)

新安装了CCS3.3，编译X264源码，不过，一定是我改了什么东西，原先的代码是可以正常编译的，那是另一个朋友帮忙 给 弄得，还好，当时这个文档用SVN进行过版本管理，于是将原先的版本找出来，SVN用的少，折腾了半天。有两个可选的版本，一个是CCS编译OK，一个是 CCS和VC7编译OK，结果只有前一个好用，于是使用前一个版本，写了一个CMD文件，编译OK，准备下板调试，发现文件中的图像数据存储的位置与 EVM板上的可用位置不一致，而这个地址后面还要用到，代码很多，需要一个调试环境一点一点找，还是需要在VC7下可用才成，VC7的调试环境比较好。于 是将这个版本的项目在VC7下编译，问题很多，原先是一个哥们帮弄的，现在只能是自己了，条错误，该增减文件，终于在VC7下编译通过。

  X264的DSP移植使用VC7和CCS双调试工具比较好，VC7调试方便，界面友好，可以提高效率，CCS不用说了，必须地。

   明天改下图像文件的地址，争取下板运行一下，看一看时间如何。

使用宏定义的方法改变函数的引用：

x264源码基于LINUX,首先移植到了WINDOWS，之后移植到CCS上，由于CCS没有文件系统，所以在原先代码中对于文件的操作需要进行改写，例如fopen()需要改写为自己写的同功能文件，这时一个简单的做法 是使用#define fopen   xxx_fopen，这样在此以后引用的该功能 的函数将不是调用C函数库中的fopen，而是改为调用xxx_fopen，因为在预编译的时候所有的fopen均已被xxx_fopen所替换.

关于SCAN8

对于x264中的x264_scan8结构不是很理解，看到了一个很好的介绍文章，转载如下，从其中可以看到在x264中用到的一些结构的内部数据排序， 如Intra4*4_pred_mode_cache[],Non_zero_count_cache[48]等，也就理解了x264_scan8的用 途，是作为一个数据的映射表而存在，见下面的内容



int8_t intra4x4_pred_mode_cache[40]; //5*8
int8_t (*intra4x4_pred_mode)[8];
和
uint8_t non_zero_count_cache[48]; //6*8
uint8_t (*non_zero_count)[16];
的理解，关键：当前MB 处理完后，仅仅其右、下4*4 宽度的边界对于后续MB 有参考价
值。
Juanny Wang



Intra4*4_pred_mode_cache[40]：如图1 所示，其中40=5*8，黄色区域为当前MB的16个4*4
块，主要根据上、左8 个4*4块的预测模式来预测当前MB的16 个模式。当前MB处理完，
其右、下边界（红色框）相对于后续MB 而言，分别是左、上边预测边界，所以要对当前
MB的右、下边界4*4预测模式进行保存，以便后用。



Intra4*4_pred_mode[8]如图2 所示，把当前MB的右、下边界4*4预测模式进行保存。
程序如下：
h->intra4x4_pred_mode[mb_xy][0]= h->intra4x4_pred_mode_cache[15];
h->intra4x4_pred_mode[mb_xy][1]= h->intra4x4_pred_mode_cache[23];
h->intra4x4_pred_mode[mb_xy][2]= h->intra4x4_pred_mode_cache[31];

h->intra4x4_pred_mode[mb_xy][3]= h->intra4x4_pred_mode_cache[39];
h->intra4x4_pred_mode[mb_xy][4]= h->intra4x4_pred_mode_cache[36];
h->intra4x4_pred_mode[mb_xy][5]= h->intra4x4_pred_mode_cache[37];
h->intra4x4_pred_mode[mb_xy][6]= h->intra4x4_pred_mode_cache[38];
39 号4*4块比较特殊，只保存到Intra4*4_pred_mod 数组（白色区域中的0、1、2、3、4、5、
6）中的[3]，[7]空缺，这也就解释了程序中的
h->intra4x4_pred_mode_cache[4]= h->intra4x4_pred_mode[top_xy][4];
h->intra4x4_pred_mode_cache[5]= h->intra4x4_pred_mode[top_xy][5];
h->intra4x4_pred_mode_cache[6]= h->intra4x4_pred_mode[top_xy][6];
h->intra4x4_pred_mode_cache[7]= h->intra4x4_pred_mode[top_xy][3];



Non_zero_count_cache[48]：non_zeor_count 缓存如图3 所示，其中48=6*8。黄色区域为当
前MB 的16 个4*4 块的非零数；绿色区域分别为两个色度块的非零数。红色框为当前MB
亮度、两个色度的右、下边界。



Non_zero_count[16]：当前MB 处理完后，原理同图1，也是对MB 的右、下4*4 宽度的边
界进行保存，保存到non_zero_count[16]供后续使用。由图4 可清楚明了，白色区域（0、1、
2、3、4、5、6、7、8、9、10、11、12）为数组non_zero_count[16]。
程序如下：
h->non_zero_count[mb_xy][0]= h->non_zero_count_cache[36];
h->non_zero_count[mb_xy][1]= h->non_zero_count_cache[37];
h->non_zero_count[mb_xy][2]= h->non_zero_count_cache[38];
h->non_zero_count[mb_xy][3]= h->non_zero_count_cache[39];
h->non_zero_count[mb_xy][4]= h->non_zero_count_cache[31];
h->non_zero_count[mb_xy][5]= h->non_zero_count_cache[23];
h->non_zero_count[mb_xy][6]= h->non_zero_count_cache[15];
h->non_zero_count[mb_xy][7]= h->non_zero_count_cache[17];
h->non_zero_count[mb_xy][8]= h->non_zero_count_cache[18];
h->non_zero_count[mb_xy][9]= h->non_zero_count_cache[10];
h->non_zero_count[mb_xy][10]=h->non_zero_count_cache[41];
h->non_zero_count[mb_xy][11]=h->non_zero_count_cache[42];
h->non_zero_count[mb_xy][12]=h->non_zero_count_cache[34];

今天又读了一个晚上的代码，对于x264的运行有了深一些的认识，现在应该讲正在深入到算法的核心部分， 越是了解的多越是矛盾，这个项目要想如原先所愿的实施，即达到D1分辨率下的实时编码看来是有很大难度的，需要将预测部分的算法改为使用硬件逻辑来实现， 这涉及到很多，主要的担心是精力和时间的问题，如果全天干2-3个人我估计也要半年以上，这真是一个现实的障碍。

   现在主要还是继续熟悉代码，争取把重要的问题搞清楚，这样也就能明确算法那些位置是负担最重的，看能不能想出什么好的方法进行优化处理一下。

   其实每次开始新的知识的时候都会感觉问题纷繁复杂，常常的想要放弃，前面的路太难走了，有些看不到终点，不过经过一段时间的摸索常会有新的发现，感觉路变 得开阔起来，这可能是开始的时候太过急于求成，想一口吃个胖子，同时思想上不端正，没有认识到任务的复杂度，结果灰心意冷，满是挫败感，甚至于放弃。

   不过这次并不是前面的问题，而是遇到的障碍确实很大，算法有难度，整个项目工作量很大，时间精力又有限，这周主要就是看代码，是否改方案或者放弃等对x264认识清了再说吧。

1、 跑了第一遍编码的分析过程，主要是IDR图像的第一个宏块编码，主要是如何选则编码的预测模式，明天跑第二个宏块会了解的更深入。

2、下载了一些资料，关于x264的码率控制，预测和DSP上的优化，还没有进行研读，有时间学习学习

对于这个项目的计划，原先可能有些跑偏，过于关注与算法代码的熟悉上，没有注意实际的移植、优化，所以进度比较慢，以后看是否要调整一下，最近一周还是熟悉代码，争取更深入的理解