史萊姆論壇

返回   史萊姆論壇 > 教學文件資料庫 > 多媒體影音轉檔燒錄技術文件
忘記密碼?
註冊帳號 論壇說明 標記討論區已讀

歡迎您來到『史萊姆論壇』 ^___^

您目前正以訪客的身份瀏覽本論壇,訪客所擁有的權限將受到限制,您可以瀏覽本論壇大部份的版區與文章,但您將無法參與任何討論或是使用私人訊息與其他會員交流。若您希望擁有完整的使用權限,請註冊成為我們的一份子,註冊的程序十分簡單、快速,而且最重要的是--註冊是完全免費的!

請點擊這裡:『註冊成為我們的一份子!』

Google 提供的廣告


 
 
主題工具 顯示模式
舊 2003-08-08, 12:22 PM   #1
psac
榮譽會員
 
psac 的頭像
榮譽勳章
UID - 3662
在線等級: 級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時
註冊日期: 2002-12-07
住址: 木柵市立動物園
文章: 17381
現金: 5253 金幣
資產: 33853 金幣
預設 用XVID製作精品DVDRIP之菜鳥秘笈

自公元1998年M$推出MPEG4的Codec,4年多來應該說改進是有限的,最大的突破是SBC,也不過是碼率的控制,所有的技術努力不過是改良,不存在實質性的革新。僅就單個畫格同樣質量來比較,我想同樣的畫面效果和M$的codec比壓縮體積也不會超過1.5:1,和電腦本身的進步來比,這些改進多多少少是令人失望的,我個人以為只有寄希望於MPEG4外未來的技術了。重點改進是採用 Avisynth 2.5 ,MPEG2DEC3,VDUBMOD
以提高壓縮速度和品質.
------------------------------------------------------------------------
重點修改了B畫格的相關參數的設定.
並取消1PASS時的QPEL勾選.
還是修改了B畫格的相關參數的設定.
1PASS與2PASS不同
----------------------------------------------------------------------
所需軟體:
1.XVID Koepi's 03-12-2002版
2.SMARTRIP 241
3.DVD2AVI 176
4.Avisynth 2.5
5.MPEG2DEC3 PLUGIN
6.VIRTUADUBMOD 141X
7.DEBUGVIEW 4.2

一.用SMARTRIP 抓取VOB文件到硬碟.

二.用DVD2AVI產生D2V和WAV文件.
用DVD2AVI開啟VOB文件後,
點VIDEO勾選FORCED FILM.
點AUDIO選OUTPUT METHOD勾選DECODE TO WAV,並勾選NORMLIZATION 到100%(放大音量).
按F4寫D2V和WAV文件.

三.用Avisynth 2.5裁邊和RESIZE
以720X272的DVD源為例
LoadPlugin("j:\avs\mpeg2dec3.dll")
mpeg2source("176.d2v")
crop(8,104,-8,-104)
LanczosResize(640,272)


四.用VIRTUADUBMOD讀取AVS文件和WAV文件
選FAST RECOMPRESS模式做XVID的1PASS和2PASS
可以選取開始畫格和結束畫格以獲得你所要的片段.

1.XVID的1_PASS設定:
選取MOTION SEARCH 為6-ULTRA HIGH.
選取QUANTIZATION TYPE 為MPEG.
勾選USE CHROMA MOTION.

最大B畫格選3,
B畫格的QUANTIZER RATIO(%)取100,
offset 取1,
經實驗B3可以達到壓縮率和質量的最佳平衡點,要盡量減少B畫格的劣化,因為B畫格也是要看的.
AUDIO可以選NO.
開始壓縮前執行DEBUGVIEW以獲取對2PASS設定的有用信息.(1PASSDEBUGVIEW可以在結束前再開啟執行,不影響最後的統計數字)
2.XVID的2_PASS設定:
設定好目標文件的體積(不含音瀕)
讀取1_PASS時DEBUGVIEW得到的LOG文件的最後一行中total-kbytes:XXXXXXXX,用其除以目標文件的大小的到的比值乘以2,四捨五入減一即為估計的QUANT值的上限.
設定2_PASS的QUANTIZATION TYPE 為H263或MPEG,一般而言1CD時為H263,2CD時為MPEG,或根據前面計算的QUANT值的上限值來定,如>=6則選H263,反之則選MPEG.
勾選ENABLE LUMI MASKING.
最大B畫格選3與B畫格的QUANTIZER RATIO(%)取100不變,
offset 改設為100,

( 不用QUARTEPEL和選用MPEG/H263都是為了求得細節和壓縮質量上的平衡)
點QUANTIZATION 設定I畫格和P畫格的最小和最大的QUANTIZER,依據前面估算的QUANTIZER值為最大值,減2為最小值.
(好的QUANTIZER範圍的設定得到的最後2PASS的DEBUGVIEW的統計X-1,X,X+1應接近正態分散,如偏往小的QUANT方則碼率會有少浪費,如偏往大GUANT則文件體積容易超標)
3.設定好壓縮的音瀕格式,注意取樣頻率要與WAV文件相同,否則可用VD自含的轉換模式搞定.(我喜歡用64K碼率的WMA,但需要在VDMOD裡勾選48K--->44.1K的采樣頻率轉換)
Q:
按照的設定,我一進入2-PASS就出現非法操作,
這是為何?
A:
可能是VD的版本問題,我用1412和1413也不行,把1413的VD EXE文件件COPY到14112PASS就不出錯了,或者僅用1411

Q:
1PASS產生的.stats信息文件是不是在[SBC Setting...]中「Encode using」填入?
因為以前我都是用net1999教我的簡單方法,用GK直接做的two-pass
A:
這個帖說得是XVID,不是SBC。。你跑題了
關於你的問題,答案是:yes

Q:

