当前位置:首页 >> 信息与通信 >>

谷歌webP和webM


谷歌 WebP 图像格式评测:压缩率显著提升
本月初,Google 宣布了 WebP 图像格式方案, 意欲挑战多年来 JPEG 图像格式在 Web 上的权威。根据 Google 官方给出的资料, WebP 使用了与 WebM 相同的 VP8 编码器来压缩图像,利用预测编码技术,通过部分像素块的颜色来预测其邻近块的颜色值,并只记 录两者的差值,因为多数情况下两者差距很小,甚至 零差距,因而大大提高了压缩的比率。简单的说,Google 想打造出一种文件体 积又小,而且画质和 JPEG 一样的图像格式,以在保证画质的前提下提高网页图像浏览的速度。

大 家知道,图形压缩技术多年都没有特别明显的更新,而 Google 这一方案的宣布无疑是一颗重磅炸弹,很快 Mac 上著名的 图片编辑工具 Pixelmator 宣布支持 WebP 图像格式。在 Google 官方都还没有放出浏览器插件的情况下,Nick Zitzmann 率先推 出了 Mac OS X 平台下的 WebP 浏览器插件。那么,现在很多人关心的是,WebP 到底能否挑战 JPEG 在互联网上的权威呢?为此, 笔者专门对 WebP 这个图像格式的画质进行了测试。

测试的方法很简单,直接使用 Pixelmator 将从数码相机中导出的原图分别转换成 JPEG 和 WebP 格式(画质均设定为 10 0%),然后分别对画质和文件尺寸进行对比,如上图,接下来我们看看测试的结果:

画质对比

整体对比,左边为 WebP,右边为 JPEG

局部多倍放大对比,可见 WebP 明显丢失了大量细节

文件尺寸对比

JPEG 文件容量 5.3MB,WebP 文件容量 2.3MB,WebP 优势明显

再来看第二张照片的对比结果:

画质对比

左边为 WebP 图像格式,右边为 JPEG 图像格式

区别最大的区域,WebP 格式同样丢失色彩细节

文件尺寸对比

WebP 格式压缩率优势明显

通过前面的对比,我们已经可以得出基本结论:WebP 格式图像在压缩率方面表现非常优秀,相对于 JPEG 来说容量小很多,完 全符合 Web 的发展趋势。但在画质表现方面,WebP 明显不能与 JPEG 相比,但整体来看容量的大幅下降完全值得牺牲那一点点画质损 失。

这里顺便简单说一下目前如何使用 WebP 图像格式(Mac 平台):

创建和转换 WebP 格式图像都可以使用 Pixelmator 最新版本来完成,需要注意的是软件安装成功后需要在终端执行一条命 令:"defaults write com.pixelmatorteam.pixelmator enableWebP YES"

在浏览器上显示 WebP 图像可以去这里下载 Weppy 浏览器插件,然后将解压的几个文件拖到系统——资源库——Internet Plug-Ins 文件夹中即可,这样在 Chrome、Safari 以及 FireFox 中都可以正常显示 WebP 图像了,不过笔者在 Mac 版 Opera 中未能测试成功,本文的第一张配图就是在 Chrome 中成功显示 WebP 图像的截图。

目前,WebP 还处在早期开发阶段,因此本文的测试也仅仅能够代表目前 WebP 图像格式的水平。

