[SilkyBible] XviD系列-4

 

引用 12-24-2002

同意小嘴巴兄的看法，我也觉得理论归理论，实际上做起来可能会有很大的差异。
而且理论也不一定 100% 正确，像我就觉得 GKnot 乱调整出来的 stats 比较好，
但是理论上 GKnot 调整 XviD 的 stats 档，结果并不正确 ^^;
又譬如说 MP3 的压缩工具 Lame 最新的开发测试版提供了几个参数让使用者调整，
开发人员根据理论建议的参数设定，实际上测出来音质反而较差，
这也是一个理论与实际不符合的例子。
其中可能的原因有：
1. 理论有错
2. 我们对理论的理解有错
3. 实际情况远比理论复杂，我们对理论应用于实际情形的认识不够
所以小弟以上所说的只是提供给大家做为参考，大致上了解是怎么一回事就好，
作为调整时参考的依据，这样用起来心理可能会比较踏实，不过也不一定要死守这些理论
能够灵活运用最好

另外如同小嘴巴兄所说的，XviD 的 B-frame 如果不提高 quant，压出来反而更大。
原因以前有提过，这跟 XviD 的 ME 搜寻范围，计算方法有关。
不过其实 DivX 5 也相同，DivX 5 的 B-frame，内定值都会乘上一个倍数，
所压出来的 B-frame，quant 都比 I/P-frame 来得高。
所以稍微调整一下 XviD 预设的 B-frame 设定，画质就可以好很多。
由于 XviD 现在的 B-frame 机制比 DivX 5 优秀（可以连续多个 B-frame，
会动态插入 B-frame，也就是动态分配 frame type），所以相同使用 B-frame，
即使调低 quant，XviD 还是会比 DivX 5 来得好。


RV9 和 WMV9 都运用了比现有 MPEG-4 part.2 更先进的压缩法，
所以它们在极低码率的压缩上画质都胜过 MPEG-4。
（不过现在的 MPEG-4 软件也还没有发挥全部真正的实力，几个对低码率极有助益的压缩工具
如 GMC 都没有正确而完整的实作出来，最强的几个 Profile 的压缩工具也还没有作出）
不过 RV9/WMV9 的主力目标都放在非常低的码率，主攻的是媒体流的市场，
当码率提高时，画质到达一定程度之后就上不去，不像 MPEG-4 可以压出更高画质的东西。
而在极低码率时，它们的压缩瑕疵比较少，相对的也要用细节减少的代价来交换，
所以虽然画面看起来很"干净"，不过那其实是另一种压缩瑕疵

MPEG-4 AVC 或者叫 H.264 则是另一种更先进的压缩法，使用了许多目前已知最强的压缩技术，
我想 WMV9 能够在低码率时拥有这么好的画质，应该也或多或少的使用了一些 H.264 的技术，
毕竟相关的压缩理论、想法都是相同的。
不过 H.264 的压缩率是另一种崭新的境界，前面所说的 50% 的大小可以达到同品质，
那真的是同品质，不是用减少细节偷工减料换来的，而是货真价实，真的一模一样的品质。
用最客观的测量方法，计算 PSNR，H.264 在 50% 的文件大小就可以达到 MPEG-4 ASP
相同的 Peak-Signal-to-Noise-Ratio。
（MPEG-4 ASP，Advanced Simple Profile，有 Qpel, GMC, B-frame 等功能，
而且是实作正确的功能，不是现在 DivX 5 那种既蹩脚又错误的表现）
甚至 H.264 还小胜一点。实际目测，肉眼可见的压缩瑕疵也少非常多。
就是因为 ITU 提出的这个技术实在太强了，所以 ISO 才不得不把它并入 MPEG-4 的标准，
成为 MPEG-4 part.10，不然我想 MPEG-4 就糗大了

H.264 主要的特色（部分，我没记全）
1. 使用整数型态的转换（类似 DCT），精确度高，不会有 iDCT mismatch 的问题。
转换的 block 大小由从前的 MPEG-1/2/4 part.2 的 8x8 改为 4x4，方块效应大为减少。

2. 一律使用 1/4 Pixel（Qpel）的动作估计、补偿，进阶模式还可以使用 1/8（!）Pixel
的动作估计、补偿。（MPEG-4 part.2 是基本 1/2 Pixel（Hpel），进阶使用 1/4 Pixel）

