[SilkyBible] XviD系列-17

引用 12-17-2003

引用应该可以吧...因为我有个matrix就来自mpeg2编码用的 screen.width-500)this.style.width=screen.width-500;" onclick="javascript:window.open(this.src);"> . 具体mpeg2跟Mpeg4用相同的matrix来量化有没有太大差别还是请Silky兄解释吧. screen.width-500)this.style.width=screen.width-500;" onclick="javascript:window.open(this.src);"> 是的，MPEG-4 的 MPEG quant 量化方式和 MPEG-2 有点不一样，所以用在 MPEG-2 上面的矩阵拿到 MPEG-4 上用效果会有一点差异。

引用再贴一个MATRIX给你,是另外一个著名的MPG压缩软件用的
看上去与小日本的一样 这好像是 MainConcept MPEG Encoder 的预设 Matrix，效果很不错

压低码率，用 CCE 的 very low matrix 效果不错 screen.width-500)this.style.width=screen.width-500;" onclick="javascript:window.open(this.src);">
intra
08 16 19 22 26 27 99 99
16 16 22 24 27 29 99 99
19 22 26 27 29 34 99 99
22 22 26 27 29 34 99 99
22 26 27 29 32 35 99 99
26 27 29 32 35 40 99 99
26 27 29 34 38 46 99 99
27 29 35 38 46 56 99 99
inter
16 17 18 19 20 21 99 99
17 18 19 20 21 22 99 99
18 19 20 21 22 23 99 99
19 20 21 22 23 24 99 99
20 21 22 23 25 26 99 99
21 22 23 24 26 27 99 99
22 23 24 26 27 28 99 99
23 24 25 27 28 30 99 99

引用这个矩阵也不是秘密啊 screen.width-500)this.style.width=screen.width-500;" onclick="javascript:window.open(this.src);"> ，CCE 用的 very low bitrate 矩阵在 CCE 这个 MPEG 压缩软件里便可以看到。
另外 RC2 矩阵也不是秘密，只是很少人用，这个矩阵在 CCE patcher 里面有内建，名称叫做 "Fox Home Entertainment" 矩阵，大概是发现它的人是在 Fox 出的 DVD 上发现的，所以命名为 Fox 矩阵。
而我是在大部分的 RC2 动画 DVD 上发现这个矩阵的，所以当初把它称为 RC2 矩阵。
我当初想，奇怪，怎么这些 RC2 DVD 的制作厂商好像都约好了一样，大家都用这个矩阵，而不用 MPEG-2 的标准矩阵或预设矩阵，难道这个矩阵有什么特殊之处吗，于是就用用看 screen.width-500)this.style.width=screen.width-500;" onclick="javascript:window.open(this.src);">
RC2 矩阵是
intra
08 08 09 11 13 13 14 17
08 08 11 12 13 14 17 18
09 11 13 13 14 17 17 16
11 11 13 13 13 17 18 20
11 13 13 13 16 17 20 24
13 13 13 16 17 20 24 29
13 12 13 17 19 23 28 34
12 13 17 19 23 28 34 41
inter
08 08 08 09 09 09 09 10
08 08 09 09 09 09 10 10
08 09 09 09 09 10 10 10
09 09 09 09 10 10 10 10
09 09 09 10 10 10 10 11
09 09 10 10 10 10 11 11
09 10 10 10 10 11 11 11
10 10 10 10 11 11 11 11

质量很高，1st-pass 压出来文件很大，要用 2-pass 缩小把文件压成和 H.263 一样大再比较。
如果同码率，RC2 矩阵会优于 H.263，那么我们可以说这个矩阵是很优良的。
不过根据我的测试，计算 PSNR，RC2 矩阵会比 H.263 低。
这个矩阵适合用在高码率，它有非常好的视觉品质，画面很锐利，同时暗部没有 H.263 量化的色块，画面很漂亮，大家可以试试看 screen.width-500)this.style.width=screen.width-500;" onclick="javascript:window.open(this.src);">
另外，sysKin 说，由于量化的特性，H.263+Trellis 通常会提高 PSNR，而 MPEG+Trellis 则会降低 PSNR，我做了几个测试都支持他的推测，不过应该有例外的情况，大家也可以试试。

引用 12-22-2003

引用不加的话，出来的质量差不如divx5，所以不甘心啊。 我這邊測試，XviD VHQ-4 和 DivX 5.1 Slowest，XviD 大概快 1/3。
兩者同樣降低品質，XviD VHQ-1 和 DivX 5.1 Standard，我沒有計算過速度，但是 DivX 5.1 Standard 質量很差，遠不如 XviD VHQ-1。
VHQ-1 的速度還是很快，而且質量也不差，若要兼顧質量和速度，建議使用 VHQ-1 就好，VHQ-4 耗費時間太多，但是質量提昇並沒有那麼多。

