|
||
|
Senior Member
 
加入日期: Oct 2002 您的住址: El's room
文章: 1,046
|
引用:
嗯.. 是 360x120 吧？ :P 不過我還是不懂這跟循序畫面使用 Field DCT 影響的關係？ 引用:
還是我沒看懂這幾句話的意思 ^^; 怕專有名詞太多，大家看得頭大，我把我和 mycai 兄討論的東西，做一個簡單的說明： 使用 Field Picture（Picture Structure = Field）時，MPEG-2 會把畫面拆成奇偶兩個獨立的 Field，各自視為一個完整的 Progressive 畫面，分開壓縮。在這種模式底下，壓縮的是兩個獨立的 Field，壓完一個再壓另一個，所以壓縮的單位是 Field。 動作預測模式可以用 Field Prediction, 16x8 Prediction，沒有使用 B-Frame 的話多一種叫做 Dual Prime 的預測方法。「動作預測」模式的意思是搜尋物體移動位置的方法。前面提過，MPEG 壓縮的時候，P, B 畫面會參考其他畫面壓縮，只記錄和其他畫面的差異。所以我們壓縮的時候要尋找現在這個物體，在參考畫面中的位置是在哪裡，這樣才能找到最相似的參考對象，差異才會縮小，差異縮小，當然需要記錄、花費的流量也就減小囉。而這個「動作預測」的方法，有好幾個不同的模式，隨著使用的 Picture Structure 不同，可以使用的種類也就不同。 DCT 的時候是用 Frame DCT，也就是每個 16x16 的 Macroblock 直接切成四等分，切成四個 8x8 的小方塊做 DCT 轉換。此時 Macroblock 中的係數，全部來自同一個 Field，因為前面已經把兩個 Field 拆開分別壓縮了，相當於在兩個 Progressive Frame 上各別做 DCT，所以要用 Frame DCT。 使用 Frame Picture（Picture Structure = Frame）時，MPEG-2 會把兩個 Field 組合成一個 Frame，視為一個畫面來壓縮，此時 progressive_frame 這個旗標會標明這個 Frame 本來是 Interlaced 還是 Progressive 的。（這也是 DVD2AVI Frame Type 顯示的 Interlaced 和 Progressive 的資訊。我知道 jackei 曾說過什麼 ^^; 但是這個旗標其實和以 Frame 為單壓縮或以 Field 為單位壓縮無關，相關的是 picture_structure 這個旗標，這個旗標才代表是以 Frame 壓縮還是以 Field 壓縮） 動作預測模式可以用 Frame Prediction, Field Prediction，沒有使用 B-Frame 的話多一種叫做 Dual Prime 的預測方法。注意 Frame Picture 的 Field 預測方法和 Field Picture 的 Field 預測方法雖然同名，但作法有些不同。 DCT 可以用 Frame DCT 或 Field DCT，視情況決定。Frame DCT 如前所述，就是直接將 16x16 大小的 Macroblock 切成四塊，此時因為是以 Frame 為單位壓縮，Macroblock 中的係數分別來自奇偶兩個 Field，以一奇一偶一奇一偶這樣的方式交叉排列，直接切成四等分，每個 8x8 的小方塊中也是包含了一奇一偶這樣來自兩個 Field 的係數，然後做 DCT 轉換。 如果是 Field DCT，則會將 Macroblock 中的奇偶順序重新排列，變成兩個 16x8 的方塊，一個方塊是由奇數的掃瞄線組成，另一方塊是由偶數的掃瞄線組成，然後再將這兩個 16x8 的方塊水平方向切成兩半，最後一樣變成四個 8x8 的方塊。 這樣這四個方塊中的係數，全部都來自同一個 Field，這樣叫做 Field DCT。 當使用 YUV 4:2:0 格式時，Chroma sample（色彩像素，也就是 UV）一律使用 Frame DCT。 為什麼要設計 Field DCT 呢？這是因為在交錯畫面時，奇偶掃瞄線上的像素分別來自兩個不同 Frame 的 Field，差異很大，譬如說一奇一偶這樣排列 1 99 2 100 3 101 你可以看出奇數掃瞄線上的像素彼此之間的的數值比較接近，而偶數掃瞄線上的像素彼此之間的數值也較接近，一奇一偶交叉排列在一起的話，這個數值會有一個很快頻率的起伏變化 小 大 小 大 小 大 這樣我們稱為，這個方塊有很高的空間頻率成分。如果直接拿這樣奇偶合併的方塊去做 DCT 轉換，DCT 這個轉換就是把空間上的像素轉換為以頻率域上的係數來表示，以消除空間上像素彼此之間的關聯性（累贅性），這樣使用幾個比較少的頻率係數就可以代表本來的訊號。當方塊中有這樣變化頻繁（奇偶差異大，關聯性小）的像素的時候，轉換後能量就不會集中在少數幾個空間頻率的係數上，當然這樣就會造成壓縮困難。 所以我們才會設計 Field DCT，將奇偶拆開分別做 DCT，以增進壓縮效率。 所以使用 Field DCT 與否的決策判斷，才會用計算奇偶的變異數乘積作為判斷的方法。 講完了 ^_^; 大家大概都暈倒了 :P |
|||||||||
2003-01-21, 12:26 PM
#21
|
|
|
Major Member
加入日期: Oct 2000 您的住址: 台灣
文章: 263
|
引用:
是360x120沒錯，抱歉打錯了。 舉個例子好了，以chroma如下的frame(隨便打的) 0 2 4 6 8 10 14 22 18 16 14 12 Field DCT時奇偶分別downsample的話，就成了 1 9.5 17 和 5 19 13 兩個field的資料upsample再合併就成了 1 3.5 4.5 6.5 8 14.5 13.5 19.5 16.5 16 18 12.5 而直接將整個frame downsample就成為 1 5 9 18 17 13 upsample回去 1 2 3.5 6 7.5 11.5 16 19 18 16 14 12.5 哪個比較接近原數值該是一看就明白了， 交錯記錄的YUV420比循序更接近原數值雖不是不可能，但要遇到也不容易。 也可以找張普爾的DVD，拿有IVTC成功的部份來格放，就能看出Frame和Field DCT的差異。 若是一般的encoder真有判斷用Field還是Frame DCT壓縮會比較有利的話， 那麼就算沒有IVTC也會有近半的Frame是用Frame DCT才是， 但我從來沒有看過有這種東西… 引用:
這句是指？？ DVD就只能用YUV420而已啊。 |
||||
|
2003-01-21, 02:52 PM
#22
|
|
|
Senior Member
加入日期: Oct 2002 您的住址: El's room
文章: 1,046
|
引用:
啊，不會這樣。downsampling 的過程在一開始的時候就做好了，畫面的組成是 Frame 還是 Field 由 picture_structure 決定，在 Frame 結構的畫面裡一樣可以使用 Field DCT，Frame/Field DCT 只是決定要怎麼重新排列 Macroblock 裡面的係數，和取樣無關。iDCT 的時候解出來的係數會再重新組合回原來的順序，然後才 upsampling。而且在 YUV 4:2:0 的時候，Chroma 只能用 Frame DCT。 downsampling 的話可以很簡單 Progressive: c1 c2 chroma=(c1+c2)>>1 >>1 是右移一個 bit 的意思，相等於 /2 不保留餘數，注意不保留餘數喔。 實作的時候為了要用 MMX 加速，像 XviD 是用 round-up average: chroma = (c1+c2+1)>>1 這樣便可以用 pavg[us]b 這個指令加速，或是 round-down average: chroma = ((c1-1)+c2+1)>>1 用 pavgb 加速 upsampling 比較複雜，例如 MSDN 上提供的 cubic convolution interpolation http://msdn.microsoft.com/library/e...ue#yuvformats_3 看下面那張 Figure 14. >>4 是右移四個 bit，注意不保留餘數喔。 所以我以為 Frame/Filed DCT 除了壓縮效率以外是沒有差的？ 引用:
請問您是用哪一個軟體看的呢？我也想要有一個比較方便可以抽 Macroblock 層的資訊出來看的軟體，一般的軟體頂多顯示到 Slice 層就沒了  引用:
是的，DVD 只能用 YUV 4:2:0 格式，可是 MPEG-2 還可以用 4:2:2 以及沒有在任何 Profile 裡面的 4:4:4 格式。MPEG-2 規定 YUV 4:2:0 的時候 Chroma 只能使用 Frame DCT，要 4:2:2 以上，Chroma 才能像 Luminance 一樣，可以有不同的 DCT Type。 |
|||
|
2003-01-22, 10:39 AM
#23
|
|
|
*停權中*
加入日期: Oct 2002 您的住址: 退出江湖,化外之民
文章: 723
|
看完各位兄姐討論後的表情:
      |