3. 动作预测的单位（Macroblock）由原本的 16x16 改为 可以用 7 种不同的方块大小来做预测，
不一定限制为正方形。
先解释一下，动作预测（动作估计）的时候，我们以 16x16 正方形的方块大小为单位，
将画面切成好几个小方块，一个方块一个方块地搜寻，在前一个参考画面中，和现在这个方块
最接近的区域在那个位置，然后记录指向这个位置的向量（Motion Vector）和差异值。

我们可以想见，预测使用的方块单位越小，搜寻时的自由度越高，每个小单位都可以各自独立寻找
最接近的参考方块，而不会被限制住。如果以 16x16 这么大的单位来寻找，则找到的方块一定要
是 16x16 方块中所有 pixel 总和的差值最小的才可以，这样非常没有弹性。
（全部总和的差值最小，不一定个别部分的区块差值也会最小，如果能够切得更细，
各自寻找最小的误差，效果会更好）
如果切成四等分，改以 4 个 8x8 的方块各自搜寻最接近的参考方块，压缩率便可以提高。

这个就是 MPEG-4 的 4MV 功能，XviD 里面叫做 inter-4v，一个 16x16 的 Macroblock 再切成四份，
四个 8x8 的小方块各自寻找最接近的参考方块。
（要注意的是这样就要记录 4 个 Motion Vector 的数值。XviD 会自动判断，哪种模式压出来最小）

而 H.264 则有更多种形式的方块组合、更小单位的方块大小：
16x16, 8x16（左右切两半）, 16x8（上下切两半）, 8x8（四份）, 4x8, 8x4, 4x4（!）

弹性、自由度超大！

4. 使用多张的参考画面。从前压缩的时候，我们只能参考前一张画面压缩。
B-frame 多一个可以参考后一张参考画面压缩。最多就是两张，而且是最靠近的两张。
H.264 可以使用前面和后面的好几张画面当作参考画面，搜寻所有画面中，
误差最小的画面作为参考画面。想当然尔，可以大大地提高压缩率

5. 4x4/16x16 Intra Prediction（预测）、MV 的 Median Prediction..... 太多记不得了


总结，H.264 的技术非常优秀，但是计算的复杂度非常高，以目前的测试模型 JM4x 系列，
即使在目前最快的个人计算机上运行，压一部影片大概要好几个月 -___-;
所以目前倾向搭配以硬件 DSP 实作。
当然 JM4x 软件只是参考用的测试模型，其程序代码还没有最佳化，等到正式被 ISO 标准化、规格化了
以后，大家便会开始投入实作 H.264 Codec 的工作，届时速度一定会有所提升。
到时候 XviD team 也应该会投入开发的工作

引用 12-24-2002

啊，没错，我都忘了 RV9/WMV9 好像都会先做一些类似 inter-loop filtering/
de-block filtering 的动作来使画面柔化，消除噪讯，使得画面比较好压缩。
而且您说的没错，从播放时的 CPU 占有率来看，RV9/WMV9 应该不至于用太多太复杂的先进技术。
非常同意


对不起小弟又忍不住有些话想讲，我尽量控制不要写太长 ^^;

讲到 bitrate control module 码率控制模块、码率控制器，简写作 RC（Rate Control），
可以说是 encoder 最重要的部分，当然 ME 的部分也是关键，
可是如果 RC 做得不好，压出来的视觉品质就会很差。

RC 会重要的影响到最终生成的文件品质。

前面曾经讨论到 XviD 目前的压缩法设计已经优于 DivX 5，但是 2-pass 的计算方法不良，
也就是 2-pass 的 RC 控制设计不良，造成码率没有办法有效率的分配，
使得现在 XviD 压出来的成品还是没有明显地大幅超胜 DivX 5。
当时讨论中 net1999 兄曾说，也许那些类似 Nandub 的曲线压缩设计是失败的，
我回答说我也这么认为

因为 XviD 开发团队的主要核心人物都在忙于开发 ME/Qpel/GMC 等压缩器的主要功能上面，
所以当初 2-pass 的部分是交给有参与过 Nandub 开发的 koepi 和 foxer 来负责，
想说他们对 2-pass 的设计也比较有经验。
结果今天 XviD 的 2-pass 计算方法就变成现在这种既复杂又莫名其妙的状态。
（对，我一直在说 koepi 的坏话 ）

