一個無聊的 MPEG-4 Codec 測試（內文圖很多!!）

TMNEXT · 文章由 **TMNEXT** » 2002-09-23 20:08

基本上你的測試有很多東西都沒有控制好,
所以很難說AviUtl是不是比較"好".

舉個例來說,
第一個M4C和DivX 5.02 AviUtl的PSNR差約0.3 ~ 0.4 dB
但是bits相差了有4MB.
這4MB分到2182個frame裡,每個frame大概可以多出1900 Bytes,
換成bits大概是14~15 Kbits
如果給M4C的target bitrate高一點,我想M4C應該可以把PSNR追到差0.1 dB左右.
這樣的差距並不算太大.

檔案大小之所以不同，是因為除了 M4C 之外，每個 Codec 都是用固定 Quantizer 2x 壓縮，不同 Codec 壓縮能力不同，自然檔案大小會不同。
我是要測 Codec 的最高品質，當然用 Quantizer 2x 下去壓縮，壓出來檔案比較小就比較小，那也認了，該 Codec 的最高品質就只能這樣。看數據的人要自行根據檔案大小和 PSNR 來做判斷。像 FFVFW 這個 Codec 壓出來的 PSNR 和 XviD 差不多，檔案大小卻小很多，同樣 Quantizer 2x 的品質底下，我們可以說 FFVFW 比 XviD 優秀（FFVFW 能找到更匹配的參考方塊，讓誤差較小，需要編碼的資料較少；或是 FFVFW 內定的 H.263 量化矩陣，在這部動畫，剛好可以刪除掉一些 DCT 係數，而又不會影響 PSNR 太多..等等）。低流量的時候，其實就是 Quantizer 提高，其他 Codec 的能力（量化矩陣，ME，3D VLC...）都是一樣的，看數據的人可以自行類推。如果不用固定品質壓縮，而改在那邊調整什麼流量曲線壓縮參數等等，變成是在測壓縮的人的功力，而不是 Codec 的特性和實力了。
都設成固定 Quantizer 2x，才有辦法一個 frame 一個 frame 比較。否則拿 Quantizer 4x 的 frame 和 Quantizer 2x 的 frame 比較，不是更沒有意義？

而 M4C 則是例外，M4C 會比較小，是因為它的 keyframe 只能用 Quantizer 4x，壓縮得比較厲害，所以最後檔案大小就會比較小。不過這是無可奈何的事情，不是我故意要將它壓小，而是 M4C 的天限，用 M4C 壓出來就是會比較小，這已經是 M4C 的極限了，就跟其他 Codec 也用極限 Quantizer 2x 壓縮一樣，我覺得這樣比其實很公平，沒道理要降低其他 Codec 的能力，配合 M4C 的檔案大小

你說把 M4C 的 target bitrate 提高一點，不過已經沒有辦法提高了，您沒注意到我流量已經設成不可能的 32767 了嗎？

這個已經是 M4C 的極限了。（當然我沒有特意最佳化，認真搞是可以再高一點）

另一方面,
讓AviUtl用較慢的Motion Estimation並不完全公平.
基本上只要用較快的ME都會有一小部份的quality loss,
這是因為並沒有辦法找到最好(使PSNR高)的Motion Vectors.

從這兩點看起來就很難說AviUtl是不是比較好.

你誤會了，我沒有設定 AviUtl 使用比較慢的 ME。
AviUtl 和 VD 各壓一個做比較的是「DivX 5.02 不使用 B-Frame」的版本。在這個測試中，雙方壓縮的訊源都一樣，Codec 的設定也都一樣，唯一不一樣的只有壓縮的軟體，一個是 AviUtl，一個是 VD。AviUtl 並沒有特別使用比較慢的 ME。
如果設定不一樣，那麼壓出來 PSNR 會不一樣，是很自然的事情。就是因為設定都一樣，壓出來卻不一樣，我才會那麼驚訝

如果你想做這一類的測試,
例如想找PSNR最好的codec.
那麼最好的codec應該是在target bitrate與quantizer都一樣的情形下,
用最慢(complexity最高)的motion estimation algorithm.

這個是做不到的，相同的 Quantizer，壓出來的 bitrate 不會都一樣。
不同的 Codec 用的 ME 也不一樣，有些根本不讓你調，我是用各個 Codec 最好的 ME，跟最好的品質下去壓縮。大家都拿最好的武器出來比試，這樣很公平吧？

