『漫游』酷论坛>『影音数码技术学习交流』>部分H.264解码器速度相 ..

部分H.264解码器速度相关测试(9楼、34楼 更新)

upyzl@2011-07-29 09:24

9楼、34楼 更新(右上有楼层直达)

似乎有些人在坐等这个评测,既然弄了,也没啥独享的必要,就放出来下。

环境:
E5200(默频2.5GHz)
9600GSO(G92 384MB 192bit / 驱动275.33 / 默频)
Win 7 x64 SP1(安装DirectX Redist 2010.6)

工具:
GraphStudio 0.3.2.0 32bit
GraphStudio 0.3.1.0 64bit
DXVA Checker 2.5.0 32bit
注:使用GraphStudio测试时,CPU是通过任务管理器的CPU Usage和CPU Usage History得来的数据。
所有测试都不渲染图像

样片:
Clip HP(哈利波特7  Part1 TWiZTED BDrip 1280x536 截取15:30~16:30 均码5500kbps)
Clip Air(TV 10 uguu~ BDrip 1920x1080 截取6:00~7:00 均码2900kbps)

结果:

DecoderClip HP (7A 15:30~16:30)Clip Air (10 6:00~7:00)
123AvgCPU123AvgCPU
FFDshow r3949 x64
clsid MSVC2010
175.8991 175.9973 176.5623 176.1529 99%91.9021 91.6327 91.8859 91.8069 89%
FFDshow r3949 x86
clsid MSVC2010
176.5986 178.3660 178.1356 177.7001 98%96.4209 96.6743 96.7737 96.6230 89%
FFDshow r3949 x86
xvidvideo ICL12
182.0981 183.0330 182.9451 182.6921 97%97.6270 96.0647 97.8474 97.1797 89%
FFDshow r3949 x86
xvidvideo ICL12 DXVA
128.3970 128.5200 128.3990 128.4387 4%47.7970 47.7080 47.7090 47.7380 2%
CoreAVC 2.5.5 x64185.0371 187.6385 186.2121 186.2959 95%103.7265 103.8780 104.0836 103.8960 93%
CoreAVC 2.5.5 x86186.4933 187.4608 186.7922 186.9154 94%105.8563 106.4466 106.1848 106.1626 92%
CoreAVC 2.5.5 x86 DXVA128.9340 128.8820 128.8740 128.8967 9%47.8300 47.7800 47.7820 47.7973 5%
CoreAVC 2.5.5 x86 CUDA123.6191 124.9794 124.9830 124.5272 16%43.7240 43.8329 43.8459 43.8009 10%
LAV CUVID 0.9 x64126.5316 127.9815 127.9428 127.4853 14%47.6258 47.7467 47.7651 47.7125 12%
LAV CUVID 0.9 x86126.2190 128.1213 128.1332 127.4912 10%47.6234 47.7589 47.7669 47.7164 9%
Microsoft DTV-DVD
Video Decoder x86 DXVA
129.1860 129.1980 129.1950 129.1930 13%47.9390 47.9310 47.9360 47.9353 6%
DiAVC x64 Free 1.2211.9292213.6046213.0770212.8703100%121.4670122.0561121.5459121.689799%

注:Cyberlink的没法测,有哪位知道方法请具体告知。
另外,本测试不涉及花屏、seek这些方面


总结啥的我就不写什么了,应该是一目了然了;要说有什么说的,就是libavcodec的发展实在是强大,前阵子支持多线程从而彻底取代了ffmpeg-mt,解码速率也出乎意料——差不多四个月前我比较过CoreAVC 2.5.1和当时最新的FFDshow(ffmpeg-mt),前者快了35%~55%,而现在前者领先幅度小于10%;还有,x64发展了这么久在视频解码领域居然还是比不上x86啊……
另外我不太清楚这些硬解结果是否正常……






[ 此帖被upyzl在2011-08-06 10:18重新编辑 ]
引用

ljwing@2011-07-30 19:49

DiAVC 出1.2版了
引用

06_taro@2011-07-31 09:26

为啥FFD的DXVA用icl12版,软解测试用MSVC版……
引用

upyzl@2011-07-31 21:52