最近看了 XviD 开发团队的讨论，才发现原来不只我这么想，开发团队的核心人物也这么想：
最近因为要处理 B-frame 的问题，Edouard Gomez（原始的 RC、1-pass RC 的设计者）
要重新改写 XviD 的 RC 程序（谢天谢地，这样以后 B-frame 会更具有威力），
在讨论到目前的 2-pass 设计，提出建议的 Marc FD 说，目前的 2-pass RC 不是很有弹性，
而且控制 B-frame 的方法也不是很清楚。
（他很委婉的说法，我猜真正的意思是其实根本看不懂 code 在搞什么）
Edouard Gomez 回答说，没错，现在的 2-pass code 真的是一团糟，他还特别注明：
「抱歉 foxer，但是我必须承认，现在的 code 我连一半都看不懂」。

Marc FD 建议 XviD 要有更聪明、更有效率的 1-pass/2-pass 甚至 3-pass 的计算方法，
如同其它一般的 MPEG 压缩软件一样。
Marc FD 说，RC 是视讯压缩中最为重要的部分之一，像 Nandub 的 SBC 有时候就能帮助破烂的
DivX 3.11 发挥神奇的作用....当然，SBC 也很烂，只是举个例子，说明 RC 很重要

看到这里，XviD 的三巨头之一 Michael Militzer，也就是 Isibaar 终于开口说话了：
是的，RC 对成品的视觉品质有非常大的影响力，也许我们过去没有花费足够的时间在这上面。
然而，我不认为 Nandub 是一个正确的例子在做这件工作上。事实上，现在的 XviD 已经太像
Nandub 了。最初的 XviD 版本有一个很简单 2-pass RC，而品质还 ok。现在的 XviD 2-pass，
自从几个类似 Nandub 的选项加进去以后，已经变得非常复杂而且难以理解。
并且，这些选项并没有真正的改进品质，只是让使用者有更多的自由，去毁坏他们的压缩成品。

下面 Isibaar 更进一步的说明目前的 2-pass 计算方法是根据两个假想去设计
1. 1st-pass 时用 quantizer 2 跑一遍求得固定品质的压缩结果
2. quantizer 和 bitrate 之间的关系是线性（linear）的

很不幸的，这两个假设都是错的。
（常看到 koepi 在 Doom9 上教训别人的想法错了，大概很难想象他也会被 XviD 的开发人员
教训想法错了 ）
（对，我对 koepi 有偏见 ）

Isibaar 说 XviD 需要一个更"科学的" 2-pass 演算法来达到更好的结果。

koepi 的回答，我就不翻译了，直接引用过来在下面给大家看：

引用

>是的，RC 对成品的视觉品质有非常大的影响力，也许我们过去没有花费足够的时间在这上面。
>然而，我不认为 Nandub 是一个正确的例子在做这件工作上。事实上，现在的 XviD 已经太像
>Nandub 了。最初的 XviD 版本有一个很简单 2-pass RC，而品质还 ok。现在的 XviD 2-pass，
>自从几个类似 Nandub 的选项加进去以后，已经变得非常复杂而且难以理解。
>并且，这些选项并没有真正的改进品质，只是让使用者有更多的自由，去毁坏他们的压缩成品。
Hey, I'm really sorry for that, but I just introduced features which I
thought they were useful (i.e. quantizer restrictions and such things,
which I now never touch anymore %) ). I think you refer to the
complexity of altCC, which is somewhat really advanced and thus
shouldn't be accessable for normal users. But I think we already agreed
on that. I'd love to see our "leaky bucket" curve compensation paired
with a plain linear curve (just read on the doom9 forums that I always
tell the people to use curve treatment that way). Whatever you do with
the other options, it seems like linear urve scaling produces the best
output.

引用 12-26-2002

如果我来编的话大家一定会用到晕倒 ^^;;;;;;;;
我只懂得一点表面的粗浅皮毛，实际真正 coding 的时候问题远比想象的复杂，
XviD 的编程人员每个人都是学富五车，而且是世界上顶尖的编程高手，
他们不是不知道这些问题，而是还在思考解决的方法。
譬如说目前 B-frame 一定要勾选 DX50 B-VOP compatibility，这个 Closed GOV
（等于 MPEG-1/2 的 Closed GOP）的问题开发人员不是不知道，而是很困难解决。
（我们来想的话会觉得很简单。没错，理论上很简单，实作就知道有多困难 ）

而且开发人员每个人都还有自己的学业、工作要忙，仅能利用一点的闲余时间
来从事这项编程工作，所以无法说改就改，立刻就解决这些问题。
不过尽管如此，XviD 仍然是目前世界上，品质最好的 MPEG-4 编码软件... 之一
（话不能说得太满，要留一点进步的空间 ）

至于我的功力只能帮忙测试，回报问题，有时候提供一点无用的建议，
和其它人都一样... ^^;;;;;;;;;