還有 XviD 開啟 B-frame 速度反而會較快，因為 B-frame 沒有 VHQ，所以有開 B-frame 反而省去了部分 VHQ 的時間，只有 I/P frame 才做 VHQ，所以整體速度反而較快。

引用 12-23-2003

引用Silky兄, 最新的cvs在我這裡vhq似乎坏了, vhq=1和vhq=4的速度和生成文件大小一樣, 能不能確認一下?
我現在用的是繁體，所以我人在外面，不能測 screen.width-500)this.style.width=screen.width-500;" onclick="javascript:window.open(this.src);">

應該不會有這種現象，我大膽猜測一下，您是不是比較 1st-pass 的結果？
現在 XviD 有 Fast1Pass，1st-pass 會關閉 chroma motion 和減少動作搜尋的次數，同時會啟用 Isibaar 的 Fast ME，還有關閉 VHQ, Trellis, Inter4V, 和高品質的 AC 預測模式。
1st-pass 的速度會非常快，大約是一半左右的時間。

我猜是不是因為你只比較 1st-pass 的結果，而現在 1st-pass 會強制關閉 VHQ，所以你改變 VHQ 設置對結果沒有影響？

因為用繁體，而且手邊沒有 XviD Codec 可以看、測試，所以不方便寫很長的說明文，以及回答問題，請大家多幫忙。

引用 12-23-2003

引用對, 我是比較的1st-pass, 原來強制關閉了 vhq, hmm... 若需要的話在 2nd-pass 再打開麽?...這樣豈不打破了 "1st,2nd-pass 設置要完全一樣" 的規矩了麽? 因为 2-pass 的设计改变了。
先前不是说在讨论 XviD 2-pass quant 跳太高的问题吗？Ed.gomez 修改了 2-pass，并且更改了 overflow 的默认值，由 60% -> 10% -> 5%，所以我说安装完新版 XviD 之后，一定要记得按 Load Defaults 载入默认值。
另外 sysKin 修改了 scale 的方式，让预测更准确，现在 2-pass 不管 header+MV 的 bit，只 scale texture 的部分，刚好近日 Isibaar 也有同样的构想，于是三人合力，Isibaar 写出一堆快速 ME，sysKin 修改 2-pass，使用新的快速 ME，关闭不影响 scale 预测的选项，让 1st-pass 的速度加快，称为 Fast1Pass。
因为 scale 的设计改变了，所以 1st-pass 的设置可以和 2nd-pass 不一样。
但是有些选项还是要 1st-pass, 2nd-pass 一致，例如 Qpel，新版的 2-pass 并不会关闭 Qpel 的设置，因为 sysKin 发现 Qpel 会重大的改变 texture 的 bit，Qpel 不一致会造成 2nd-pass 的 scale 预测混乱，并且真的会严重影响画面质量，所以如果 1st-pass 有设置 Qpel，Fast1Pass 并不会跳过 Qpel。

修改过后的 2-pass 很棒，试试看 screen.width-500)this.style.width=screen.width-500;" onclick="javascript:window.open(this.src);">

引用 12-23-2003

引用b幀的 packed bitstream 變成的默認的選項, 我記得以前討論說其為b幀bits的另一種儲存方式, 不一定會帶來更高的壓縮率云云, 不過大多數mpeg4播放器對其支持得也挺好。具體是個什麽東西呀? 现在不适宜写长篇大论 ^^;

勉强找了一台计算器作转码...

packed bitstream 是 DivX 设计的，因为他们发现在 AVI 里面放 B-frame，会造成严重的影音不同步的问题，为了要解决这个问题，所以他们设计了 packed bitstream。

AVI 这个文件格式当初设计的时候并没有考虑会有 B-frame 放在里面，它的 sequence order 是循序的，也就是
1 2 3 4 5 6 7 8
I B P B P B P B ....

然而播放的时候，读入 2B 并不能立刻解码播放，要等下一个 3P 被读进来解码完毕以后，才能解码 2B，因为 2B 会参考它后面的 3P，在 3P 还没有解码完毕之前，我们不知道 2B 要参考的 3P 是什么样子，也就无法解码 2B。

这样子就会造成一个解码的 lag，解码的延迟，所以解码会变成这样

代码 (双击代码复制到粘贴板)

1 2 3 4 5 6 7 8
I B P B P B P B ....  <-- 输入
I B P B P B P B ....  <-- 输出

往后 delay 一个 frame，在 3 的时间点，读入 3P，于是便可以输出 2B。
所以用 VFW Codec(xvid.dll) 去解码这种 AVI，第一个画面会显示英文「警告，无法输出画面，因为 B-frame decoding lag」。