今天在 Google I/O 谷歌发布一个开放源码的、免费视频格式 WebM 。WebM 是一个高画质 的、开放的、免费实现的以及专门针对 Web 优化的视频格式。不过今天放出的仅仅是开发 者预览版本。 除了宣布 WebM.谷歌还上说明 Webm 将是支持 Youtube 作为 HTML5 的一部分, 所有视频 是在 720p 或更高的上传到 YouTube 的从今天起将在 WebM 除了 H.264 的编码。 VP8 视频编解码器采用类 BSD 许可证授权,免版税。Google 还联合 Mozilla、Opera 推出了 结合 VP8 视频流和 Vorbis 音频的 WebM 容器格式, YouTube 的 HTML5 beta 已率先支持 WebM, Windows 用户可下载 相应插件观看 WebM 视频。 目前支持的浏览器包括 Chromium tip/nightly trunk 版和 Mozilla Firefox nightly trunk 版,Opera beta 即将支持,Chrome 开发者版本将在 5 月 24 日提供支持。互联网视频编解码器大战正式启动。 同时, Google 把之前 On2 公司的 VP8 视频编码也开源了 (Google 前阵子刚刚把 On2 并入囊中) ,今天晚上的最新版 Chromium 就将初步加入 WebM 和 VP8 的支持,大家可 以下载一个最新版 Chromium 看看,或者等待下一次 Chrome Dev 分支的更新。 据称 IE9 也将支持 VP8 这一格式。

深入了解 VP8
感谢 delectate 的投递 问题一:vp8 到底怎么样? 难道他真的比 x264 拥有更高的压缩比率,是个优秀的编码器吗?他真的比 h264 优秀吗?似乎 On2 自己都羞于承认…拿 vp7 举例,O n2 宣称 vp7 比 h264 快 15%,但事实是编码视频速度既不快,视频质量也不高。On2 曾经把 vp3 开源,似乎想借助社区的力量 deb ug,最终 theora 上 当……他们花了 6 年时间,结果做出来的还是个鸡肋……

问题二:vp8 真的没有专利问题吗? 这个东西,还是 google 说了算……微软几年前发布 VC-1,然后说没有专利问题……但是几个月后,就有众多公司认领了专利并成立了专 利池(指几 家公司把各自的专利放在一起,组成一个‖池‖。其他人如果要使用 VC-1,就须向‖池‖的管理公司申请许可,一旦获得了许 可,就可以使用‖池‖中的所有专利。)

问题三:vp8 的代码情况如何

首先你要知道:一个很好的编码器,可能是基于一个很烂的标准(divx?xvid?lol);而一个很好的标准,也可能会出现 n 多很烂的编 码程序 (h264 vs coreavc?不知道耶)。 vp8 的文档真的很烂,很多细节要不就是没有文字说明,要不就是拿一大堆 c 代码来填补空白。真的好痛苦……我一直认为 H.264 的规 格写得太啰嗦,但和 vp8 相比,至少他是精确而详细的,至少不会杀伤我这么多脑细胞。如果只靠 vp8 的这份文档,我想我死 也写不 出来 vp8 的解码器……(莫非他们就是一行一行读 h264 的文档然后写的 ffh264 解码器?牛!)不吐槽了,把视线收回来,看 vp8。 一般处理视频的步骤都是: 编码:预测 -> 变换+量化处理 -> 熵编码 -> 环路过滤器 解码:熵编码 -> 预测 -> 反量化处理+变幻 -> 环路过滤器

p帧

就是通过当前帧已有的部分预测其他区块的内容。可以是在当前帧进行,也可以通过运动补偿的方式在帧间进行。

帧内预测

帧内预测是用来编码帧间不同,在空间域上进行的预测编码算法,可以除去相邻块之间的空间冗余度,取得更为有效的压缩。 vp8 的帧内预测基本上都是照抄 h264 的。‖subblock‖几乎和 h264 一样(他们竟然用了同样的名字),还有 h264 的 4×4 模 式…… whole block 预测也基本上一样使用 16×16 模式。色度预测模式也几乎没有区别,所以不可能拥有比 h264 更出色的效果了。但是值 得一提的是,他们用 TM_PRED 替代了 planar 预测模式。在预测方式上看起来有些不同,但是实际上 h264 都提供了相似的实现方法。 所以我对 vp8 有点失望。虽然说 h264 的预测功能的确不错,但是这也是 7 年的老物了……需要改进,所以我真的希望类似 real 这样的 公司赶紧灭亡 吧,一个存在了十几年而从来没有任何改进的格式(rm,rmvb)……我希望 on2 能做一些更有创造性的工作,而不是照 搬 h264 的东西,因为 h264 的 专利问题就是一个定时炸弹。h264 的帧内预测可是有专利的,真不知道 on2 怎么想的,我可不认为 o n2 改个名字就能蒙混过关。 帧内预测对决:大部份照抄 h264,甚至有的连名字都没改……但是效果貌似还不如 h264。

