VP8/VP9 與 AV1 相關資訊

近日想將更新個人 Video Coding 簡報的內容
期望新增 VP8, VP9 與 AV1 的介紹
這裡紀錄將引用的相關資料

VP8:

• TECHNICAL OVERVIEW OF VP8, AN OPENSOURCE VIDEO CODEC FOR THE WEB 
• An Analysis of VP8, a new video codec for the web

VP9:

• A Technical Overview of VP9: The latest royalty-free video codec from Google
• Overview of VP-Next
• Overview of the VP9 video codec
• How VP9 Works

AV1:

• AOM - AV1How does it work
• Predicting Chroma from Luma in AV1
• The AV1 Constrained Directional Enhancement Filter (CDEF)
• next generation video: Introducing AV1
• An Introduction to AV1

Theora (VP3)

• Theora Specification

Video Compression Standards - History & Introduction 簡報

這份簡報是由於臺北科技大學的黃士嘉教授的邀約
為了數位電視的實務課程中向學生們介紹 MPEG 相關標準的歷史而所準備

Video Compression Standards - History & Introduction from Champ Yen

VP8 spec study - Chapter 4 壓縮資料格式概論

每個frame的 bitstream 包含了3個以上的部份. 開頭為未壓縮資料, 在 intra frame 為 10 bytes, inter frame 為 3 bytes. 緊接著的是2個或以上的段落(被稱為 partition), 每個 partition 皆為 byte alignment.

第一個 partition 包含兩個段落
1. 套用於整個 frame 的 header 資訊
2. per-macroblock 資訊, 指定讓 decoder 推測 macroblock 內容的 prediction mode.
macroblock 資訊以 raster-scan 方式存放.

剩餘的 partition 包含了每個 macroblock 用以計算 residue signal 的 DCT/WHT 參數(coefficient). 這部份大約佔用 70% 的資料量. VP8 支援將序列的 macroblock 壓縮後之 DCT/WHT 參數, pack 為分開的數個 partition. 若有不只一個 partition 用以存放這些 DCT/WHT 參數, 除了最後一個 partition 之外, 每個 partition 的位元長度, 以 little endian/3bytes 格式存放於每個 partition 的開頭. 長度欄位使得 decoder 能夠一次存取數個 partition, 平行處理這些參數.

將 predicton data 與 coefficient data 分開於不同的partiton存放, 允許 decoder 的實作更有彈性. 實作可能先存放 frame prediction 資料, 之後再計算 frame 的 residue signal. 也有可能同時處理兩個 partition 資料以 macroblock 為單位計算 prediciton 與 residue signal.

不同的 partition 必須以分開的 entropy decoder 解壓縮. 而 in-partition 的搜尋並不被支援.

Google 公開 On2 VP8 Tech.

Google 又丟了一顆震憾彈, 在今日成立 WebM 計劃
該計劃以 BSD-License, royalty-free 方式公開釋出 VP8 格式標準與相關程式碼
並同時地在 Youtube HTML5 beta 支援中加入了 VP8 支援

儘管在Google 收購 On2 之後, 公開 VP8 的傳言就沒有斷過
但看到相關新聞的第一時間, 想法還只是圍繞在 VP8 規格
之後細看與思考後, 才體會到這樣作法的背後可能有著多強的效應

在視訊瀏覽服務以成為主流服務的今日
這些服務以往多半只仰賴著 Adobe Flash 技術
對於 Adobe 而言, Flash 平台可以說是金雞母, 對於 PC 有著極高的安裝率
因此也理所當然成為網頁動態/互動效果與多媒體服務的一時之選

然而對一些人對於Flash感到頭疼
像是問題早已存在於既有的智慧型手機使用者
因此手持裝置與非 x86 平台裝置開發商也對此感到感冒
著名的有如: 蘋果的 Jobs 因為不支援 Flash 問題而動怒,
ARM 也因為 Flash 延誤 Smartbook 市場策略而公開斥責
意會到手機使用者的潛在市場的網站, 也增加了HTML5 的支援 (scribd, youtube...)

