『漫游』酷论坛>『影音数码技术学习交流』>『[V9RMVB] 动画压制交流论坛』>Helix Producer Plus的新EHQ ..

Helix Producer Plus的新EHQ Mode使用小结

bosch@2003-06-15 20:43

搜新网的压缩包中写有：

这个升级包能把你的 Helix Producer 9 中的 RealVideo 9.0
编码器升级到最新的 v6.0.7.2646 , 由此也新增加了一个被
称作为 EHQ 的压缩技术，据称能提高编码后的 RMVB 的清晰度。

如果你想反安装，把 BAK 目录下面的两个 DLL 文件覆盖回
codecs 目录即可。

如果想调节 EHQ 的“质量”，请自行改变注册表：

"encoderComplexity"=dword:00000050

这里后面那个 50 的值，注意是 16 进制的， 50就表示质量是“80”

---------------------------------------

我的pc安装后，注册表中没有增加项目，手动执行了“C:\Program Files\Real\Helix Producer Plus\codecs\ehq” 目录中的添加注册表项目后出现了。
安装后，在helix producer plus 中自动使用EHQ。

encoderComplexity默认值 50H （H是16进制的意思，50H＝十进制的80） ，这个在 注册表的项目中用括号写了。英文的说明，我没有找到，因pc一直在压片和ed中，也没有在real的网站看看。自己测试了几个参数，20H 50H 80H。

体会是： 20H压片速度好快，质量差了吗？（我没有仔细看出来，用的是 攻克 15的 op），50H的速度正常，和不使用EHQ前一致。80H明显慢了太多了，我也没有看出来画质的问题。 OP的动作太多，文件的动态采样率都很大，设置为 500-1000KBPs，压出的op 都在 836 -850KBPs之间，很接近源片了。

把encoderComplexity的值修改为 64H （100），总感觉压缩计算时，0-100才是参数范围（没有源程序，不知道具体范围多少）。 耐心的压缩了攻克15，1pass 500-1000KBPs ，用的时间是不使用EHQ的3倍，和我先前压的攻克15（1pass 520-1000KBPS），相比，文件增加了近3个MB。

二个攻克 15 我都会放ed，感兴趣的可以下载了看看，比较画质（我的色彩识别能力差点，毕竟不是学美术的，是学工科的，对色彩这东西无研究）

搜索关键词 bosch stand alone ，使用了 ehq的 带有 EHQ 字样
引用

caoxiao@2003-06-15 21:20

汗, 搜新网的压缩包中有英文的说明，下面是全文

//-----------------------------------------------------------------

这个升级包能把你的 Helix Producer 9 中的 RealVideo 9.0
编码器升级到最新的 v6.0.7.2646 , 由此也新增加了一个被
称作为 EHQ 的压缩技术，据称能提高编码后的 RMVB 的清晰度。

如果你想反安装，把 BAK 目录下面的两个 DLL 文件覆盖回
codecs 目录即可。

如果想调节 EHQ 的“质量”，请自行改变注册表：

"encoderComplexity"=dword:00000050

这里后面那个 50 的值，注意是 16 进制的， 50就表示质量是“80”

其它就自己看 E 文吧。

2003.6.13 souxin.com wcx








以下是相关的介绍：

The Helix Producer 9.2 June 4th build includes an EHQ mode that I am quite happy with [hopefully everything else is okay, because I have only been testing the codec, and have not tested that exact Producer build too much].

For certain content a quality improvement corresponding to a 30% bitrate reduction can be seen, and this is with a fully backwards compatible bitstream. On average though, and for very high bitrate content, it will be less, but for my current test encodings I can reduce the number of bits/pixel quite significantly, and have the result still look very pleasing.

It will be very interesting to get some feedback. Remember though, every improvement is incremental, and it takes some time to adjust to the new mode. For instance, if you previously used such a high bitrate relative to resolution, that no compression artifacts could be seen, using the same bitrate now, you will still see no visual degradation. The improvement then would have been that you could have gotten away with a lower bitrate and still have seen no problems. I know you will ask if it can be made faster, and the answer is that every CPU cycle is spent trying to find more optimal compression parameters, and every CPU intensive function is fully MMX/SSE/SSE2 optimized. I would rather have my computer's 2.4 GHz P4 do that instead of searching for aliens in its free time

Will the improvement be worth the slower encoding speed? Well, certainly for me it will, but if your CPU is on the slow side, it may be too much. I have used it enough now to see the improved visual quality. I can now lower the bitrate more without seeing "stuff going on" both in the background and around edges. Of course, being the implementor, it is not possible to get more biased, but I am very happy with the result.

As you may know, PSNR measurements are the most commonly used indication of compression efficiency for video codecs. Compared with for instance VSS H.264 codec in its best quality mode, RV9-EHQ has higher compression efficiency, and encodes 25X faster. I may post a couple of these PSNR charts.

Enabling RV9-EHQ

Audience/job file:

Include the following in the section of the audience:


code:--------------------------------------------------------------------------------

80
16000

--------------------------------------------------------------------------------


encoderComplexity sets the EHQ level:

65 = Default : improved efficiency for high action
70 = High : same as 65 + better mode decisions, better representation of high motion
80 = Extra High: same as 70 + best possible mode decisions, very high accuracy motion representation

