『漫游』酷论坛>『影音数码技术学习交流』>[测试]athrun_fantasy贴后 ..

[测试]athrun_fantasy贴后记，小测低码率rmvb/x264资源占用和编码效率

MeteorRain@2008-06-21 01:09

引用

athrun_fantasy 在 06-20-2008 15:51 谈到:

偶在帖子说了半天，就是说的低码下RMVB资源占用比X264少

现在给出测试数据。有问题的话请和我提。

注意，本次测试的rmvb压制参数为随意压制，没有经过反复推敲处理，码率曲线也没有很好地优化，可能会造成数据偏差。经某位朋友测试，在他电脑上跑下来rmvb和x264差距不大。因此有待进一步测试和讨论。

复制代码
  1. 一共压制了3份视频供测试
  2. 硬件环境: AthlonX2 3800+, 2G DDR, 690G
  3. 软件环境: vista u 64bit
  4. 源: kodomo no jikan dvd ncop vob，dgdecode，挂IVTC到24fps，加crop和bicubicresize，848*480
  5. 播放环境: 完美解码干净安装后，勾选所有的mpc内置滤镜。
  6. 资源消耗测试方法: 自资源管理器直接按下回车启动mpc播放器，随即最小化。mpc连续播放3遍，然后回退到最开始。记录此时的纯CPU时间。
  8. 编码环境:
  9. rmvb: DIORPG1.44 (32bit WOW64模拟环境)
  10. x264: x264 0.54.650 命令行+tee 导出日志 (32bit WOW64模拟环境)
  12. 文件大小和码率:
  13. rmvb: 7,733 KB 677.887 Kbit/s
  14. x264-q26: 8,177 KB 716.809 Kbit/s
  15. x264-q27: 7,466 KB 654.482 Kbit/s
  17. 编码参数:
  18. rmvb: 450K-10000K RV10 EHQ100
  19. x264-q26: qp26 ref 3 bframes 4 b-pyramid weightb analyse-all 8x8dct me-umh mixed-refs direct-spatial
  20. x264-q27: qp27 ref 3 bframes 4 b-pyramid weightb analyse-all 8x8dct me-umh mixed-refs direct-spatial
  22. 编码时间(AVS一线程，编码器一线程):
  23. rmvb: 21:34:07->21:39:06 299s, 2188frame, 7.32 fps
  24. x264-q26: 9.85 fps
  25. x264-q27: 10.24 fps
  27. 编码器测得PSNR:
  28. rmvb: 43.10
  29. x264-q26: 44.519
  30. x264-q27: 44.068
  32. avs-compare函数在yuy2下测得PSNR(directshowsource导入并同步帧后测试):
  33. rmvb: AVG 43.4979 OVALL 42.7426
  34. x264-q26: AVG 44.9041 OVALL 44.3567
  35. x264-q27: AVG 44.4037 OVALL 43.8462
  37. 播放3次CPU时间总计:
  38. rmvb: 0:01:35
  39. x264-q26: 0:00:56
  40. x264-q27: 0:00:55
引用

Fucklay@2008-06-21 01:16

沙发
引用

gundom@2008-06-21 01:16

哦哦 MR 辛苦了
果然还是 x264 稍胜一筹
引用

Fucklay@2008-06-21 01:17

抑制不住激动的心情，地板也占了吧
引用

tcyy@2008-06-21 01:17

MR真闲,机器真好~
引用

hhck@2008-06-21 02:04

于是数据也有了么.....
果然还是毫无悬念的众望所归的X264赞.....
引用

alphaa@2008-06-21 03:12

前排占位支持~
引用

chiman@2008-06-21 07:24

美。。。很美。。。
引用

athrun_fantasy@2008-06-21 13:23

既然是针对偶的测试，偶也来说两句

首先，这个测试完全是没有意义的

引用

编码环境:
rmvb: DIORPG1.44 (32bit WOW64模拟环境)
x264: x264 0.54.650 命令行+tee 导出日志 (32bit WOW64模拟环境)