帧间预测:

帧内预测主要用在去除空间冗余上而帧间预测则主要用在去除时间冗余上。运动估计就是在参考帧中寻找与当前编码宏块最匹配的宏块, 而运动补偿就是计算 二者的差值。帧间预测主要由两个部分组成:参考帧和运动矢量。vp8 支持 3 中参考帧:p 帧,g 帧(golden fr

eam)和 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 却没有

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 的致命错误是已经不使用宏块级量化作为其核心功能。该算法利用宏块级量化的优势被称为―自适应量化‖,是绝对至关重要的。x2 64 使用执行方差的自适应量化(算法对比:使 用前,使 用后)后效果明显,至今仍然是 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 的差,因缺乏自动适应性。虽然选择快速模式可以加快速度,但是成像结果惨不忍睹,十分模糊。

?

附录 A:

总体而言,很明显,VP8 明显比 H.264 差。上面提到的主要弱点是缺乏适当的自适应量化,没有 B 帧,缺少 8 × 8 变换,以及非自适 应性环路滤波器。其实我真的希望 VP8 能超越 H.264,VC – 1 或者 H.264 Baseline Profile。当然,vp8 现在性能明显优于 theor a 和 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 带来一丝曙光。 对比: VP8 (On2 VP8 rc8) (source) H.264 (Recent x264) (source) H.264 Baseline Profile (Recent x264) (source) Theora (Recent ptalabvorm nightly) (source) Dirac (Schroedinger 1.0.9) (source) VC-1 (Microsoft VC-1 SDK) (source) MPEG-4 ASP (Xvid 1.2.2) (source)

?

附录 B:

谷歌之所以选择 Matroska 作为封装格式,这是不足为奇的:的 Matroska 是目前使用最广泛使用的视频封装格式之一,也许 MP4(又 名 ISOmedia)可能是一个更好的设计格式,但不是很灵活,而且是一个封闭格式。 另一个优点是 Matroska 可用于视频流:虽然不常用,它的确可以。请注意,我不是说渐进式下载(a’la YouTube)的,而是实际的 流,其中编码器是实时工作的。这样做的唯一方法是用 MP4 通过发送视频的―片段‖,非常 hacky 的方法。 真搞不懂为什么 google 非要给 Matroska 起 WebM 这么个愚蠢的名字 音频选择 Vorbis 格式,是明智之举,没有专利问题,而且性能优秀。而且 libvorbis 是最好的开源通用音频编码器。虽然 AAC 是在低 的比特 率表现较好,但是没有好的开源的 AAC 编码器:FAAC 的 FFmpeg 的 AAC 编码器是更糟。此外,FAAC 分部是不是免费软件, 它包含了非免费编码器的 代码。因为专利的问题,估计 google 也别无可选……

?

参考资料:

http://x264dev.multimedia.cx/?p=377 http://www.ruanyifeng.com/blog/2010/05/the_first_view_of_vp8.html http://baike.baidu.com/view/587027.htm http://hi.baidu.com/hnu_lina/blog/item/f13a59b1fd7eb9520823023e.html http://zh.wikipedia.org/zh/%E7%86%B5%E7%BC%96%E7%A0%81 部分翻译:http://x264dev.multimedia.cx/?p=377

VP8 视频格式初探
作者: 阮一峰

日期: 2010 年 5 月 20 日

昨天,Google 发布了一个开源项目 WebM。

这个项目的目的,是在文件格式方面,为制作和发布互联网视频提供了一个开源 的解决方案。

WebM 采用 MKV 作为封装格式,里面的音频编码用 Vorbis 格式,视频编码用 VP8 格式。

MKV 和 Vorbis 都是早就存在的开源格式,而 VP8 本来属于 On2 公司的封闭格 式,是不开源的。去年 8 月,Google 花了 1 亿美元收购 On2,才有了今天。