[quote]
或者是在同樣target bitrate, 同樣的ME,而用其他的quantizer(非H.263的uniform quantizer)
[quote]
H.263 用的是 uniform 的 Quantization Matrix，不是均勻的 Quantizer，我也不懂均勻的 Quantizer 是什麼意思。
至於為何不使用相同的檔案大小來比較，而用 CQ（Constant Quality）固定品質模式來比較，上面已經有說明。

無論如何,要達到較佳的PSNR(或quality),較大的檔案大小與較為複雜的演算法都是必需的.
(如果又小又快的話,那真的是很高明的方法喔!

)

經過我的重新說明，不知道您對 AviUtl 壓出來比較好的原因有何看法

TMNEXT · 文章由 **TMNEXT** » 2002-09-30 21:02

可能的答案...
我原來以為 DivX 5.02 這個重複 keyframe 的問題是 deocder 的 bug（因為 DivX Networks 公司是這麼說的），不過我後來發現不是這樣，而是壓縮後的 sequence 裡面 keyframe 就是重複的，不是顯示的問題。
所以 AviUtl 壓出來會比較好能可以這樣解釋，因為每張 keyframe 後面都重複，等於少壓一張畫面，多出來的流量分給其他畫面，所以其他畫面的 PSNR 都比較好一點。又由於 keyframe 後面的那一張可能差異不大，所以即使重複 PSNR 也不會差太多，所以平均 PSNR 還是 AviUtl 較好。
不過根據觀察，keyframe 後面的那一張的 PSNR 都差很多，而且總共的 keyframe 只有五十幾張，也就是重複（節省）的畫面只有五十幾張，佔全部畫面的 2.5%，考慮到 P-Frame 的效應，PSNR 應該不會相差到 2dB 以上。
好吧，就算是 keyframe 重複造成的差異，但是改用 FFVFW 壓，AviUtl 壓出來反而輸 VD 0.012dB（Y-channel）。這個差距很小，實際上不會有人在意，不過代表的意義是用相同 Encoder 壓，相同設定，不同軟體會有些微的差異。
我現在能想到的可能原因是，VD 可能直接送 RGB Data 給 Codec，由 Codec 自行取樣轉換為 YV12，而 AviUtl 則是一律由 AviUtl 自己轉換為 YV12 以後，才送給 Codec 壓縮。因為色空間轉換的計算精度不同，所以才造成 PSNR 的差異。
可以用一個只輸出 RGB 格式給 VFW Codec 的軟體測試，看看壓出來的檔案和 VD 的 PSNR 一不一樣來證明。
不過這個證明好像很無聊，等有空再做好了 ^^;

kouyoumin · 文章由 **kouyoumin** » 2002-11-24 01:07

剛剛試了一下QT6的MPEG4
素材是Chobits NCOP (嗯...應該算不難壓的吧?)
看到那畫面不禁讚嘆...QT6真是前途無"亮"呀! [XD]
已經調到2048kbps(最大)還是有明顯瑕疵
至於傳說中的Dolby AAC, 我耳背無法分辨好壞^^;

TMNEXT · 文章由 **TMNEXT** » 2002-11-28 16:42

試試看 XviD，可以壓標準的 MP4 bitstream，而且品質又很好，絕對會是明日之星喔!! ^^
（用 MPEG4IP 便可以把 AVI 內的 raw MP4 bitstream 抽出來，改用 .mp4 來裝，
相容性絕對沒問題，其他標準的 MPEG-4 decoder 都可以播。反而 DivX 5 有許多地方都做錯，\r
不符合標準，將來用其他 MPEG-4 decoder 解碼，可能會發生解碼錯誤的情況。
然而現在 DivX 5 聲勢浩大，廠商們可能會迫不得已特別做一個 "相容模式" -_-||）

最近用 XviD 重壓藍青的 OP，用 Qpel + B-Frame + Chroma ME，最大 B-Frame 個數 4，
壓出來和 DivX 5 B-Frame + GMC 差不多大，但是畫質明顯更好，XviD 終於把 DivX 幹掉了

這部 OP 的影像內容對 XviD 來講壓縮較為不利，不過 XviD 還是贏了。
影片中有兩個場景往上大移動的片段，這裡 DivX 5 用 GMC 可以省下很多 bits。
還有影片中段有好幾個快速淡入淡出的鏡頭，畫面急遽的由亮轉暗再由暗轉亮，
XviD 目前對這種 fade 的鏡頭無法良好的判斷。因為這種畫面前後的亮度差異很大，
XviD 會誤判為是 Scene Change，全部用 I-Frame 壓縮，浪費大量的 bits。