用 DirectShow Filter(xvid.ax) 播放时，XviD 的 DShow 有设计过，不会输出这个画面，所以我们看不到。（1.0 beta 1 的 DShow 好像还没有改过，所以会输出这个画面，pre-beta 3 的 decoder 就不会了，而 VFW Codec 因为 VFW 限制的关系，一定会输出这个画面）

不管有没有这个画面，都会延迟一个 frame，所以会造成影音不同步，由于只有差距一个 B-frame，所以不注意听的话可能不会察觉，但是仔细听的话就会发现。

而 .mpg 文件没有这个问题，因为它的 bitstream 是
1 3 2 5 4 7 6 9 8
I P B P B P B P B ....

这样排列的。

MPEG-4 有自己的标准 "载体"，装载 bitstream 的容器，container，叫做 .mp4，这个是从 apple 的 .mov 格式改过来的，里面可以放声音、影像、图片、文字、动画... 等等各种各样的物件。
用 .mp4 来装 MPEG-4 的 bitstream 的话，就跟 .mpg 装 MPEG-2 一样，不会有 B-frame decoding lag 的问题。
不过大家还是习惯用 AVI 装 MPEG-4 视讯。

DivX 为了解决这个问题，提出了 packed bitstream，把 B-frame 和它要参考的 P-frame 包在一起，变成下面这个样子

代码 (双击代码复制到粘贴板)

1  3 2       5 4       7 6
I [P|B]
[P|B]
[P|B] ....

是 null，空的 frame。

解码器遇到 packed bitstream，就知道 P 跟 B 是包在一起的，中间有一个特殊设计的 | 会区分开来，B-frame 可以实时解出来，而后面的
则显示先前解出来的 P-frame。

这样就破解了 AVI 之中无法处理 B-frame 的限制。

也许有人会想，就算不用 packed bitstream，我把声音也跟着往后 delay，不就可以解决了吗。确实，这样就不会有影音不同步的问题，但是还是有许多兼容性的问题，在不同 player 上，会发生各种奇怪的现象，例如画面显示的顺序错乱等等。
而且 XviD 的 B-frame 不只一个，它可以
I B B P B B ....

甚至还可以
I B P B B P B P P B B B ....

lag 更乱。

把压好的 XviD B-frame AVI 用 VD 加载，按左右方向键移动试试看，比较有 packed bitstream 和没有 packed bitstream 的文件的差异，相信你就会明白有开 packed bitstream 的重要性。
例如 XviD 的三巨头之一 Isibaar，他自己压影片一定会开 packed bitstream screen.width-500)this.style.width=screen.width-500;" onclick="javascript:window.open(this.src);">

所以用 AVI 格式的时候，packed bitstream 非常重要，一定要开启。

引用 12-23-2003

引用刚才试了一下最新的CVS，发现停顿感非常严重，首先怀疑的就是b幀的packed bitstream，果然去掉这个选项后就正常了，试验的片源是RahXephon的OP csr2000 兄是用 ffdshow 播放吗？
据说 ffdshow 解 XviD 的 packed bitstream 会有问题，我很久没用 ffdshow，所以不确定真实的情况。
我知道 sysKin 有提过这个问题，他有向 ffdshow 的作者 milan 回报这个 bug，不过 milan 最近似乎很忙，还没有回应。

还有另一个可能，那就是 DivX 5.1 的 decoder 默认会取代系统上所有的 MPEG-4 解码器，自动播放所有的 MPEG-4 AVI，连 XviD 的 AVI 也被它抢去播放。
DivX 5.1 的 decoder 播放 XviD 的多个 B-frame 是没有问题，但是我发现一个 bug，那就是当 XviD 的 AVI 是 120fps 的时候，120fps 的 AVI 本身就插入许多 null frame，而 packed bitstream 也会插入新的 null frame，假设下面的 sequence 是 30p，每一张 frame 后面要插入 3 张 null frame
I

[P|B]

[B]

代表 packed bitstream 插入的，用来取代 P 的 Null frame。

DivX 解码只有一个 B-frame 的 120fps 没有问题，但是解码有两个或两个以上的 B-frame 的 120fps，sequence 向上面那样，就会 skip 跳中间的第二张 B-frame，造成画面会顿。

我之前也是播放 120fps 的 XviD B-frame AVI 都会顿，后来才发现是 DivX 搞的鬼，换回 XviD 自己解码就没有问题了。
DivX 5.1 decoder 把设定画面中的 "Support Generic Mpeg-4" 选项取消，就不会用 DivX 来解码 XviD 的 MPEG-4。