認識 VP8 影像編碼:整合 HTML5 更小更漂亮、挑戰 H.264 地位

ADVERTISEMENT

VP8的3大特色

VP8與H.264壓縮影片的概念大致相同,但是在實際處理的過程中,還是有不同的地方。筆者將VP8獨有技術,選出3個比較有特色的部份,分別是2階段轉換、畫格內預測、畫格間預測,以下分別向讀者說明。

1. 對影像進行2階轉換

常見的影像編碼格式,會在色彩取樣完畢之後,將畫面切割為許多16 x 16像素的巨區塊(macroblock),並對這些巨區塊進行離散餘弦轉換(discrete cosine transform,DCT),利用DCT的數學特性,將資料分布集中於低頻區域,之後再對轉換後的資料進行量化(quantization ),以節省空間
VP8則是會先將每個巨區塊,再細切為16個4 x 4像素的小區塊,先對小區塊個別進行DCT後,再將得到的16組參數進行阿達馬轉換(Walsh–Hadamard transform,WHT),透過WHT轉換,可以更進一步刪去資料重複的部分,節省儲存空間。

認識 VP8 影像編碼:整合 HTML5 更小更漂亮、挑戰 H.264 地位

▲一般編碼器是直接對16 x 16的巨區塊進行DCT,VP8則是先將巨區塊切成16個小區塊,先進行DCT後,再將巨區塊進行WHT。

2. 用畫格內預測分析色彩

VP8在分析畫面色彩的時候,會將畫面切割為許多子區塊(VP8允許4 x 4、16 x 16大小亮度子區塊,和8 x 8色度子區塊),分析該像素的亮度、色度與鄰近像素的關係,並建立延伸的預測矩陣(請參考圖中淺綠色部分),透過重複利用預測矩陣中的參考值,以縮減資料量。

若以4 x 4區塊為例,圖中白色部分就是區塊中的16個像素資料,H_PRED(horizontal prediction)、V_PRED(vertical prediction)分別是將被分析的單一像素,套入左邊或上面的參考值,比如X00的H_PRED為L0,X32的V_PRED為A2。DC _PRED(DC prediction)則是套入左邊加上面參考值的平均,X12的參考值即為L1 + A2的平均。

最後一個比較特別的方法是TM_PRED(TrueMotion prediction),它是將整個區塊加上一個補償參考值C,並透過以下公式計算Xij=Li + Aj – C,以X12為例,其參考值即為L1 + A2 – C。根據官方提供的資料,使用這些方式可以節省20 ~ 45%的資料流量。

3. 畫格間預測捨去I、P、B frame

VP8捨棄了以往H.264及其他編碼常用的I、P、B frame動態預測畫格,改用最後畫格(last frame)、黃金畫格(golden frame)、備用畫格(alternate frame),但是2種方式的概念、原理並沒有相差太多。
最後畫格說穿了就是和I frame一樣,將整個畫面完整地記錄下來,雖然會花費最多儲存空間,但是只要解碼單一畫格,就可以顯示該時間點的完整畫面。

黃金畫格則是類似P frame的概念,只記錄與上一幀相異的部份,至於相同的部份,則延用上一幀的資料。黃金畫格除了可以節省資料流量外,對於即時編碼(比如視訊聊天)也有很大的用處,它可以透過動態補償的方式,即時修復畫面中的錯誤,而不用重新傳送1張全新的畫面。

認識 VP8 影像編碼:整合 HTML5 更小更漂亮、挑戰 H.264 地位

▲在預測矩陣中的元素A、L、C,都是由編碼器依照矩陣中像素的分佈,經過計算產生的參考值,可以透過「複製、貼上」、公式計算的方式,將資料填入實際畫面中。

認識 VP8 影像編碼:整合 HTML5 更小更漂亮、挑戰 H.264 地位

▲以此圖為例,若X的預測方式處理為DC_PRED的話,X=(A1+L1)/2,若為TM_PRED的話,X=A1+L1-C。若Y的預測方式為H_PRED的話,Y=L3,若為V_PRED的話,Y=A3。

以備用畫格取代B frame

備用畫格是VP8獨有的技術,它最大的特色就是畫格中的物件不一定要顯示在畫面上,而且可以將其中物件插入不同畫格中,說得具體一點,它的用途是用來取代傳統的B frame。

B frame的運作的方式和P frame很相近,不同的是B frame可以比對上、下一幀畫格,從2個畫格擷取畫面中的物件進行動態補償,然而P frame只能從上一幀畫格做動態補償。

備用畫格可以把許多將被用於動態補償的物件,收集在單一畫格中,並且在解碼時分配給多個黃金畫格使用,以增進壓縮的效率。由於備用畫格的傳輸、解碼與其他畫格並無不同,所以不會造成處理器額外的負擔,頂多是因緩衝的需求(暫存畫格中物件),額外佔用些微記憶體,很適合用於低階硬體。

認識 VP8 影像編碼:整合 HTML5 更小更漂亮、挑戰 H.264 地位

▲圖中I、B、P分別指I、P、B frame,L、G、A表示最後、黃金、備用畫格,紅色箭頭表示可以讀取其他畫格資料的方向。黃金畫格也能和B frame一樣,可以向2個方向讀取資料。

