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帧
[1] VP8的前途与使命
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
}
intra_bmode;
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。