这个决定轰动了业界,因为这意味着,我们终于有了一个没有专利约束、并且获 得大公司支持的免费视频编码格式 VP8(详见我翻译的《HTML5 视频格式之争》 一文)。

但是,VP8 其实只是一种规格,以前从来没有公开过,也没有任何基于它的产品 问世。所以,外界一直不知道 VP8 的性能究竟如何。

开源视频转换程序 ffmpeg 的开发者之一 Jason Garrett-Glaser,有机会提前接触 到了 VP8。他写了一篇很详细的评估,说出了自己对 VP8 的印象,并将 VP8 与 专利格式 H.264 做了比较。

下面就是这篇评估的简单翻译,删去了讨论技术细节的部分。

=======================

VP8 视频格式初探(精简版)

作者:Jason Garrett-Glaser

译者:阮一峰

原文网址:http://x264dev.multimedia.cx/?p=377

一、On2 是一家怎样的公司?

在开始讨论 VP8 之前,我想先谈谈对 On2 公司的印象。

它曾经宣称,VP8 比 H.264 的性能高出 50%。但是,它的话是不可信的。因为它 也说过, 比 H.264 的性能高出 15%。 VP7 但是后来人们发现, 远远不如 H.264。 VP7

2003 年,On2 宣布 VP3 开源。表面上,它好像为开源事业做出了贡献。但是实 际上,它的目的是,希望开源社区为它修正错误。Theora 项目上了当,选择 VP3

作为自己的代码基础,结果修改代码的时间用去了 6 年,做出来的产品性能还是 不如 H.264。

二、VP8 的规格

这份规格文件令人很不满意。很多技术细节,不是写得太简单,就是写得太模糊。 大部分地方都是直接张贴 C 代码, 而不是用文字表述。 要知道 C 代码和格式规格, 完全是两回事,根本不能替代。

我曾经觉得,H.264 的规格写得太啰嗦,但它至少是准确的。VP8 的规格根本就 是不清晰,不准确,太简短,很多细节没有解释清楚。老实说,仅仅根据这份规 格,地球上根本不可能有人能够写出 VP8 的解码器。

更令人惊奇的是,根据代码中的注释,VP8 有些部分写于 2004 年初,比 H.264 还要古老!On2 在此后 6 年的时间中,都不做修改,这是说不过去的。

三、VP8 编码器(Encoder)

首先要明确一件事情。格式规格和它的具体实现,是两回事。一个很好的编码程 序,可能是基于一个很烂的规格;而一个很好的规格,也可能会产生出一个很烂 的编码程序。

原厂提供的解码器,生成的图像质量虽然大大好于 VP3,但是并没有明显胜过 H.264 的地方。

这个编码器的编码速度要慢于 H.264。 我的机器是 1.6Ghz 的 Core i7, 编码 1080p 时速度为 26fps;而用 H.264 编码器,选择"最快速度"选项时,可以达到 101fps。

在压缩性能方面,VP8 也不如 H.264。

四、VP8 解码器(Decoder)

原厂提供的 VP8 解码器,比 ffmpeg 的 H.264 解码器慢了 16%,更不要说其他更 先进的 H.264 解码器了。

就算最终通过各种优化,VP8 解码器可以达到 H.264 的同样水平。但是,H.264 有众多硬件支持,而 VP8 只能靠软解码,所以谁快谁慢不言而喻。

五、专利问题

VP8 的一大卖点,就是没有专利权问题。但是,它的某些细节与 H.264 太像,我 觉得已经很难用巧合解释了,将来肯定会出现专利纠纷。

在没有明确证据表明 VP8 通过专利检验之前,我建议使用时一定要非常谨慎。

[附录]

Youtube 已经开始提供 WebM 视频了,不过只有最新的浏览器才支持。具体的观 看方法请查看 http://www.ghacks.net/2010/05/20/webm-video/(英文)。

(完)


相关文章:
更多相关标签: