1 Other Codecs
l MSN 使用的video codec “x-rtvc1”,09之前的版本使用的ML20.參考網址：
http://www.amsn-project.net/forums/index.php?topic=6612.0
l Yahoo messenger 使用GIPS的LSVX codec.
l 這兩個codecs技術保密性強，找不到有用的信息，自己開發的codec使用碼流分析工具肯定也分析不出來。
l QQ的傳輸協議在應用層加密了，分析不出來用的什么codec.
2 Skype’s codec:VP8
Skype視頻通信的分辨率隨着帶寬的變化而調整的。Skype Video adapts its sending rate by varying framerate, frame quality and video resolution。
今年2月，Google 收購了On2 Technologies。之后Google開放了其擁有的VP8視頻編碼技術源代碼並免費提供給所有開發者使用，發布 WebM 開放網絡媒體項目。
Opinions on VP8:
總得來看，VP8並沒有聲稱的比H.264好多少，其標准的文檔就相當糟糕，大段大段的復制C代碼作為說明，Google’s VP8 specs 只描述了 baseline profile,很多地方不完整而且解釋不清。
VP8,作為encoder,視覺質量在Xvid 和Microsoft’s VC-1之間，作為decoder,比ffmpeg 的H.264還要慢。
VP8發布后的3天，x.264社區的工程師，就對VP8的核心算法進行了剖析，隨之網上廣為流傳。 這是匯總了的一些觀點（如下表）。[1]
VP8的戰略目標並不在高清離線視頻領域。從這張表里，你可以很清晰地發現,VP8所刪除的特性大多數都是涉及到高清/離線視頻。這些特性對於PC上觀看高清視頻是特別有用的，但是對於低帶寬視頻卻沒有太大用處。
一個 H264 開發者對 VP8 的深入分析[3]:
幀內預測： VP8的幀內預測基本上跟H.264是一樣的：“子區塊”預測模式幾乎跟H.264的為I4 × 4模式一模一樣，（他們甚至有相同的名字！）完整塊預測模式跟i16 × 16基本一致。色度預測模式也幾乎沒有區別，所以不可能擁有比h264更出色的效果了。但是值得一提的是，他們用 TM_PRED替代了planar預測模式。在預測方式上看起來有些不同，但是實際上h264都提供了相似的實現方法。
幀間預測：vp8支持3中參考幀：p幀，g幀（golden fream）和alt ref幀。運動矢量上，vp8支持比h264更多的可變大小區塊，次像素精度上，他支持四分之一像素和6-tap插值過濾。簡而言之就是：
· vp8參考幀：3
· h264：16
· vp8支持區塊類型：6×16, 16×8, 8×16, 8×8, 4×4
· h264：16×16, 16×8, 8×16, 但是還有更靈活的子區塊：例如 8×8 可以被分為 8×8, 8×4, 4×8, 或者 4×4
· VP8 chroma MV derivation:4×4 色度均值處理 (有點類似於 MPEG-4 ASP)
· h264：直接使用，沒有什么處理（沒有均值處理，所以視覺效果比較好）
· H.264 擁有b幀和加權預測，但是vp8卻沒有
VP8的插值過濾器可能稍好，但實現起來肯定會慢，包括編碼器端和解碼器端。
變換與量化編碼及環路濾波器: 未關注，參看[3]
3 VP8 編碼測試
網上的對H264與VP8視覺效果的比較測試參看鏈接 [2]VP8 vs H.264 Google WebM視頻畫質對比 。總體結果是VP8並不比H264有優勢。
使用Google VP8 Code[4]中提供的編碼器simple_encoder.exe對forman_cif.yuv編碼，只是個demo，具體的參數未知，Usage: simple_encoder.exe <width> <height> <infile> <outfile>
編碼后再使用simple_decoder.exe解碼得到重建的yuv序列forman_vp8out.yuv.
再拿上次264的測試比較，264基本參數為jm16.2, main profile ,Qp=36,CABAC模式,編碼100幀，二者不具可比性，僅為參考。
VP8編碼300幀的時間只用了幾秒，很快，編碼輸出的碼流大小為413KB，原始yuv序列大小為44550KB，壓縮比44550/413=107。上次264編碼100幀后碼流為75KB壓縮比44550/(75*3)=198。
原始yuv與重建序列比較：
圖1 org_frame5
圖2 VP8_frame5
圖3 org_frame86
圖4 VP8_frame86
圖5 264_frame86 QP36 mani profile CABAC僅作參考
圖5是上次264編碼測試的結果，平均PSNR 32.11，與VP8的不具可比性，僅為參考。
計算PSNR，VP8 300幀的平均PSNR為34.32，主觀比較中，5、6、7幀的PSNR剛好在31 多點，主觀效果不好，有馬賽克，其他幀的主觀質量都很不錯，參看附件各幀PSNR” PSNRorgandVP8out.txt”。
雖然PSNR較高，但是主觀上看每幀在色度上都能明顯感覺到與原始序列有不同的地方。不過264得到的結果也有這種感覺。
4 VP8 編碼測試(續)
參數為：vpxenc.exe -D --limit=100 --rt -v --psnr -w 352 -h 288 --fps=15/1 --min-q=36 --max-q=37 -o foreman_cif.vp8 foreman_cif.yuv 時，編碼出的比特率 198673b/s，PSNR(Y) 35.84
--limit編碼幀數，實際只編碼了99幀。參數 --fps=rate/scale，不知道scale的意義。--fps=15/2 時：
99876b/s , PSNR(Y) 35.86
這樣與264的比較沒有什么意義。
同時固定碼率在80kbp下比較:
VP8參數: vpxenc.exe -D --limit=100 --rt -v --psnr -w 352 -h 288 --fps=15/1 --end-usage=1 --target-bitrate=80 -o foreman_cifR.vp8 foreman_cif.yuv
264參數：main profile CABAC。-p FramesToBeEncoded=100 -p FrameRate=15 -p IntraPeriod=0 -p RateControlEnable=1 -p Bitrate=80000 -p SymbolMode=1
-p NumberReferenceFrames=3 -p BasicUnit=12 -p SearchRange=16
-p NumberBFrames=0
| Bitrate(kbps) |
SNR Y(dB) |
輸出大小 |
|
| VP8 |
71.6 |
31.773 |
60KB |
| JM8.6 |
80.33 |
32.96 |
65.3KB |
主觀效果上VP8明顯比264要差。
圖表 2 vp8第86幀
圖表 3 264 第86幀
圖表 4 vp8第11幀
圖表 5 264 第11幀
http://oss.org.cn/?action-viewnews-itemid-10042
[2] VP8 vs H.264 Google WebM視頻畫質對比
[3] Google VP8 Code 首次深入技術分析http://blog.fulin.org/2010/05/vp8_first_in_depth_tech_analysis.html
分析很透徹全面，原英文版http://x264dev.multimedia.cx/archives/377 。
[4] Google VP8 Code 下載 http://code.google.com/p/webm/downloads/list
[5] Google vp8 specs : VP8 Data Format and Decoding Guide.pdf
5 VP8 specs閱讀
兩種frame types
Intraframes,也稱keyframes,264里的I幀
Interframes,P幀，根據前一幀為參考幀編碼，不能容忍幀丟失。
沒有B幀
golden frame 和altref farmes (alternative reference frames) 的概念，P幀的blocks可以從前一參考幀預測同樣也可以從最近的golden frame 或altref farmes預測。Every key frame is automatically golden and altref, and any interframe may optionally replace the most recent golden or altrefframe.
Golden frames可以用來克服幀丟失，大概意思就是golden frames包含和重新編碼了介於之間的interframes的變化(context updates)。
Intra prediction mode
l 16*16 四種 DC_PRED , V_PRED , H_PRED , and TM_PRED
typedef enum
{
DC_PRED, /* predict DC using row above and column to the left */
V_PRED, /* predict rows using row above */
H_PRED, /* predict columns using column to the left */
TM_PRED, /* propagate second differences a la "true motion" */
B_PRED, /* each Y subblock is independently predicted */
num_uv_modes = B_PRED, /* first four modes apply to chroma */
num_ymodes /* all modes apply to luma */
}
intra_mbmode;
l 4*4 10種
typedef enum
{
B_DC_PRED, /* predict DC using row above and column to the left */
B_TM_PRED, /* propagate second differences a la "true motion" */
B_VE_PRED, /* predict rows using row above */
B_HE_PRED, /* predict columns using column to the left */
B_LD_PRED, /* southwest (left and down) 45 degree diagonal prediction */
B_RD_PRED, /* southeast (right and down) "" */
B_VR_PRED, /* SSE (vertical right) diagonal prediction */
B_VL_PRED, /* SSW (vertical left) "" */
B_HD_PRED, /* ESE (horizontal down) "" */
B_HU_PRED, /* ENE (horizontal up) "" */
num_intra_bmodes
}
Inter prediction
Bool pro_last為0，前一幀為參考幀，如為1通過prob_gf 選擇參考幀是黃金幀(0)還是替代幀(1)。
Chroma和luma的mv精度都是1/8 pixel。
| 0 |
1 |
2 |
3 |
| 4 |
5 |
6 |
7 |
| 8 |
9 |
10 |
11 |
| 12 |
13 |
14 |
15 |
Chroma的mv是同一區域4個Y subblock的均值， U and V block 0 的mv是 Y subblocks { 0, 1, 4, 5}的均值。
變換
對於轉換，VP8也是利用一個與H.264非常類似的方案。每個16 × 16塊划分為16個4 × 4的DCT塊，每個塊由一個位准確的DCT作近似轉化。然后，每個塊的DC系數被收集到另一個4 × 4組，再對這個組做Hadamard轉化。
第一個是完全省略了8 × 8變換（因為缺乏i8 × 8 模式）。
第二是轉換規范自身。H.264標准采用了非常簡化的“DCT”，與標准的DCT差別很大，以至於經常被稱為HCT（H.264的余弦變換）。
這種簡化的轉換在壓縮上比原來差大約1％，但大大簡化了轉換本身，使得僅僅用加，減，右移一位操作就能實現。
VP8使用一個非常精確，而且不太必要的版本，使用非常大的數字乘法（20091和35468）。
第三個區別是，Hadamard 變換在一些內部塊上實現 ，不僅僅是i16 × 16。