此合成程序是指的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<事件同步>的函数。具体细看等明天吧。今天暂时这样。