動態補償除了要記錄相同的物件外,也要記錄物件的移動方向(動態補償向量),透過VP8的SPLITMV技術,如果某一區塊的動態補償向量與鄰近區塊相同時,編碼器只需標記要延用上方或是左方的數值,不需記錄完整資料。

對付低畫質影片利器

VP8和其他的影像編碼器一樣,會將畫面分為數個16 x 16像素的巨區塊,並以巨區塊做為影像處理的基本單位,即使分析色彩時可以再細切為4 x 4、8 x 8的子區塊,但最終還是會組合成16 x 16巨區塊。在壓製品質比較差的影片中,常常會看到形似馬賽克的塊狀雜訊,就是巨區塊架構的後疑症。

認識 VP8 影像編碼:整合 HTML5 更小更漂亮、挑戰 H.264 地位

▲假設一個4 x 4的區塊具有3種動態補償向量,其分佈如圖所示,在未經SPLITMV處理前,編碼器需記錄16組資料,但是經過處理後,只需記錄3組資料,其他13組則參考鄰近區塊即可。

一般編碼器會透過迴路濾波器(loop filter)來減低這種塊狀雜訊,不過對於單一畫面,只能使用相同濾波強度。VP8的可變式迴路濾波器(adaptive loop filter)可以針對畫面中不同的區域套用不同濾波強度,而且能夠在每幀之間調整強度,如此一來既可以消除塊狀雜訊,也可以減緩整體畫面變模糊的情況。

認識 VP8 影像編碼:整合 HTML5 更小更漂亮、挑戰 H.264 地位

▲筆者以遊戲畫面來說明可變式迴路濾波器的概念。圖中前景人物(玩家角色)即為變動多的部分,可以增加濾波器的強度,背景人物(路人)變動的幅度比較小,可以降低濾波器強度,因為場景沒有變動,不需使用濾波器。

具有與H.264對抗的潛力

筆者以libvpx及x264編碼器,分別進行VP8、H.264的轉檔測試,轉檔條件為將片長為2分鐘的1080p預告片,以固定品質(CRF參數=20)的方式,轉成解析度為960 x 544,不附帶音訊的影片。

測試平台搭配的是Core2 Duo E6550處理器,從下方數據可以看到,除了編碼時間之外,2者的表現十分接近,無論在播放時的處理器佔用率,以及壓縮率的方面,表現幾乎一模一樣。如果libvpx可以在往後的更新加強效率的話,實用性或許可以和H.264並駕齊驅。

認識 VP8 影像編碼:整合 HTML5 更小更漂亮、挑戰 H.264 地位

(點圖可放大)

▲libvpx及x264都是收錄於ffmpeg的編碼器,在表現上只有編碼效率有著比較大的差異。由於測試時是採固定品質方式編碼,所以資訊流量會不段變動,因此採用整體流量除以片長的方式,計算其平均流量。

以目前的局勢來看,足以左右勝負的「枱面下內容」,仍然以RMVB、H.264等格式為主,這將成為WebM想要一統江山最大的阻礙。筆者認為要說服他們轉向WebM,最重要的關鍵還是在於編碼器,該如何強化libvpx的表現,甚至推出品質可靠的圖形介面轉檔程式,將是VP8當前最重要的課題。

使用 Facebook 留言

18e846c93645d367bc0e99f0cdedfd3b?size=48&default=wavatar
3.  Thomas (發表於 2012年6月25日 10:39)
使用效率相近, 編碼效率差這麼大, 為何要改用VP8 ?
Ae05d59c1c23bf4b84acb66359a2cc0b?size=48&default=wavatar
1人給推

4.  RC (發表於 2012年6月25日 10:45)
※ 引述《Thomas》的留言:
> 使用效率相近, 編碼效率差這麼大, 為何要改用VP8 ?

因為不用錢
18e846c93645d367bc0e99f0cdedfd3b?size=48&default=wavatar
2人給推

5.  Thomas (發表於 2012年6月25日 11:25)
※ 引述《RC》的留言:
> ※ 引述《Thomas》的留言:
> > 使用效率相近, 編碼效率差這麼大, 為何要改用VP8 ?
>
> 因為不用錢

咳咳..檯面下的何時付過費..呵呵..

就像MP3當時一起競爭的格式, 最後廠商還是趨向"主流"..
Cc71a7e0c2171af5a740610cd0d6f40d?size=48&default=wavatar
8.  zzz (發表於 2012年6月25日 16:51)
「免費的從來都是最貴..」
這句話是花大錢卻沒得到好服務品質的時候在用的,
跟「長那麼高的葡萄都很酸」差不多,
立場相反而已╮(╯_╰)╭
B62b5e27df8c1b5b22f9261340a44e2a?size=48&default=wavatar
11.  Lewis (發表於 2012年6月26日 11:57)
編碼效率真的差太多了,這絕對是個問題!
感覺在播放處理效率也沒改善太多,搞不好統計檢定根本不顯著!
Fe9ec061bc82c67eb65c25401e3478ba?size=48&default=wavatar
13.  Hancock (發表於 2012年7月10日 18:42)
那張圖為什麼P frame會參考B frame,B frame又參考P frame?兩者互相參考,誰先誰後?
是不是P frame參考I frame比較合理(⊙ˍ⊙)

發表回應

謹慎發言,尊重彼此。按此展開留言規則