又更新了 ^^;
（最近很频繁...）
Koepi's XviD-02122002-1.exe
http://www.roeder.goe.net/~koepi/
Changelog:
- Fresh CVS checkout
- bframe updates (mpeg + cust. quant matrices work)
- refdivx's lumi masking bugfixed (hopefully)
- sysKin's updated dynamic halfpel/quarterpel code is used.
- StatsReader updated to 2.0.
- 现在 B-frame 可以和使用者自订的 MPEG Quantization Matrix
一起使用（之前不行）。
- RefDivX 是一个人，他提供了一些 HVS 的适应性量化程序代码
加入到 adapt_quant.c 里面。
之前据说有画面上会产生白点的 bug，希望现在已经修正了。
打开 lumi masking 才会使用。
HVS（Human Visual System）
人类视觉系统，根据人类视觉的特性，建立模型，量化的时候根据这些特性，
将人眼较不敏感的区域压得差一点，将人眼较容易注意到的区域压得好一点，
可以提升肉眼看起来的品质。
- sysKin 也是一个人，是 XviD 目前使用的 ME 算法、动态 I/P/B Frame 决策
的设计者。他现在加入了动态 HPel/QPel 使用决策的设计，会先侦测画面边缘，
来判断画面是锐利的还是平滑的，锐利的画面才使用 Qpel，并且在高动态的时候
使用 HPel。
（侦测边缘的程序代码是直接从 RefDivX 提供的 HVS 程序代码里面 copy 来的 :P
使用的侦测法是 sobel 微分法，不过目前程序代码没有 asm 化，速度会比较慢）
QPel（1/4 Pixel）和 HPel（1/2 Pixel）的 Motion Estimation
现实生活中物体的移动和像素（Pixel）无关，物体不会按照像素的格子，
一格一格的移动，每次都移动整数的格子点，刚好落在像素上。
所以我们以整数像素的单位做搜寻、比对，显然无法找到误差最小的参考方块。
为了克服这个问题，MPEG-2 压缩的时候，会先将要参考的画面做内插补值
（interpolation），补出像素和像素之间的次像素的数值，如：
A x B
x x x
C x D
x: 1/2 Pixel
以此 1/2 Pixel 精确度的画面做为参考画面，于其上搜寻最近似的参考方块。
MPEG-4 用的 QPel = 1/4 Pel，就是再补出 1/2 像素和像素之间的 1/4 Pixel：
AoxoB
ooooo
xoxox
ooooo
CoxoD
o: 1/4 Pixel
sysKin 说根据他的测试，现在使用的动态 HPel/QPel，可以达到压出来的档案大小
和只使用 HPel一样大，但是保留 QPel 的锐利、细节较多的效果。
许多使用者和我的测试都显示，使用 QPel，以固定 quant 压缩，
压出来的档案会变大。
这表示在同样档案大小下，使用 QPel 的品质会较差。
（2-pass 固定档案大小，QPel 压出来会较小，这是因为 quant 提高，
并不是因为 QPel 提升了压缩率）
所以 sysKin 现在很高兴，新的动态 HPel/QPel 决策能使压出来的档案
和只使用 HPel 一样大，同时保留了 QPel 的优点。
不过 XviD 开发团队的 Michael 持不同的看法，他认为 Qpel 不是只有在锐利的
画面才有用，而平滑的画面就没有用。
不过高动态使用 HPel 也许是比较好的作法，因为根据他的观察，QPel 在高动态
的时候越难成功的找到误差最小的参考方块。
（这点也和我的测试结果相同，我觉得这是目前 XviD 使用的 ME 算法的问题）
另外他很困惑为什么使用者会回报使用 QPel 档案反而会变大。
根据他的测试，QPel 压出来几乎都比 HPel 小。他手上有一个 clip，
QPel 压出来比 HPel小了 30%（^^; 是哪一个 clip 这么猛）。
我自己的测试，我没用学界常用的那几个标准的 clip 来测试，
只有压了几部动画的 OP。
出来的结果，QPel 几乎都大了约 3%。
至于 QPel 压出来的画面较锐利，细节较多？
好像是有那么一点，不过 noise 也较多 :P
TMPGEnc 的设定中说，静止画面使用 HPel ME 画面会模糊，
那么照理说低通得更厉害的 QPel 应该更糊才对？
- StatsReader 2.0，可以让使用者插入 keyframe。
这表示 2nd-pass 的时候不会重做 I/P/B 分配决策了？
希望能够再加入强制指定某个 Frame 为 P-Frame or B-Frame 的功能。
现在的 XviD 对淡入淡出的场景压缩很差，因为这种场景前后亮度的变化很大，
XviD 会误判为 Scene Change，全部压缩成 I-Frame，浪费许多 bits。
如果有手动指定 Frame Type 的功能，在 encoder 改进之前可以先手动补救一下。
因为我无法使用 Koepi 编译的版本（他用的最佳化方式会使得我的破烂 CPU 的指令集
无法支持），而他的这个版本的许多更新是直接跟作者拿的热腾腾的 source code，
CVS 上都还没更新，所以我也无法自行编译测试，就静待各位的测试心得