(50 = Fast : not recommended, use only for Live capture encoding)

as you can see, there is some improvement even for the default mode.
The customPacketSize parameter increases compression efficiency for high action. Note that streams compressed with the customPacketSize parameter set to 16000 are not recommended for Internet streaming. This parameter will be default for VBR over a certain bitrate, but is needed for now.

Encoding times:

(65) same encoding time as before
(70) will take about 2X - 2.5X encoding time compared to default
(80) about 3X - 4X default


Registry over-rides

--->8---

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\RealNetworks\RV9]
"encoderComplexity"=dword:00000050
"customPacketSize"=dword:00003e80

--->8---

[copy and paste this to a new file, save as rv9enc.reg, double-click to enter in registry. Please remember that you have these these keys, otherwise the audience file settings will have no effect. These keys may change in the future]

These settings can be used after replacing the encoder DLL in the GUI Helix Producer, and any other tool which does not have the EHQ setting. Note that the encoder DLL needs to be replaced in all cases...

IMPORTANT: These values are in HEX so 0x50 = 80 decimal, and 0x3e80 = 16000 decimal. Remember to click the Decimal checkbox when entering new values in the registry editor.

//-----------------------------------------------------------------

压缩率只有4档，分别是
50, 65,70和80, 个人认为设为65比较实用。但对大动态画面改良的效果我还未看出来。
引用

bosch@2003-06-15 21:30

呵呵，不好意思，没有看到，晕～～。

这个代码对 MMX/SSE/SSE2 进行了优化，没有对超线程进行优化，呵呵。（这意味着 intel 和amd的cpu在压缩方面一致，amd的同样支持sse，mmx，intel 的 C系列 cpu浪费钱了）
引用

caoxiao@2003-06-15 21:57

另外，搜新网的安装包好像少了文件， 下面是setup.bat的全文：

//-----------------------------------
@echo off
cd ..
md bak
copy rv403260.dll bak
copy erv43260.dll bak
cd ehq
copy rv403260.dll .. /y
regedit /s rv9-ehq-souxin.com.reg
//-----------------------------------

应该还有个新的 erv43260.dll ， 不知为什么没copy进来？？？
引用

littleyizhi@2003-06-15 22:46

doom9上就是这么写的，他也是照抄而已，
还是用完整的命令行的版本吧
引用

Arbiter@2003-06-15 23:20

引用
最初由 bosch 发布
呵呵，不好意思，没有看到，晕～～。

这个代码对 MMX/SSE/SSE2 进行了优化，没有对超线程进行优化，呵呵。（这意味着 intel 和amd的cpu在压缩方面一致，amd的同样支持sse，mmx，intel 的 C系列 cpu浪费钱了）


AMD 的 CPU 不支持 SSE2 啊,而且 C 系列的极大的内存带宽应该能起不少作用吧.
引用

kewen05110792@2003-06-16 01:37

谢谢,我已经安装好了,现在就压缩看一看
引用

bosch@2003-06-16 11:25

新的 erv43260.dll 在 C:\Program Files\Real\Helix Producer Plus\codecs\ehq，输入注册表后，默认的启动了。不信可以压片看看。（不用命令行的方式也可以的，至少我没有用）

AMd cpu是不支持 SSE2，但是它有自己的 3Dnow ，3dnow！ 技术。

intel的C系列 800外频，内存带宽很大， 但只是双通道的 DDR400而已，不是什么新的技术。amd的主板，NF2系列在 2002 年就支持 双通道的 DDR400 了，实用效果也好。
引用

伊寒@2003-06-17 23:53

惨。。
偶就是P4 2.4C。。。
用EHQ 65看起来感觉是细腻了一些~
速度倒是没什么差别
引用

lfwine@2003-06-18 00:41

好象没什么变化~~~~~~~~~~
引用

fyxin@2003-06-18 14:37

我装了后用real压缩器压了两集动画，好像速度跟没装是差不多，每集动画都是在一个小时内压完，并且是用two pass。
我用的是80这个参数。
出来的结果是
一集动画原压缩大小为：75.9M 现压缩大小为：74.2M
一集动画原压缩大小为：73.0M 现压缩大小为：72.3M
我没装成功吗？还是real压缩器不支持EHQ？
引用

fyxin@2003-06-18 14:45

再加一点，我用的是P4 2.0A的CPU，64M的显卡。
现准备再压那部夜叉犬1.4G的OVA测一下。
引用

Kidd@2003-06-18 16:25

我们是不是可以认为EHQ是V9编码器的脱胎换骨呢，而不仅仅是意义上的优化

看了下EHQ level：
50：快速编码
65：默认
70：高质量
80：最高质量
(这里的50、65、70、80为十六进制)
按照一般的逻辑，质量用的越高，自然所消耗的时间也就越多

看到这里，我就想到了在EAC里外挂MAC作APE
同样也是几个模式
所不同的只是，在EAC里面是选模式，而在这里我们是通过改动注册表来实现
而我又认为，编码就这么几个档，应该不是楼主所认为的0-100(是十进制吧)才是参数范围的

以上

想来楼主所用的64H其实也不过是Default吧(笑)
引用
| TOP