更新DiAVC,由于测试时进程什么的可能跟之前不是完全相同(虽然我印象中开的东西应该是一样的),所以也许会有些许误差,不过仅从速度上看,DiAVC的优势毫无疑问是很明显的

引用
引用第1楼ljwing于2011-07-30 19:49发表的  :
DiAVC 出1.2版了


感谢提醒,这两天旅游去了

引用
引用第2楼06_taro于2011-07-31 09:26发表的  :
为啥FFD的DXVA用icl12版,软解测试用MSVC版……


请塔罗大看清,软解同样有icl12版的

引用

06_taro@2011-07-31 23:45

哦我眼殘了……
引用

upyzl@2011-08-01 06:48

忘记说明一点了,关于解码器的设置

FFDshow: 默认
CoreAVC: 默认(也就是测DXVA/CUDA时需要改变下硬件加速那块)
DiAVC: Drop non-reference frames when hard 这项取消(GraphStudio的测试原理应该是解码所有的帧,再除以时间得来的fps结果,所以我认为这项必须取消)
LAV CUVID: 默认
MS的那个应该改都改不了吧……反正我没改,所以算默认

----

两个视频的编码参数我还是贴出来好了(整个视频的,非clip)

HP的
Writing library                  : x264 core 114 r1924 08d04a4
Encoding settings                : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x133 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=1 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=4915 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00

Air的
Writing library                  : x264 core 96 r1602 69588a7
Encoding settings                : cabac=1 / ref=4 / deblock=1:1:1 / analyse=0x3:0x113 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
[ 此帖被upyzl在2011-08-01 07:36重新编辑 ]
引用

roozhou@2011-08-01 19:00

为什么拿来测试的码率这么低?
引用

upyzl@2011-08-01 23:22

引用
引用第6楼roozhou于2011-08-01 19:00发表的  :
为什么拿来测试的码率这么低?


这我之前倒是没意识到……
当时也就是拿现成的跑测试了

之后我再加一段高码率的测试看下
引用

回 7楼(upyzl) 的帖子

nuomi1@2011-08-02 00:18

我垃圾CPU+更垃圾GPU,ffmpeg-mt解碼(完美者解碼20110603),低碼率確實沒有很大的說服力(不說沒有,還是有一定的說服力,最近不少“高壓”產物),上高碼率之後可以看得出。
我這高碼率(也就4000k多的“高”)的1080p用ffmpeg-mt解碼吃力了,CoreAVC不吃力不過RP花屏
歸根到底還是垃圾CPU+更垃圾GPU。
引用

upyzl@2011-08-02 08:30

增加一个样片测试

FF13高清中文电影(天幻)v2 Part B
我用x264 (r2044) --crf 12 --level 4.1 --vbv-maxrate 40000 --vbv-bufsize 30000压了一段,均码20.5Mbps
视频分辨率1280x720

由于不好排版,我直接提供Excel文件下载好了(已转成xls, 只要有office软件就能看),反正还不到8KB;顺便另外2个sheet是附送的

http://dl.dbank.com/c063pnqbqx

需要说明的是,跑ffdshow x64总是0fps(所以我写Error),不知道哪里出问题了

果然硬解需要高码率才有优势



[ 此帖被upyzl在2011-08-02 08:41重新编辑 ]
引用

roozhou@2011-08-02 18:48

怎么不用BD-remux的流测试呢?
引用

upyzl@2011-08-02 20:19

引用
引用第10楼roozhou于2011-08-02 18:48发表的  :
怎么不用BD-remux的流测试呢?


见到的下载速度都太慢了,再加上BD Remux本来就很大,故放弃……
引用

mawen1250@2011-08-03 12:12

用2160p鸭子测试吧……
引用

upyzl@2011-08-03 14:41

引用
引用第12楼mawen1250于2011-08-03 12:12发表的  :
用2160p鸭子测试吧……


不说我倒还忘了,两年前多下过这个视频,可惜又找不到了
我看看现在还能不能找到下下来
引用

upyzl@2011-08-03 19:33

引用
引用第12楼mawen1250于2011-08-03 12:12发表的  :
用2160p鸭子测试吧……


看样子可能是资源太久远了,网上找到的都没速度啊……
引用

«1234»共4页

| TOP