DIORPG有新版本，在新版中更新了REAL编码内核

引用

文件大小和码率:
rmvb: 7,733 KB 677.887 Kbit/s
x264-q26: 8,177 KB 716.809 Kbit/s
x264-q27: 7,466 KB 654.482 Kbit/s

完全没意义，剪辑的BITRATE根本不能说明问题，值得提一下的是X264在文件大小以及画质上完胜RMVB是有事实依据的

引用

编码参数:
rmvb: 450K-10000K RV10 EHQ100
x264-q26: qp26 ref 3 bframes 4 b-pyramid weightb analyse-all 8x8dct me-umh mixed-refs direct-spatial
x264-q27: qp27 ref 3 bframes 4 b-pyramid weightb analyse-all 8x8dct me-umh mixed-refs direct-spatial

RMVB用的450-10000？最高码率有必要设置为那么高？1500足以

X264采用的是Q值，也就是固定量化值，但是实际上这个值也会跳，偶的实测，Q值31的情况下，在n—n+2的范围内波动

综上RMVB使用的是动态码率，而且码率可以无限扩张，REAL的编码器可以肆虐了...不过偶相信，它也是有度的，不过有时候，它也会失控的，最终码率抛开先不谈

X264采用的等同静态码率，虽然也在跳，但是绝对不会超过Q26或者Q27对应的码率，也就是变相的决定了，BITRATE不会超过某一阀值

拿类静态码率与动态码率比较？这是没意义的原因之一

引用

编码时间(AVS一线程，编码器一线程):
rmvb: 21:34:07->21:39:06 299s, 2188frame, 7.32 fps
x264-q26: 9.85 fps
x264-q27: 10.24 fps

略过，偶从来无视时间

引用

编码器测得PSNR:
rmvb: 43.10
x264-q26: 44.519
x264-q27: 44.068

略过，RMVB必败

引用

avs-compare函数在yuy2下测得PSNR(directshowsource导入并同步帧后测试):
rmvb: AVG 43.4979 OVALL 42.7426
x264-q26: AVG 44.9041 OVALL 44.3567
x264-q27: AVG 44.4037 OVALL 43.8462

同上面，略过

引用

播放3次CPU时间总计:
rmvb: 0:01:35
x264-q26: 0:00:56
x264-q27: 0:00:55

由于RMVB采用的是动态码率，偶不清楚MR使用的源的动态情况，如果动态比较大，RMVB码率自然就高，码率高了，解码消耗的CPU资源自然就多

再来看X264，Q值编码，无悬念的类静态码率，BITRATE可以说波动很小，并且不会超过某一阀值,后面的测试贴会说明这个带来的影响

以上是我对这篇测试的看法，下面是偶自己的测试数据

