新安装了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所替换.
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中的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认识清了再说吧。
现在主要还是继续熟悉代码,争取把重要的问题搞清楚,这样也就能明确算法那些位置是负担最重的,看能不能想出什么好的方法进行优化处理一下。
其实每次开始新的知识的时候都会感觉问题纷繁复杂,常常的想要放弃,前面的路太难走了,有些看不到终点,不过经过一段时间的摸索常会有新的发现,感觉路变 得开阔起来,这可能是开始的时候太过急于求成,想一口吃个胖子,同时思想上不端正,没有认识到任务的复杂度,结果灰心意冷,满是挫败感,甚至于放弃。
不过这次并不是前面的问题,而是遇到的障碍确实很大,算法有难度,整个项目工作量很大,时间精力又有限,这周主要就是看代码,是否改方案或者放弃等对x264认识清了再说吧。
1、 跑了第一遍编码的分析过程,主要是IDR图像的第一个宏块编码,主要是如何选则编码的预测模式,明天跑第二个宏块会了解的更深入。
2、下载了一些资料,关于x264的码率控制,预测和DSP上的优化,还没有进行研读,有时间学习学习
对于这个项目的计划,原先可能有些跑偏,过于关注与算法代码的熟悉上,没有注意实际的移植、优化,所以进度比较慢,以后看是否要调整一下,最近一周还是熟悉代码,争取更深入的理解
2、下载了一些资料,关于x264的码率控制,预测和DSP上的优化,还没有进行研读,有时间学习学习
对于这个项目的计划,原先可能有些跑偏,过于关注与算法代码的熟悉上,没有注意实际的移植、优化,所以进度比较慢,以后看是否要调整一下,最近一周还是熟悉代码,争取更深入的理解