主流编解码器（H.264 AVC, H.265 HEVC, VP8, VP9）比较

最新推荐文章于 2024-05-31 09:50:29 发布
最新推荐文章于 2024-05-31 09:50:29 发布
阅读量1.9w 收藏 32
点赞数 3
分类专栏： 音视频开发

主流编解码器（H.264 AVC, H.265 HEVC, VP8, VP9）比较

 

 

本文转自：http://houh-1984.blog.163.com/blog/static/31127834201321995354105/

概述

H.264(MPEG 4, class 10 )是目前嵌入式和移动设备中采用最多的视频编解码算法标准。目前超过50家公司提供H.264相关的产品(H.264 hardware/software building blocks )。最近几年谷歌Google开源了

 WebM video coder 来构建基于Android的移动和消费视频平台。还有其他开源的视频标准codec如Dirac, FFMpeg and Theora,但市场上应用的很少。一些市场上的主导者如 Allegro, Broadcom, Samsung, 和 ViXS等已经开始H.265High Efficiency Video Coder (HVEC)的开发。

Embedded论坛上有一些论述H.264/H.265编解码器设计的文章博客或者白皮书:

Making mobile video apps more energy efficient 
A tutorial on the H.264 scalable video codec 
Introduction to video transcoding for consumer electronics 
A low power implementation of the H.264 codec for consumer apps 
Trade-offs with H.264 and other video codecs 
Wireless HDMI with a low latency, lossless H.264 video codec 
Zero latency time-critical video encode/decode with H.264 

Codec designfor nextgen Internet Video

 Using the H.264 spec to do anywhere, anytime placeshifted video,

Apple's continued support for the standards

虽然H.264/H.265仍然是视频codec的首选，但由于专利等问题，Google的WebM开源编解码器也在嵌入式平台得到了很大的应用。Google的chrome处理器也优先集成VP8、VP9的编解码标准。

H.264/MPEG-4 AVC

概述

H.264/MPEG-4第10部分，或称AVC（Advanced Video Coding，高级视频编码），是一种视频压缩标准，一种被广泛使用的高精度视频的录制、压缩和发布格式。第一版标准的最终草案于2003年5月完成。H.264/MPEG-4 AVC是一种面向块的基于运动补偿的编解码器标准。由ITU-T视频编码专家组与ISO/IEC联合工作组——即动态图像专家组（MPEG）——联合组成的联合视频组（JVT，Joint Video Team）开发。因ITU-T H.264标准和 ISO/IEC MPEG-4 AVC标准（正式名称是ISO/IEC 14496-10 — MPEG-4第十部分，高级视频编码）有相同的技术内容，故被共同管理。H.264因其是蓝光盘的一种编解码标准而著名，所有蓝光盘(blue-ray)播放器都必须能解码H.264。它也被广泛用于网络流媒体数据如Vimeo、YouTube、以及Apple的iTunes Store，网络软件如Adobe Flash Player和Microsoft Silverlight，以及各种高清晰度电视陆地广播（ATSC，ISDB-T，DVB-T或DVB-T2），线缆（DVB-C）以及卫星（DVB-S和DVB-S2）。

图1. H.264编码流程图

技术细节

