ffmpeg与新合成程序效率对比测试

此合成程序是指的CUDA5.0所带的encoder与decoder两个软编和软解的样例代码进行合成为一个，直接把MPEG2文件转换成H264文件<原来的样例代码，编码是把yuv文件压缩成h264文件，解码是把mpeg2文件解压缩成yuv文件>

找到了合成的程序崩溃原因，是new了一个新的数组以后，没有及时的delete，当数据量增大以后，由于循环调用，引起了内存分配不足，从而程序崩溃。

解决方法：代码之前，用到内存拷贝时再new,拷贝完后紧接着delete,这样就解决了问题。

测试了三组视频，

这是周五测试的那次，有所补充和修改，其中Linux码率：200kb/s,  windows 码率4000kb/s, 结果如下：

测试项	平台	原始文件大小 <.m2v>	生成文件大小 <.h264>	编解码所用时间 <s>	H264视频 帧数	H264视频播放帧率 <fps>	理论播放时长 <s>	播放时长 <m,s>	加速比 <播放时长 /编解码时 长>
样例视频 plush1_720p_10s.m2v <播放时长：10s 帧数： 330帧>	Linux ffmpeg	13.6M	1.23M	14.24s	330 <I:2 P: 86 B:242>	30	11s	11s	0.77s
	Windows 合成程序	13.6M	5.39M	28.6s	326	29.97	10.88s	9s	0.315
Fsen给的视频 Fsen.m2v <播放时长：27s 帧数： 695帧>	Linux ffmpeg	4.82M	6.21M	33.201S	695 <I: 9 P:686>	25	27.8s	27S	0.813
	Windows 合成程序	4.82Ms	11.8M	76.559S	692	29.97	23.09	19S	0.248
geeks.m2v <播放时长：3540s 帧数： 88199帧>	Linux ffmpeg	386M	513.4M	67m35s 即： 4055s	88199	25	3527.92s	75m22s 即： 4522s	1.1
	Windows 合成程序	386M	1.37G	9151.87s	88196	29.97	2942.81s	39m53s 即：2393s	0.26

 

之所以文件大小不一样是因为比特率设置的不同，ffmpeg命令中如果不设置比特率，那么默认的是200kb/s,而windows编解码合成程序里面配置文件里设置的比特率是4000kb/s。

先说一下比特率，比特率即码率，表示的是数据传输过程中单位时间传送的数据位数，常用的单位就是kbps，千位每秒。码率越大，表示精度越高，处理的文件感觉图像质量会越好点。但是码率与文件体积成正比，就是码率越大，处理后的图像占用空间越多，我们往往追求的是最少的码率表现最丰富的画面。

找到这个原因以后，第二次做的测试是在Linux下面把码率设置成4000kb/s看一下得到的文件数据。数据如下：

 

测试项	平台	原始文件大小 <.m2v>	生成文件大小 <.h264>	H264视频 帧数	H264视频播放帧率 <fps>	理论播放时长 <s>	播放时长 <m,s>	编解码所用时间 <s>	加速比 <播放时长 /编解码时 长>
样例视频 plush1_720p_10s.m2v <播放时长：10s 帧数： 330帧>	Linux ffmpeg	13.6M	5.44M	330 <I:2 P: 86 B:242>	30	11s	10s	14.24s	0.70
	Windows 合成程序	13.6M	5.42M	326	29.97	18.88s	9s	28.6s	0.315
Fsen给的视频 Fsen.m2v <播放时长：27s 帧数： 695帧>	Linux ffmpeg	4.82M	12.9M	695 <I: 9 P:686>	25	27.8s	32s <confused!!实际:24s >	33.201S
	Windows 合成程序	4.82Ms	11.8M	692	29.97	23.09	19S	76.559S	0.248
geeks.m2v <播放时长：3540s 帧数： 88199帧>	Linux ffmpeg	386M	1.6G	88199	25	3527.92s	3933s	67m35s 即： 4055s	0.97
	Windows 合成程序	386M	1.37G	88196	29.97	2942.81s	39m53s 即：2393s	9151.87s	0.26

 

 

 

 

然后第三次测试是又把windows程序里面配置文件的码率改成200kb/s与之前Linux一个标准

测试项	平台	原始文件大小 <.m2v>	生成文件大小 <.h264>	H264视频 帧数	H264视频播放帧率 <fps>	理论播放时长 <s>	播放时长 <m,s>	编解码所用时间 <s>	加速比 <播放时长 /编解码时 长>
样例视频 plush1_720p_10s.m2v <播放时长：10s 帧数： 330帧>	Linux ffmpeg	13.6M	1.23M	14.24s	330 <I:2 P: 86 B:242>	30	11s	11s	0.77s
	Windows 合成程序	13.6M	2.24M	326	29.97	10.88s	3s <confused!!实际：10s>	28.6s
Fsen给的视频 Fsen.m2v <播放时长：27s 帧数： 695帧>	Linux ffmpeg	4.82M	6.21M	33.201S	695 <I: 9 P:686>	25	27.8s	27S	0.813
	Windows 合成程序	4.82Ms	5.98M	692	29.97	23.09	10s <confused!!!实际：24s>	76.559S
geeks.m2v <播放时长：3540s 帧数： 88199帧>	Linux ffmpeg	386M	513.4M	88199	25	3527.92s	4522s	67m35s 即： 4055s	1.1
	Windows 合成程序	386M	632M	88196	29.97	2942.81s	1061s <still confused!!>	9151.87s

 

Well, About that confused…….括号外数据是指用暴风影音打开播放时显示的播放长度，而括号内实际上的数据是指实际播放的长度，因此，加速比我也没有算，这个，我明天早会解释一下。

还有，通过profiler大致看了一下windows的那个程序，发现时间大部分是被驱动层的函数占用的，尤其是一个cuEventSynchronize<事件同步>的函数。具体细看等明天吧。今天暂时这样。