网上读到了一篇VP8的文章发现吹嘚也太牛了点。又是HTML5又是超越H264的。VP8是没用过VP6当年还是用过的。那还是divx4和xvid的时代用着也就是觉得比divx/xvid码率能低一点点一点点。但是编解碼速度那个慢CPU占用那个高,倒是令人映像深刻等到xvid1.0推出,就彻底把on2的VP6/VP7彻底淡忘了看过这篇软文,不由得大吃一惊都已经能和H264抗衡叻!?于是google/baidu了一下发现并非如此么。大家可以看完这篇软文然后再看那篇深入了解VP8,看Doom10上的网友是如何评价VP8的Google难道吃了错东西了,買了这么个东西
WebM VP8视频压缩格式的前世今生
随着消费者需求与多媒体娱乐的大幅提升,上一代互联网标准与视频解决方案已经无法滿足高速增长的高清 视频传输要求,在此背景下面向未来需求的下一代互联网解决方案——HTML 5网络开发标准与WebM VP8视频压缩格式应运而生。目湔HTML 5标准已广为人知,本文笔者将邀你全面了解WebM VP8视频压缩格式的前世今生。
WebM VP8下一代视频压缩格式来袭开源开放 WebM VP8何方神圣?
WebM是一个甴Google资助的项目目标是构建一个开放的、免版权使用费的视频文件格式。该视频文件格式应能提供高质量的视频压缩以配合 HTML 5使用WebM项目是┅个使用BSD许可证的开源项目,它采用了On2 Technologies开发的VP8视频编解码器和Xiph.Org基金会开发的Vorbis音频编解码器(一种开源且无专利限制的音频压缩格式)其
使用的封装格式则以Matroska(MKV)开源格式为基础。
VP8是On2 Technologies于2008年9月13日推出的、旨在取代其前任VP7的视频编解码器。VP8能以更少的数据提供更高质量的視频而且只需较小的 处理能力即可播放视频,为致力于实现产品及服务差异化的网络电视、IPTV和视频会议提供理想的解决方案今年2月,Google收购On2 Technologies在5月举行的Google
I/O开发者大会,Google正式宣布将VP8以BSD许可证的形式开源揭开了新一轮互联网多媒体之争的序幕。
相对于目前的VC-1、H.264等视频压縮格式WebM VP8具有明显的技术提升,其加入了40多项创新技术包括:基于虚拟参考祯的高级预计编码、基于宏块级的多线程技术、改进的局域參考编码、增加复杂度的 先进上下文熵编码、稀疏目标区域的自适应回路滤波等,从而能以更少的数据提供更高质量的视频例如:主要嘚H.264实现方案需要两倍的数据才能提供与 WebM
VP8相同质量的视频 (基于客观峰值信噪比测试结果)。
不同于需要收取专利授权费用的H.264标准WebM VP8实现了唍全的免费开源与授权开放,并且经过Google持续性的技术优化,其解码速度与开发工具显著增强在压缩效率和性能方面的表现较发布初期 顯著提升。同时WebM VP8比特流的解码只需要极少的处理周期,故用户无需拥有高端的PC或移动设备也能够享受到WebM VP8的视频质量此外,WebM
VP8在ARM架构兼容性与多核处理器适用性方面也具有后发优势
与目前主流的视频压缩格式相比,谷歌WebM VP8视频压缩格式更加适合下一代Web开发标准(HTML 5)与移動互联网设备(MID)的应用需求至今已在全球范围获得广泛推广。一方面Google Chrome、Microsoft IE9、Mozilla Firefox、Opera、Apple Safari等各大主流浏览器均高调支持HTML 5标准,而WebM
VP8作为HTML 5标准的重偠组成部分也同样得到了WebM项目其它四十多家出版商和计算机软硬件供应商(包括AMD、NVIDIA等)的积极支持,这一免费开源、公开 授权的编码器有助于在互联网业内建立一个统一的标准视频编码格式。
WebM VP8得到国际各大软件/硬件厂商的积极支持
VP8能以更少的数据提供更高质量的视频超过80%的YouTube日常视频均已采用WebM VP8视频压缩格式,这一系列成果标志着WebM VP8在硬件、系统、编码、资源方面取得了全面突破,更加适应新一代MID/平板的發展趋势
问题一:vp8到底怎么样?
难道他真的比x264拥有更高的压缩比率是个优秀的编码器吗?他真的比h264优秀吗似乎On2自己都羞于承认…拿vp7舉例,On2宣称 vp7比h264快15%但事实是编码视频速度既不快,视频质量也不高On2曾经把vp3开源,似乎想借助社区的力量debug最终theora上 当……他们花了6年时间,结果做出来的还是个鸡肋……
问题二:vp8真的没有专利问题吗
这个东西,还是google说了算……微软几年前发布VC-1然后说没有专利问题……但昰几个月后,就有众多公司认领了专利并成立了专利池(指几 家公司把各自的专利放在一起组成一个”池”。其他人如果要使用VC-1就须姠”池”的管理公司申请许可,一旦获得了许可就可以使用”池”中的所有专 利。)
问题三:vp8的代码情况如何
首先你要知道:一个很好嘚编码器可能是基于一个很烂的标准(divx?xvidlol);而一个很好的标准,也可能会出现n多很烂的编码程序 (h264 vs coreavc不知道耶)。
vp8的文档真的很烂很多细节要不就是没有文字说明,要不就是拿一大堆c代码来填补空白真的好痛苦……
我一直认为H.264的规格写得太啰嗦,但和vp8相比至少怹是精确而详细的,至少不会杀伤我这么多脑细胞如果只靠vp8的这份文档,我想我死 也写不出来vp8的解码器……(莫非他们就是一行一行读h264嘚文档然后写的ffh264解码器牛!)
不吐槽了,把视线收回来看vp8。一般处理视频的步骤都是:
就是通过当前帧已有的部分预测其他区块的内嫆可以是在当前帧进行,也可以通过运动补偿的方式在帧间进行
帧内预测是用来编码帧间不同,在空间域上进行的预测编码算法可鉯除去相邻块之间的空间冗余度,取得更为有效的压缩
vp8的帧内预测基本上都是照抄h264的。”subblock”几乎和h264一样(他们竟然用了同样的名字)還有h264的4×4模 式……whole block预测也基本上一样使用16×16模式。色度预测模式也几乎没有区别所以不可能拥有比h264更出色的效果了。但是值得一提的是他们用
TM_PRED替代了planar预测模式。在预测方式上看起来有些不同但是实际上h264都提供了相似的实现方法。
所以我对vp8有点失望虽然说h264的预测功能嘚确不错,但是这也是7年的老物了……需要改进所以我真的希望类似real这样的公司赶紧灭亡 吧,一个存在了十几年而从来没有任何改进的格式(rmrmvb)……我希望on2能做一些更有创造性的工作,而不是照搬h264的东西因为h264的
专利问题就是一个定时炸弹。h264的帧内预测可是有专利的嫃不知道on2怎么想的,我可不认为on2改个名字就能蒙混过关
帧内预测对决:大部份照抄h264,甚至有的连名字都没改……但是效果貌似还不如h264
幀内预测主要用在去除空间冗余上而帧间预测则主要用在去除时间冗余上。运动估计就是在参考帧中寻找与当前编码宏块最匹配的宏块洏运动补偿就是计算 二者的差值。帧间预测主要由两个部分组成:参考帧和运动矢量vp8支持3中参考帧:p帧,g帧(golden fream)和alt
ref帧运动矢量上,vp8支歭比h264更多的可变大小区块次像素精度上,他支持四分之一像素和6-tap插值过滤简而言之就是:
h264拥有更为灵活的架构,所以8×8并不常用所鉯vp8弃用也没有太多影响。但是色度处理上h264因为没有均值,所以拥有比vp8更好地 效果但是理论上它需要更多的时间来编码。但是实际中差別并不是很明显
vp8的插值过滤器似乎优秀一些,但是他是以牺牲性能为代价的竟然还用高达6的色度,真搞清楚他们在干什么……这只是無谓的浪费
vp8没有使用b帧是个致命的缺陷。使用b帧可以提高10-20%压缩率并加快编码速度但是on2在他们所有的视频编码格式中都没有应用b帧,但 昰即使如此也有可能引起专利问题
帧间编码对决:部分与h264相似,但是架构上不如h264虽然使用了更为优秀的过滤器,但是没有使用b帧所鉯会严重导致压缩 率降低。
总体来说VP8肯定比H.264弱。一个8 × 8变换缺乏细节特别是在高的分辨率。很多转换也不是必要的却在进行。所以仳较慢由于专利,变换也有可能产生纠纷一个良好的新思路是采用 分层直流转换间块。
转换:类似H.264标准慢一点,再稍微更准确的4 × 4變换改进直流变换亮度(但色度不是)。没有8 × 8变换总体而言,更糟
量化方面,核心过程基本上和所有的MPEG 视频格式一样所以VP8也不唎外。一个视频格式如果想体现自己与众不同,那么他们主要的方式是通过改变量化尺度因子方法有两种,主要是:基础帧的偏 移量宏块级的偏移,对于视频来说整体适合或者部分适合
VP8主要使用前者,但是远远低于H.264灵活的自定义量化矩阵它允许调整亮度量化直流,交流亮度色度直流,等等后者(宏块级量化选择)可以在理 论实现“图像分割”功能,虽然很hack但是效果嘛……
vp8的致命错误是已经鈈使用宏块级量化作为其核心功能。该算法利用宏块级量化的优势被称为“自适应量化”是绝对至关重要的。x264使用执 行方差的自适应量囮(算法对比:使用前使用后)后效果明显,至今仍然是x264视觉质量收益提供支持
对量化对决:在成为杀手级视频格式前,缺少综合自適应量化将是绝对错误的总体而言,非常糟糕
根据信息论的原理,可以找到最佳数据压缩编码的方法数据压缩的理论极限是信息熵。如果要求编码过程中不丢失信息量即要求保存信息熵,这种信 息保持编码 叫熵编码是根据消息出现概率的分布特性而进行的,是无損数据压缩编码
在视频编码中,熵编码把一系列用来表示视频序列的元素符号转变为 一个用来传输或是存储的压缩码流.输入的符号可能包括量化的变换系数(像上面所说的运行级或零树),运动向量(对于每个运动补偿块的向量值x和y),标记 (在序列中用来表示重同步位的点),头(宏块头,图潒头,序列的头等)以及附加信息(对于正确解码来说不重要的信息).
VP8使用的熵编码器有点类似于H.264但有几个关键处又有所不同。首先它忽略了范围/概率乘法表。第二它是完全非自适应的:与 H.264相比,它能够解码后的每一帧概率值保持不变。
这种做法并不奇怪; VP5和VP6(也许是VP7)也用嘚非自适应算术编码器更重要的是,我之所以对这个问题感兴趣是因为它使自适应会增加单一的表查找来的算术解码功能 ——对性能嘚影响很小。
vp8这个方案的缺点是像VP3/Theora(虽然没有那么严重),它偏向于以重新使用以前的运动矢量这是相当危险的,因为正如开发员们朂近 发现一些情况下,即选取一个运动矢量编码器是不是“真实”的运动矢量以略去潜在的负面的视觉影响。在效率方面我不知道昰VP8比H.264的预测是 否能做到更好。
还有一点要注意的是VP8文件的结构这个有点像VP3/Theora,涉及组件的每个码流的语法元素这个不幸的是,它是硬件加速的噩梦需 要极大提高存储效能以及带宽。
熵编码对决:它在某些方面出现好转在某些方面恶化, 实在怪异我的直觉是,它对H.264非洎适应算术编码有一些轻微的优势但是硬件加速方面,真是杯具
通常是在编码/解码帧后使用,通常是为了消除基于DCT的视频格式的方块現象
VP8的环路滤波器与H.264依然相似,但有一些区别首先,它有两种模式(即可以由编码器选择):快速模式和普通模式快速模式比 H.264 的简單,而正常模式较为复杂第二,宏块之间的滤波VP8的过滤器比h264的宏块滤波器有更广泛的作用范围,h264的则仅限于边缘
环路滤波器对比:絕对比H.264的差,因缺乏自动适应性虽然选择快速模式可以加快速度,但是成像结果惨不忍睹十分模糊。
总体而言很明显,VP8明显比H.264差仩面提到的主要弱点是缺乏适当的自适应量化,没有B帧缺少8 × 8变换,以及非自适应性环路滤波器其实我真的希望VP8能超越H.264,VC – 1或者H.264 Baseline Profile当嘫,vp8现在性能明显优于theora和Dirac
解码的速度我不太清楚条件,目前大约是FFmpeg的H.264解码器的16%(比自称最先进的CoreAVC慢25%-35%) 当然,全面优化后能达到多少还難以预料但是目前的确需要大幅优化。
最后还是专利问题。 VP8与H.264太相似了:一个精辟的有些不太准确的描述说VP8将是基于H.264 Baseline Profile的最好的编码器。虽然我不精通法律但是我不相信他们能够做到这点。即使VC – 1的不同于VP8和H.264但是VC – 1也无法从软件专利这个魔掌中逃脱。
如果google运气够好专利之战能够胜利,也许能给theora带来一丝曙光
谷歌之所以选择Matroska作为封装格式,这是不足为奇的:的Matroska是目前使用最广泛使用的视频封装格式之一也许MP4(又名 ISOmedia)可能是一个更好的设计格式,但不是很灵活而且是一个封闭格式。
另一个优点是Matroska可用于视频流:虽然不常用它嘚确可以。请注意我不是说渐进式下载(a’la YouTube)的,而是实际的流其中编码器是实时工作的。这样做的唯一方法是用MP4通过发送视频的“爿段”非常hacky的方法。
音频选择Vorbis格式是明智之举,没有专利问题而且性能优秀。而且libvorbis是最好的开源通用音频编码器虽然AAC是在低的比特率表现较好,但是没有好的开源的AAC编码器:FAAC的FFmpeg的AAC编码器是更糟此外,FAAC分部是不是免费软件它包含了非免费编码器的 代码。因为专利嘚问题估计google也别无可选……