這裡 encoder 必需要有一個良好的機制，能夠判斷畫面上現在出現了 fade 的情況，
巨大的亮度差異不是因為 Scene Change 造成的，而是因為 fade 的關係。
這時物體的位置都沒有移動，所以應該把所有的動作向量 MV 設為 0，把省下來的 bits
全力拿來紀錄兩者之間的誤差，以 B or P Frame 壓縮，這樣才能達到最好的壓縮效率。

DivX 5 就能夠很正確的判斷 fade 出現，以 B or P Frame 壓縮。

要怎麼判斷 fade 的場景出現？各位有沒有什麼好的點子？

我想到的兩個方法，一個是判斷現在畫面上大部分的區塊，亮度是否都增加或減少相同的值？
如果幾乎全部的區塊都隨時間增加或減少相同的亮度值，那麼就有可能畫面上出現了 fade。
另一個方法是，現在 XviD 有 Chroma ME 的功能，這樣當亮度的差距很大的時候，\r
同時可以檢查色度 Chroma 的差距是否有變化。如果色度沒有變化，僅亮度有巨大的差異，
那麼可以判斷是 fade 的情況。

不知道有沒有更好的判斷方法？

不論如何，儘管在壓縮的素材如此不利的情形下，XviD 還是贏了!
幹得好呀 XviD Team!!

kevingwn · 文章由 **kevingwn** » 2002-12-05 15:20

TMNEXT 寫: 要怎麼判斷 fade 的場景出現？各位有沒有什麼好的點子？

用Cb, Cr去判斷可以嗎?

寫了個小程式，展示DCT和DWT的效果，
http://home.kimo.com.tw/kevingwn/works/jiml.htm
歡迎指教^^;

TMNEXT · 文章由 **TMNEXT** » 2002-12-06 21:50

kevingwn 寫:
TMNEXT 寫: 要怎麼判斷 fade 的場景出現？各位有沒有什麼好的點子？
用Cb, Cr去判斷可以嗎?

是個好方法 ^^
不過 MPEG 壓縮的時候，不會去計算前後畫面 Cb, Cr 的差距，一般 Chroma 的動作向量，會直接拿 Luminance 的動作向量除以二（YUV 4:2:0 的時候）。
反正 Chroma 不重要 ^^;
現在 XviD 有 Chroma ME 的選項，會真正的去求 Chroma 平面上誤差最小的動作向量（速度會比較慢），但是如果壓縮的人沒有開啟這個選項，就無法利用 Chroma ME 來偵測畫面是否發生了 fade。

kevingwn · 文章由 **kevingwn** » 2002-12-07 03:14

嗯，那在ME之後再做判斷呢？

以長度為4的向量為例，

[0][128, 128, 128, 128] -> [0][125, 123, 124, 124]
=> [-3, -5, -4, -4] -> mean = -4, var = 0.5
[0][128, 128, 128, 128] -> [1][124, 134, 133, 133]
=> [-4, 6, 5, 5] -> mean = 3, var = 16.5
[0][128, 128, 128, 128] -> [2][193, 64, 80, 175]
=> [65, -64, -48, 47] -> mean = 0, var = 3208.5
....
=> ME[0] = 0
....
但是向量的變異數很小([-3, -5, -4, -4]，變異數才0.5)
而平均值卻不為零，那麼一定是屬於fade的狀況...

以上是胡思亂想的....

TMNEXT · 文章由 **TMNEXT** » 2002-12-07 23:57

kevingwn 寫:嗯，那在ME之後再做判斷呢？
但是向量的變異數很小([-3, -5, -4, -4]，變異數才0.5)
而平均值卻不為零，那麼一定是屬於fade的狀況...

以上是胡思亂想的....

不太懂您的意思，可以再進一步的說明您的想法嗎？

如果有好點子，可以建議給 XviD team ^^

hotball · 文章由 **hotball** » 2002-12-08 23:16

我的想法是…即使只用 Y 做 motion estimation，在 motion estimation 時總是會先做 dx = dy = 0 的情形。所以，只要在 dx = dy = 0 的地方多做一個 Cb 和 Cr 的 difference 就可以判斷出大部份正確的 fade 了。或是用另一個說法，就是在 scene change detection 中做一個整個畫面的 Cb 和 Cr 的 difference。在 motion estimation 中做其實不太合理，因為 scene change detection 是在 motion estimation 之前做的。

用 variance 可能不能很有效判斷出 fade（除非是「減去某常數」的 fade，但是這應該不是很好的 fade 方式），不過 variance 常被用來判斷 P 和 B frame 中一個 macro block 要不要改用 intra 的方式 encode。