這些林林總總與瀏覽器戰爭所帶來的教訓
人們都意識到與其寄望單一廠商的開放, 不如訴諸公開標準
在 Apple Inc. 提到 HTML5 後, 除了知名度大升之外, 的確也被人們寄予厚望.

然而HTML5只是格式, 對於多媒體支援並無侷限.
頓時瀏覽器都必須選邊站, 於是就成了經濟實力的角力
有錢人組的 Google, Microsoft, Apple 對於旗下瀏覽器HTML5 選擇支援 H.264
支援公開標準組的 Mozilla, Opera, ... etc 選擇支援 Theora(事實上這是On2 的VP3技術)
(這麼說是很簡化的說法, Google Chrome 也有支援 Theora)

一時間, HTML5 的視訊支援的選擇陷入了分歧, 且少有交集
H.264除了商業瀏覽器的採用外, 加上最大線上視訊服務 Youtube 採用
可以說 H.264 在 HTML5 的視訊服務採用上佔有極大優勢

或許 Google 意會到這與其網路服務業務有極大關係
選擇在這樣的方式提供了兩個陣營都可以接受的方案(微軟第一時間也決定 IE9 將支援 VP8)
同時地, Youtube HTML5 beta 服務也加入了 WebM(VP8) 的支援
也因此 VP8 非常有可能成為 HTML5 中最被廣泛採用的視訊格式.

儘管現在 Flash 依然在 Web 佔有相當重要的地位
然而在 Adobe 開放不足, 加上缺乏善意的情況下
當大眾有共識地要擺脫 Flash 的當下, Adobe 或許該好好反省
不然 Flash 很有可能要面臨成為另一個 Java 的窘境.

Matroska File Format

Matroska is a multimedia container format like AVI and aim to be an open standard.
It is open and absolutely free for use. Everyone can get specification easily and develop for their own purpose(personal, research or commercial).
The format adopts EBML(Extensible Binary Meta Language) design for extension flexibility.

There are some free implementations for matroska.
The most famous projectss are libebml & libmatroska released under LGPL.

For most case, LGPL is ok. But for commercial usage and companies, BSD License is prefered.
Before 2007, a parser released under BSD License can be found easily on internet.
But it is hard to get a copy now.
For those who try to get it, you can get it (2 files:MatroskaParser.c MatroskaParser.h)
via aegisub project (whole project released under 3-clause BSD License).

For InputStream implementation reference, mkv_wrap.cpp and mkv_wrap.h can be refered.

ARM - Building Multimedia Devices with ARM and ARM Partners Solutions

週二參加了這個活動
簡單的說, 這是 ARM 推廣自己的 Mali 系列相關 IP 的活動
儘管有其他像是 MontaVista, Ittiam, Aplix 等廠商的簡報,
然而水準上不若於 ARM 一般重視
而另一個可惜的是與會者做的功課不夠, 常可聽到缺乏sense的問題

著名的日商 Aplix 的簡報算是不錯, 然而定位上比較與活動主題無關
Ittiam 有如照本宣科的簡報
加上最後的 MontaVista 的簡報在內容與問答上有相當的錯謬

Mali GPU:
從 Mali 55 到 Mali 200/400
而自sigle frag. processor, vertex + frag. processor
到 vertex + 4 frag processor (with internal cache)
看得出 ARM 在這個領域上的架構與軟體支援日趨成熟
而對於之後的規劃與規格以很明確 - Vithar & Thor
甚至未來在規劃上有打算支援 OpenCL
回想當時, 應該詢問對於競爭者 Imagination, Vivante 的看法 與 Mali GPU 相較的優勢為何

Mali VE:
這技術源自於 ARM 所收購的 Logipard
在Mali GPU 簡報中強調可以將 VE 的輸出直接作為 GPU 的 texture
DM上可以看出 VE 俱備了 Memory, ME, MC, Transform, Control, Parser, Output 等7個部份
由於具有彈性支援各式video format的特性
因此每個部份都具有相當的programmable flexibility
這樣的做法應該相當接近 configurable video codec 理想