注意：此处的类静态码率一说完全是我把const quantizer(cq)与const quality(crf)弄混了,雷大发怒并非没有来由:(

下面说一下偶的理解：

cq是固定量化值模式，码率是根据帧的复杂度可变的，而且变化范围极大（能说无限么？偶不确定），也就是说，高动态高码，低动态低码

crf是固定质量模式,码率相对比较平稳（偶喜欢用这个，原因不明），与CQ相反，低动态高码，高动态低码，是相对的低码，有时候会跳的很高

注：CRF虽然说会尽量压平曲线，但是遇到该高的它依然会用高码率去压，这里的高动态低码有局限性，理解成尽量低码比较妥，
引用

athrun_fantasy@2008-06-21 13:28

硬件环境：略过，无任何硬件加速环境

软件环境：WIN XP

源：鲁鲁修R2第4话全篇

播放环境:MPC+FFDSHOW解码X264，MPC调用最新REALPLAYER内置解码器解码RMVB(去掉MPC所有内置滤镜)

资源消耗测试方法:同MR

编码环境:
rmvb: DIORPG1.45(REAL编码器比1.44的新)
x264: core:60,r886

文件大小和码率:
RMVB:77.4M,AVG:445K
X264-q31:64.9M,AVG:315K(此值为MEGUI计算器所得)

编码参数:
略过，只要出来的东西合格这个可以无视

编码时间(AVS一线程，编码器一线程):
略过，没的比

编码器测得PSNR:
同样略过，没的比

avs-compare函数在yuy2下测得PSNR(directshowsource导入并同步帧后测试):
同上略过，也没的比

播放N次CPU时间总计:

1.播放长度为1：31，有高动态情况下

rmvb:44（浮动范围2）
x264-q31:44（浮动范围2）

这里无法确定孰优孰劣，RMVB有低于X264的情况，X264同样也有低于RMVB的情况，可以肯定的是，高动态下，X264-Q31压过RMVB


2.播放长度为1：00，绝大部分静态场景

RMVB:17
X264-Q31：22

这里可以说RMVB完胜，不管如何有误差，不会超过5


注意：
这里的画质可以接受指的是从观看者的角度出发，部分瑕疵可以忽略的情况（就连火星人都知道，RMVB与X264比画质完全不具可比性，哪个更好？相信大家比偶清楚）

容量相近，指的是不要相差太大,而且这不是讨论的重点

本帖分析的重点是在从观看者的角度出发可以接受的画质下解码的CPU使用率，因此大家可以明白为什么我说了很多的略过，偶的理解解码是不需要编码参数的，虽然据MR所说，X264有几个编码参数会影响解码效率，不过此贴忽略这个问题，因为偶不了解哪些参数会影响解码效率,MR自己也说"这需要去翻译E文文档，一时说不上"(郁闷的是，偶讲了半天是观看者可以接受的前提下，居然只有一位老兄听明白偶的话)

偶的X264编码参数完全用的MR的参数，最后的Q31也是MR定的




最后说一下总结：

1.偶没心思参加这个测试，但是既然MR点名了，偶不冒出来说不过去

2.本人水平很有限，高手看了不要笑

3.此篇测试的CPU占用计算方法值得商榷

4.按照MR说的计算方法，偶的结论是，RMVB在低动态情况下的CPU使用要优于X264-Q31，而在高动态情况下，两者相当

5.为什么X264在高动态下与RMVB相当，甚至超过RMVB,而低动态下，RMVB要优于X264？因为X264的码率相对比较稳定，而RMVB，该低的低，该升的升，高动态一直是RMVB的软肋,但是看下来，哪些片子是全篇高动态的？
（此处有问题，因偶把QP与CRF的用法搞调包了，实际是X264跟RMVB同处于一种情况，高动态高码，低动态低码,不过那不是更能说明情况？高动态偶的测试结果表明两者相当，而低动态，RMVB比X264的CPU时间足足低5个点）

6.此贴所说的结论局限于本次测试的两个片子范围之内

7.本帖测试数据仅仅是从观看者的角度分析，并非技术贴，要比较解码效率，码率必须相同或者接近，而此贴的两个实例，AVG码率RMVB明显超过X264，如此看来，哪个解码更省资源大家有目共睹
引用

xtyz@2008-06-21 13:30

引用

完全没意义，剪辑的BITRATE根本不能说明问题，值得提一下的是X264在文件大小以及画质上完胜RMVB是有事实依据的


一段剪辑和全片差别有多大?对编码器还不是一样?
要说TV的一话 那是电视台一天所播放的M2TS流的剪辑（中途不停播的话可能是一月 一年 甚至N年的M2TS流中的一段剪辑) 要说DVD/BD,一话就是其中的一段剪辑.照你说都没意义?如果测试的本体拿来都不能说明问题,那要怎么说明问题？

引用

RMVB用的450-10000？最高码率有必要设置为那么高？1500足以