H.264/AVC包含了一系列新的特征，使得它比起以前的编解码器不但能够更有效的进行编码，还能在各种网络环境下的应用中使用。这些新特性包括：

  • 多参考帧的运动补偿。比起以前的视频编码标准，H.264/AVC以更灵活的方式使用已编码的更多帧来作为参考帧。在某些情况下，可以使用最多32个参考帧（在以前的标准里面，参考帧的数目不是1就是对B帧来说的2）。该特性对大多数场景串行都可以带来一定的码率降低或者质量提高，对某些类型的场景串行，例如快速重复的闪光，反复的剪切或者背景遮挡的情况，它能很显著的降低编码的码率。

  • 变块尺寸运动补偿。可使用最大16x16至最小4x4的块来进行运动估计与运动补偿，能够对图像串行中的运动区域进行更精确的分区。这些类型共有16×16、16×8、8×16、8×8、8×4、4×8、4×4。

  • 为了减少混叠（Aliasing）并得到更锐化的图像，采用六抽头的滤波器（六阶数字滤波器）来产生二分之一像素的亮度份量预测值。

  • 宏块对结构允许场模式中采用16x16的宏块（相对于MPEG-2中的16x8）。

  • 1/4像素精度的运动补偿能够提供更高精度的运动块预测，由于色度通常是亮度抽样的1/2（参见4:2:0），这时运动补偿的精度就达到了1/8像素精度。

  • 加权的运动预测，指在运动补偿时可以使用增加权重和偏移的办法。它能在一些特殊的场合，如淡入、淡出、淡出而后淡入等情况提供相当大的编码增益。

  • 使用了一个Loop的除块效应滤波器，能够减轻普遍存在于其他基于离散余弦变换（DCT）的视频编解码器的块效应。

  • 一个匹配的整数4x4变换（类似于离散余弦变换的设计），同样在高精度拓展中，采用整数8x8变换，并能在4x4变换和8x8变换中进行自适应的选择。

  • 在第一次4x4变换后，对DC系数（色度的DC系数和某种特殊状况的亮度DC系数）再进行一次Hadamard变换，使得在平滑区域得到更好的压缩效果。

  • 利用临近块的边界像素的Intra空间预测（比曾在MPEG-2视频部分使用的直流系数预测和在H.263+和MPEG-4视频部分使用的变换系数预测的效果要好）。

  • 基于上下文的二元算数编码（CABAC），它能够灵活的将各种语法元素，在已知相应上下文概率分布的状况下进行更有效的无损熵编码。

  • 基于上下文的变长编码（CAVLC），用于对量化后的变化系数进行编码。比起CABAC它的复杂度相对较低，压缩比不高，但是比起以前的视频编码标准所使用的熵编码方案，它又是相当有效的。

  • 对既不是用CABAC也不是用CAVLC的语法元素，使用指数哥伦布码（Exponential-Golomb，Exp-Golomb）熵编码方案，进行编码。

  • 使用一个网络抽像层 (NAL)，使得相同的视频语法可以适用于多种网络环境中；并且使用了串行参数集（SPSs）和图像参数集（PPSs）来提供更高的强健性（robustness）和灵活性。

  • 切换条带（Switching slices，包括SP和SI两种），它使得编码器能够指令解码器跳转到一个正在处理的视频码流，用来解决视频码流码率切换和"窍门模式"(Trick mode)操作。当解码器利用SP/SI条带跳转到一个视频码流中间时，除非之后的解码帧引用切换帧之前的图像作为参考帧，它都可以得到完全一致的解码重建图像。

  • 灵活的宏块排列模式（FMO for Flexible macroblock ordering，也被称为条带组slice groups技术）和任意条带排列（ASO for arbitrary slice ordering）模式，用来更改图像编码的最基本单位-宏块的编码顺序。它能够用来提高有绕信道下码流的强韧性（robustness）以及一些其它的目的。

  • 数据分区（DP for Data partitioning），能够将重要程度不同的语法元素分开打包传输，并使用非平等数据保护（UEP for unequal error protection）等技术来改善视频码流对抗信道误码／丢包的强韧性（Robustness）.

  • 冗余条带（RS for Redundant Slices），同样是一个提高码流鲁棒性的技术。编码器利用该技术可以发送图像某区域（或者全部）的另一个编码表示（通常是较低分辨率的编码码流）使得当主表示发生错误或者丢失的时候能够用冗余的第二个编码表示来解码。

  • 使用了一个自动的字节码流打包方法，避免了码流中出现与开始码重复的码字。开始码是码流中用于随机访问和重建同步的码字。

  • 补充增强信息（SEI for Supplemental Enhancement Information）和视频可用信息（VUI for Video Usability Information）增加了向视频码流中加入信息的办法，为各种应用提供了用途。

  • 辅助图层（Auxiliary pictures），可以用来实现某些特殊的功能，例如alpha复合（alpha compositing）。

  • 帧编号，使用该功能支持创建一个视频串行的子串行，可用来支持实现时域的可伸缩性，还支持对丢失的整帧图像进行检测和隐藏（丢失可能是由于网络丢包或者信道误码造成的）。

  • 图像顺序计数，使用该功能使得各帧图像的顺序和解码图像的像素值与时间信息无关，即使用一个单独的系统对时间信息进行传输、控制、更改，从而不影响解码图像的像素值。

上述这些技术，与其它技术的结合，使得H.264比起以前的视频编解码能够带来性能上显著的提高，并在各种不同的环境下达成更广泛的应用。H.264在压缩性能上比起MPEG-2有很大的提高，在相同的图像质量下可以，码率可以减少到一半或者更少。和MPEG的其它视频标准一样，H.264/AVC也提供了一个参考软件JM(http://iphome.hhi.de/suehring/tml/)以及开源的快速实现x264(http://www.videolan.org/x264.html)，并可以免费下载。它的主要目的是提供一个演示H.264/AVC各种功能的演示平台，而不是作为一个直接的应用平台。目前在MPEG也同时在进行一些硬件参考设计的实现。

应用领域和实现

苹果公司已经将H.264集成进入Mac OS X版本v10.4（昵称Tiger），并于2005年5月发布了支持H.264的QuickTime版本7.0。

第三代移动通信合作组织（3GPP）已经在第六次发布中批准H.264/AVC作为其移动多媒体电话服务标准的可选技术。

美国国防部下的运动图像标准协会（MISB for The Motion Imagery Standards Board）已经接受H.264/AVC为其核心应用的推荐视频编解码器。

互联网工程工作小组（IETF）已经完成了一个负载打包格式（RFC 3984）作为在其实时传输协议（RTP）上传输H.264/AVC码流的打包办法。

互联网流媒体协会（ISMA for Internet Streaming Media Alliance）已经接受H.264/AVC作为其ISMA 2.0的技术规范。

MPEG组织将H.264/AVC完全的集成进入了它的系统协议（例如MPEG-2和MPEG-4系统）和ISO媒体格式协议。

国际电信联盟ITU-T标准组已经采纳H.264/AVC作为其H.32x系列的多媒体电话系统的系统规范的一部分。ITU-T的采纳，使得H264/AVC已经被广泛的使用在视频会议系统中，并获得了视频电话主要的两家产品提供商（Polycom和Tandberg的支持。实际上所有新的视频会议产品都支持H.264/AVC。

H.264将很可能被各种视频点播服务（Video-On-Demand，VOD）使用，用来在互联网上提供电影和电视节目直接到个人电脑的点播服务。

H.264/MPEG-4 AVC SVC

可伸缩视频编码（Scalable Video Coding, SVC）是传统H.264/MPEG-4 AVC编码的改进，可提升更大的编码弹性，并具有时间可伸缩（Temporal Scalability）、空间可伸缩（Spatial Scalability）及信噪比可伸缩（SNR Scalability）三大特性，使视频传输更能适应在异质的网络带宽。SVC的目标在于标准化已使编码的高品质的视频码流，其中包含一个或多个子位流（subset bitstream）进行解码，可以自己用一个复杂和重建质量达到类似的利用现有的H.264/MPEG- 4 AVC的设计与相同数量的数据码流中的一个子集。

一个子集码流（subset bitstream）可以代表一个较低的空间或时间分辨率较低或质量的视频信号（每个单独或组合）相比。

  • 时间（帧速率）的可扩展性：运动补偿，使依赖的结构完整的图片（即他们相关的数据包）可以从bitstream中被丢弃。（时间可扩展性已经启用的H.264/MPEG-4 AVC的。SVC还加强信息只提供参考，以改善其使用量。）

  • 空间（图片大小）的可扩展性：视频编码是在多个空间分辨率。解码后的数据和样品较低的分辨率可以用来预测数据或样本，更高的分辨率，以降低bitrate更高的分辨率。

  • 信噪比/质量 /富达可扩展性：编码视频是在一个单一的空间分辨率，但在不同的品质（qualities）。解码后的数据和样品素质较低，可用于预测数据或样本的高品质，减少bitrate以取得较高的品质（qualities）。

  • 联合可扩展性（Combined scalability）：结合上述三个扩展性。

技术细节

Scalable Video Coding包含了若干可伸缩的配置： Scalable Baseline, Scalable High, Scalable High Intra, Scalable Constrained Baseline and Scalable Constrained High Profile. 这些配置组合了基准层的H.264/MPEG-4 AVC的配置以及用于可伸缩的扩展工具：

  • Scalable Baseline Profile:面向会话、移动和监控应用

    • 基本层为H.264/MPEG-4 AVC Baseline Profile

    • 支持B slices,加权预测weighted prediction, CABAC 熵编码,增强层的8×8亮度变换，而基本层没有这些增强工具；

    • 空间可伸缩被限制在水平和垂直分辨率比值在1.5和2之间；而质量和时间可伸缩则没有限制；

    • Quality and temporal scalable coding are supported without any restriction.

  • Scalable High Profile:面向广播、流媒体、存储和视频会议的应用。

    • 基本层为H.264/MPEG-4 AVC High Profile

    • 支持Scalable Video Coding扩展中的所有工具.

    • 空间分辨率、质量和时间可伸缩则没有限制

  • Scalable High Intra Profile:面向专业应用

    • 只采用瞬时解码刷新图像 Instantaneous Decoder Refresh (IDR). IDR图像不会以之前的图像作为参考。

    • 基本层为H.264/MPEG-4 AVC High Profile的只有IDR图像的模式；

    • 空间分辨率、质量和时间可伸缩则没有限制，但只对IDR图像有意义；

  • Scalable Constrained Baseline Profile

  • Scalable Constrained High Profile

H.265 High Efficiency Video Coding

H.265是ITU-T VCEG继H.264之后所制定的高压缩率的视频压缩格式。H.265视频格式标准在2013年1月25日由国际电信联盟（ITU）正式宣布,最高分辨率可达 8192×4320。 NGVC想要将比特率减少了50％，同时主要图像质量和计算复杂性与H.264相比，计算复杂度从提升到3倍。HEVC面向下一代HDTV设计，特性如帧扫描(progressive scanned)、支持采样率到 4320p (8192×4320)，增强的动态范围调整和噪声抑制等。

图2. H.265编码流程图

技术特点

  • 二维不可分离的自适应插补滤波器

  • 可分离的 AIF

  • 定向的AIF

  • 不再使用运动补偿与1/8-pel运动矢量

  • Supermacroblock结构到64x64转换（H.264仅到32x32）

  • 自适应预测误差编码组织（APEC）

  • 自适应量化矩阵选择（AQMS）

  • 运动矢量选择与编码的竞争方式

  • 针对内部编码的模块相依的KLT

预测块大小

HEVC将之前标准中定义的宏块(macroblocks)用一种最大到64x64像素的并且可以进一步细分成可变大小的块。HEVC把编码树单元（coding tree units (CTUs)）变成亮度和色度的编码块（coding tree blocks (CTBs)）。一个CTB可以大小为64x64、32x32或者16x16.这样帧内（intra-picture）和帧间（inter-picture）的预测块(prediction units，PU)大小从64x64到4x4大小，只是对于双向预测，只能到8x4到4x8大小。预测残差编码的变换块大小可以是32x32、16x16、8x8、4x4.

内部色深的增加

内部色深增加（Internal bit depth increase (IBDI)）可以让编码器运行在色宽更高的内部状态。IBDI最多可以作用于14-bit位宽。

并行处理工具（Parallel processing tools）

可以把图像分成独立编解码的矩形块和条带，即条带slice和tile瓷片的概念。条带大部分可以单独解码，只是最终需要同步成一个视频流。条带可以编码成条带间没有预测，互相独立。当然条带间可能还是需要环路滤波的。

熵编码（Entropy coding）

HEVC采用基于上下文自适应的熵编码算法（context-adaptive binary arithmetic coding (CABAC)），和H.264类似。只不过HEVC只支持CABAC编码。

帧内预测（intra prediction）

HEVC的帧内预测有33个方向模式，而h.264中只有8个，HEVC还指定了planar和DC帧内预测模式。

运动补偿(Motion compensation)

HEVC采用半像素或者1/4像素的精度运动补偿，以及7抽头或者8抽头的滤波器。H.264使用半像素精度和6抽头的滤波器。对于4：2：0视频的色度分量有1/8像素精度和4抽头的滤波器。HEVC中的加权预测可以是单向也可以是双向的预测。

运动矢量预测Motion vector prediction

HEVC定义了16-bit的水平和垂直运动矢量，支持范围到[-32768, 32767]，即最多-8192到8191.75个亮度像素点，H.264只支持到-512到511.75个像素点。HEVC的MV模式有高级运动矢量预测（Advanced Motion Vector Prediction (AMVP)）和合并模式。合并模式运行从邻近块继承mv向量值，从而有skip和direct模式。

反量化（Inverse transforms）

HEVC中预测残差编码的变换块大小可以是32x32、16x16、8x8、4x4.一个CTB可以递归的分成4个或者更多个TU。TU会使用基本的变换DCT（discrete cosine transform），另外4x4的帧内预测亮度块的残差采用从DST( discrete sine transform)中推导的整数变换。这相对于原来的4x4亮度变换有1%的码率降低。色度块采用和亮度块相同的TU大小。

环路滤波器

HEVC有两个环路滤波器，解块滤波器（DBF， deblocking filter）与样本自适应偏移量（SAO，sample adaptive offset）滤波器 (DBF)。Deblocking滤波器和H.264/MPEG-4 AVC中的类似，HEVC中的DBF只能用于8x8的块（提高并行处理性能），而H.264适用于4x4的块。HEVC中DBF的强度从0到2.对垂直边界做水平滤波，对水平边界做垂直滤波。SAO滤波器在DBF滤波器之后，为了更好的重建原始图像。每个CTB的SAO滤波器可以使能或者禁止边界偏移模式或者子段偏移模式。

解块滤波器

DBF使用H.264/MPEG-4 AVC类似的设计，更好的支持并发处理是类似的。在HEVC的DBF只适??用于一个8×8个采样网格，而与H.264 / MPEG-4 AVC的DBF适用的一个4×4个采样网格。的DBF使用一个8×8个采样网格，因为它会导致没有明显的降解，并显著提高了并发处理，因为的DBF不再导致级联与其他操作的相互作用。另一个变化是HEVC只允许为0?2的三个DBF长处。HEVC也需要的DBF首先应用到画面的垂直边缘的水平滤波和只有在那之后它应用对于水平边缘的垂直滤波的图片,这允许为多个并发线程的DBF。

样本自适应偏移量

在DBF之后的使用SAO过滤器，并使用偏移以产生更好地重建原始信号。每C个TB的SAO滤波器可有两个模式：边缘偏移模式??或带偏移模式。边缘偏移量模式中通过比较的取样的值，根据比较两个邻居，将样品分为五类之一：最小，两种边缘，最大值，或两者都不是，对于每个第一四类施加一个偏移量。能带偏移的模式可分类成32个频带，并选择四个连续频带传送偏移量。SAO滤波器设计来以提高图像质量，并减少振荡效应.

编码效率 coding efficiency

图1各种视频标准相同PSNR下的对比

视频编码标准

平均码率下降

H.264/MPEG-4 AVC HP

MPEG-4 ASP

H.263 HLP

H.262/MPEG-2 MP

HEVC MP

35.4%

63.7%

65.1%

70.8%

H.264/MPEG-4 AVC HP

-

44.5%

46.6%

55.4%

MPEG-4 ASP

-

-

3.9%

19.7%

H.263 HLP

-

-

-

16.2%

视频编码效率通常用peak signal-to-noise ratio (PSNR)客观评价指标来度量。HEVC受益于更大的Coding Tree Block (CTB)大小。HM-8.0 HEVC视频分辨率为2560×1600，和使用64×64 CTB大小相比，如果采用 32×32 CTB大小，码率增加5.7%，如果使用16×16 CTB大小，码率增加28.2%。而且分辨率越大，CTB大小越大的码率减少越多同时解码时间也减少。上表是HEVC Main Profile (MP)和H.264/MPEG-4 AVC High Profile (HP), MPEG-4 Advanced Simple Profile (ASP), H.263 High Latency Profile (HLP),以及 H.262/MPEG-2 Main Profile (MP)的编码效率比较。测试序列包括了5个HD分辨率和4个WVGA (800×480)分辨率。主观测试的结果表明相同的主观质量下，HEVC MP比H.264/MPEG-4 AVC HP码率平均下降49.3%.

VP8

VP8 是一个开放的图像压缩格式，最早由 On2 Technologiesis 开发，随后由 Google 发布。同时 Google 也发布了 VP8编码的实做库：libvpx，以BSD授权条款的方式发布，随后也附加了专利使用权。而在经过一些争论之后，最终 VP8 的授权确认为一个开放源代码授权。VP8编码的开发从2008年9月13日开始，目的是要取代旧有的 VP7 编码格式。Google 在2010年收购了 On2 之后，各界便呼吁 Google发布 VP8的源代码，在2010年3月12日，自由软件基金会发表了一个公开信，希望 Google 能够逐渐的以 HTML5 和开放的 VP8，取代 Youtube 目前使用的 Adobe Flash Player 和 H.264。

2010年5月19日，Google在 Google I/O年会上，以BSD授权条款的发布了 VP8 编码软件，VP8的比特流格式则是以不可撤回的免费专利使用权发布。VP8也成为第二个 On2 Technologies以开放源代码方式发布的编码产品，前一个是捐赠给Xiph.Org基金会 的VP3，随后成为了图像编码格式 Theora。

编码

目前 VP8只能通过 libvpx来进行编码，而 Google聘用了 FFmpeg 的开发者 Ronald Bultje 来开发基于 x264 架构的 VP8 编码器，称为 xvp8，将来发布后会集成在 x264中。而芬兰的 WebM硬件开发团队则是发布了暂存器转换层次结构（Register transfer level）的VP8硬件编码器，提供给半导体制造商免费使用。

解码

libvpx可以解码 VP8的图像，在2010年7月23日，FFmpeg 的开发者Jason Garrett-Glaser、Ronald Bultje和 David Conrad发布了名为 ffvp8的 VP8解码器，测试结果显示 ffvp8比 Google自己的 libvpx解码器性能更佳。另外 WebM专案的硬件团队也有发布暂存器转换层次结构（Register transfer level）的硬件解码器，同样是免费使用。

WebM

WebM专案和 VP8同时在2010年5月19日发表，Mozilla、Opera、Google和其他40多家厂商共同协助发展，目的是让 VP8 成为HTML5的图像格式。WebM为一个容器格式，图像部份使用 VP8，声音格式则是使用 Vorbis。Internet Explorer 9 可以通过安装解码器支持 WebM图像，行动操作系统 Android 则是在2.3版（Gingerbread）之后支持 WebM Adobe 也宣布会在将来的 Flash Player 中支持 VP8图像的播放。

WebP

在2010年9月30日，Google发布了 WebP，是以 VP8编码为基础的图片文件格式，目的是取代现有的 JPEG ，作为网络图片的传输使用，使用的容器格式为Resource Interchange File Format (RIFF)。

和H.264的比较

H.264是目前使用最多的网络图像编码格式，因此最常拿来和 VP8做比较。

H.264 的编码技术包含专利（由 MPEG-LA 提供授权），而且在硬件上使用需要取得授权，VP8则不需要。即使有Google的背书，但VP8仍然很难避过所有的专利，其下场可能跟VC-1如出一辙。管理H.264专利池的MPEG LA声称有12家公司持有Google VP8的专利。美国MPEG LA表示："创建VP8专利池的相关准备正在进行"。

根据 MSU Graphics & Media Lab在2011年5月的测试，VP8需要约213%的数据量，才能达到和 H.264相同的图像品质。

x264 的开发者之一：Jason Garrett-Glaser，给了一些针对 VP8的评论，他认为 VP8目前并没有实现真正的比特流规范，而且在一些编码的技术上有所欠缺。

VP8的subblock预测和H.264的4×4模式一致，但VP8不支持 H.264 High profile的8×8模式，会影响对细节的保持。VP8缺少 B frame是另一个大问题。H.264已有大量的硬件支持，但VP8仍需要依靠软件解码。VP8的标准文档过于简陋可能是最让人诟病的问题，大部分是直接贴C language code，而不是文字表述，许多细节没有交待清楚。

VP9

VP9 是Google提供的开源的免费视频codec，是VP8的后续版本，初始开发时命名为下一代开源视频或者VP-NEXT. VP9的开发始于2011年Q3，试图降低VP8的50%的码率而保持相同的质量，另外希望VP9比H.265（ High Efficiency Video Coding）有更好的编码效率。 2012年底，VP9的解码器被加入Chrome浏览器，2013年2月发布正式版本的chrome浏览器。VP9支持超宏块大小到32x32，也采用了四叉树的宏块分解结构。

Reference:

http://houh-1984.blog.163.com

http://www.embedded.com/electronics-blogs/cole-bin/4407676/Who-ll-win-the-consumer-video-codec-battles-?cid=Newsletter+-+Embedded.com+Tech+Focus

http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding

http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC

http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC_products_and_implementations

http://en.wikipedia.org/wiki/Scalable_Video_Coding

http://en.wikipedia.org/wiki/VP8

http://en.wikipedia.org/wiki/VP9

本文介绍了目前消费电子市场常用的视频编解码器H.264 AVC, H.265 HEVC以及Google开源的VP8和VP9编解码器，分析了他们的技术特点、编码效率和应用领域。

zhangbijun1230
关注
  • 3
    点赞
  • 踩
  • 32
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
WebRTC 视频编解码类型的选择 VP8 H264 还是其他？(openh264编码，ffmpeg解码)
一蓑烟雨任平生 也无风雨也无晴
02-16 2010
在你的WebRTC应用中，选择正确的视频编解码器很重要，但是如何选择又是一个棘手的问题。 WebRTC 视频编解码器 –简要回顾 WebRTC 曾经很容易。你有 VP8、Opus 和 G.711。 G.711 被删除是因为我不想让你使用它。真的没有理由这样做。 后来，H.264 被添加为强制实现视频编解码器。在 WebRTC 的世界里一切都很好。 谷歌随后决定在 Chrome 中引入 VP9。作为可选编解码器。 Mozilla 也将 VP9 添加到 Firefox。微软当他们..
完整的H263和H264和H265和MPEG4和vp8和vp9测试影片
06-13
本资源包含的“完整的H263和H264和H265和MPEG4和vp8和vp9测试影片”是一个集合，涵盖了多种主流的视频编码格式，这些格式各有特点，适应不同的应用场景。下面我们将详细探讨这些编码标准。 1. H.263：由国际电信...
H.265/HEVC压缩编码标准
06-03
JCTVC-L1003_v9(High Efficiency Video Coding (HEVC) text specification draft 10 (for FDIS & Consent))； 是为了了解SPS每一个参数的意义找的，确实有说明每一个参数，像毕厚杰那本“新一代压缩标准H264”介绍一样
HEVC，VP9，x264性能对比
dianyimo9099的博客
02-09 815
Dan Grois等人在论文《Performance Comparison of H.265/MPEG-HEVC, VP9, andH.264/MPEG-AVC Encoders》中，比较了下一代编码标准HEVC，VP9的以及当前主流编码标准H.264之间的性能。在此记录一下。 本文中选用的编码器如下： HEVC：HM VP9：libvpx H.264：x264 ...
推荐开源项目：Medooze SFU - 革命性的WebRTC VP9 SVC服务器
最新发布
gitblog_00065的博客
05-31 251
推荐开源项目：Medooze SFU - 革命性的WebRTC VP9 SVC服务器 项目地址:https://gitcode.com/medooze/sfu 1、项目介绍 Medooze SFU是一个前瞻性实验项目，专注于为WebRTC多会议提供未来可能的高性能和高质量解决方案。该项目旨在探索并提前提供即将改变游戏规则的新功能，特别是针对VP9 SVC（Scalable Video Coding...
HEVC与VP9编码效率对比
雷霄骅(leixiaohua1020)的专栏
09-15 1542
HEVC（High EfficiencyVideo Coding，高效率视频编码）是一种视频压缩标准，H.264/MPEG-4 AVC的继任者。目前正在由ISO/IEC MPEG和ITU-T VCEG开发中。为此目的MPEG与VCEG联合成立了一个JCT-VC（JointCollaborative Team on Video Coding）作为共同开发HEVC的团队。HEVC被认为不仅提升图像质...
VP9 Video Codec
weixin_33836223的博客
06-15 1492
http://www.webmproject.org/vp9/   WebM Repositories libvpx: VP8/VP9 Codec SDK   pull http://git.chromium.org/webm/libvpx.git push ssh://gerrit.chromium.org:29418/webm/libvp...
音视频基础1：H264、H265、MPEG-4、VP8、VP9编码基础知识
jakezhang1990的专栏
01-04 7710
这里写自定义目录标题个人认知，程序员职业发展出路 个人认知，程序员职业发展出路 随着5G时代的到来，音视频成功走上风口，程序员如何发展，其实不管是入门级选手还是30岁，35岁中年危机的IT开发者，异或是更年长的IT开发者，都会有自己的职业发展路线。总结来说，目前大部分人的职业路线，职业出路，或者说职业遇到瓶颈以后解决方案可以总结为一下几种，程序员是天天解决问题，天天给各种问题解决方案的人，对于自己的职业当然也得给出最好的解决方案： ，转行；最简单粗暴的，从写代码的工作变换到开个杂货铺，开个烧烤摊，或者考个
一种简单的封装VP8/VP9视频的容器：IVF格式
lessconcern的专栏
08-18 7417
IVF是一个非常简单的视频容器。用于封装VP8/VP9的数据。 下面多字节的数据是采用小端编码(little-endian)。IVF文件头由32字节组成： bytes 0-3    signature: 'DKIF' bytes 4-5    version (should be 0) bytes 6-7    length of header in bytes bytes
h264 h265码流分析工具（Elecard HEVC Analyzer，Elecard StreamEye Tools，H264Visa）
08-21
Wireshark是一个强大的网络封包分析软件，配合h265_export.lua和rtp_h264_extractor.lua这两款Lua脚本，可以方便地从网络流量中捕获并导出H264和H265的裸码流数据，这对于研究码流结构、开发解码器或进行网络性能...
VP9编码器 v1.3.0
01-07
VP9相比VP8有着很多的提升。在比特率方面，VP9比VP8提高2倍图像画质，H265的画质也比H264高2倍。VP9一大的优势是没有版税。和H.264和H.265不同，它免费进行使用。
世界上最快的VP9视频解码器
01-07
世界上最快的VP9视频解码器 As before , I was very excited when Google released VP9 – for one, because I was one of the people involved in creating it back when I worked for Google (I no longer do). How good is it, and how much better can it be? To evaluate that question, Clément Bœsch and I set out to write a VP9 decoder from scratch for FFmpeg. The goals never changed from the original ffvp8 situation (community-developed, fast, free from the beginning). We also wanted to answer new questions: how does a well-written decoder compare, speed-wise, with a well-written decoder for other codecs? TLDR (see rest of post for details): as a codec, VP9 is quite impressive – it beats x264 in many cases. However, the encoder is slow, very slow. At higher speed settings, the quality gain melts away. This seems to be similar to what people report about HEVC (using e.g. x265 as an encoder). single-threaded decoding speed of libvpx isn’t great. FFvp9 beats it by 25-50% on a variety of machines. FFvp9 is somewhat slower than ffvp8, and somewhat faster than ffh264 decoding speed (for files encoded to matching SSIM scores). Multi-threading performance in libvpx is deplorable, it gains virtually nothing from its loopfilter-mt algorithm. FFvp9 multi-threading gains nearly as much as ffh264/ffvp8 multithreading, but there’s a cap (material-, settings- and resolution-dependent, we found it to be around 3 threads in one of our clips although it’s typically higher) after which further threads don’t cause any more gain. The codec itself To start, we did some tests on the encoder itself. The direct goal here was to identify bitrates at which encodings would give matching SSIM-scores so we could do same-quality decoder performance measurements. However, as such, it also allows us to compare encoder performance in itself. We used settings very close to recommended settings forVP8,VP9andx264, optimized for SSIM as a metric. As source clips, we chose Sintel (1920×1080 CGI content, source ), a 2-minute clip from Tears of Steel (1920×800 cinematic content, source ), and a 3-minute clip from Enter the Void (1920×818 high-grain/noise content,screenshot). For each, we encoded at various bitrates and plotted effective bitrate versus SSIM . sintel_ssimtos_ssimetv_ssim You’ll notice that in most cases, VP9 can indeed beat x264, but, there’s some big caveats: VP9 encoding (using libvpx) is horrendously slow – like, 50x slower than VP8/x264 encoding. This means that encoding a 3-minute 1080p clip takes several days on a high-end machine. Higher –cpu-used=X parameters make the quality gains melt away. libvpx’ VP9 encodes miss the target bitrates by a long shot (100% off) for the ETV clip, possibly because of our use of –aq-mode=1. libvpx tends to slowly crumble at higher bitrates for hard content – again, look at the ETV clip, where x264 shows some serious mature killer instinct at the high bitrate end of things. Overall, these results are promising, although the lack-of-speed is a serious issue. Decoder performance For decoding performance measurements, we chose (Sintel)500 (VP9), 1200 (VP8) and 700 (x264) kbps (SSIM=19.8); Tears of Steel4.0 (VP9), 7.9 (VP8) and 6.3 (x264) mbps (SSIM=19.2); and Enter the Void 9.7 (VP9), 16.6 (VP8) and 10.7 (x264) mbps (SSIM=16.2). We used FFmpeg to decode each of these files, either using the built-in decoder (to compare between codecs), or using libvpx-vp9 (to compare ffvp9 versus libvpx). Decoding time was measured in seconds using “time ffmpeg -threads 1 [-c:v libvpx-vp9] -i $file -f null -v 0 -nostats – 2>&1 | grep user”, with this FFmpeg and this libvpx revision (downloaded on Feb 20th, 2014). sintel_archs tos_archsetv_archs A few notes on ffvp9 vs. libvpx-vp9 performance: ffvp9 beats libvpx consistently by 25-50%. In practice, this means that typical middle- to high-end hardware will be able to playback 4K content using ffvp9, but not using libvpx. Low-end hardware will struggle to playback even 720p content using libvpx (but do so fine using ffvp9). on Haswell, the difference is significantly smaller than on sandybridge, likely because libvpx has some AVX2 optimizations (e.g. for MC and loop filtering), whereas ffvp9 doesn’t have that yet; this means this difference might grow over time as ffvp9 gets AVX2 optimizations also. on the Atom, the differences are significantly smaller than on other systems; the reason for this is likely that we haven’t done any significant work on Atom-performance yet. Atom has unusually large latencies between GPRs and XMM registers, which means you need to take special care in ordering your instructions to prevent unnecessary halts – we haven’t done anything in that area yet (for ffvp9). Some users may find that ffvp9 is a lot slower than advertised on 32bit; this is correct, most of our SIMD only works on 64bit machines. If you have 32bit software, port it to 64bit. Can’t port it? Ditch it. Nobody owns 32bit x86 hardware anymore these days. So how does VP9 decoding performance compare to that of other codecs? There’s basically two ways to measure this: same-bitrate (e.g. a 500kbps VP8 file vs. a 500kbps VP9 file, where the VP9 file likely looks much better), or same-quality (e.g. a VP8 file with SSIM=19.2 vs. a VP9 file with SSIM=19.2, where the VP9 file likely has a much lower bitrate). We did same-quality measurements, and found: ffvp9 tends to beat ffh264 by a tiny bit (10%), except on Atom (which is likely because ffh264 has received more Atom-specific attention than ffvp9). ffvp9 tends to be quite a bit slower than ffvp8 (15%), although the massive bitrate differences in Enter the Void actually makes it win for that clip (by about 15%, except on Atom). Given that Google promised VP9 would be no more than 40% more complex than VP8, it seems they kept that promise. we did some same-bitrate comparisons, and found that x264 and ffvp9 are essentially identical in that scenario (with x264 having slightly lower SSIM scores); vp8 tends to be about 50% faster, but looks significantly worse. Multithreading One of the killer-features in FFmpeg is frame-level multithreading, which allows multiple cores to decode different video frames in parallel. Libvpx also supports multithreading. So which is better?
VP9 视频编码标准 （谷歌官方）
06-21
官方文档，与大家共享，有经验者请留下联系方式，以后一起探讨
VP9 视频编码标准
03-05
Google的VP9 视频编码。VP9是一个由Google开发的开放格式、无使用授权费的视频压缩标准。VP9在开发初期曾被命名为Next Gen Open Video （NGOV，下一代开放视频）与VP-Next。VP9将是VP8的后继者
说明资料(VP9与H265区别)
11-11
VP9无法动摇H265的地位
Python-实践介绍视频技术图像视频编解码器av1h264h265和ffmpeg编码
08-10
本实践介绍将聚焦于视频技术，包括图像处理、视频编解码器（如AV1、H.264、H.265）以及FFmpeg工具的使用。 首先，图像和视频是多媒体处理的基础。图像处理涉及到颜色空间转换、滤波、特征检测等技术，而视频处理则...
Video-codec-source-code.zip_视频 编解码_视频编解码
09-22
对于视频，MPEG系列（如MPEG-1、MPEG-2）、H.26x系列（如H.264/AVC、H.265/HEVC）和VPx系列（如VP8、VP9）是广泛应用的有损编码标准。 在"视频编解码源码"中，我们可以期待找到实现这些编解码算法的代码示例。例如...
Intel Video Pro Analyzer Evaluation2015R3
08-14
Intel Video Pro Analyzer提供了对多种视频编解码标准的支持，包括但不限于HEVC（高效视频编码）、H.264（高级视频编码）以及VP9和VP8。这些编码格式是当前网络视频传输中的主流标准，各自具有独特的编码效率和性能...
H.264/AVC、H.265/HEVC、VP8、VP9、AV1的对比
05-15
H.264/AVC、H.265/HEVC、VP8、VP9、AV1都是视频编解码标准。下面是它们之间的一些对比： 1. 压缩率方面： H.265/HEVC相较于H.264/AVC，在保证同等视频质量下，可以将码率降低约50%。VP9则相比于VP8，可以将码率降低约30%。 AV1相较于VP9，压缩率提高了约30%。 2. 实时性方面： H.264/AVC和H.265/HEVC在实时性方面较差，不适用于实时性要求较高的场景，例如视频会议等。而VP8、VP9和AV1都支持实时编解码。 3. 开源程度方面： H.264/AVC和H.265/HEVC都是专利算法，存在专利费用问题，使用受到限制。VP8和VP9都是Google开源的，AV1则是由多个公司组成的联盟共同开发的开源算法。 4. 兼容性方面： H.264/AVC是当前使用最广泛的编码标准，几乎所有的设备和软件都支持。H.265/HEVC、VP8、VP9和AV1的兼容性相对较差，需要特别注意设备和软件的支持情况。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值