|
2003-01-22, 01:18 PM
#24
|
|
|
Major Member
加入日期: Oct 2000 您的住址: 台灣
文章: 263
|
引用:
我從沒用力去K過MPEG，這方面我遠沒有你了解… 不過真是一時被上面那句話搞迷糊了  即使chroma的DCT是以Frame為單位，但之前的downsample是對奇偶field分別進行的啊~~~ 之前的討論真是有點牛頭沒對上馬嘴…… 這點其實拿張DVD來看就可以看出來了。 不然在交錯畫面時，chroma的downsample還對整個frame作不會完蛋才怪。 以前在普威爾的討論區也有提過這個問題， 當時雖然Jackei大表示比起field和frame在chroma downsample上的差異， 他比較在意的還是壓縮效率上的差別。 因為以DVD2AVI的6 step upsample來說，兩者差異已不是那麼明顯， 若是在一些數十step upsample的高階player上，差異看來就會更小。 所以Field DCT時chroma是以field單位 downsample這點該不會有錯。 引用:
所以，就如前面提到的，直接看DVD的畫面就是 |
||
|
2003-01-22, 02:04 PM
#25
|
|
|
Senior Member
加入日期: Oct 2002 您的住址: El's room
文章: 1,046
|
引用:
mycai 兄： 其實我也不是很了解，這方面 jackei 大大^n要遠遠遠遠比我了解多了，我也是看了他的文章才慢慢了解一點這些東西的（而且還可能有理解錯誤的地方... 狂汗）。 我重新看了一次我們的討論，我想我找到問題的癥結所在了。 首先，Chroma 是不會用 Field DCT 的，因為標準規定，YUV 4:2:0 格式，Chroma 只能用 Frame DCT。 其二，DCT Type 和怎麼 downsampling 無關，downsampling 是以整張畫面為單位，在做 DCT 之前就先做好的。DCT Type 只是決定要怎麼 "重新排列" Macroblock 裡面的 DCT 係數，使得 DCT 的轉換更有效率。這個決定可以以更小的 Macroblock 為單位作切換的。譬如說在交錯畫面中，也有可能畫面上大部分的區域都是靜止不動的，因此並沒有交錯，只有人物開口說話的部分是交錯的。那麼我們就可以切換，在大部分靜態的背景區域，因為無交錯，垂直的關聯性高，所以還是使用 Frame DCT。只有在有動作的交錯區域，我們才使用 Field DCT。 其三，畫面是以 Frame 為單位壓縮或是以 Field 為單位壓縮由 picture_structure 這個旗標決定。如果 progressive_frame 這個旗標等於 1（DVD2AVI 的 Frame Type 會顯示 Progressive），代表畫面是循序的，此時 picture_structure 會等於 Frame，同時另一個 frame_pred_frame_dct 旗標也會等於 1，代表此畫面中的 Macroblock 一律使用 Frame Prediction 的動作預測模式和 Frame DCT。 如果 progressive_frame 這個旗標等於 0（DVD2AVI 的 Frame Type 會顯示 Interlaced），則 picture_structure 還是可以為 Frame，還是可以用 Frame Prediction 和 Frame DCT。 其四，downsampling 的取樣是以整張畫面為單位的，當畫面是循序畫面時 progressive_frame = 1 chroma = (c1+c2)/2 當畫面是交錯畫面時 progressive_frame = 0 chroma1 = 0.75*c1 + 0.25*c3, chroma2 = 0.25*c2 + 0.75*c4 當然還可以用其他更複雜的 filter 來做 downsampling  所以您的意思應該是指 downsampling 的問題而不是 DCT Type 的問題？ 小弟是從 DCT Type 的方向去想，所以前面的討論完全牛頭不對馬嘴 ^^; 不知道這樣整理有沒有釐清我們討論的問題？ |
|
|
2003-01-22, 08:35 PM
#26
|
|
|
Senior Member
加入日期: Oct 2002 您的住址: El's room
文章: 1,046
|
引用:
雪野姐： 真是抱歉，寫了一堆讓人看了頭暈的東西 ^^; 其實我也很努力想解釋到讓大家都能明白我在講什麼，不過我的表達能力拙劣，而且如果每一項都解釋得鉅細靡遺，大概要寫好幾萬字，到時候小弟就算不累死，我想也沒人有興趣看下去 :P |
|
|
2003-01-22, 08:38 PM
#27
|
|
|
Major Member
加入日期: Oct 2000 您的住址: 台灣
文章: 263
|
引用:
沒錯，上面那個算式就是針對field作取樣。 不過雖說可以用更複雜的 filter 來 downsample… 對一些市上的encoder可別太期待，也有用chroma1 = 0.5*c1 + 0.5*c3, chroma2 = 0.5*c2 + 0.5*c4的東西存在，這可以參考三區的SP和LHA。 播放時upsample的複雜度的影響說來蠻大， 用PowerDVD看時Frame和Field DCT的差異相當明顯(我是這麼覺得啦)； WinDVD播放的Field DCT則和PowerDVD播的Frame DCT部份差不多， 不過WinDVD播的Frame DCT沒有比Field的好到哪去； DVD2AVI解出來的還能看出Frame 和Field DCT的差異，不過畫質是三者中最好的。 市售player的話，除去panasonic的和其它一些公司的旗艦機外，拜chroma upsampling error所賜，Frame DCT看起來反而會比較爛一點… |
|
|
2003-01-23, 07:09 AM
#28
|
|
|
Senior Member
加入日期: Oct 2002 您的住址: El's room
文章: 1,046
|
引用:
直接用 0.5 平均蠻奇怪的，畢竟 Standard 文件裡面有特別強調交錯畫面 Chroma 的取樣位置不是位在兩個 Luminance 的中間，而是位在 3:1 的位置上，所以當把交錯畫面的兩個 Field 合併成一個 Frame 的時候， Chroma 在空間上的取樣位置才會和 Progressive Frame 一致。 不過我也看過有 Encoder 簡便的作法，直接是拿 chroma1 = c1, chroma2 = c2 使用，一點內插都沒有 ^^; 一般的話是用 075*c1 + 0.25*c3，也有一些會用 cubic filter 做更複雜的取樣。 引用:
呃呃､､您想說的意思指的是 downsampling 吧（Frame Type, Progressive/Interlaced Frame），和 DCT Type 無關喔，不然我們又要雞同鴨講了 :P 嗯，把循序畫面當成交錯畫面來取樣，問題確實很大，我也見過有幾張 DVD 這樣搞，例如普威爾 GateKeeper 21 附的 NCOP，就是全部 Interlaced Frame（不過 Picture Structure 是 Frame，也會用 Frame Prediction 和 Frame DCT。Frame Type 和 Picture Structure 這兩個意義是不一樣的，這個觀念要釐清）。 這個 NCOP 我猜普威爾是因為特殊原因，直接拿二區的來用..... 嗯嗯，而且竟然是用 Linear Quantization，不知道日本那邊壓縮的廠商是在惡搞嗎？ :P DVD2AVI 的畫質真的很好，upsampling 的作法大約等於 MSSG 裡面用的 6-tap FIR filter，可惜計算量大速度慢了一點。WinDVD..... 播放交錯畫面的 chroma upsampling 好像還是錯的？所以我現在都用 PowerDVD 看  引用:
這個 bug 到現在還沒普遍修正嗎？我以為這個問題發現以後廠商應該很快就會更正的說...  這個問題又不難解決，只要偵測 progressive_frame 這個旗標，循序畫面用循序畫面的 upsampling 函式，交錯畫面用交錯畫面的 upsampling 函式，就解決了呀。而且這是 Standard 文件裡面就有提到的標準解碼程序... 雖然是沒有一個步驟一個步驟講得很詳細，不過也應該不難看懂（比 MPEG-4 好看多了），廠商竟然會做錯，真是令人意外。（又不像軟體 DVD Player，如果要走 YV12 Overlay 的話，要解決交錯畫面解錯的問題確實很麻煩。像 PowerDVD 乾脆用 YUY2 Overlay，缺點是要自己先 upsampling 到 YUV 4:2:2，又要即時，品質會比較差一點，容易感到畫面上有雜點在閃爍。這是在電腦上才有的限制，做成硬體 DVD Player 還犯這種錯誤，真是不可原諒） 補充幾張圖，第一個是 YUV 4:2:0 在 Progressive Frame 和 Interlaced Frame 中的取樣方式，注意 Chroma 的取樣位置  ╳ Represent luminance samples ○ Represent chrominance samples Figure 6-1 -- The position of luminance and chrominance samples. 4:2:0 data.  Figure 6-2a – Vertical and temporal positions of samples in an interlaced frame with top_field_first = 1. chroma1 = 0.75*c1 + 0.25*c3, chroma2 = 0.25*c2 + 0.75*c4  Figure 6-3 – Vertical and temporal positions of samples in a progressive frame. chroma1 = 0.5*c1 + 0.5*c2, chroma2 = 0.5*c3 + 0.5*c4 mycai 兄提到的 chroma upsampling error，就是市售的 DVD Player 往往只有一種 upsampling 的演算法，不會去偵測 progressive_frame 這個旗標，判斷畫面是循序的還是交錯的，切換不同的 upsampling 方式。譬如說硬體 DVD Player 只有 Interlaced Frame 的 upsampling 方法，這樣遇到 Progressive Frame 就會解出錯誤的 Chroma 畫面，請參考這個網頁的圖片 http://www.hometheaterhifi.com/volu...bug-4-2001.html 文章中就有提到 progressive_frame 這個旗標，和一般硬體 DVD Player chroma upsampling 的錯誤。 第二個是 Frame DCT 和 Field DCT 的意義圖示  Figure 6-12 Luminance macroblock structure in frame DCT coding  Figure 6-13 Luminance macroblock structure in field DCT coding |
|||
|
2003-01-23, 04:01 PM
#29
|
|
|
Major Member
加入日期: Oct 2000 您的住址: 台灣
文章: 263
|
引用:
抱歉。 但也不能說無關吧，基本上有一定的對應… 引用:
普威爾出的DVD裡，偶而就會出現一些不像是普威爾的encoder壓出來的東西… 反正總是會有特殊的原因造成這種結果，大家心知肚明也就夠了 此文章於 2003-01-23 07:19 PM 被 mycai 編輯. |
||
|
2003-01-23, 04:36 PM
#30
|
|