妹子(误很大,那是测试码率

引用

X264采用的是Q值，也就是固定量化值，但是实际上这个值也会跳，偶的实测，Q值31的情况下，在n—n+2的范围内波动

固定量化是P帧的 I小一点 B大一点很正常

引用

综上RMVB使用的是动态码率，而且码率可以无限扩张，REAL的编码器可以肆虐了...不过偶相信，它也是有度的，不过有时候，它也会失控的，最终码率抛开先不谈

RV 2pass就是无视Max Bitrate的-______,-

引用

X264采用的等同静态码率，虽然也在跳，但是绝对不会超过Q26或者Q27对应的码率，也就是变相的决定了，BITRATE不会超过某一阀值

Q对应的码率?Q本来就是无视码率的压制
应该去看某QYQ写的东西 前段时间Hack GU的剧场 码率随便爆到200M 平均QP还只有24的样子-____________,-
如果乃硬要说Q24最大码有200M我也不说啥
如果LS真认为每个Q值是有对应码率的 那可就贻笑大方了

引用

拿类静态码率与动态码率比较？这是没意义的原因之一

喝水

顺便补充 这段我之前也做过 x264 Q16裸压在3K的样子(太遥远了 具体数据记不清了 OP的话算省的了

记得某片Q16下能ED能爆到30Mbps=___=
引用

雷鸣@2008-06-21 14:06

引用
完全没意义，剪辑的BITRATE根本不能说明问题，值得提一下的是X264在文件大小以及画质上完胜RMVB是有事实依据的

bitrate不能说明问题，那么你想要什么？在无视bitrate和文件大小的情况下比较质量么
引用
RMVB用的450-10000？最高码率有必要设置为那么高？1500足以

若1500足以，那么设置成10000它也不会上10000，因为1500“足以”

引用
综上RMVB使用的是动态码率，而且码率可以无限扩张，REAL的编码器可以肆虐了...不过偶相信，它也是有度的，不过有时候，它也会失控的，最终码率抛开先不谈

码率抛开不谈？uncompress画质最好

引用
X264采用的等同静态码率，虽然也在跳，但是绝对不会超过Q26或者Q27对应的码率，也就是变相的决定了，BITRATE不会超过某一阀值

那啥……什么时候变成静态码率的

引用
拿类静态码率与动态码率比较？这是没意义的原因之一

话说哪个静态了来着？


引用
由于RMVB采用的是动态码率，偶不清楚MR使用的源的动态情况，如果动态比较大，RMVB码率自然就高，码率高了，解码消耗的CPU资源自然就多

再来看X264，Q值编码，无悬念的类静态码率，BITRATE可以说波动很小，并且不会超过某一阀值,后面的测试贴会说明这个带来的影响

很想说，“静你老〇”

引用
2.本人水平很有限，高手看了不要笑

水平有限就别在这里卖弄
笑的就是你！
引用

roozhou@2008-06-21 14:07

任何视频编码比较的前提是码率相同，也就是文件大小相同，否则没意义
还有解码速度你连什么解码器都不知道比出来的结果没有意义

关于解码速度，我做过测试是同样码率下KMP+drvc.dll解rmvb比KMP+CoreAVC 1.6解x264大概是2:3。
引用

dongjuanyong@2008-06-21 14:09

引用
最初由 athrun_fantasy 发布

播放环境:MPC+FFDSHOW解码X264，MPC调用最新REALPLAYER内置解码器解码RMVB


FFDSHOW……虽说x264官方推荐它，不过它解264的效率最差……coreavc才是最常用的
引用

chiman@2008-06-21 14:11

引用
quote:
编码时间(AVS一线程，编码器一线程):
rmvb: 21:34:07->21:39:06 299s, 2188frame, 7.32 fps
x264-q26: 9.85 fps
x264-q27: 10.24 fps

略过，偶从来无视时间


编码时间(AVS一线程，编码器一线程):
略过，没的比



R2都播到第十话，中间还休息了一周。。。lz的组才出到4。。。

敢情是因为压rmvb太费时间？难怪啊。。。



说起来昨天我过去lz论坛玩。。。又是重激活又是删id又是ban ip。。。

不是说“你要在偶的社区，偶同样可以让你受到这种待遇”么？

人都没有最后就劳动lz亲自来“待遇”我了啊。。。
引用

«12345»共11页

| TOP