Latest development (unstable) binary:
XviD-09122002-1.exe (386kb)
Changelog:
- refdivx's lumi masking finally fixed.
- dynamic hpel/qpel decision - switchable.
- Suxendrol's experimental chroma optimizer
(http://www.xvid.org/modules.php?op=m...iewtopic&t=815)
- sysKin fixed the search range for qpel resolution.

又要開始忙活了
A:
以前曾經說過,使用 Qpel 的時候遇到高動態的場景,壓出來的檔案反而會變大。
我有提到這是 XviD ME 演算法的問題,後來有做一個補充說明沒在這邊提過:


以前曾經說過,使用 Qpel 的時候遇到高動態的場景,壓出來的檔案反而會變大。
我有提到這是 XviD ME 演算法的問題,後來有做一個補充說明沒在這邊提過:
靜態場景還是會增大文件大小,我懷疑是interpoloate的不準確導致額外信息的加入
- sysKin fixed the search range for qpel resolution.
上述問題現在改進了
壓了N個片段加一個全片,效果好像。。是好了那麼一點點,不知道是不是心理作用
- Suxendrol's experimental chroma optimizer
這個 chroma 最佳化的處理是做在 decoder 的部分。
雖然原始提議的 mf 說搞不好用在 encoder 上也可以增加壓縮率,
不過我覺得說明 應該不大。

使用動態切換 qpel/hpel,每個 VOP 需要增加一些額外的信息,記錄這個 VOP 切換為
哪一種過取樣模式。
就像 Quant Type 使用 Modulated 一樣,要動態切換 H.263/MPEG 的量化方法,
每切換一次也需要增加一些額外的信息,這樣 decode 時譯碼器才知道要怎麼正確解碼。
如果這些動態的切換沒有能夠提高壓縮率,或是增進畫面的品質,這樣這些切換反而會
白白的浪費一些 bit,用在記錄這些額外的信息上面。
之前 sysKin 之所以設計動態 qpel/hpel,是因為使用 qpel 壓出來的檔案反而變大,
為了讓 qpel 的使用更有效率,能夠真正的提升壓縮率,所設計了動態切換的機制,
只有靜態、銳利的畫面才使用 qpel。
然而現在 qpel 的搜尋範圍的 bug 已經修正,即使在高動態的畫面,qpel 也應該能提高
壓縮率,所以 koepi 提供一個切換的開關,讓你試試是單獨用 qpel 壓出來好,
還是動態切換 qpel/hpel 壓出來好?
koepi加的這個開關絕對有問題,壓了四個3分鐘的片斷,發現根本沒有辦法單獨使用QPEL,單獨開啟其中一個開關的結果就等於完全沒有使用QPEL,文件大小一摸一樣,連一BIT的差別都沒有

最新進度:XviD 現在已經實作出 rrp 的編解碼,加油 XviD!!朝最強的 MPEG-4 Encoder
繼續邁進吧~~

時間不多,稍微提一下,關於 2-pass 使用的 quant type,1st pass 用的 quant type
要和 2nd pass 用的 quant type 一樣,壓出來的效果才會好。
2nd pass 的時候會按照 1st pass 壓出來的流量曲線做調整,scale 每個 frame 的大小,
如果 1st pass 用的量化方法和 2nd pass 用的不一樣,scale 的預測就會非常不準確,
連帶影響 encoder 分配 bit 的效果,這樣就無法做到 linear-scaling 了。
所以 koepi 以前說,當你使用 Modulated 的量化方法時,quantizer < 4 會用 MPEG 量化,
>= 4 會用 H.263 量化,quant type 會自動切換。這時如果你設定的碼率比較低,
可以預期 2nd pass 時大部分的 frame 的 quantizer 會大於或等於 4,也就是大部分的
frame 會用 H.263 量化,此時你的 1st pass 就要選項 H.263,這樣 2nd pass 的 scale
才會準確。
反過來,如果 2nd pass 大部分的 frame quantizer 會小於 4,則你 1st pass 就最好選項
MPEG 量化。
如果沒有使用動態的切換 quant type,則 1st pass 時用哪種 quant type,2nd pass 就用哪種。

同樣的道理,1st pass 時有用 QPel/Lumi masking,2nd pass 就要跟著用 QPel/Lumi masking;
1st pass 時沒有用 QPel/Lumi masking,2nd pass 時就不要用 QPel/Lumi masking。
1st pass 的設定要和 2nd pass 一致。

補充一下,如果用的是HQMod,前面剛好是反過來的做法
另外順便再提一下這個linear curve,sbc對於curve的壓縮已經是約定俗成,xvid的早期開發也一直對這個問題糾纏不清,還搞出original cc和alt cc兩套做法,我實在想不明白為什麼一下子又回到了原始狀態。。而且效果還比cc好?或許xvid本身的碼率分配比較合理?koepi一直對這個問題避而不答,也沒有程序員出來解釋。。

關於 DVD2AVI 的 Force Film,以下針對的是 NTSC 的 DVD 說明:

DVD2AVI 的 Force Film 只有在 Film 的比例高達 95% 以上時才能使用。
先用預覽 Preview 跑一遍,或是大概跑一段,看看 Film 的比例佔多少,
如果 Film 的比率太低,強制 Force Film 輸出,輸出的結果會是垃圾。

DVD2AVI 的 Force Film 選項並不是像 TMPGEnc 的 IVTC 那樣,
真的去分析畫面交錯的資料來判斷還原回原來的 24fps。
DVD2AVI 的 Force Film 只是根據 DVD 內儲存的旗標(Flag)信息,
組合出原本儲存在 DVD 內的 24fps 的 Frame。
Film 的 DVD,也就是 24fps 的 DVD,是在 DVD 壓縮的時候,就先做好IVTC。
也就是 DVD 壓縮的內容,本來就已經是 24fps 了。
先做好 IVTC 再壓縮,因為每秒鐘需要壓縮的 Frame 由 30fps 減少為 24fps,
少壓 6 個 Frame,所以會比較好壓,同碼率下畫質會更好。
然而輸出的時候,DVD Player 會根據 DVD 內的 RTF/TFF 旗標的信息,
將內部儲存的 24fps Frame 組合成 30fps 輸出,以符合 NTSC TV 的規格。
DVD2AVI 的 Force Film 就是根據這兩個旗標的信息,反過來不做 24->30 的轉換,
直接輸出原本內部儲存的 24fps。
所以如果原本的 DVD 的 Film 比例不高(也就是 24fps 的比例不高,
為 24/30 fps 混雜的 DVD),強制 Film 輸出的結果會得到錯誤的 Frame 組合。
因此唯有當 Film 的例超過 95%,才可以選項強制 Film 輸出。
一區的 DVD 有很多都是 Film(24fps)的 DVD,所以強制 Film 輸出沒有什麼問題。

因為 DVD2AVI 並不是真的在做 IVTC,真的去分析畫面,組合還原回正確的 Frame,
所以也不能批評 DVD2AVI 的 ""IVTC"" 很爛。
使用者應該自行判斷,什麼時候該用 Force Film,什麼時候不該用 Force Film。
我一直建議使用avisynth去場,ntsc和pal都適用,當然這是因為我極少接觸NTSC制式的DVD
如果用的是HQMod,前面剛好是反過來的做法
另外順便再提一下這個linear curve,sbc對於curve的壓縮已經是約定俗成,xvid的早期開發也一直對這個問題糾纏不清,還搞出original cc和alt cc兩套做法,我實在想不明白為什麼一下子又回到了原始狀態。。而且效果還比cc好?或許xvid本身的碼率分配比較合理?koepi一直對這個問題避而不答,也沒有程序員出來解釋。。


我也不懂為什麼他沒有回答這個問題。
2-pass 的 curve compression/scaling 主要就是由他和 foxer 設計的,
他不回答,其它三位真正的 XviD 核心開發人員(gruel,michael,pete)也無法幫他說明。
(他們三位也不上 Doom9,這三位才是 XviD 幕後的大功臣)
從理論上來說,linear-scaling 應該是最完美的,不過當碼率不夠的時候,用 original cc/
Alt. cc 應該還是會有它的作用。不過這個調整不好調,參數設錯,反而會遭致反效果。
問題是怎樣的設定才是好的設定?這個最佳的設定會隨影片不同而不同,沒有類BIOS的標準。
所以說很難調。(而且 Alt. cc 的參數很難懂,有多少人知道那些參數代表的意義?
連 XviD Stats Viewer 的作者 NiTroGen 一開始的時候都搞不清楚 curve aggression 是在
做什麼....)

不過,我最近突然發現,用 GKnot 亂搞出來的 scaling 效果反而更好?!
GKnot 的 linear-scaling 會分析畫面的 motion,更適當的分配碼率。
不過它並不適用在 XviD 上,GKnot 主要是針對 Nandub 設計,有很多判斷的方法不適用於 XviD。
如 GKnot 會計算 Luma noise,XviD 根本沒有這種問題。
GKnot 還會根據 1st pass 每個 frame 的:
1.k-blocks: = intra-blocks 不參考前後畫面,獨立壓縮的 block。
Intra-frame(或者稱為 I-frame)全部都用這種 block 壓縮。
所以如果解析度是 640x480,總共的 MacroBlock 是 (640/16)*(480/16) = 1200 個,
如果是 I-frame,1st pass 時你會看到 XviD 回報該 frame 的 k-blocks 是 1200,
m-blocks 和 u-blocks 都為 0。

2.m-blocks: = inter-blocks 參考前後畫面,壓縮的 block,記錄的是和前後畫面的誤差。
P-frame 和 B-frame(統稱為 Inter-frame)中大部分的 block 都是這種 block,
只有當該 block 和前後畫面的差異太大,找不到適當的參考方塊,才會改以 intra-block 壓縮。

3.u-blocks: = uncoded-block = skip block,不壓縮,直接 skip 掉的 block。
當該 block 幾乎沒有變動,和前後參考畫面幾乎完全一樣時,譬如說完全靜止的畫面,
我們就可以 skip 掉這個 block 不壓縮,直接沿用前一個 block 來顯示。

這三個數值 1st pass 的時候會計算出來,GKnot 會根據這些數值來判斷 motion/scene change。

k-blocks + m-blocks + u-blocks = 總 MacroBlock 數,如 640x480 即為 1200。
XviD 1st pass 時 debug view 只會顯示 k-blocks 和 m-blocks,而 1200-(kblocks + mblocks)
得到的數字便是 u-blocks。

然而這個不適用在 XviD 上,因為 XviD 目前 B-frame 回報的數目並不正確,GKnot 可能會算錯
真正的 motion 值!

不過我很意外的發現,用 GKnot scale 出來的 2nd-pass stats 效果還是比 StatsReader 好!
不過不要用 GKnot 判斷 scene change 的功能,要選項保留原 1st-pass stats 檔的 Key-Frames
設定(按 Stats 按鈕),其它如 F.-Size Correction、Motion Correction、Luma Correction
通通不能勾選。

我只有試過幾個 clip,壓出來的效果都比 StatsReader 的 scaling 好,不過不確定是否所有影片
都具有同樣的效果,如果你不滿意 XviD 目前的 2-pass 算法,可以試試看 GKnot。
重申一次,我不確定這樣亂搞壓出來的效果一定會比較好,您可以觀察 2nd-pass 壓出來的
平均 quantizer 有沒有降低,如果有降低,那應該就是有說明 :P
(不過目前 XviD 顯示的 B-frame quantizer 也不正確,似乎不能做為判斷依據 ^^;)


DOOM9上也有人提出,相信很快就會修正,這不是大問題。

CC的棄用我認為證明那一套失敗了,當初設計的時候可能考慮了D3的做法,也可能是為了「區別」D5的證明:XVID比保密的D5要更「開放」。alt cc的調節容易引起混亂,曾經很多人想依靠試驗得出最佳效果,但是排列出來的組合太多,根本沒辦法一一試驗,更何況電影的千差萬別呢,現在使用linear scale,問題簡單化,對使用者和編程者都是一件好事。

GK的curve計算也可以用在XVID上。。這倒是第一次聽說,以前被alt cc已經搞得頭大,還真沒想過用GK計算,有空一定試驗一下。不過我猜想GK除了改變碼率分配曲線,可能還因為B畫格的不正確讀入自行加入了一定數量的intra-frame?GK已經長期沒有更新,希望下一個版本能直接支持XVID的曲線壓縮計算,除了能快速產生avs文件外,這也是GK最拿手的法寶了,希望thewefs不會讓我們失望

B畫格的quantizer一直是我想不通的問題,XVID的VFW界面下可以設定上限的只有I和P畫格,B畫格的quant計算公式。。我看不懂。記得syskin說過在150%的ratio下B畫格會比相鄰的P畫格大1或2個quant值,但是因為P畫格的上限永遠是整個電影的最高上限(debugview內的結果),所以我想不通,要麼是xvid報錯信息,要麼本來就是如此。要是silky兄對此有心得,還望不吝賜教。

rrv看來也不是什麼好跡象 減少細節我不是很在乎,畢竟是在高動態下,看不到無所謂。但是估計decode的時候又要給CPU加活了



CC的棄用我認為證明那一套失敗了,當初設計的時候可能考慮了D3的做法,也可能是為了「區別」D5的證明:XVID比保密的D5要更「開放」。alt cc的調節容易引起混亂,曾經很多人想依靠試驗得出最佳效果,但是排列出來的組合太多,根本沒辦法一一試驗,更何況電影的千差萬別呢,現在使用linear scale,問題簡單化,對使用者和編程者都是一件好事。

您說出了我心裡面的想法,我也覺得 Alt. cc 的設計是失敗的,
參數太過複雜,使用者根本不知道要怎麼調整,而且調整的效果也不是非常理想。
像 DivX 5 的 2-pass 多輕鬆,使用者根本不需要去修改什麼設定,反覆實驗最佳的結果。
通常來說,只要用預設值就可以得到不錯的碼率分配,這對初學者來說,容易上手得多。

Q:
GK的curve計算也可以用在XVID上。。這倒是第一次聽說,以前被alt cc已經搞得頭大,還真沒想過用GK計算,有空一定試驗一下。不過我猜想GK除了改變碼率分配曲線,可能還因為B畫格的不正確讀入自行加入了一定數量的intra-frame?GK已經長期沒有更新,希望下一個版本能直接支持XVID的曲線壓縮計算,除了能快速產生avs文件外,這也是GK最拿手的法寶了,希望thewefs不會讓我們失望


A:
因為 XviD 的 2-pass 是 koepi 設計的,koepi 從前曾經參與過 Nandub 的改版設計,
所以他在設計 XviD 的 2-pass 的時候,就採用了和 Nandub 一樣的 stats 檔格式,
所以 GKnot 也可以讀取 XviD 產生的 stats 檔。
不過如前所述,兩者的參數有些不相同,像 XviD 的 stats 檔就沒有 Luma noise
這個參數,所以 GKnot 讀取顯示的 Luma noise 的數值都是錯的。
基本上是不能用 GKnot 來做 XviD 的 scaling 的,所以我以前也從沒這樣做過。
最近是一時無聊,試試看用 GKnot 亂搞出來的 stats 檔拿給 XviD 壓會壓出什麼結果,
結果效果非常好!我自己也很驚奇,我原來以為會壓出亂七八糟的東西....

XviD 我現在最不滿意的就是 2-pass 的算法不像 DivX 5 那麼好,
而使用 linear-scaling 時如果碼率太低,靜態畫面的畫質會不夠好,
導致明明 XviD 的壓縮效率已經大幅超越 DivX 5,但是做 2-pass 的時候總是覺得某些畫面
還是不如 DivX 5(因為分配碼率的問題,要分配得恰到好處,才能在有限的碼率下隱藏壓縮
的缺點,增進表面上看起來的視覺品質)。
現在用 GKnot scaling 出來的 stats,我覺得已經接近 DivX 5 VBR 的水準,
讓 XviD 的 2-pass 明顯超越同碼率下的 DivX 5。
不過再重申一次,我只有做了兩三個 clip 的壓縮測試,無法確定每一部電影使用 GKnot 都會有
相同的優異效果,畢竟現在的 GKnot 理論上根本不支持判斷、分析、計算 XviD 的 stats 檔。

我也是擔心 GKnot 會自己加入 Key-Frame,導致不正確的結果,所以在 Key-Frames 的設定那邊
指定 GKnot 使用原本 stats 檔內的 Frame Type 不要變更(按 Stats 那個按鈕),
同時 ""不能"" 勾選 F.-Size、Motion、Luma 這三個 Correction 的校正,
然後才按 Calculate 計算 scale 的 Frame 大小,然後儲存碟。
壓出來 Key-Frames 的數目是對的,沒有亂增加。
不過說實在的,用得心理毛毛的 ^^;
看起很不錯就是了

Q:

B畫格的quantizer一直是我想不通的問題,XVID的VFW界面下可以設定上限的只有I和P畫格,B畫格的quant計算公式。。我看不懂。記得syskin說過在150%的ratio下B畫格會比相鄰的P畫格大1或2個quant值,但是因為P畫格的上限永遠是整個電影的最高上限(debugview內的結果),所以我想不通,要麼是xvid報錯信息,要麼本來就是如此。要是silky兄對此有心得,還望不吝賜教。

A:
賜教不敢當,小弟提供一點心得,您參考看看,大家一起研究研究
XviD 的 B-frame 的 quantizer 設定是用 B-frame quantizer ratio 和 B-frame quantizer offset
這兩個參數來控制的。
因為 B-frame 不能拿來做為參考畫面,也就是說 B-frame 不會再被其它畫面參考到,所以 B-frame
可以壓得比較差一點,通常 quantizer 會設得比較高。
這是因為 MPEG 壓縮的時候 I-frame 和 P-frame 會被其它畫面拿來做為參考畫面,
其它畫面會參考這兩種 frame 來壓縮,只紀錄和參考畫面之間的差異。
參考的時候參考的是壓縮過的畫面,舉例:
I P P P ...

首先第一張 I 獨立壓縮,壓縮完以後再解壓縮,還原一張經過壓縮過的畫面 I'。
第二張 P 要參考前一張畫面壓縮,此時要參考的是未壓縮過的、原本的畫面 I,
還是壓縮過,再解壓縮回來的 I' 畫面?
答案是壓縮過,再解壓縮回來的 I' 畫面。
因為 P 紀錄的是和前一個畫面的差異,解壓縮時用前一張畫面補上這個差異便能得到正確的畫面。
然而解壓縮的時候的前一張畫面是什麼?是經過壓縮過的 I',不是原本的 I。
原本的 I 在壓縮檔裡面已經不存在了(當然,不然怎麼叫有損壓縮 )。
所以我們可以瞭解,P 要參考的畫面必須是壓縮過的 I' 畫面,要記錄的是未壓縮的目前的畫面,
和前一張壓縮過的參考畫面之間的差異。
所以,如果前一張 I' 壓縮得很爛,它和目前的畫面的差異必然很大,必然很不像現在的這張畫面。
這樣這張 P 就必須提高碼率才能記錄這麼大的差異,如果碼率不夠用,這張 P 就無法壓得很好。
接著後面的 P 又要參考這張前面壓得不好的 P..... 如此惡性循環,結果所有的 frame 都無法壓得好。

所以會被參考的 I-frame/P-frame 必須要壓好一點(或者說要壓得正確一點),
尤其是 I-frame是獨立壓縮,比較不好壓縮,需要的碼率要大,所以才會有 I-frame boost 這種選項。
(不過要做到 linear-scaling 便不能使用 I-frame boost,前一次忘了提,這裡補充)

反過來說,B-frame 不會被參考到,所以可以壓得比較不精確一點,所以通常我們會提高
B-frame 的 quantizer 達到高壓縮率。
例如 TMPGEnc 的 VBR 和 CQ 壓縮模式當中的設定選項「B picture spoilage」
(英文版,中文版我不知道是怎麼翻譯),就是讓你設定 B Frame 相較於 I/P Frame 所要減少的品質。

回過來說 XviD 的 B-frame quantizer 設定。本來只有一個選項「B-frame quantizer ratio」,
用的算式是:
((前面參考畫面的 quantizer + 後面參考畫面的 quantizer)/2 * ratio)/100

例如前面參考畫面的 quant 是 4,後面是 6,ratio 設 200,則 B-frame 的 quant 就是
((4+6)/2*200)/100 = 10

也就是「前後畫面的 quant 平均,然後乘上 2」。

不過這種設計你可以看出來很不理想,如果前後的平均 quant 為 10,
中間的 B-frame 的 quant 一下子就會跳到 20。
我們知道 10 和 20 壓出來的品質差很多,這種設計 quant 一下跳太快,比較沒有彈性,
容易造成某些畫面突然發生劣化,出現明顯的瑕疵。

所以後來有人建議,才又加上了 offset 這個參數,整個 B-frame 的 quant 算式變成:
b_quant =
(AVG(prev vop quant, future vop quant) * bquant_ratio +
bquant_offset) / 100

也就是
((前面參考畫面的 quantizer + 後面參考畫面的 quantizer)/2 * ratio + "offset")/100

例如 ratio 設 150,offset 設 50,前後平均 5,則 B-frame 的 quant 就是
(5*150 + 50)/100 = 5*1.5 + 0.5 = 7.5 + 0.5 = 8

這樣比較有彈性,前後畫面是高 quant 的時候 B-frame 也不會一下劣化太快。

那麼為什麼 debug view 裡面回報的 B-frame 的 quant 數目和算出來的不一樣?
因為目前 B-frame 回報的那個數值是錯的
(那個只是壓縮時 Codec 丟出來的訊息,本來只有設計顯示 I/P Frame 訊息的部分,
沒有考慮到 B-frame。反正對壓縮沒有影響,目前也沒有人去修改這個輸出的訊息。
開發人員都很忙,有更重要的 bug 要去修正 )

除了這個 quant 的數目,1st pass B-frame 顯示出來的 k-blocks, m-blocks, u-blocks
這些數字也都是錯的 -_-;;

Q:

rrv看來也不是什麼好跡象 減少細節我不是很在乎,畢竟是在高動態下,看不到無所謂。但是估計decode的時候又要給CPU加活了
A:
這倒是
等開發完成,應該會做個選項讓使用者決定要不要開啟吧。


Q:
只想知道rrp 的編解碼是什麼?
它的原理和功效.
A:
抱歉上面你打錯了,是 rrv 不是 rrp ^^;
rrp 全名是 reduced resolution VOPs,當高動態的時候,人眼看不清楚細節,
高動態的時候通常必須使用高 quantizer 來壓縮,導致畫面出現明顯壓縮瑕疵,
此時如果改成紀錄比較低的分辦率的畫面,壓縮的畫面縮小,就可以降低 quantizer,
顯示的時候再 up-sampling 回原本的分辦率顯示。
雖然這樣細節會減少,但是反正高動態人眼也看不清楚,總之沒有明顯壓縮瑕疵就好 :P

rrv 會將記錄的 texture,長寬各縮短一半,也就是重新取樣變為原本的 1/4,32x32 -> 16x16
只記錄一半的分辦率,解壓縮時再 up-sampling,放大回原本的分辦率。

這個是 MPEG-4 Profile 中,屬於 Advanced Real Time Simple 這個 Profile 所使用的壓縮工具。
http://www.m4if.org/resources/profiles/visualtools.php
其中的 Dynamic Resolution Conversion 就是。
XviD 的目標是要作出 Advanced Coding Efficency 這個 Profile 中的所有壓縮工具。

不過有人也說了,XviD 目前還有沒完整做完 Advanced Simple Profile 中所有的工具,
並且最佳化這些工具,使之達到最大的壓縮效益和最快的壓縮速度,
現在就直接跳到開發 rrv,另一個 Profile 的壓縮工具,似乎太早了一些。
我非常同意

Q:
不過這個好像沒有做IVTC的部分。 是簡單沒寫,還是漏了,或者是不用做?
A:
dvd2avi的forced film就是IVTC
Q:
為什麼不直接做2-pass(手動做),是不是為了得到QUANT值的上限(這是不是1-pass的唯一的工作),1-pass不用設avi輸入文件大小嗎,預設?
A:
1PASS的主要目的是獲得整個影片的信息,才能在2PASS時採用合適的碼率分配並同時控制文件到期望的大小,獲得QUANT的上限只是1PASS的一個副產品.


DivX5.02至今仍讓我感到佩服的就是其使用方便和穩定性,畢竟他們想走商業化的路子,成立了公司,可以讓程序員全職幹這一行。。當然代價就是大家都要付錢。就在兩三個月前,XVID的B畫格還沒完全開放使用,linear scale還未被推薦的情況下,使用XVID想做出質量比較好的電影還是有點困難,而divx5推出的時候只是更新了兩個版本就已經相當穩定好用,不用改任何設定,一個初學者就可以做出質量相當不錯的效果。甚至到了現在,正如你所說,XVID技術上已經比divx5高出不少,但是仍然會有一些情況下做出比divx5更差的畫面。
這段時間試驗下來,發現XVID在一種狀態下表現不是很好,就是靜止而且相當昏暗的場景,馬賽克不但會出現在物體邊緣,而且會出現在色彩單一的平面上。開始我以為是lumi masking的錯誤,關閉後仍然如此,這種情況在做單獨片斷時極為少見,但是壓全片就容易看到。比較同樣用divx5壓縮出來的全片,會發現divx5並沒有這種現象,雖說大部分場景下divx5比不上xvid,但是xvid的這點瑕疵實在讓我不舒服,你上面說過的「XviD 的壓縮效率已經大幅超越 DivX 5」所以出現這種情況實在不應該。
我有幾種猜測,一是divx5模糊了細節,減少了出現馬賽克的可能性,不過這種可能性並不是很大,另外一個猜測是因為這些場景因為動態小而使用了低於4的quant,而我使用的mod對這些畫格進行了mpeg量化,效果說不定要h263要差,而divx5使用的量化永遠是h263,所以就有此區別。為此做了一些試驗,用h263/h263製作,效果。。似乎是好了些,但是仍然沒有完全解決。
看來還是有其他原因,我的猜測是xvid的碼率分配差別太大,這種場景需要的碼率分配過小,也就是說xvid的曲線要比divx5波動更大,所以導致了這種情況。其實做一個試驗就能夠判斷是否如此:用xvid和divx5用同樣的解析度壓一個全片,然後把這一段在xvid下似乎碼率不夠的片斷切下來比較文件大小,就可以得知,但是我一直沒時間做這個比較。。前兩天用xvid壓了一個全片,看來是時候用divx5也壓一個了,反正編碼速度比xvid快很多,不是什麼麻煩事情
(說起編碼速度,大家都知道xvid現在實在太不人道,各項功能開啟後連p4 2G也過不了10fps,已經可以和wme9的2pass一爭高下了,看來這也應該是xvid開發小組應該考慮的問題,至少應該讓mvhint支持b畫格和qpel吧。。divx5因為建立motion vector文件,2nd pass的時候速度的提高非常明顯,xvid本來也有這一手,可惜最近被廢了,一直沒跟進 )
說遠了,還是回到原話題。
既然xvid的曲線波動太大,導致低碼率的時候碼率太小,除非xvid能改進這點,不然曲線壓縮還是必需的,今天一早起來,看見silky兄再次提起GKnot,手又癢了,不過恐怕是沒時間了,要到今晚甚至深夜才有時間回家試驗。手上已經有一個用linear scale做出來的全片和stats文件,只要再做一個用GK處理過stats文件的2nd pass就可以比較了。

說起B畫格,那個公式我也算過,得出的結果和你一樣:B畫格的quant值是應該比前後畫格的quant要大,只是我沒想到xvid在debugview下的b畫格顯示是錯誤的,所以一直在迷糊。現在給你這樣一說,總算明白了 ratio和offset的數值設定也可以放心套用公式了

rrv其實可以和lumi masking配合操作嘛,至少在色彩相同的區域內應該大有作為,例如電影裡面經常出現的白色或者黑色區域,當然,還有動畫片這種有大量色彩塊的編碼
xvid應該像MS學習,做一些用戶友好的界面,例如做一些模組出來:選這個做高動態action movie、選這個做低動態文藝電影、選那個做動畫片、選最後一個進入advanced user界面,就是我們現在見到的那個界面
當然這種可能性太小了,畢竟是一個公開的project,不是商業軟體,沒人會在乎的

Q:
DivX5.02至今仍讓我感到佩服的就是其使用方便和穩定性,畢竟他們想走商業化的路子...
A:

我雖然不懂理論計算,但是反覆比較這兩個CODEC壓縮的東西,還是覺得XVID好過DIVX5!
顏色和圖像還原都優於DIVX!特別是背景的壓縮處理,DIVX差之甚遠!
Q:
我選項了"QUARTEPEL"沒有選"換勾選ENABLE LUMI MASKING"和"MPEG"沒有選"H263",
效果很好,尺寸也控制得好!

A:
2PASS時勾選QUARTEPEL對菜鳥而言可能有問題,
噪點的增加超過了清晰度的增加,已到了使圖像失真的地步.
又作了幾次比較!
覺得我寧可只選項"QUARTE PEL"也不會選項"Chroma Motion"!
後者帶來的結果是增加背景馬賽克!
這是我只選項"QUARTE PEL"沒有用""Chroma Motion"選項的"第一滴血"的截圖總共大小715MB(包括音瀕MP3 192K)
沒有噪點!

Q:
照菜鳥密籍已修改了B畫格的設定參數:
3
100
1
並取消1PASS時QPEL的選項,
犧牲10-20的品質達到提高速度50%以上的目的.
A:
3是什麼?
100是什麼?
1又是什麼?
速度是很重要!
不過我更偏重質量!
做一個120分鐘的XVID要6個小時!
我的機器配置差,所以速度上不去!



Q:
讀取1_PASS時DEBUGVIEW得到的LOG文件的最後一行中total-kbytes:XXXXXXXX,用其除以目標文件的大小的到的比值乘以2,四捨五入即為估計的QUANT值的上限.
(還是不明白)
total-kbytes:532312 bframe quant:2 H.263 kblocks:2 mblocks:1194
是不是用532312以200(我想最終目標的容量)得值再X以2呢?..出來的值很大喔.QUANT不會那麼大吧?

A:
一個是Kbyte,你要的目標容量是M(=1024K)
所以應該是(532312/(200X1024))x2=5.2,四捨五入得5
Q:
!!下有點問題想請教.初學者呀.有許多不明.多多指點!

設定I畫格和P畫格的最小和最大的QUANTIZER,依據前面估算的QUANTIZER值為最大值,減2為最小值.

意思是不是我估算 出來的是5,那麼MIN\I按照上面說.就是3..MAX值就是5? MIN\P和MAX值也是3和5?

按照上面說的.卡了QPEL可以少容量前提.保證畫質

那麼一般24分鐘左右的片.不含音瀕率.做成200M.有沒有必要開呢?

A:

有關2PASS時QUANT的上下限的估算的理解是對的,這也是密籍的亮點之一,控制上下限的目的是讓QUAN集中在一個最好的可接受水準.

舉例,如果一個QUANT3的畫格只用QUANT4來處理,那麼省出來的碼率可一把幾個QUANT6的畫格拉回到QUANT5,因QUANT5以下的畫格所需的碼率是按幾何數字增長的.

控制QUANT值的最高境界是把其控制在兩級的水準上,即X和X-1 OR X+1,但這可能要用3PASS才能實現.

密籍的亮點之二是有關B畫格設定,RADIO和OFFSET預設的設定可能是150/100,安照此設定2CD碼率時都會有>QUANT6的劣質B畫格出現,1CD碼率時則會有>QUANT10的B畫格出現,儘管DEBUGVIEW統計的QUANT的分散看上去是不錯的,但其B畫格的QUANT的原始資料是錯的.

1PASS時用QPEL採集可以使少數畫格的細節提高(約10%-30%畫格),特別是對細節豐富品質超群的DVD源,如D9原版或直灌碟.如果覺的油多不壞菜就用吧.

Q:

1PASS時用QPEL採集可以使少數畫格的細節提高(約10%-30%畫格),特別是對細節豐富品質超群的DVD源,如D9原版或直灌碟.如果覺的油多不壞菜就用吧.


如果在2PASS的時候再用.會更好或者又有什麼作用呢?


A:

1PASS時用QPEL主要是影響碼率分配,細節多的畫格得到相對多一點的碼率.
可以逐畫格分析一下某個片段1PASS時在DEBUGVIEW的每畫格的碼率變化,不難看到啟用QPEL後沒畫格碼率的起伏變化比不用QBEL來的要大,特別是對應與那些細節多動態大的的場景,QPEL的每畫格的碼率可以高出非QPEL的15%以上,而平均的文件體積才增大5%左右
2PASS時用QPEL則是實際按過採集取樣壓縮,直接的副作用是帶來細節的不真實的地增加,產生噪點,浪費碼率.

Q:

如果只看DEBUGVIEW的統計數字或個別的畫格一定是預設的好.
設定QUANT的上下限的目的是為了杜絕全片都不出現壞畫格.


A:

菜鳥密籍第三版:
1PASS B畫格參數設定:3/100/1
2PASS B畫格參數設定:3/100/100
經測試1PASS選3/100/1構造碼率曲線能夠最大地保障B畫格的質量.
2PASS時選3/100/100能適當地對B畫格進行壓縮,取得QUANT的平衡.
Q:

我在想,可接受的量化因子的範圍到底是多少?是否照此做法,所有影片的Q值不是3∼5就是4∼6,還可能有別的嗎?如果超出這個範圍,是不是就應該改變預期文件大小了?

A:
個人經驗,5以下絕大部分畫格都可以接受,超過5的話很多畫格會惡化,這可以用具體電影的某幾小段用不同的1pass-quant值測試。
如果codec演算正確,應該不會有其他quant的出現。小嘴巴本來是想把IPB畫格全部限定在2個連續QUANT內,可惜XVID的B畫格有怪異問題出現,只能+1了
如果不限定這個範圍,少量QUANT值可能會比較大,通常只佔2~3%(甚至更小)的比例,雖然不多,但是造成壞畫格的原因基本都是這些QUANT,所以要挖下面補上面,越平均越好。
這個範圍是由預期文件大小而決定的,所以QUANT值要用"1PASS/預期文件大小"的比例再乘1PASS的QUANT(2),由此可以預期文件越小,結果的平均QUANT值就更大。。。
嘴巴兄的理想是用一個QUANT值按照曲線壓成精確文件大小,當然這是不可能的,所以要用兩種QUANT值再配合B畫格湊合著算了

Q:
Chroma Motion
它有什麼作用的?

A:
簡單地說,一般的ME是通過Y值(亮度)搜尋,CM提供色彩搜尋(UV值),更加精確,在某種程度上可以看成是Motion Search Presicion 7 (當然,會增加編碼時間。。)
DivX5.02據說只提供Y值搜尋,所以XviD的ME更先進--通過壓縮動畫片可以體會這一點。


Q:
我都是用2-6隨它去,一般沒問題。我用1209koepi壓的「尋槍」,有興趣的看一下批評指教
ed2k://|file|The.Missing.Gun.(2002).Xvid.vsa.avi|731156480|ed5ae0e70b1541e0ff546fa12ceeb051|/
ed2k://|file|The.Missing.Gun.(2002).Xvid.vsa.Subtitles.(Eng+Chs).rar|1391036|e05275251d925360011bcf6e93de369f|/

A:
還從來沒在donkey上下過完整電影。。
其實就算用koepi定的預設值,什麼都不改,一般片子做出來的效果也沒多大問題了,玩法不同而已。

Q:
我都是用2-6隨它去,一般沒問題。我用1209koepi壓的「尋槍」,有興趣的看一下批評指教
ed2k://|file|The.Missing.Gun.(2002).Xvid.vsa.avi|731156480|ed5ae0e70b1541e0ff546fa12ceeb051|/
ed2k://|file|The.Missing.Gun.(2002).Xvid.vsa.Subtitles.(Eng+Chs).rar|1391036|e05275251d925360011bcf6e93de369f|/

A:
QUAN 2-6 的應該不如QUAN 3-5的.
因為Q2比Q3不會有多少差別,而Q6比Q5就要差很多.
對一些長時間(>2小時),高細節動態(D9),高解析度的(720X XXX,640X480)的RIP,1CD碼率時Q6的上限往往會不夠,結果是文件體積超標.
1209K的碼率經驗上QUANT的上限可控制在Q5或更低.
簡單地說,一般的ME是通過Y值(亮度)搜尋,CM提供色彩搜尋(UV值),更加精確,在某種程度上可以看成是Motion Search Presicion 7 (當然,會增加編碼時間。。)
DivX5.02據說只提供Y值搜尋,所以XviD的ME更先進--通過壓縮動畫片可以體會這一點。

個人意見,我覺得 1st-pass 的設定要和 2nd-pass 的設定一致比較好,
從理論上來說,這樣編碼器的碼率控制器(bitrate control)才能準確的工作。
碼率控制器根據 1st-pass 壓出來的每個 frame 的 size 做 scaling 調整大小,
也就是 2nd-pass 壓縮的時候調整 quantizer 控制每個 frame 的 size 接近 scaled 後的大小,
如果因為 2nd-pass 的設定不一樣,造成壓出來的 frame size 和預測的差很多,
碼率控制器就無法準確的預測使用的 bit 超出(overflow)的情形,
做出適當的補償(payback),這樣便可能會發生無法預期的結果。
當然這是從理論上來說,實際壓出來不一定會有不好的結果,因為實際的情況可能是很複雜的,
小弟只是提供一點理論面的說法,大家參考看看,如果有時間的話可以反覆多壓幾次,
做做實驗

另外建議如果是要儲存用的影片,最好不要在最終的產生結果使用 qpel。
目前 XviD 的 qpel 使用 XviD 自己的 xvid.dll 這個 vfw codec 播放是正常的,
不過這是理所當然的
如果用 ffdshow,也就是 libavcodec 這個譯碼器播放,水準/垂直/水準加垂直 三種 interpolation
都不正確,DivX 5 的譯碼器播放 水準/垂直 看起來好像沒有問題,但是 水準加垂直 還是不正確。
這種錯誤一開始並不明顯,但是如果一直參考同一個位置,連續 100 個 frame 以後就會變得很明顯。
(因為各家譯碼器對 qpel interpolation 內插補值的作法不一樣,造成補償加上去的差值不一樣,
這個錯誤會一直累積,連續 100 frames 之後就會變成非常明顯的錯誤瑕疵)

因為 DivX 5 的 qpel 的作法本來就不正確,不符合標準 ISO MPEG-4 的規範,
所以 DivX 5 不能正確解碼 XviD 的 qpel 無所謂。
但是使用 MS MPEG-4 FADM 這個 MS 作的 100% 標準的 MPEG-4 軟體來譯碼也不正確,
這個問題就很嚴重了,這代表目前 XviD 的 qpel 可能有相容性(正確性)的問題。
淒慘的是,目前幾個 MPEG-4 譯碼軟體 XviD/ffdshow/DivX 5/Envivio TV 對 qpel 的 interpolation
作法都不一樣,到底是誰做錯?難道大家都做錯?還要再研究。
(也許根本沒人看懂 ISO 的標準說明文件到底在寫什麼 )

XviD 的開發人員之一 Isibaar(Michael Militzer)目前還在研究,尋找到底是哪裡有問題。
XviD 的目標是要作出完全標準的 MPEG-4 視訊編譯碼器,「不標準的 MPEG-4 編譯碼器
有 DivX 5 一個就夠了」他笑著說。
所以如果你考慮到將來播放、相容性的問題,最好不要在儲存用的影片上使用 qpel。
不過 1st-pass 的時候使用 qpel 倒是沒有關係,因為並不是 qpel 有錯誤,
只是各家的作法不一樣,造成在不同譯碼器上播放有不同的結果,這對 1st-pass 使用 qpel
不會造成任何影響。
(雖然我還是建議 1st-pass 的設定要和 2nd-pass 一致 )

再次提醒,Koepi/Nic/uManiac 提供的最新的 binary 是開發中的版本(development, unstable),
任何新加入的功能都可能有著錯誤、相容性問題的危險,這些新功能不見得能夠提高壓縮率,
帶來高畫質,相反的它可能會製造充滿錯誤的壓縮結果,所以如果您是想用它來壓縮要儲存的影片,
在勾選這些功能之前請確定你知道你在做什麼。
XviD 的主要開發人員之一 gruel 很擔憂的說,GMC 現在充滿了 bug,甚至無法正確的譯碼,
但是已經有人使用 GMC 來壓縮要儲存的影片,他可以想見將來這些使用者發現過去壓縮的影片
無法正確譯碼的時候,將會是多麼的憤怒,論壇上將會充斥著這些使用者抱怨的聲音。
到時候開發小組的回答恐怕只能是:
「既然你知道這是 unstable、開發中的版本,既然你根本不曉得那些選項是做什麼用的,
那你為什麼還用它?」

目前已知比較安全應該沒有問題的新功能:
1. Chroma Motion
實際上就是動作估計(ME)的時候多做色彩平面上的動作向量搜尋,讓 ME 的結果更精確,
找到更小的誤差,可以視為是 Motion Search - 7,完全沒有規格上的爭議,不會有錯誤,
所以相當安全。

2. B-frame
應該已經很穩定了,測試過各家譯碼器解碼大致上都正確,視情況動態插入 B-frame 的設計更是
XviD 的首創。B-frame 功能是目前能提供最大壓縮率的利器,但是要注意的是 "一定" 要勾選
"DX50 B-VOP compatibility" 這個選項,禁止 B-VOP(B-frame)的下一張參考畫面是 I-VOP,
否則這個 B-VOP 會出現一堆錯誤的方塊。這個錯誤雖然只有一個 frame,畫面一閃而過,
但是注意看的話還是會發現,所以請 "一定" 要勾選 "DX50 B-VOP compatibility"。

比較有爭議的新功能:
1. Qpel
理由如上所述。
如果你不在意相容性的問題,不在乎壓出來的東西是否合於標準的 MPEG-4 規範,
不打算未來在家電產品上播放目前壓的 MPEG-4 影片,並且只打算在電腦上使用 xvid.dll 播放,
那麼可以使用這個功能。

2. GMC
開發中,功能簡陋,完全沒有實質上的壓縮助益,並且還有錯誤需要修正,絕對不要使用。
DivX 5 的 GMC 也一樣,功能簡陋,不會比 XviD 好多少,XviD 的 GMC 很快的就會超越 DivX 5。

3. Modulated Quantization Type
動態切換 H.263/MPEG 的量化方式。這個 ISO 沒有明文規定不可以,而且目前的譯碼器都支持
Modulated Quant,播放上完全沒有問題,但是... 還是有隱憂,因為不保證將來的家電產品
一定都可以解 Modulated Quant,畢竟文件上沒有要求要有這種規格。

如果你覺得將來太遙遠,到時候可能都已經不用 MPEG-4 part 2(目前的 MPEG-4 視訊壓縮法),
而改用壓縮率更高,更強大,更先進的 MPEG-4 part 10(或者叫 MPEG-4 AVC,Advanced Visual
Coding,先進視訊編碼法,也就是 ITU 的 H.264,舊名叫 H.26L)來編碼,所以將來支不支持
舊的壓縮法,對你來說都無關緊要,那麼可以使用這個功能。

以上提供給大家做為參考。


這次寫太短了,後面加一些不相關的討論跟大家閒聊

最近 Doom9 有一篇在討論如何壓出最高品質的帖子,討論到使用 quantizer 1 的問題,
為什麼以前不建議使用 quantizer 1 呢?
quantizer 1 使用「非線性量化表」對應的量化倍數是 1x,
也就是 DCT 係數直接除量化矩陣。這樣的失真應該最小,品質應該最好,
為什麼反而不建議使用呢?

因為 XviD 使用的 iDCT(inverse DCT,反向 DCT 運算),會做捨棄小數,如果 quant = 1,
則矩陣中很可能會出現非常小的 DCT 係數(沒有被除為零),
這些 DCT 係數在壓縮時會經過 iDCT 轉換回來當成參考畫面。
(壓縮器當中必須包含譯碼器才能將壓縮過的畫面解回來當作參考畫面)

此時這些很小的係數會造成非零的 iDCT 輸入,解出來卻因為捨棄小數的關係而變成為零的輸出。
這樣子很浪費 bit,因為這些 iDCT 後為 0 的 block 本來應該 skip 掉,試想補償時加上差值
為 0 的補償要做什麼?這樣子不是等於沒補償?那花費 bit 去記錄這些資料不是很浪費?
而且在 MPEG-4 規範中,這是不可以的。
如果播放的譯碼器使用的是和壓縮器不同的 iDCT(iDCT 的算法有很多種,有的速度快,
有的算得很精確,沒有規定譯碼器一定要用哪一種 iDCT 算法,所以不同譯碼器畫質也可能不同),
播放端譯碼器的 iDCT 輸出可能不為零,這樣就慘了,原本壓縮時,參考畫面是輸出為零的結果,
現在解壓縮時,參考畫面卻不是為零,這個錯誤會一直累積,慢慢的畫面上就會出現肉眼看得到的瑕疵。

這個叫做壓縮器/譯碼器 iDCT mismatch 的問題。
解決這個 zero-iDCT 問題的方法,
1. 不要用 quantizer 1 (MS MPEG-4 和 DivX 5 都不用 quantizer 1)
2. 利用 TOO SMALL LIMIT 這個參數,當 block 中的 DCT 總和小於一定門坎就 skip 掉,
一般情況下是設為 1,遇到 quant =1 時調整為 2,防止 sum = 1,iDCT 後卻變成 0 的情況。

XviD 已經用 2 的方法解決這個問題,不過以前說過 TOO SMALL LIMIT 太高,會損失細節。
所以到底用 quantizer 1 好不好?我試壓了幾個 clip,quantizer 1 的畫質還是明顯比較好,
不過壓出來的檔案非常非常大 ^^;


我們知道 resize 最強的計算方法是 lanczos3,這個計算法轉換後的畫面既銳利、而且又沒有
aliasing/ringing 的問題。壓縮 lanzcos3 resize 的畫面,銳利的線條、物體的邊緣不容易
出現擴散的,斑斑點點的壓縮噪訊。也就是雖然 lanzcos3 畫面銳利,但是又不會增加太多的
壓縮困難度。這是因為 lanzcos3 的計算法本身就等於一個完美的 Low Pass Filter,
不像其它的 resize 法為了要設計一個適當的 LPF 而傷透腦筋。
這個 resize 法本來是由一個很厲害的人實作在 AviUtl 這個軟體上,做成 AviUtl 的 plug-in。
後來西方有人注意到這個好用、畫面又漂亮的 resize 法,於是提議 Avisynth 加入這個 filter。
因為越來越多人使用,成為大家公認的最棒的 resize 法,所以 VD 的作者也在 1.4.13 版加入了
這個 resize。
我以前都是用 AviUtl 的 lanzcos3,不過因為 AviUtl 的速度實在太慢,所以想說改用 VD 內建的
來試試看,結果...
不知道 VD 的作者是怎麼作的,VD 的 lanzcos3 aliasing 得非常嚴重,resize 後的畫面鋸齒得
很厲害,壓出來的線條周圍噪訊飛散,慘不忍睹,就像 bicubic 的算法如果設定成銳利化得太厲害,
壓縮後的線條周圍會都是噪訊一樣。
所以,建議大家不要用 VD 的 lanzcos3
我沒用過 Avisynth 的版本,不過我相信 Avisynth 作的應該是對的
MPEG-4 AVC,全名應該是
Advanced Video Coding
壓縮效率是現有的 MPEG-4 ASP 的 2 倍,
只要 50% 的檔案大小就可以達到和原來相同的品質,
2 CD 可以變成 1 CD
因為壓縮法非常複雜,壓縮速度非常非常慢,
期待它明年正式被 ISO/JVT 標準化,然後實用化的一天到來
我說短點
xvid.ax或者ffdshow解碼qpel都不行,xvid.dll雖然好一點,還是可以看出額外的雜質,一句話:xvid的qpel interpolation還是沒完善。
B畫格穩定是穩定了,但是ratio,offset的設定不能隨意,不然出來的效果比不用B畫格還差。
盡量不要使用Dub中的filter,盡量使用avisynth以保證速度和質量

Q:

我也覺得理論歸理論,實際上做起來可能會有很大的差異。
而且理論也不一定 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 也應該會投入開發的工作
A:

就看見兩位在長篇大論。。
H264如果不借助硬體壓縮解壓,我懷疑3年內都不能被使用。不知道還有沒有人記得VCD剛在電腦上推出的時候PC的主頻是多少?那時候還得需要解壓卡才可以順利播放,呵呵。現在就算是最便宜機種的PC在播放MPEG1的時候也是順暢自如吧。
DivX5.02和XviD的B畫格資料含量和P畫格差不多,我想也是因為ME已經比MPEG1/2複雜多了的原因,別忘了上述兩種MPEG的壓縮效率是比MPEG4來得低,Vector記錄的優勢比較明顯,B畫格可以輕鬆達到P畫格的1/2大小,在MPEG4上就比較難體現這點,本來記錄MACROBLOCK的DATA已經不大,加上還要記錄4個BLOCK的移動位置,不增加一下QUANT值,大小還真差不多。
R9和W9算法如何還是摸不清楚,不過可以肯定的是編碼的時候加了FILTER,所以才會有乾淨的效果而且可以保留相當一部分的細節。實際上很多人在做RIP的時候也使用filters,再沒有源文件比較的情況下,觀看效果還是很不錯的,而且類似簡單去噪的插件還可以減輕編碼的壓力減少錯誤的出現。R9和W9雖然看上去更先進,可是我不太相信他們使用了多少AVC的東西,仔細看一下就知道AVC不但需要極其費時的編碼時間,解碼也是相當耗時的,就算做了出來,能有多少PC可以播放?B畫格參考不只兩畫格?BLOCK可以不是正方形?我就不信P4 3G可以正常播放。但是實際上R9和W9播放時CPU的佔有率還是相當低的--比XD或者DX都低。
Q:

啊,沒錯,我都忘了 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 跑一遍求得類BIOS品質的壓縮結果
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.
A:
很喜歡看兄的長篇大論

linear scaling只能算不是辦法的辦法,當初ko興高采烈地建議大家用他的stats reader我就納悶了:這有什麼好高興的?1st pass的碼率分配不管有多完美,2nd pass的時候低碼率不可能夠用的,特別是B畫格更容易因為碼率不夠QUANT值過大而惡化,好事變壞事了。更有趣的是,他還把這一套做成2nd pass internal的default

上次看了兄用GK壓縮stats文件的辦法後做了一次全片試驗,發現處理過後的stats文件中的碼率分配曲線被壓平了很多,碼率從高補低的感覺很明顯,不過當時我的B畫格設定還是使用4/150/100,兩個結果我都不滿意。。昨天看GK出了0.27版,看了一下,核心部分(stats計算)沒有絲毫改變,對XviD還是沒支持,有點失望。。不過可能作者也認為XviD還沒完全成熟,不想過早趟混水吧,現在網上對XviD的各種怪毛病的抱怨已經夠多了。

補充一下。。我對B畫格的計算公式相當不滿意。((a+b)/2*ratio+offset)/100,可以看出IP的QUANT越高的時候,B的QUANT也「幾乎」是成比例上升。我個人認為如果IP畫格QUANT值小的時候,B畫格的QUANT倒是可以適當調高點,現在是剛好相反的情形,難怪片子某些部分畫質相當好,某些部分連DivX5都不如了。除非他們改B畫格控制的方式,不然我認為把ratio調成100%是目前比較合理的做法。offset就難說了,100或者200都應該可以接受,要看具體情況。

Q:
以在1PASS時我們盡量保障這裡B畫格分配到多一點碼率,如設定B畫格的參數為100/1,2PASS時SCALING實際的壓縮碼率就比較多,防止了該B畫格的QUANT值明顯劣化.
2PASS時B畫格的壓縮設定參數,我們都認為現有條件下100/100比較好,控制B畫格的QUANT最多只劣化1.雖然全片的QUANT均值會有1-2的抬高,但6或以下的QUANT都是可以接受的可觀看水準.當然如果還100/1,就失去了B畫格壓縮效率高的意義.

另外QUANT的大小高低也是相對的,當1PASAS時QUANT2碼率分配多時2PASS SCALING的碼率就多,QUANT的值就高,但不一定與源比起來就是品質不好,試想如果1PASS用QUANT1構造碼率分配曲線,2PASS得到的平均的QUANT值就一定高於1PASS 用QUANT2採集的,但最後的的品質不但不會下降,反而會有提高.

最後,個人感覺XVID的B畫格效率還是有很大的改善餘地,與MPG壓縮比起來,起B畫格的壓縮效率看上去是很低的,如果你選100/1得到1PASS 文件體積,將與不用B畫格的時候相當或更大.

A:
我用兩種參數壓縮了同樣的影片,發現還是
Q 2-6
的效果好於 3-5
而且加了QuarterPel的效果比沒有加要好!

Q:
我用兩種參數壓縮了同樣的影片,發現還是
Q 2-6
的效果好於 3-5
而且加了QuarterPel的效果比沒有加要好!

A:
2-6/3-5或者用不用qpel其實是口味問題。。不過你這兩幅圖差別也太大了,上圖有些部分在下圖完全黑掉,不像是單純qpel使用的差別。
你用什麼方式截的圖?vfw解碼還是directshow的?

截圖比較方法的好壞是有一定的片面性的,在不能統計出全段/片的PSNR數值時,只有相信自己的眼睛和相信DEBUGVIEW的到的QUANT均值水準和分散了.
目前我們只能從理論上承認,如1PASS采樣方法一樣,2PASS時得到的QUANT值小的就意味著品質好,比較截圖時最好也能知道其對應的QUANT數值,否則難免有用上等馬對下等馬之嫌.
另外:最好能比較B畫格的截圖,因為XVID的B畫格設定問題較多.
也上兩圖:一圖是1P_3/100/1+2P_3/100/100 Q6-7 壓的,另一是預設的B畫格設定壓的.
解析度640X480 碼率約為750K


Q:
話又說回來,我還是不喜歡XViD... ...
現在依然使用SBC

A:
SBC已是昨日黃花了,用DX311的編碼壓片會遇到許多片子都壓不好的情況,上次有位大俠就指出過一段動畫片壓不好,結果RTZ大大測試後認為是311編碼本身的不足所致.
今天我也給你一段普通的DVDRIP片段,4.75M,因為是相對靜態的場景,你用1CD(750K)的碼率把它壓的好一點嗎?用XVID壓縮時這是輕而易舉能辦到的
640X272
HTTP://24.78.61.250/TEST.RAR


Q:
2個小時的片子怎麼設定才能避免背景馬賽克!

A:
主要的手段是提高碼率或降低分辯率
保障該畫格的QUAN不高於6
次要的手段是使使細節減少圖像柔和模糊,可以用H263和一些濾鏡來
Q:
我反覆用幾種辦法,在保持原橫向解析度720的情況下,壓縮120的電影,背景都出現方格!
只要電影長度保持在90分鐘的話!效果就很好!
一旦超過
我試一試你的辦法!

A:不要用大於640的解析度!即使在今天,仍有一半以上的電腦播放這種文件有困難。關鍵是,大多數顯示卡不提供大於640x480的YUV overlay surface。


2小時的片子還用720的話,碼率恐怕不夠
除了用h263和加濾鏡外,還可以考慮用ogg音軌



Q:
DIVX 不是YV12嗎?和YUV 有何差別?
可不可以改成YUV420
如果DVD都可以看,那麼為什麼DIVX不行呢?

A:
YUV是統稱,包括一大堆格式,互相可以快速轉換。顯示卡一般並不提供這麼多格式的支持,而是只支持常用的一種或幾種。但是,很多顯示卡都不支持任何一種超過640的YUV Overlay。
DVD也不是什麼機器都能播放的,不過,顯示卡有些功能是用來輔助DVD解碼的,對MPEG4卻沒有說明 ,所以解碼MPEG4對CPU的要求更高一些。
MPEG 儲存的 YU(Cb)V(Cr) 格式是遵循 CCIR601,也就是 ITU-R BT.601 的規範,Y 亮度的範圍是 16~235,UV(CbCr) 色度是以無色 =128 為中心,範圍是 16~240。
一般民生消費產品使用的 MPEG 壓縮,大都採用 YUV 4:2:0 的格式,也就是如果分辦率是 720x576,則每個 Frame,Y 有 720x576 個點,U 只有 360x288 個點,V 也只有 360x288 個點。色度的信息只有亮度的 1/4。那麼為什麼不寫 YUV 4:1:1(UV 和 Y 的比例是 1:4) 而要寫 YUV 4:2:0?這是因為要區分取樣的方式不同。YUV 4:1:1 是指水準 Y 取樣四個點,UV 各只取樣一個點,水準的 Y 和 UV 的取樣比例是 4:1,也就是
Y Y Y Y 一個 U 一個 V ....

YUV 4:2:0 是指水準和垂直 Y 各取樣兩個點,UV 各只取樣一個點,水準的取樣比例是 2:1,重直的取樣比例 2:1,也就是
Y Y
Y Y 一個 U 一個 V ....

和 YUV 4:1:1 一樣,色度和亮度差 1/2 * 1/2 = 1/4,只是取樣的方式不同。

而 MPEG 最常採用的 YUV 4:2:0 格式,其 UV 的取樣位置,MPEG-1 和 MPEG-2 又不同(MPEG-4 是用和 MPEG-2 一樣的取樣位置)
MPEG-1
Y Y
_x
Y Y

x 是 UV 的取樣位置

MPEG-2
Y Y
x
Y Y

x 是 UV 的取樣位置


瞭解了 YUV 4:2:0 以後,我們來看什麼是 YV12,什麼是 YUY2。
在個人電腦上,這些 YUV 讀出來以後會以一些格式包裝起來,送給軟體或硬體處理。包裝的方式分成兩種,一種是 packed format,把 Y 和相對應的 UV 包在一起。另一種是 planar format,把 Y 和 U 和 V 三種分別包裝,拆成三個 plane(平面)。
其中 YV12 和 YUY2 都是一種 YUV 的包裝格式,而且兩種都是 packed format。
YV12 和 YUY2 的不同,在於 YV12 是 YUV 4:2:0 格式,也就是 DVD/VCD 上原本儲存的格式。YUY2 則是 YUV 4:2:2 格式,也就是

Y Y 一個 UV Y Y 一個 UV ....

水準取樣比例是 1/2
重直取樣比例是 1/1,也就是垂直 UV 和 Y 的個數一樣多
以解析度來講,就是 Y 720x576 U 360x576 V 360x576。

至於詳細的包裝格式,這裡就不畫圖了,請參考
http://www.fourcc.org/fccyuv.htm
http://msdn.microsoft.com/library/de...YUVFormats.asp


以 DVD/VCD 的播放來說,讀出來的 YUV 4:2:0 包成 YV12 的格式,如果顯示卡有支持 YV12 的 FourCC Codec,播放時就會直接走 DirectDraw YV12 Overlay,直接丟 YV12 的資料給顯示卡處理,由顯示卡去做 YUV 4:2:0 展開(內插補點)-> YUV 4:2:2 -> YUV 4:4:4 -> RGB32,也就是色彩空間轉換的的工作。如果你的螢幕解析度大於影片原始分辦率,顯示卡還要做 scaling,也就是放大畫面的動作,將影片的分辦率放大到和你的螢幕的分辦率相同,例如 640x480 -> 1024x768。(內插補點,補出不足的點)
所以顯示卡的 YUV 4:2:0 -> 4:4:4 內插補點的好壞第一個就影響 MPEG 的播放品質,如果顯示卡的 interpolating filter 不好,色彩補得不夠平滑,紅色的部分(人眼對紅色較敏感,特別容易看出)就會出現一格一格的鋸齒狀。
再來就是顯示卡的 scaling filter,放大補點的好壞,放大補點不好,畫面就容易出現鋸齒或是變得模糊不夠清晰。

YV12 是最多顯示卡支持的格式,傳輸的資料只有 YUV 4:2:0,比 RGB32 少很多,速度最快,所以大部分的軟體都用這種格式傳送資料。然而這種格式在遇到 interlaced 場線交錯的畫面的時候,會發生色度譯碼錯誤的問題。這個問題說起來很複雜,再講個這篇文章又會太長,有興趣的人可以參考 DVD2AVI 作者的網頁,他有詳細的說明,這個譯碼錯誤的問題也是他撰寫 DVD2AVI 這個軟體的原因:
The decoding problem with interlaced frame of most software MPEG-2 decoders
http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/interlace/

另一種錯誤,發生在 progressive frame 上
http://www.hometheaterhifi.com/volum...ug-4-2001.html

這個說起來太長,有機會我再解釋。

另一種一般的格式,就是 YUY2,也有許多顯示卡支持,PowerDVD 為了解決上述的交錯線彩色信息譯碼錯誤的問題便是使用這種格式。YUY2 也就是 YUV 4:2:2 的一種包裝形式,播放時軟體會先自己做 YUV 4:2:0 -> YUV 4:2:2 的內插補點(upsampling),做好以後再將 YUV 4:2:2 包成 YUY2,走 DirectDraw YUY2 Overlay,直接丟資料給顯示卡,由顯示卡去做後續的 YUV 4:2:2 -> 4:4:4 -> RGB32 的工作。

我們再來看顯示卡的 DirectDraw Overlay 什麼時候會啟動,這個很重要,因為由以上可知,如果不使用 DirectDraw Overlay,而走傳統的 GDI(Graphic Display Interface)圖形顯示接頭,顯示速度會很慢
1. 無法使用 DirectDraw 硬體加速,無法使用硬體的內插補點和色彩空間轉換,CPU 負擔非常重
2. 直接傳送 RGB32,資料量大。無法使用顯示卡的 scaling/interpolating filter,放大到全螢幕幕,會鋸齒方塊一格一格的非常難看。

所以 DirectDraw Overlay 有沒有啟動非常重要,現在大部分的顯示卡,即使在高分辦率的時候,DirectDraw Overlay 還是會啟動,尤其是 ATI 的顯示卡,即使在超高分辦率的時候還是可以啟動。
但是大部分的顯示卡都有一個限制,那就是影片的分辦率,水準的點數必須能被 32 整除,這樣才能使用 DirectDraw Overlay。所以 GKnot 的 resize 選項,水準部分會有一個 32 Mod(能被 32 整除)的限制,就是這個原因。由上述可知,720 的水準分辦率不能被 32 整除,所以會有無法啟動 DirectDraw Overlay 的危險,為了最大的相容性,製作的影片水準分辦率最好是能夠被 32 整除。
附帶一提,垂直高度最好是能夠被 16 整除,因為 MPEG 壓縮是以 16x16 的巨方塊為服務機構壓縮,不是 16 的倍數的高度會製造壓縮困難,壓縮後可能會出現壓縮瑕疵。
最好是先做好 resize 再壓縮,不要以原始的分辦率 720x576 壓縮,播放時才調整比例作既時 resize。
既時 resize 的效果無法和慢慢計算的高品質 resize 相比,畫質會比較差,本來是想保留較多的原始訊息,結果播放時的 resize 不好,反而得不償失。


提到 YV12,順便聊一下最近引起熱烈討論的 Avisynth 2.5 alpha。
Avisynth 2.5 alpha 最大的特色,就是支持 YV12 直接處理。我們知道原始 MPEG 資料是 YUV 4:2:0,也就是 YV12 的格式,以前我們在做 DivX/XviD 壓縮的時候,處理流程是:
DVD/VCD(YUV 4:2:0) -> DVD2AVI(YUV 4:2:0 -> YUV 4:2:2 -> YUV 4:4:4 -> RGB24) -> VFAPI(RGB24) -> TMPGEnc/AviUtl/VirtualDub(RGB24) -> DivX/XviD Codec(RGB24 -> YUV 4:2:0) -> MPEG-4(YUV 4:2:0)

ps. VFAPI 內部只能以 RGB24 傳遞資料,所以會轉成 RGB24 輸出

或是
DVD/VCD(YUV 4:2:0) -> MPG2DEC.DLL(YUV 4:2:0 -> YUV 4:2:2) -> Avisynth 2.0.x(只能用支援 YUV 4:2:2 的 filter,不能用 RGB24/32 的 filter) -> VirtualDub(YUV 4:2:2,不能使用 VD 的 filter,因為 VD 的 filetr 都是在 RGB32 上處理,壓縮時要選 Fast recompress,才會直接原封不動的送 YUV 4:2:2,也就是 YUY2 的資料給 Codec 壓縮) -> DivX/XviD Codec(YUV 4:2:2 -> YUV 4:2:0) -> MPEG-4(YUV 4:2:0)

所以以前的處理流程中間要經過好幾次 YUV <-> RGB 的轉換。這個轉換是有損的,做得越多次,原始的色彩信息就損失的越嚴重。而且這個轉換的計算又耗時。那麼有人(Marc FD)就想到,反正最後轉成 MPEG 都要存成 YUV 4:2:0 的格式,那麼為什麼不乾脆一路到底,全程都以 YV12 處理,也就是所有的 filter 都改寫成 YV12 的版本,直接在 YV12 上做調整色彩、濾噪訊、IVTC 等工作,這樣
1. 處理的資料量少。(YV12 的資料,UV 比 YUY2 少一半,比 RGB 24/32 少更多)
2. 不用轉換計算

所以速度快。再加上又可以避免 YUV <-> RGB 轉換的損失,豈不是一舉兩得?
所以支持 YV12 的 Avisynth 2.5 就誕生了
但是目前 VirtualDub 還是不支持 YV12,即使選 Fast recompress,VD 還是會將 YV12 的輸入轉為 YUY2,所以要得到全程 YV12 處理的好處,必須使用 VirtualDubMod 這個軟體才行,這個改版才有支持 YV12(一樣要選 Fast recompress)。

不過因為我要用 TMPGEnc(只接受 RGB24/32),所以我還是沒使用全程 YV12 的方法


因為前面提到了 YUV 的數值範圍(Y: 16~235, UV: 16~240),之前 Doom9 上也有一篇 Lumi masking 的帖子在討論這個,不過.....,所以我順便轉貼以前寫的一篇文章給大家參考:



DVD/VCD/DV 等使用的 MPEG/MJPEG 壓縮,記錄的 YCbCr 格式,是遵循 ITU-R BT.601 的
規範,其資料範圍(動態範圍)為 Y(亮度)16~235,C(色度)以 128 為中心代表無色
,範圍 16~240。
做處理和顯示的時候,YCbCr 要轉為 RGB,其範圍為 16~235。
但是電腦螢幕上,純白的點,其 RGB 值為 (255,255,255),純黑的點,
其 RGB 為 (0,0,0)。所以 MPEG/MJPEG 所記錄的純白 (235,235,235) 在電腦螢幕上看起
來就不是純白,純黑 (16,16,16) 在電腦螢幕上看起來也不會是純黑。
因此 DV 錄下來的東西,拿到電腦上看,會覺得顏色變淡,好像照上了一層白紗。
同時因為資料範圍(動態範圍)縮小為 16~235,而不是全範圍(Full Scale)0~255,
所以會覺得對比不足(最亮和最暗的差距縮小),不如在電視上看漂亮。
所以在電腦上看、編輯 DV AVI,必需要先做 Y/C 伸張,也就是將 Y/C 的動態由原來的
16~235 擴展到 0~255,然後轉為 RGB 0~255,這樣在電腦螢幕上看到的顏色才會是正確的
。以此為基準作顏色校正、各種濾鏡處理,出來的結果才會是正確的。
經過 Y/C 伸張以後,然後才作各種的編輯。
最後要壓成 DVD/VCD/DV 的時候,因為仍然是存成 MPEG/MJPEG 格式,
資料範圍還是 16~235,所以已經做過 Y/C 伸張的影像在壓縮之前,必須先做 Y/C 壓縮,
把目前 RGB 0~255 的資料壓縮為 16~235,然後轉為 YCbCr 16~235,這樣才會正確。
不然超過的資料在轉為 YCbCr 16~235 的時候會被削掉(clipping),
對比、顏色會完全錯誤。

如果沒有編輯、修改畫面的必要,只是要將 DV AVI 直接做成 DVD/VCD,
則可以不必做 Y/C 伸張,直接壓縮為 DVD/VCD。
此時資料沒有做過 Y/C 伸張,所以壓縮的時候,不可以再做一次 Y/C 壓縮然後壓 MPEG,
否則做好的 DVD/VCD 即使在電視上播放,對比、顏色也會是錯的。

總結:
原始資料以 MPEG/MJPEG 儲存,為 Y/C 壓縮過的資料,
修改編輯時需先做 Y/C 伸張之後再修改。
若做過 Y/C 伸張,壓縮時需做 Y/C 壓縮,出來的畫面才是正確的。
若沒做過 Y/C 伸張,壓縮時不可以做 Y/C 壓縮,出來的畫面才是正確的。

以 TMPGEnc 這個壓縮軟體為例,壓縮時預設是接收 0~255 的 RGB 資料,
先做 Y/C 壓縮,然後才壓 MPEG。
所以如果是 YCbCr 16~235 的資料要對畫面做修改,必須使用 Descale CCIR601 這個濾鏡
(CCIR601 就是 ITU-R BT.601,CCIR 是 ITU 以前的名字),把 Luminous, Chroma 兩個
選項都推到 255(也就是做 Y/C 伸張),然後才做其它的編輯動作。
Descale CCIR601 的順位要排第一位。
然後壓縮時直接壓縮便可以得到正確的結果。
如果沒有要對畫面做修改,則不必做 Y/C 伸張,但是壓縮的時候必需要勾選
進階設定--> 量子化行列(Quantize matrix)底下的 "Basic YCbCr ?出力"
(Out YUV data as Basic YCbCr not CCIR601),這樣 TMPGEnc 壓縮時便不會
做 Y/C 壓縮,壓出來的顏色、對比才會正確。

總結:
如果原始資料是 YCbCr 16~235
有做 Y/C 伸張的話,壓縮時直接壓縮就好,不能勾選 "Basic YCbCr ?出力"。
沒有做 Y/C 伸張的話,壓縮時必須勾選 "Basic YCbCr ?出力"。

再以 Cinema Craft Encoder SP 這個壓縮軟體為例,設定選項的
"16 ??235" = TMPGEnc 不勾選 "Basic YCbCr ?出力" = 壓縮時先做 Y/C 壓縮
"0 ??255" = TMPGEnc 勾選 "Basic YCbCr ?出力" = 壓縮時不做 Y/C 壓縮

實際上 CCE SP 是用兩個不同的 YUV <--> RGB 轉換式,列在下面給有興趣的人參考:
"16 ??235"
Rd = 219*R + 16*256
Gd = 219*G + 16*256
Bd = 219*B + 16*256
Y = 77*Rd + 150*Gd + 29*Bd / 2^16
CR = (( 131*Rd - 110*Gd - 21*Bd ) / 2^16 ) +128
CB = (( -44*Rd - 87*Gd + 131*Bd ) / 2^16 ) +128

"0 ??255"
Y = 77*Rd + 150*Gd + 29*Bd / 2^8
CR = (( 131*Rd - 110*Gd - 21*Bd ) / 2^8 ) +128
CB = (( -44*Rd - 87*Gd + 131*Bd ) / 2^8 ) +128

而 YC 伸張的計算式是(簡略)
Y' = (Y - 16) * 255 / (235 - 16)
C' = C * 255 / (255 - (240-16))

再來探討兩個問題,第一個是 DV Codec 在輸出資料給壓縮軟體時,可能會輸出兩種格式
,第一種是直接輸出 YUV 4:1:1,由壓縮軟體自己去做 YUV --> RGB 的轉換。
第二種是由 Codec 內部先做 YUV --> RGB 轉換,再輸出 RGB 給壓縮軟體。
如果 Codec 是輸出 YUV 4:1:1,則轉換後的 RGB 範圍是 0~255(有做 Y/C 伸張)
還是 16~235(沒做 Y/C 伸張),由執行轉換的壓縮軟體決定。
如 TMPGEnc 的環境設定的選項中,有針對 Canopus DV Codec 做設定,提供你選項,
YUV --> RGB 轉換時,要用哪一種轉換式。有三種,Basic YCbCr,CCIR601,YUV。

如果是由 Codec 做轉換,輸出 RGB,則是否做伸張由 Codec 決定。
不同 Codec 有不同作法,是否有做伸張必須要做實驗才能確定。

如果 YUV --> RGB 時已經做過伸張,則 RGB 資料已經是 0~255 的範圍,
就不可以再用 Descale CCIR601 濾鏡,否則會有許多資料破表被削掉,切記。

第二個問題,壓縮軟體壓縮時,是否會先做 Y/C 壓縮?
如 MS MPEG-4 Codec,DivX Codec,XviD Codec 這幾個 Codec 都是假設收到的資料是
0~255,會先做 Y/C 壓縮的動作。那麼其它 Codec 和壓縮軟體呢?
這個也必須要做實驗驗證才能確定。

唯有解壓縮和壓縮的轉換式能正確搭配(做過 Y/C 伸張壓縮時就必須做 Y/C 壓縮,
沒做 Y/C 伸張壓縮時就不可以做 Y/C 壓縮)最後壓出來的成品才會是正確的。


補充一
DVD2AVI 的 Color Space 選 RGB/YUV 和 PC Scale/TV Scale 的差異

RGB 模式是輸出 RGB24,YV12 (YUV 4:2:0) --> YUY2 (YUV 4:2:2) --> RGB24,
由 dvd2avi 做內插展開(4:2:0 -> 4:2:2)和轉換的工作(YUV -> RGB)。
內插展開的算式作者的網站有寫,相當於 6-tap 的 FIR Filter。

YUV 模式是輸出 YUV 4:2:2(YUY2)。

輸出 RGB 時,preview 顯示會走傳統的 GDI 圖形顯示接頭,送 RGB24 的資料給顯示卡,
此時電腦螢幕上看到的顏色正不正確,由 YUV -> RGB 這個選項決定。
(要選 PC Scale 看到的顏色才會正確)

輸出 YUV 時,preview 顯示會走 DirectDraw YUY2 Overlay,直接送 YUY2 的資料
給顯示卡,由顯示卡去做展開和色空間轉換。顯示卡用的都是 PC Scale
(會做 Y/C 伸張,擴展原來的 16~235 的資料為 0~255),所以您可以在螢幕上
看到正確的顏色。

(同理,DVD/VCD 播放時,播放軟體會走 DirectDraw Overlay 丟 YUY2 或 YV12
的資料給顯示卡,由顯示卡來做展開、色空間轉換、和放大(scaling filter)的工作。
由於顯示卡用的是 PC Scale,會做 Y/C 伸張,所以您才可以在電腦螢幕上看到正確的
DVD/VCD 的顏色)

(前提是,做好的 DVD/VCD,其 YUV 4:2:0 的資料範圍必須是 16~235,
經過顯示卡 PC Scale 16~235 -> 0~255 才會正確。
如果 DVD/VCD 做錯,壓縮前沒有先做 Y/C 壓縮,儲存的是 0~255 的 YUV 資料,
則顯示時再經過顯示卡的 Y/C 伸張,會發生 clipping(資料超過範圍被削掉))

(而 16~235 的資料拿到電視上放,電視本來就吃 16~235 的資料,
所以顯示也是正常的)
(所以結論,DVD/VCD 上的資料,必須遵照 CCIR601 的規範,維持 16~235 的範圍)

至於輸出,也是按照 YUV/RGB 的設定,分別輸出 YUY2 和 RGB24。

但是如果您有用 vfapi,因為 vfapi 內部完全以 RGB24 傳送資料,
所以如果你把 .d2v 轉成 vfapi-ref-avi,即使 color space 選 YUV,
dvd2avi 也會做展開轉換成 RGB24 輸出。如果要用 dvd2avi 直接做 Y/C 伸張,
dvd2avi 的 YUV -> RGB 選項勾選 PC Scale 即可。

另外,如果用 TMPGEnc/AviUtl 直接開啟 .d2v,因為這些軟體還是以 RGB24
讀取,所以 dvd2avi 也還是以 RGB24 輸出。

那.... 倒底什麼時候會用 YUY2 輸出?
直接存 AVI 的時候... ^^;

所以如果您是用 vfapi 或用 TMPGEnc/AviUtl 讀取,選 YUV 或 RGB 都沒有差異。

附帶一提 ^^; 如果 dvd2avi 輸出時已經選了 PC Scale(有做 Y/C 伸張),
就不可以再用 TMPGEnc 的 Descale CCIR601 這個濾鏡,也不可以用
AviUtl 的 "ITU-R BT.601 補正",這兩個作的事情是一樣的,都是做 Y/C 伸張。
已經伸張過再做伸張,會有許多資料 clipping。

補充二
XviD 使用的 RGB -> YUV 算式

由 source code 可以得知,XviD 和大部分的軟體一樣是遵照這本書的標準轉換式作的
http://www.video-demystified.com/book1/index.htm
算式為

Y = (0.257 * R) + (0.504 * G) + (0.098 * B) + 16

Cr = V = (0.439 * R) - (0.368 * G) - (0.071 * B) + 128

Cb = U = -(0.148 * R) - (0.291 * G) + (0.439 * B) + 128

此算式等於上述 CCE SP 的第一個算式,也就是假設收到的是 0~255 的 RGB 資料,會先做 Y/C 壓縮,然後才壓 MPEG。


Q:
順便問........
射手網上的vodsub 2.27all如何安裝
裡面全是.dll文件和輔導工具,為什麼沒有發現主文件的安裝文件檔案,在哪個壓縮檔案裡呀?
A:
其實…………你認真的看一下網頁………………除了下載外的說明:

軟體說明:在影片播放同時顯示中文字幕、VirtualDub從VOB使用字幕流(支持CC字幕)的插件、調整各種字幕時間碼、 字幕格式轉換、OCR製作文本字幕等。
安裝方法: 將新版中的 VSfilter.dll 和 unrar.dll 複製到 %WINDOWS%/system32 目錄後,執行 regsvr32 VSfilter.dll 即可。通過執行 rundll32 VSFilter,DirectVobSub 即可進入設定面板。


這些原理確實很複雜,不容易理解,所以 Doom9 上討論了老半天也沒講對。
我自己本來也不懂,後來是因為 DVD2AVI 的作者教我,我才明白其中的來龍去脈。
(當然,如果有錯,也是我的理解有誤,和 DVD2AVI 的作者無關 )

(DVD2AVI 的作者實在非常非常非常的厲害,有許多道理都是他研究出來再教給大家的。譬如說 NTSC 4:3 的 DVD,720x480 的分辦率,要先左右共削掉 16 個點,變成 704x480 再 resize 成 640x480/512x384 ... 才是正確的比例,這個道理便是他研究發現的,然後再教給 GKnot 的作者 TheWEF。GKnot 有個選項叫 "Follow ITU-R BT.601 Standard",選了這個選項 GKnot 便可以遵照 ITU-R BT.601 的標準,做正確的 resize。唯有按照 ITU-R BT.601 的規範做 resize,resize 後的比例才是正確的,GKnot 變成唯一可以幫你計算正確 resize 方法的軟體,其它軟體的 resize 亂七八糟都是錯的。而 GKnot 之所以知道正確的作法,就是因為 DVD2AVI 的作者 jackei 教的)

(PAL 同樣要遵循 ITU-R BT.601 的規範,至於正確的作法我沒有研究,有需要的人可以利用 GKnot 幫忙計算正確的 resize 作法)

(關於 ITU-R BT.601 和正確的比例如何計算的原理,說起來很複雜,有機會我再解釋 有興趣的人可以參考 http://www.uwasa.fi/~f76998/video/conversion/。

.....簡單的說,因為 DVD 取樣記錄的時候,取樣的點之間的長寬比,Pixel Aspect Ratio,也就是 PAR 不是 1:1。而我們個人電腦的螢幕上 Pixel 和 Pixel 之間的長寬間距都一樣,也就是 PAR 是 1:1,也就是正方形的 Pixel,Square Pixel。所以 resize 的時候,不能直接從 DVD 的原始分辦率 resize 至目標的比例,如 4:3 or 16:9,而要做一些處理。通常來講,要左右削掉一些 Pixel,轉換後的比例才正確。例如 NTSC 720x480 16:9 squeeze 的影片要 resize,正確的作法要左右共削掉 16 個點,變成 704x480 再 resize 至 704x396(16:9) 才是正確的比例。然而 704x396 的高度 396 不能被 16 整除,不利於 MPEG 壓縮,所以我們再上下各補 2 個點,補上黑邊,補成 704x400 之後再送進去壓縮。因為 AVI 這種格式沒有紀錄 DAR,Display Aspect Ratio,播放時的比例的信息,所以播放軟體播放時不知道正確的播放比例應該是多少,因此製作時就要先設計好正確的長寬比例,如上例中的 704x396(16:9)。您可能會疑惑可是最後我們為了壓縮需要又補了四個點上去,變成 704x400,這樣就不是 16:9 了啊。沒錯,704x400 不是 16:9,但是因為補上去的多餘的點是黑邊,所以即使放大到全螢幕幕,比例還是正確的 16:9,多出來的黑邊不影響畫面中央有影像部分的正確比例。有點抽像,要好好想一下才能明白其中的道理 ^^;)

糟糕,我又扯遠了 上述的那個網頁,最後有一段問答,我覺得很有意思,轉過來給大家看:
4.4 I have been doing digital video projects for the last 50 years. I know my stuff! If you were correct, everything I have done to process my precious video has always been wrong, aspect-ratio wise!

That may very well be the sad truth. Fortunately, even if you had used wrong methods for scaling/resampling the image, the difference between the correct aspect ratio and a wrong aspect ratio is often small enough to go unnoticed unless you really start looking for it.

4.9 This is really scary and nasty stuff. I thought digital video was simple! Now my head hurts!

But that's just the way video is. Fortunately, the conversions are not really that complicated once you practice them a little.


雖然道理很複雜,不過我覺得這很重要,所以才提出來和大家討論。
譬如說當我看到 TMPGEnc vs. CCE SP 的壓縮測試,測試說 TMPGEnc 壓出來的顏色比較鮮艷,CCE SP 的顏色比較黯淡,我第一個就會想到,測試時 TMPGEnc 和 CCE SP 的 Y/C 伸張/壓縮 的設定是什麼?兩者的設定是否相同?如果兩者的設定不同,則出來的顏色表現不同是當然的。
或者說 TMPGEnc 的畫面較模糊,CCE SP 的畫面較清晰,我就會想到,TMPGEnc 的 resize 方法是用「平均像素法」,這種 resize 法的畫面本來就較模糊,但是對低碼率的 VCD 來說,這樣比較好壓。模糊是 resize 造成的結果,和壓縮無關,如果真的要比壓縮編碼的效果,應該用別的軟體先做好 resize,譬如說用 Avisynth 的 lanczos3 先做好 resize,再送進去給 TMPGEnc/CCE SP 壓縮,這樣比較才有意義。

所以知道這些原理還是有它的用處的。

至於採集卡,小弟使用的經驗不多,所以無法提供建議 ^^;;
採集卡應該要遵循 ITU-R BT.601 的規範,YUV 的範圍應該在 16~235 之間,所以必須做 Y/C 伸張。但是實際上各家的採集晶片不一定會完全依照 ITU-R BT.601,事實上 ITU-R BT.601 也沒有強制 Y/C 一定要在 16~235 之間,超出一點是可以的,這個設計本來有很大的一個原因是因為 MPEG 壓縮後資料不會和原來一樣,可能會超出一點,事先規範壓縮前的 YUV 在 16~235 之間可以預留一些空間(低於 16 和高於 235),給壓縮後超出的資料使用。
譬如說新出的 SAA7134HL 和 CX23881 晶片,SAA7134HL 的 scale(範圍)是 15~235,CX23881 則是 0~255,不用再作 Y/C 伸張。所以 CX23881 採集下來的畫面看起來比 SAA7134HL 鮮艷非常多,不知道的人還以為 SAA7134HL 很爛,顏色很黯淡。
請看這個網頁的比較圖片
http://anipeg.yks.ne.jp/topic.html

一般來說要驗證自己的採集卡的動態範圍,好知道後續要做什麼樣的色調補正處理,必須從外部產生一個標準的 ColorBar,色彩條,也就是上述那個網頁的第一個圖,作為輸入,看看採集後的顏色和原來相差多少,用 PhotoShop 或 AviUtl 之類的軟體看 RGB 的數值。ColorBar 的每個色條有類BIOS的 RGB 值,用 Avisynth 的 colorbar 指令便可以產生一個 ColorBar。
Q:
這張圖的意思是不是說明7134的轉換精度比833881要高?
記得7134是9BIT的,83881是10BIT的
看來有點跑題,但是用採集卡直接採集XVID效果也是很好的

先裁邊再RESIZE到是很有意思,不知道能不能具體比較一下兩條道有多大的差異?
A:
本來SAA713x的9bit就比Conexant的10bit轉換效果好

Q:
這張圖的意思是不是說明7134的轉換精度比833881要高?
記得7134是9BIT的,83881是10BIT的
看來有點跑題,但是用採集卡直接採集XVID效果也是很好的

先裁邊再RESIZE到是很有意思,不知道能不能具體比較一下兩條道有多大的差異?

A:
據說 Conexant 的 A/D 變換技術一直都在 Philips 之下,10bit 聽說只和 9bit 打平,
不過那個雜點看起來像 driver 的 bug,該網頁的作者過了一段時間之後重試,
結果還是一樣
不過那個資料已經有點舊了,也許現在的版本已經改正了,我沒有測試過新的採集卡,
這個要請有使用經驗的人出來提供心得。


resize 的錯誤一般看不出來,如同我上面轉貼的那個問答中所講的:
Fortunately, even if you had used wrong methods for scaling/resampling the image, the difference between the correct aspect ratio and a wrong aspect ratio is often small enough to go unnoticed unless you really start looking for it.
大致上的意思:
幸運的,雖然你用了錯誤的 resize 方法,不過這個正確的比例和錯誤的比例之間的差距,
通常是很小的而不會被注意到,除非你開始真的去觀察、注意這個錯誤。

這個錯誤大概會造成 ~2.5% 的比例錯誤。
有人做過實驗,用 DV 去拍圓球,使用錯誤的 resize 法,會讓正圓的球體變成橢圓。
PowerDVD, WinDVD 等這些軟體的 DVD Player 所做的 resize 也都是錯誤的。
(WinDVD 新版的已經瞭解到這個問題,開始改進)
所以大家在電腦上看了那麼久的 DVD,比例都是錯的
不過如上述所講的,幸運的,一般沒有注意的話是看不出來的。
不過一旦發現了以後,就會開始注意到這個錯誤了

為什麼直接 resize 是錯的呢?因為根據 ITU-R BT.601,取樣的時候長寬的取樣比例不是 1:1,
PAR(Pixel Aspect Ratio)不是 square pixel,正方形的 pixel,而是長方形的 pixel。
NTSC 的 PAR 是 10:11,也就是說如果橫軸每隔 1cm 取樣一點,縱軸就是每隔 1.1cm 取樣一點,
取樣的間距是 1:1.1 = 10:11。
橫軸取樣的間距比較短,也就是取樣的次數比較密集,也就是取樣出來的點數會比較多。
假設原始影像是 PAR 1:1 640x480 的圖形,經過 ITU-R BT.601 重新取樣後,
分辦率會變成 PAR 10:11 704x480(高度 480 不變,長度變為原本的 1.1 倍,640*1.1=704,
橫軸的點數變多),而不是 720x480。
所以 NTSC PAR 10:11 720x480 的 DVD 要 resize 到 PAR 1:1 640x480,要左右共砍 16 個點,
變成 704x480 再 resize 到 640x480 才會正確。

不知道這樣解釋容易瞭解嗎? ^^;
公式是
PAR = DAR * (水準解析度/垂直解析度)

DAR 是 Display Aspect Ratio,譬如說電視是 4:3
NTSC 的 PAR 是 10:11,所以
4/3 = 10/11 * 704/480

要從 704x480 resize 到 640x480/512x384... 才會得到正確的 DAR 4:3 的比例。

而 PAL 的 PAR 則是 59:54
4/3 = 59/54 * 702.91/576

所以要先截邊變成 702.91,再 resize 到 640x480/512x384... 才會得到正確的 DAR 4:3 的比例。

我沒有研究過 PAL 的算法,剛剛用 GKnot 幫忙算了幾組正確的比例(要讓 Aspect Error 這個項目
顯示的百分比為 0%,水準解析度必須能被 32 整除,垂直分辦率必須能被 16 整除),
得到下面的結果(因為無法截邊為 702.91,GKnot 是取整數 702):
PAL 4:3
720x576 -> 702x576 -> 704x528 /Aspect Ratio 1.333(4:3), Aspect Error 0%

注意,雖然此時 GKnot 顯示 W-Zoom(水準放大)為 100%(沒有放大),
但是實際上水準已經由 702 放大到 704,只是放大的幅度太小所以忽略。
我沒有實際壓過,不知道這樣到底好不好。

720x576 -> 702x576 -> 640x480 /Aspect Ratio 1.333(4:3), Aspect Error 0%
720x576 -> 702x576 -> 576x432 /Aspect Ratio 1.333(4:3), Aspect Error 0%
720x576 -> 702x576 -> 512x384 /Aspect Ratio 1.333(4:3), Aspect Error 0%
720x576 -> 702x576 -> 448x336 /Aspect Ratio 1.333(4:3), Aspect Error 0%
720x576 -> 702x576 -> 384x288 /Aspect Ratio 1.333(4:3), Aspect Error 0%
720x576 -> 702x576 -> 320x240 /Aspect Ratio 1.333(4:3), Aspect Error 0%
.....

如果電影比例小於 4:3,上下會多出黑邊,此時就把黑邊削掉就好,
只要注意高度必須能被 16 整除。


PAL 16:9(anamorphic,原始影片上下無黑邊,變形畫面,完全填滿整個 720x576 的畫面)
720x576 -> 702x576 -> 704x396 /Aspect Ratio 1.778(16:9), Aspect Error 0%

注意,雖然此時 GKnot 顯示 W-Zoom(水準放大)為 100%(沒有放大),
但是實際上水準已經由 702 放大到 704,只是放大的幅度太小所以忽略。
注意高度 396 不能被 16 整除,所以 resize 完以後,要上下多補 2 個 pixel 的黑邊,
補成 704x400 再送進去壓縮。
如果電影比例小於 16:9,上下會多出黑邊,此時就把黑邊削掉就好,
只要注意高度必須能被 16 整除。

720x576 -> 702x576 -> 640x360 /Aspect Ratio 1.778(16:9), Aspect Error 0%

注意高度 360 不能被 16 整除,所以 resize 完以後,要上下多補 4 個 pixel 的黑邊,
補成 640x368 再送進去壓縮。

720x576 -> 702x576 -> 576x324 /Aspect Ratio 1.778(16:9), Aspect Error 0%

324 不能被 16 整除,補為 576x336。

720x576 -> 702x576 -> 512x288 /Aspect Ratio 1.778(16:9), Aspect Error 0%
720x576 -> 702x576 -> 480x270 /Aspect Ratio 1.778(16:9), Aspect Error 0%
270 ->補為 272

720x576 -> 702x576 -> 448x252 /Aspect Ratio 1.778(16:9), Aspect Error 0%
252 -> 256

720x576 -> 702x576 -> 384x216 /Aspect Ratio 1.778(16:9), Aspect Error 0%
216 -> 224
.....

其它還有很多組可以自行利用 GKnot 計算。
(算 16:9(anamorphic) 的時候先把 H-Modul = 16(高度必須能被 16 整除的限制)改成 1,
這樣的彈性比較大,會有比較多組可以選項,等算好 resize 後的大小後,如果高度不能被 16 整除,
再自行考慮要多補,或者是削掉多少黑邊)

再來講更複雜的 ^^;

前面說到根據 CCIR601,模擬影像轉為數字時(由電影膠片轉為數字格式,如 D1),
由於取樣的長寬間距(Sample Aspect Ratio/SAR or Pixel Aspect Ratio/PAR)不一樣,
假設 NTSC 是橫軸每 1cm 取樣一點,縱軸便是每 1.1cm 取樣一點,取樣的長寬間距不一樣,
不是 1:1(square pixel),而是 1:1.1(non-square pixel),所以影像在電腦上看是變形的。
由於橫軸的取樣間距短,取樣次數較頻繁,所以取樣出來的點比較多。
NTSC PAR 1:1.1 704x480 的影像(變形的)其實等於 NTSC PAR 1:1 640x480(4:3) 的影像。
704/1.1 = 640
或者反過來看,縱軸點數一樣多(480),橫軸 PAR 1:1.1 的點數要比 PAR 1:1 的多出 1.1 倍
640*1.1 = 704

所以我們拿到 NTSC 的 DVD,規格是 PAR 1:1.1 720x480,要 resize 到 640x480,
或其它 4:3 的比例,直接從 720x480 -> 640x480 是錯誤的,必須要左右截邊變成 704x480,
再 resize 到 640x480,這樣比例才會正確。
因為 PAR 1:1 640x480 的畫面,對應的 PAR 1:1.1 畫面大小是 704x480,
而非 720x480。

同樣的道理 PAL 的 PAR 是 59:54,假設橫軸每 5.9 的服務機構長度取樣一點,
縱軸便是每 5.4 的服務機構長度取樣一點,橫軸的取樣間距較長,取樣次數較稀少,
取樣出來的點比較少。
所以 PAL PAR 59:54 702.91x576 的影像其實等於 PAL 1:1 768x576(4:3) 的影像。
702.91/(54/59) = 768
或者反過來看,縱軸點數一樣多(576),橫軸 PAR 59:54 的點數要比 PAR 1:1 的少 54/59 倍。
768*(54/59) = 702.91

所以我們拿到 PAL 的 DVD,要 resize 到 768x576/640x480 或其它 4:3 的比例,
直接從 720x576 -> 768x576/640x480 是錯誤的,必須要左右先截邊變成 702.91x576,
再 resize 到 768x576/640x480 ...。

ps. 702.91 是近似值,實際上的數字應該是 702+54/59 = 702.915254237288135593220338983050847..
為了數字化處理方便,使用 704 來替代。
也就是 720x576 削邊-> 704x576 -> 640x480 ... etc,16:9 也是先削邊 704x576 -> 640x360 ...。
做 PAL VCD 的時候,VCD 的 PAR 和 DVD 相同,所以要削邊 704x576 兩邊等倍縮小 1/2 => 352x288。

這個是上次說的,那麼 NTSC 10:11/PAL 59:54 這個 PAR 是怎麼算來的呢?
因為要整合 NTSC 和 PAL 系統,減少硬體設計成本,所以 ITU-R BT.601 把取樣頻率定為 13.5MHz,
然而對 525-line NTSC (ANSI/SMPTE 170M-1994) 的模擬訊號,要取樣成 1:1 的 square Pixel,
根據 SMPTE 244M "industry standard" square pixel,取樣頻率必須是 12 + 27/99 MHz。
所以可以得到 525-line Rec.601 NTSC 的 PAR 是 13.5 / (12 + 27/99) = 11/10 (y/x)

而對 625-line PAL (Rec. ITU-R BT.470-3) 的模擬訊號,要取樣成 1:1 的 square Pixel,
取樣頻率必須是 14.75MHz,所以可以得到 625-line Rec.601 PAR = 13.5 / (14.75) = 54/59 (y/x)

最後總結,關於比例,Doom9 上也討論過好多次,有興趣者可以自行查閱,或是參考下列兩個網址
http://www.mir.com/DMG/aspect.html
http://www.lurkertech.com/lg/pixelaspect.html
能看繁體中文的話,請看 DVD2AVI 的作者 jackei 的解說
http://bbs.irradiance.net/txtVersion...hreadList.html
http://bbs.irradiance.net/txtVersion...hreadList.html


然而也許有人會注意到,根據這個網頁
http://www.uwasa.fi/~f76998/video/conversion/
NTSC 的 PAR 竟然不是 10/11 (x/y),而是 72/79;PAL 的 PAR 竟然不是 59/54,而是 128/117!
這又是怎麼回事呢?
這就是令人頭痛的地方,也就是複雜的地方 ^^;

下面有點複雜,我沒有保握能夠解說得很簡單清楚明瞭,建議最好仔細閱讀以上提供的網頁再往下看。

前面計算 PAR 的時候,我們是拿 13.5MHz 直接去除 "industry standard" 的 square pixel
的取樣頻率,來求得 NTSC 和 PAL 的 PAR。但是實際上這些 "industry standard" 的取樣頻率,
取樣出來的仍然不是 1:1 的 square pixel,只是很接近 square pixel,所以直接這樣除,
得到的 PAR 並不精確。

精確的計算方法:
625/50 PAL 每一條掃瞄線的取樣時間為 64μs,實際上用來記錄資料的時間只有 52μs,
其它時間用來同步和等待掃瞄線歸位,所以要記錄 1:1 768x576,取樣頻率應該是
52μs * (14 + 10/13)MHz = 768

一條掃瞄線要 768 點(取樣 768 次),取樣時間 52μs,反算回來取樣頻率就得要是
14 + 10/13 MHz,而不是 "industry standard" 的 14.75MHz。

525/59.94 NTSC 每一條掃瞄線的取樣時間為 63+5/9 (63.555...) μs,
實際上用來記錄資料的時間只有 52+2/3 (52.666...) μs,其它時間用來同步和等待掃瞄線歸位,
所以要記錄 1:1 640x480(648x486),取樣頻率應該是
52+2/3μs * (12 + 24/79)MHz = 640(648)

而不是 SMPTE 244M "industry standard" square pixel 的 12 + 27/99 MHz。

所以根據正確的紀錄時間(PAL 52μs/NTSC 52+2/3μs)來推算 PAR,得到的結果就是
NTSC 72/79,PAL 128/117 了。

頭開始痛了嗎? ^^;
本來我們都已經習慣左右截邊 -> 704 之後再 resize,這也是一般看到的作法,
大家都是這麼作的,結果根據這個算法,NTSC PAR 變成是 72/79,
本來是
640 * 11/10 = 640*1.1 = 704

現在變成
640 * 79/72 = 702 + 2/9

要截邊為 702 + 2/9 再 resize 為 640x480 才是正確的。

不過該網頁的作者也建議,還是使用 704 比較好,704 這個數字剛好可以被 16 整除,
704 這個數字剛好是 VCD 352 的兩倍,704 剛好是 VCD 可以存放的靜態圖片的最大分辦率,
704 剛好是 ATSC 數字電視的標準分辦率...
有這麼多的 "巧合",所以我們還是選項削邊為 704 來處理。
DVD2AVI 的作者也是建議,還是以 704 來處理。

而 PAL 就很有趣了,因為 PAL 真正的 PAR 是 128/117,所以
768 * 117/128 = 702

剛剛好等於 702 一點都不差!
所以也許 PAL DVD 要 resize 為 PAR 1:1 640x480/512x384 ...,
截邊為 702 之後再 resize,會比 704 更好。

講完正確的 resize 作法之後,小弟也就可以功成身退了
Q:
你的描速好專業!
請講解工具使用,列舉一個實例我就更加明白了!
謝謝
A:
文筆太差,寫到我自己都看不懂 ^^;
工具有很多,例如 DVD2AVI 的 Video -> Clip & Resize,
選好左邊和右邊要切多少點,兩邊切的點數不一樣沒關係,
總之左右加起來為 16 點(->704)或 18 點(->702)即可。
DVD 的畫面通常左右都會留下黑邊,畫面不一定在正中間,哪一邊黑邊留得多就哪邊削多一點。
然後存為 .d2v。
DVD2AVI 不能切為 ->702,如果要切為 702,可以用其它軟體來處理。
例如 Avisynth 的 Crop 也是切邊的,AviUtl 裡面也有切邊的工具,
TMPGEnc, VirtualDub 都有,看你是要照以前的習慣切為 704,
或是按照那個網頁說的切為 702 都可以。
切邊以後,再進去去行 Resize -> 4:3 or 16:9 的比例,這樣就會正確了。
只是要注意水準最好要能被 32 整除,垂直最好要能被 16 整除,
如果上下有多餘的黑邊再把黑邊削掉即可,

例如:

NTSC 16:9(anamorphic) 原始解析度 720x480
DVD2AVI Clip 削邊為 704x480 存成 .d2v。
或是 MPEG2DEC.DLL 利用 Avisynth 的 Crop
# Crop(clip, int left, int top, int width, int height)
Crop(8,0,704,480)

附帶一提,Avisynth 說明檔中也有下面這個範例,大家可以找出來看看:
Crop crops excess pixels off of each frame. If your source video has 720x480 resolution,
and you want to reduce it to 352x240 for VideoCD, here's the correct way to do it:
# Convert CCIR601 to VCD, preserving the correct aspect ratio
ReduceBy2
Crop(4,0,352,240)

如果你要從 CCIR601 720x480 resize 到 VCD 352x240,**兩邊等倍縮小** 1/2(ReduceBy2),
然後左右各切 4 個點,360x240 -> 352x240,或是先左右各切 8 個點,再 704x480 -> 352x240,
這才是正確作法,直接從 720x480 -> 352x240 是**錯誤的**。
原因上面已經講過,不再贅述。同樣的,PAL 720x576 -> 360x288 -> 352x288,
或 720x576 -> 704x576 -> 352x288,這樣才是正確的。
一定要**兩邊等倍縮小**,為什麼?DVD 和 VCD 的 PAR 相同,原本 10:11,要兩邊等倍縮小,
同除 2,10/2 : 11/2 = 10:11,PAR 才會仍然保持為 10:11。

不止 DVD/VCD 如此,DV 也是一樣。

言歸正傳,如果要用 Avisynth 切邊為 702
Crop(9,0,702,480)

注意此時左右兩邊各切 9,這是一個大問題。
前面曾經提過 702.91 最接近的數字 703 這個數字數字處理不好處理,
所以改用 704,和這個道理很像。
因為 YUY2/YV12 格式的水準,色彩(Chroma)信息是每兩個 sample 取樣一個,
所以切的時候,一定要以偶數為服務機構切割(亮度 Y 切 8,色度 C 就要切 8/2 = 4,
Y 如果切 9,那麼 C 要怎麼切?),所以如果要切 9,就不能以 YUY2/YV12 模式處理,
要轉為 RGB 模式才可以。

如果你是用 TMPGEnc, AviUtl, VirtualDub 切割,因為這些軟體以 RGB 模式處理,
所以沒有以上的限制。

假設我們是切為 704x480,resize 為 16:9 後是 704x396,396 不是 16 的整數倍,
上下填黑,補成 400 再壓縮。例如 Avisynth 上下填 2 個 pixel:
# AddBorders(clip, int left, int top, int right, int bottom)
AddBorders(0,2,2,0)

或是用 VirtualDub 的 resize filter:
Expand frame and letterbox image
Frame width : 704
Frame height : 400
Fill color : 選黑色

AviUtl 有另外的 plug-in 可以做填黑,處理的優先順位要調到 resize 之後,
相信會用的人自然知道,不用小弟多言。

TMPGEnc ..等,也是一樣的作法,做完以後再壓縮就可以了。

至於幾個正確的解析度,前面已經有算好了,直接拿來用就可以了。
如果不要用 702,想用 704,將前面那些算好的數字 702 改為 704 即可。
想用其它解析度可以用 Gordian Knot 幫忙算。

我剛剛才發現,新出的 Gordian Knot 0.27 版已經改為使用那個網頁上的計算方法,
以 702 為正確的切邊數字。現在 NTSC 用 704 會顯示是錯誤的 Aspect Ratio,
和 PAL 一樣,要用 702 才會得到正確的結果... 真麻煩啊,NTSC 我還是想用 704 耶...

希望這樣補充可以幫得上忙。



Q:
對1st pass的stats文件進行分析,得出max size和I、P、B frame的數量,然後根據max size確定2nd pass的文件大小

A:
你說的是Stats Reader吧.
XviD Analyzer 可以分析2-pass中I/P/B Quantz的分散,當然了,就目前而言
BF的Quantz的報告是錯誤的,所以BF的分析當然也是不作數的了.

Q:
用VD做XVID的2PASS-1STPASS時,馬上崩潰,VD1411和VD1413都是如此,請高手幫忙看一下。以下是出錯資訊和截圖:
A:
VirtualDub crash report -- build 14328 (release)
試試1月03的XVID版本

Q:
一開始馬上崩潰恐怕是因為鉤上了 hinted ME。這個功能目前不能用。

A:
確實如此,非常感謝

Q:
resize 用哪種方式?
是 bicubic
還是 bilinear?

A:
好問題
也許有人看過 Nicky 寫的這篇:
http://nickyguides.digital-digest.co...vs-bicubic.htm
他的建議是
放大用 bicubic
縮小用 bilinear

一般我們做 DVDRip 的時候都是用縮小 resize,放大留給播放的時候再去放大。

縮小 resize 的計算步驟
1. pre-filter
2. 坐標變換
3. post-filter

resize 的時候,要計算像素的坐標變換,例如 704x480 -> 320x240,
新畫面坐標 (99,99) 這個點對應到原畫面,是 (217.8,198) 這個點,
落在原畫面的整數像素之間。
704/320 = 2.2
x = 99*2.2 = 217.8

480/240 = 2
y= 99*2 = 198

所以 (99,99) 對應的 (x,y) 是 (217.8,198)

當然原畫面是沒有 (217.8,198) 這個點的數值,那我們要計算這個位置的像素值應該是多少,
也就是對應過來的新畫面坐標 (99,99) 的像素值是多少。
那要怎麼計算這個在像素中間的值呢?
我們會利用內插法,也就是利用這個點周圍鄰居的像素值,來推算這個位於像素中間的數值。
這個內插法使用的 interpolation filter 也就是步驟三的 post-filter,
一般的有以下幾種方法:
1. Nearest neighbor: 最近鄰居法,就是很簡單的直接拿最靠近的鄰居(像素)數值來使用。

2. bilinear: 使用周圍 2x2,4 個鄰居做垂直、水準的線性內插。

3. bicubic: 使用周圍 4x4,16 個鄰居來做內插,內插的算式比較複雜,按距離的遠近有不同的權重。

縮小的時候會發生一種瑕疵叫做 aliasing,也就是原本的高頻被當成低頻訊號,
使得縮小後的低頻出現不正確的結果。
從畫面上看起來 aliasing 會造成 moire 和 鋸齒,線條會一格一格的很難看。
解決的方法是步驟一,先用一個 pre-filter 濾掉 resize 後無法正確記錄、
會引起 aliasing 的高頻訊號,然後再 resize,這樣就可以解決 aliasing 的問題。

但是這個 pre-filter(也就是一個 low pass filter)的設計有兩個困難。
不同種類的 filter 濾除高頻的特性不一樣,有的會造成畫面模糊。
如果 filter 的 tap 數越高(計算的像素個數越多),計算越精確,
品質當然越好。但是 tap 數太高,會造成另一種瑕疵叫做 ringing effect,
所以這個 filter tap 數不能太高。
但是如果 tap 數太低,無法無法良好的濾除高頻,又會發生 aliasing 的瑕疵。
所以這是一個兩難,必須視縮小率來調整最恰當的設計。

Avisynth 的 bicubic 設定
# BicubicResize(clip, int target_width, int target_height, float "b", float "c")

其中參數 b 代表模糊的程度,c 代表 ringing 的程度。
預設值是 b = 1/3, c = 1/3。
b = 0, c = 0.75 等於 VirtualDub 的 "precise bicubic"。
Avisynth 建議,理論上保持 b + 2 * c = 1 會得到最正確、最適當的 filter 結果。
例如 b = 0, c 便要 = 0.5,如果 c 超過 0.5 就會產生 ringing 瑕疵。

bilinear 的畫面比較模糊,但是也比較好壓縮,做 1 CD 的時候,用 bilinear 會比較好。
SimpleResize 這個 resize 法就等於 bilinear 拿掉 triangle filter,
所以它的畫面會比 bilinear 銳利一點。
如果你的畫面本來就很銳利,用 SimpleResize 縮小,那麼就會出現 aliasing 瑕疵。


前面的討論中,我們有提到一個 resize 的王者,叫做 lanczos3。
這個 resize 法是一種 decimation filter,本身具有 low pass 的效果,
也就是使用 lanczos windowed 的 FIR Low Pass Filter,它的 tap 數會根據縮小率
自動變化,在清晰度和 ringing effect/aliasing 等瑕疵之間取得最佳的平衡點。
所以 lanczos3 等於自己是一個完美的 low pass filter
根據大家的實驗,lanczos3 可以保留最多的細節,而又不會造成太大的壓縮困難,
所以建議如果碼率夠的話,用 lanczos3 可以得到最佳的結果。
相關討論,可以看日本的網站或 Doom9。

另外,lanczos3 處理放大,效果也很不錯。
放大縮小都行,所以說它是 resize 的王者


用XVID製作精品DVDRIP之菜鳥密籍第三版:

採用 Avisynth 2.5 ,MPEG2DEC3,VDUBMOD
提高壓縮速度和品質.

1.DVD2AVI換用用176版,並取消用DVD2AVI裁邊的步驟,以適應新方法的需要.

2.Avisynth 2.5的基本語句:
以720X272的DVD源為例
LoadPlugin("j:\avs\mpeg2dec3.dll")
mpeg2source("176.d2v")
crop(8,104,-8,-104)
LanczosResize(640,272)

3.用VDUBMOD讀入AVS文件,選FAST RECOMPRESS模式做XVID的1PASS和2PASS

對基本的VIDEO壓縮而言,可以提高壓縮速度25%左右
品質也應該有提高,間接的證據是1PASS的總文件體積比VD要大,QUANT的值自然也比VD差一點點,說明細節多難壓了.
當然還是看圖吧.有人認為VDMOD由於避免了色彩轉換的誤差結果色彩的還原明顯比VD要好,細節也少許增加.

Q:
用VD作XVID 1PASS的時候沒有問題,但是2PASS總是出現問題意外退出!
怎麼回事?

A:
可能原因之一是同時壓了格式不對的聲頻
Q:
我也遇到同樣問題,而且我根本就沒加音瀕。試過koepi的12-03-2002版和01-03-2003版,VD也試過1411和1413版,都是如此,2PASS-2nd pass int幾分鐘後就出錯退出.
系統是WIN2K
A:
個人經驗,碼率有限情況下,選項性用Lanczos


Q:Avisynth 2.5 和MPEG2DEC3上來,怎麼http://www.videotools.net上只有Avisynth2.07版呢



A:
http://cultact-server.novi.dk/kpo/av...nth_alpha.html
avisynth_a_030103.zip

http://ziquash.chez.tiscali.fr/
http://forum.doom9.org/showthread.php?threadid=37717


MPEG2Dec3 v0.94.zip
Q:
兄能不能寫個如何合併使用Avisynth 2.5和VD的指南!(帶截圖的那種)有勞了!

A:
和2.0X用法一樣,把xxp所帶的附件.放到SYSTEM32里面.其餘做法和2.0X一樣,再把所需的插件換成YV12的就成了!


Q:
請問老大一下
為什麼在做1pass時,要將bf quantizer offset先設為1

然後在做2pass時將offset?#123;回預設值100

另外就是在你說的在1pass時選項的quantization為mpeg
在做2pass時要先看是否為1CD or 2CD來決定用h263 or mpeg,是關於什麼原理^_^
對了還有lumi masking要打勾(沒試過^_^),所以請教一下老大




另外我自己在做時
1pass和2pass我是都在Global裡頭的設定
使用
Qpel+Chorma motion+dynamic h/lpel decision
bf=3,bf quantizer ratio=150,bf quantizer offset=100
這樣的設定有沒有直得改進的地方
(另外不使用curve+alt.c-目前沒用了)

A:
首先請看一下有關XVIDB畫格的QUAN的控制原理和方法.
1PASS時設定為1是為了使B畫格獲得更多的碼率分配
2PASS時改回100可以適當提高B畫格的壓縮(效率),如仍用1將會時總的文件體積比不用B畫格時還要大,如用的太大(>100)也將會是B畫格的QUAN劣化太多,所以設為100的最後的QUAN的結果只是使B畫格的QUAN只比P/I畫格劣化1.
設bf quantizer ratio=150,將使B畫格的QUAN劣化1.5倍,負作用比bf quantizer offset設為200以上還大,因為在控制B畫格的QUAN時前者是X,後者是+.
在壓成同樣的QUAN值的前提下,MPEG模式比H263模式需要的碼率多些,估計要多30%或以上

Q:
2.Avisynth 2.5的基本語句:
以720X272的DVD源為例
LoadPlugin("j:\avs\mpeg2dec3.dll")
mpeg2source("176.d2v")
crop(8,104,-8,-104)
LanczosResize(640,272)

3.用VDUBMOD讀入AVS文件,選FAST RECOMPRESS模式做XVID的1PASS和2PASS

8,104,-8,-104
是什麼意思?和avisynth以前版本的crop用法不一樣?Crop(clip,left,top,width,height)
A:

以前也有這種用法

If a negative value is entered in the width and height these are also treated as offsets. For example:

#Crop 16 pixels all the way around the picture, regardless of image size:
Crop(16,16,-16,-16)


Q:
對了有個問題就是
BF=3,老大們是如何算出來的
比如我在XviD裡頭的quantization中設定
Min i-frame=1
Max i-frame=4
Min p-frame=1
Max p-frame=5
而在Global裡頭的選項我選項rate=150,offset=100
所以
{[(1+4)+(1+5)]/2*150+100}/100=9.25
是不是在BF就設成9.25呢?

A:
BF=3是指的最多的可連續的B畫格的個數,
與{[(1+4)+(1+5)]/2*150+100}/100=9.25算出來的QUAN值沒有關係

Q:
這個crop(8,104,-8,-104)的數值是如何算出的??有什麼工具可以用嗎?

A:

對絕大多數DVDRIP來講,RESIZE的解析度都是類BIOS的
以N制DVD為例:
7200X480 --> CHOP(8,0,-8,0)
720X352 --> CHOP(8,64,-8,-64)
720X272 --> CHOP(8,104,-8,-104)

用Gordian Knot切割,可以得出比較準確的數字

不過!準確不等於標準
弄巧成拙的話還要加黑邊吧?

不過還是拉一張RTZ帖文來有詳細說明:

"做DivX的一點經驗 - 如何確定解析度 "
自製DivX的朋友越來越多了,讓我們多交流,多出精品。

自製DivX的重要步驟之一是確定DivX的解析度。我們看到一般各個rls group製作的DivX都是640x272,640x352,或512x384。這是TDX Rule 2001推薦的對應2.35:1,1.85:1,1.33:1的影片的解析度。為做到這一點,需要在NanDub中加入resize filter並crop掉黑邊。

resize一般情況下是一定要做的。一方面是把畫面減小,提高分配給每個畫素的碼率,改進畫質,另一個原因是720x480是每個DVD存儲時的共同的解析度,在播放時DVD碟內的參數告訴播放機應該如何變形,做DivX如果不resize得到的99%是變形畫面。

由於某些顯示卡Overlay顯示的需要,寬度和高度都要是16的整數。這樣會稍微有一點變形,但可以忽略不計。

至於為什麼寬度要用最大640,我個人認為這是為了在VGA方式下可以不Zoom而滿屏播放。另外多次實踐也證明這是一個畫質和大小的最佳tradeoff點。另外有時為了滿足畫質,用576x或者512x的也是有的。

這裡有一個問題,1.33:1的影片為什麼不推薦640x480?通過下面計算每畫格畫素數可以知道640x480的畫素數很大,幾乎是640x272的兩倍,通常的1000kbps左右的碼率很難得到優質畫面,所以不得已而降為512x384。這樣一來,對於同樣長度的影片來說,1.85:1的影片就可以說是最難壓的了。2.35:1的影片畫素數最少,一般來說即使是120min的影片,如果aggressive一點,也可以做到1CD裡面。

640x272=174080
640x352=225280
512x384=196608
640x480=307200

那麼應該如何確定最終解析度?我認為靠目視是不可靠的,要查DVD的原始資料。

通常我是到DVD Empire http://www.dvdempire.com/ 裡查某個title,然後看Product Information裡的Video項。
比如 The Sound of Music 是 Widescreen 2.20:1 (Anamorphic) ,那麼
640/2.20=290.9
取最接近的16整數倍為288,所以最終解析度應為640x288。這是比較特殊的例子,既不是272也不是352。

順便承認失誤,做The Lion King II時相信了自己的眼睛,用了640x400,實際上查DVD Empire,原始DVD是1.66:1,應該用640x384才對。好在是動畫片,有些變形還不是太明顯,但也留下了遺憾。
Q:
為何我這裡總是B畫格破損??上次你做的那個和我這次做的都有這個問題?
A:
找到原因了,2002/12/29的版本有問題,換用2003/01/03就好了

Q:
今天真奇怪又遇到這個錯??一做2Pass就出錯,不能繼續

A:
這個問題我遇過
我是用2pass-ext來做的
那時我在2pass時的_顟B沒有事先指定目錄
所以一做2pass時就有你上述的問題
建議你事先在XviD的Two pass裡頭
」自己用手動方式事先先填好1pass和2pass的_顟B要存放的目錄」(注意你自己設的_顟B目錄位址一定要類BIOS)
你在做一次就沒問題了

Q:
mpeg2source裡是相對路徑,我填入絕對路徑:mpeg2source("D:\software\VirtualDubMod\test.d2v")也會這樣,難道是我的語法錯誤嗎?
A:
(我再問的話,老鳥們可能怨氣沖天了,一個菜鳥方案沒想到招惹這麼多麻煩 ,不好意思,第一次使用,有勞各位大哥了。:)


A:
把MPEG2(VOB)/D2V/MPEG2Dec3.dll/放到同一個目錄下

AVS2.5是試驗版,會發生許多奇怪的問題
第一隻能用DVD2AVI176
第二不能在DVD2AVI裡先做CROPING
第三如果AVS文件錯過一次就需要逐字重寫過新的,COPY偷懶都不行
第四-------------------------------------------------------------------
問題搞清了,是DVD2AVI 1.76的問題,又下載了一個DVD2AVI(還是1.76),問題解決了。
說起來也真怪,前面出問題的那個版本同樣是1.76,文件大小一樣,配置也一模一樣。可產生的D2V文件就是不認。害得我瞎折騰了老半天。 仔細對比兩個同版本的DVD2AVI,只發現修改日期有所不同,一個是2001-4-12(不能用),一個是2001-5-7(正常)。


Q:
DVD(YUV4:2:0)經過DVD2AVI處理後,轉換成.d2v(YUV4:2:2)文件,DVD2AVI不支持YV12格式,如何實現用全程YV12 處理呢?

A:

直接讀取VOB文件
新版的VDMOD有這個功能
但在RESIZE上和IVTC也有一些問題還搞不好

Q:
DVD(YUV4:2:0)經過DVD2AVI處理後,轉換成.d2v(YUV4:2:2)文件,DVD2AVI不支持YV12格式,如何實現用全程YV12 處理呢?

A:
用MPEGDecoder_YV12直接讀vob
http://nic.dnsalias.com/MPEGDecoder.html
這個東西配合AVS2.5a問題的確很多,但是優勢也很明顯了,色彩和速度都很好。
Q:
另外一個比較菜的問題請教,碰到比較差的D版碟,用DVD2AVI Forced FILM不能完全解決拉絲的問題,在VitualDubMod中用Deinterlace filter可以解決,但運動模糊很厲害。如果用GK的Decomb+AVIsynth能比較好的解決,或者用TMPGenc效果也更好,如果用Decomb參數,調入AVS文件時會當機,TMPGenc的tpr文件經過VFAPIconv之後產生的AVI文件又不能用Avisynth 2.5來resize和clip,請問該怎麼解決呢?謝謝。
A:
Tmpeg處理,做了YUV->RGB->YUV的處理,沒有必要再使用AVS2.5a支持的YV12模式了

MPEGDecoder_YV12支持forces film,可以不做IVTC,如:
MPEGSource("e:\rip\big.vob", 0, "ff")

Q:
意思是用MPEGDECODER_YV12時不用加DECOMB嗎?

A:
效果與在DVD2AVI中選Forced FILM一樣,對FILM類型的DVD不用加DECOMB。
如:
LoadPlugin("d:\bin\DVDRIP\MPEGDecoder.dll")
MPEGSource("vts_01_1.vob+vts_01_2.vob+vts_01_3.vob",0, "ff")



.d2v只是一個信息文件,並未做真正的轉換

五.開始壓----------
以P4_2G的機器參考,640X272全程壓縮時間約1:2
壓好後可從DEBUGVIEW裡看到你的精品DVDRIP的壓縮質量統計.

注: 1-PASS後用DEBUGVIEW預估的QUANTIZER上限可以根據個人經驗調整
VIDEO型的DVDRIP要向高手學習用AVS做IVTC.

95/98/ME版http://www.sysinternals.com/files/dbgv98.zip
NT/2K/XP版http://www.sysinternals.com/files/dbgvnt.zip
psac 目前離線  
送花文章: 3, 收花文章: 1625 篇, 收花: 3194 次
舊 2004-12-03, 03:11 AM   #2 (permalink)
榮譽會員
 
psac 的頭像
榮譽勳章
UID - 3662
在線等級: 級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時
註冊日期: 2002-12-07
住址: 木柵市立動物園
文章: 17381
現金: 5253 金幣
資產: 33853 金幣
預設

用XVID製作品DVDRIP之菜鳥秘笈第三版

第三版的重點改進是採用 Avisynth 2.5 ,MPEG2DEC3,VDUBMOD
以提高度壓縮速度和品質.
------------------------------------------------------------------------
第二版重點修改了B畫格的相關參數的設定.
並取消1PASS時的QPEL勾選.
第三版還是修改了B畫格的相關參數的設定.
1PASS與2PASS不同
----------------------------------------------------------------------
所需軟體:
1.XVID Koepi's 03-12-2002版
2.SMARTRIP 241
3.DVD2AVI 176
4.Avisynth 2.5
5.MPEG2DEC3 PLUGIN
6.VIRTUADUBMOD 141X
7.DEBUGVIEW 4.2

一.用SMARTRIP 抓取VOB文件到硬碟.

二.用DVD2AVI產生D2V和WAV文件.
用DVD2AVI開啟VOB文件後,
點VIDEO勾選FORCED FILM.
點AUDIO選OUTPUT METHOD勾選DECODE TO WAV,並勾選NORMLIZATION 到100%(放大音量).
按F4寫D2V和WAV文件.

三.用Avisynth 2.5裁邊和RESIZE
以720X272的DVD源為例
LoadPlugin("j:\avs\mpeg2dec3.dll")
mpeg2source("176.d2v")
crop(8,104,-8,-104)
LanczosResize(640,272)


四.用VIRTUADUBMOD讀取AVS文件和WAV文件
選FAST RECOMPRESS模式做XVID的1PASS和2PASS
可以選取開始畫格和結束畫格以獲得你所要的片段.

1.XVID的1_PASS設定:
選取MOTION SEARCH 為6-ULTRA HIGH.
選取QUANTIZATION TYPE 為MPEG.
勾選USE CHROMA MOTION.

最大B畫格選3,
B畫格的QUANTIZER RATIO(%)取100,
offset 取1,
經實驗B3可以達到壓縮率和品質的最佳平衡點,要盡量減少B畫格的劣化,因為B畫格也是要看的.
AUDIO可以選NO.
開始壓縮前執行DEBUGVIEW以獲取對2PASS設定的有用訊息.(1PASSDEBUGVIEW可以在結束前再開啟執行,不影響最後的統計數位)
2.XVID的2_PASS設定:
設定好目標文件的體積(不含音瀕)
讀取1_PASS時DEBUGVIEW得到的LOG文件的最後一行中total-kbytes:XXXXXXXX,用其除以目標文件的大小的到的比值乘以2,四捨五入減一即為估計的QUANT值的上限.
設定2_PASS的QUANTIZATION TYPE 為H263或MPEG,一般而言1CD時為H263,2CD時為MPEG,或根據前面計算的QUANT值的上限值來定,如>=6則選H263,反之則選MPEG.
勾選ENABLE LUMI MASKING.
最大B畫格選3與B畫格的QUANTIZER RATIO(%)取100不變,
offset 改設為100,

( 不用QUARTEPEL和選用MPEG/H263都是為了求得細節和壓縮品質上的平衡)
點QUANTIZATION 設定I畫格和P畫格的最小和最大的QUANTIZER,依據前面估算的QUANTIZER值為最大值,減2為最小值.
(好的QUANTIZER範圍的設定得到的最後2PASS的DEBUGVIEW的統計X-1,X,X+1應接近正態分佈,如偏往小的QUANT方則碼率會有少浪費,如偏往大GUANT則文件體積容易超標)
3.設定好壓縮的音瀕格式,注意取樣頻率要與WAV文件相同,否則可用VD自含的轉換模式搞定.(我喜歡用64K碼率的WMA,但需要在VDMOD裡勾選48K--->44.1K的採樣頻率轉換)

五.開壓----------
以P4_2G的機器參考,640X272全程壓縮時間約1:2
壓好後可從DEBUGVIEW裡看到你的精品DVDRIP的壓縮品質統計.

注: 1-PASS後用DEBUGVIEW預估的QUANTIZER上限可以根據個人經驗調整
VIDEO型的DVDRIP要向高手學習用AVS做IVTC.
psac 目前離線  
送花文章: 3, 收花文章: 1625 篇, 收花: 3194 次
 


主題工具
顯示模式

發表規則
不可以發文
不可以回覆主題
不可以上傳附加檔案
不可以編輯您的文章

論壇啟用 BB 語法
論壇啟用 表情符號
論壇啟用 [IMG] 語法
論壇禁用 HTML 語法
Trackbacks are 禁用
Pingbacks are 禁用
Refbacks are 禁用


所有時間均為台北時間。現在的時間是 08:41 AM


Powered by vBulletin® 版本 3.6.8
版權所有 ©2000 - 2019, Jelsoft Enterprises Ltd.


SEO by vBSEO 3.6.1