『漫游』酷论坛>『影音数码技术学习交流』>部分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