关于x264的笔记整理Word下载.docx
- 文档编号:17901089
- 上传时间:2022-12-12
- 格式:DOCX
- 页数:21
- 大小:29.02KB
关于x264的笔记整理Word下载.docx
《关于x264的笔记整理Word下载.docx》由会员分享,可在线阅读,更多相关《关于x264的笔记整理Word下载.docx(21页珍藏版)》请在冰豆网上搜索。
&
rcc->
b_2pass)...,
rate_estimate_qscale中的
if(rcc->
b_2pass)..
init_pass2(){...}函数
10.去掉encoder_en.c中的x264_validate_levels(h)语句和set_en.c中对应的函
数
以上有一些修改涉及到检查参数的正确性,是因为在保证参数正确性的情况下这些语
句是可以去除的
2008-01-1614:
43
1.去掉if(h->
param.rc.b_stat_read)开头的语句
2.去掉assert()语句
3.将CCS中的程序中的fprintf(...)全部去掉,(因为涉及到文件的操作,使用USB口传
输很耗时)
4.去掉exit(-1)之类报告程序错误的函数
5.去掉encoder_en中的#ifdefDEBUG_MB_TYPE...#endif之间的语句
6.去掉common.c中的x264_param_parse()函数
7.去掉analyse_en.c中的staticconstinti_mb_b_cost_table[19]类似的数组(B
帧用到的),以及以if(h->
sh.i_type==SLICE_TYPE_B)...开头的语句
2008-01-1619:
33
1.去掉analyse_en.c中的x264_mb_analyse_inter_direct
(),x264_mb_analyse_inter_b16x16
(),x264_mb_analyse_inter_b8x8,x264_mb_analyse_inter_b16x8,x264_mb_analyse
_inter_b8x16()等五个函数,这五个函数是用来进行B帧帧间预测的,不需要用到
2.去掉macroblock.c中的if(h->
sh.i_type==SLICE_TYPE_B&
h-
param.b_cabac)...
3.去掉所有以if(h->
sh.i_type==SLICE_TYPE_B)..开头的语句
4.去掉以if(h->
param.analyse.b_psnr)...开头计算PSNR的语句
5.将以for(i_list=0;
i_list<
(h->
sh.i_type==SLICE_TYPE_B?
2:
1);
i_list++)的循环去掉,因为不使用P帧只执行一次,不需循环
但需加入i_list=0;
置初值
6将#ifdef_BS_H
#warningFIXMEMultipleinclusionofbs.h
#else
#define_BS_H
改为:
#ifndef_BS_H
7.analyse_en.c中的x264_mb_analyse_b_rd(),refine_bidir()函数去掉
8.去掉cavlc_en.c中的uint8_tmb_type_b_to_golomb[3][9]和
sub_mb_type_b_to_golomb[13]数组
9.去掉common.c中的parse_enum(),parse_cqm(),atobool()函数
希望:
将encoder_en.c中的if(h->
param.rc.psz_stat_out)
h->
param.rc.psz_stat_out=strdup(h->
param.rc.psz_stat_out);
这样就不需要自己定义的strdup函数了
2008-01-179:
48
1.去掉encoder_en.c的x264_encoder_encode()函数中的两个没有用到的变
量:
i_mb_i和i_mb_p(在CCS编译时的警告提示这两个变量定义但未被使用,
其它有类似的警告也可以考虑去掉)
2.去掉frame.c中的x264_frame_new()函数中的以fail:
标号开头的三句话(在程序中
不会调用)
去掉macroblock.c中的x264_macroblock_cache_init()函数中的以fail:
标号开头
的两句话
3.pridect.c中的UNUNSED变量该如何处理?
(CCS中警告说没有使用,但直接删除在VC
下会报错!
)
4.去掉所有以#ifdefHAVE_MMXEXT...#endif的语句
5.去掉ratecontrol_en.c中的parse_zones相关的三处代码
6.去掉encoder_en.c中的x264_encoder_close()函数中的
x264_ratecontrol_summary(h)函数及在ratecontrol.c中的相应代码(因为在这个
函数中调用了if(rc->
b_abr)...;
7.去掉ratecontrol_en.c中的与rate_estimate_qscale()和get_diff_limited_q()
有关的函数
8.去掉x264.c中的strtable_lookup()函数,与/*updatestatusline(upto1000
timesperinputfile)*/有关的语句
*******************
1.考虑将ratecontrol_en.h中的声明的函数在程序中被使用的地方全部替换!
即删
掉ratecontrol_en.c文件,不使用码率控制
2.去掉以rc->
b_abr,b->
2pass判断的语句
2008-01-1719:
53
1.去掉ratecontrol_en.c中的get_qscale()和clip_qscale()函数
2.去掉encoder_en.c中的关于x264_psnr()的宏及调用它的函数(不计算信噪比)
ratecontrol_en.c中的调用:
1.
Searchingfor'
x264_ratecontrol_start'
...
F:
\H.264\youhua\x264Vc\encoder_en.c(1350):
x264_ratecontrol_start(h,
i_slice_type,h->
fenc->
i_qpplus1);
2.Searchingfor'
x264_ratecontrol_new'
\H.264\youhua\x264Vc\encoder_en.c(617):
if(x264_ratecontrol_new(h
)<
0)
3.Searchingfor'
x264_ratecontrol_delete'
\H.264\youhua\x264Vc\encoder_en.c(1842):
x264_ratecontrol_delete(h
);
4.Searchingfor'
x264_ratecontrol_threads_start'
\H.264\youhua\x264Vc\encoder_en.c(1124):
x264_ratecontrol_threads_start(h);
\H.264\youhua\x264Vc\encoder_en.c(1148):
5.Searchingfor'
x264_ratecontrol_slice_type'
\H.264\youhua\x264Vc\slicetype_decision_en.c(381):
x264_ratecontrol_slice_type(h,h->
frames.next[i]->
i_frame);
(已经被去掉)2008-01-1720:
37
6.Searchingfor'
x264_ratecontrol_mb'
\H.264\youhua\x264Vc\encoder_en.c(1074):
x264_ratecontrol_mb(h,bs_pos(&
h->
out.bs)-mb_spos);
7.earchingfor'
x264_ratecontrol_qp'
\H.264\youhua\x264Vc\analyse_en.c(1950):
x264_mb_analyse_init(h,
analysis,x264_ratecontrol_qp(h));
\H.264\youhua\x264Vc\encoder_en.c(1351):
i_global_qp=
x264_ratecontrol_qp(h);
8.Searchingfor'
x264_ratecontrol_end'
\H.264\youhua\x264Vc\encoder_en.c(1541):
x264_ratecontrol_end(h,
i_frame_size*8);
2008-01-199:
17
1.修改x264.c中的Encode_frame()和Encode()函数,修改原来程序中的编码一帧,写
一帧到输出文件为编码所有的帧完成后再一次写入到输出文件中
(此处给存放输出文件的缓冲只分配了1M大小)
2008-01-2017:
23
1.在编译选项中添加-k,-mw,可以生成反馈文件信息(.asm)
2008-01-2220:
修改X264.C中的main函数,
为输入的文件分配一个缓冲,p_readYUV,5M大小.
先将YUV文件读入到这个缓冲中,然后在编码时每次读取YU的V分量只需要使用MEMCPY
从内存中复制对应的数据即可.
两天时间,终于快解决这个输入缓冲的问题!
这样做仍然在CCS中仍然是将PC上的YUV
文件通过USB口读取到EVM的SDRAM中,速度仍然很慢,今后要是
能使用网络传输应该会快很多,但现在主要是作优化,只要与PC通信的这块能够不占
入编码时间就很好了.
主要代码如下:
/*raw420yuvfileoperation*/
intopen_file_yuv(char*psz_filename,hnd_t*p_handle,x264_param_t
*p_param)
{....
//获得文件的长度
fseek(h->
fh,0,SEEK_END);
i_file_length=ftell(h->
fh);
fh,0,SEEK_SET);
//读取YUV文件
fread(p_readYUV,1,i_file_length,h->
...
}
intread_frame_yuv(x264_picture_t*p_pic,hnd_thandle,inti_frame)
{
yuv_input_t*h=handle;
/*if(i_frame!
=h->
next_frame)
if(fseek(h->
fh,(uint64_t)i_frame*h->
width*h->
height*3/
2,SEEK_SET))
return-1;
*/
/*
if(fread(p_pic->
img.plane[0],1,h->
height,
fh)<
=0
||fread(p_pic->
img.plane[1],1,h->
height/4,
img.plane[2],1,h->
=0)
//从内存中复制数据
memcpy(p_pic->
img.plane[0],p_readYUVBuffer,h->
width*
height);
img.plane[1],p_readYUVBuffer+h->
width*h
->
height,h->
height/4);
img.plane[2],p_readYUVBuffer+h->
height+h->
height/4,h->
p_readYUVBuffer=p_readYUVBuffer+h->
height+h
height/4+h->
height/4;
next_frame=i_frame+1;
return0;
在CCS中的char换成uint8_t
2008-01-2315:
29
修改DSP/BIOS,将BIOS的对象分配到IRAM中,将BIOS需要的STACK分配在DDR2FORHEAP
中,
1.此时在p_readYUVBuffer=x264_malloc(0x500000);
分配5M的输入缓冲时占了较长
时间(估计有10分钟了)
修改COMMON.C中的X264_malloc,将buf=(uint8_t*)malloc(i_size+15+
sizeof(void**)+
sizeof(int));
改成:
buf=(uint8_t*)MEM_calloc(DDR2forHeap,i_size+15+
sizeof(int),0);
(使用DSP/BIOS提供的MEM分配函数)
2008-01-2421:
1.下午将fread从CCS中读到的数据,用CCS的DATA->
SAVE把对应的foreman01.yuv文件
保存为DATA格式的foreman01.dat,以后要作测试时,直接使用
DATA-->
LOAD将其导入到SRAM中即可
2.调试时出现问题:
在编码第一帧后又返回到了主函数,这样一直在重复编码一帧!
不
知道是不是因为将main()和smain()函数放在同一个x264.c文件里面的
缘故?
是不是main()函数必须单独作一个文件?
在log_printf.pjt工程里证明不是因为必须在一个文件里的问题
3.以上出现程序跑飞的原因可能是因为TSK0的任务堆栈太小(默认是1024),在
DSP/BIOS里改成了(10000)
4.是在encoder_en.c中的x264_slice_write函数中又跑到主函数中去的
可能是因为文件操作的原因?
2008-02-2015:
47
关于用CCS的DATA->
SAVE把对应的foreman01.yuv文件保存为DATA格式的
foreman01.dat,以后要作测试时,直接使用
LOAD将其导入到SRAM中,在CCS中使用VIEW-MEMORY查看内存中的数的读的方
法:
如DAT文件如下
1651185000010011fb80
0xFFC9280A
0xFEFEFEF7
0xFEFEFEFE
0xE9FEFFFD
..........
在SRAM中0x85000010存放第一个数0xFFC9280A,第二个数的0xFEFEFEF7的地址为
0x85000010+4*(2-1)=0x85000014,
第12个数0xE9FEFFFD的地址为0x85000010+4*(C-1)=0x8500003C;
最后一个数(第1178496个数)的地址为0x85000010+4*(11fb80-1)=0x8547ee0c;
(1178496转换为十六进制为0x11fb80);
即第n个数的存放地址为0x85000010+4*(n(十六进制)-1);
2008-02-2210:
21
将所有的fseek换成lseek(
s=xhtml&
boardid=20&
id=118797)
仍不能解决问题!
2008-02-2215:
07
1.尝试方法:
恢复1.17号的X264.C文件,即还是采用fopen,fread,从PC上读一帧编码
后再从PC上读另一帧,看是否正常
使用DATA-LOAD的备份文件为:
复件(4)x264.c
在使用DATA-LOAD的程序中似乎可以不需要open_file_yuv..
使用类似的程序在VC下可以正常编码..
2008-02-2221:
问题得到解决:
将ccs中的macroblock.c用F:
\H.264\youhua\x264Vc目录下的
macroblock.c文件替换,就可以正常编码了
可见当时对这两个文件没有同步更新!
导致一个跨越年度的错误!
但生成的文件有800多kb,
2008-02-2516:
27
将DSP/BIOS中的MEM重新分配,使p_writeBuffer与p_readBuffer不指向同一块内存,
生成的文件大为缩小,只有132KB,
但是编码30帧的速度仍然需时近5分钟
2008-02-2619:
56
使用BUILDOPTION:
-g-k-o3-fr"
$(Proj_dir)\Debug"
-d"
_DEBUG"
__X264__"
-mw-mv6400+--
mem_model:
data=far
速度30帧大约需要1分钟
对于fps的计算仍未清楚,clock()两次运行同样的程序得到的时间竟然不同!
2008-02-2721:
20
仍然在研究使用何种方法来获得程序运行的时间,
clock()只有用load6x()时才较准确,
CLK_getltime()是推荐的用法,不过要引入中断
新建一个工作(在F:
\DSP\CCS\CLK)专门用来测试CLK_getltime()的用法,发现:
1.只有用timer0时,定时器中断才能进入,
2.使用Profile菜单中的clock->
view看时钟时,根据DSP/BIOS中的CLKmanager中的
Specifyinputclockrate来,得到的clock不同,
默认这项是选中的,27MHZ时得到的cycle数比不选中时(594MHZ)时少的多,这可能也
是采用clock()不准确的原因
2008-02-289:
05
跟昨天一样的程序,同样的DSP/BIOS配置,昨天可以用CLK_getltime()获取时间,今天
为什么就返回的是0了?
?
1.将dsp264_3.pjt的DSP/BIOS的CLKmanager中选中为timer0
在x264.c的encode函数中将计算fps,需获得开始时间改为:
i_start=CLK_getltime();
i_end=CLK_getltime();
调试程序时测得i_start=15,i_end=55462(单位ms),
fps=31(帧)/i_end-i_start=0.56(帧/秒)与实际观测相近
2008-02-2819:
00
1.删除mdate.c及相关的X264_mdate()宏,使用CLK_getltime()获取时间
(删除common.h中的int64_tx264_mdate(void);
encoder_en.c中的#defineTIMER_START(d)\...宏,和encoder_en.c中的调用了
TIMER_START()和TIMER_STOP的宏的行(这在VC上可以成功))
2.变量存储类型调整:
在VC中long和int都是定义成32位,(见MSDN)而在CCS中long定
义成40位,因此将CCS中的long换成int
在VC中同步更新
4.去掉if__x264__..else语句
5.在x264.c中的encode函数中加入doublefp
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 关于 x264 笔记 整理