Web 视频编解码器指南
本指南介绍了您在 Web 上最可能遇到或考虑使用的视频编解码器,概述了它们的功能以及任何兼容性和实用性问题,并提供了帮助您为项目的视频选择正确编解码器的建议。
由于未压缩视频数据的大小非常庞大,因此需要对其进行大幅压缩才能存储,更不用说通过网络传输了。想象一下存储未压缩视频所需的数据量。
- 一帧全彩色(每个像素 4 字节)的高清 (1920x1080) 视频为 8,294,400 字节。
- 以典型的每秒 30 帧的速度,每秒高清视频将占用 248,832,000 字节(约 249 MB)。
- 一分钟的高清视频需要 14.93 GB 的存储空间。
- 一个相当典型的 30 分钟视频会议将需要大约 447.9 GB 的存储空间,而一部 2 小时的电影将需要将近 1.79 TB(即 1790 GB)。
不仅所需的存储空间巨大,而且传输此类未压缩视频所需的网络带宽也巨大,为 249 MB/秒——不包括音频和开销。这就是视频编解码器发挥作用的地方。就像音频编解码器对声音数据所做的那样,视频编解码器会压缩视频数据并将其编码为一种格式,稍后可以对其进行解码和回放或编辑。
大多数视频编解码器都是有损的,因为解码后的视频与源视频并不完全匹配。某些细节可能会丢失;丢失的程度取决于编解码器及其配置方式,但总的来说,您获得的压缩越多,细节和保真度的损失就越大。确实存在一些无损编解码器,但它们通常用于存档和存储以供本地回放,而不是用于网络。
常用编解码器
以下视频编解码器是 Web 上最常用的编解码器。对于每个编解码器,还列出了可以支持它们的容器(文件类型)。每个编解码器都提供指向下面一个部分的链接,该部分提供了有关编解码器的其他详细信息,包括您可能需要注意的特定功能和兼容性问题。
编解码器名称(简称) | 完整编解码器名称 | 容器支持 |
---|---|---|
AV1 | AOMedia 视频 1 | MP4、WebM |
AVC (H.264) | 高级视频编码 | 3GP、MP4 |
H.263 | H.263 视频 | 3GP |
HEVC (H.265) | 高效视频编码 | MP4 |
MP4V-ES | MPEG-4 视频基本流 | 3GP、MP4 |
MPEG-1 | MPEG-1 第 2 部分视觉 | MPEG、QuickTime |
MPEG-2 | MPEG-2 第 2 部分视觉 | MP4、MPEG、QuickTime |
Theora 已弃用 | Theora | Ogg |
VP8 | 视频处理器 8 | 3GP、Ogg、WebM |
VP9 | 视频处理器 9 | MP4、Ogg、WebM |
影响编码视频的因素
与任何编码器一样,有两个基本因素会影响编码视频的大小和质量:有关源视频格式和内容的详细信息,以及编码视频时使用的编解码器的特性和配置。
最简单的指导原则是:任何使编码视频看起来更像原始未压缩视频的内容通常也会使生成的数据更大。因此,它始终是大小与质量之间的权衡。在某些情况下,为了降低数据大小而牺牲更大的质量是值得的;在其他情况下,质量损失是不可接受的,因此有必要接受导致相应更大文件的编解码器配置。
源视频格式对编码输出的影响
源视频格式影响输出的程度取决于编解码器及其工作方式。如果编解码器将媒体转换为内部像素格式,或以其他方式使用除简单像素之外的方法表示图像,则原始图像的格式没有任何区别。但是,帧速率和分辨率等内容始终会对媒体的输出大小产生影响。
此外,所有编解码器都有其优点和缺点。有些编解码器难以处理特定类型的形状和图案,或者不擅长复制锐利边缘,或者倾向于在黑暗区域丢失细节,或者还有许多其他可能性。这一切都取决于底层的算法和数学。
功能 | 对质量的影响 | 对大小的影响 |
---|---|---|
色彩深度(位深度) | 色彩位深度越高,视频中实现的色彩保真度越高。此外,在图像的饱和部分(即颜色纯净且强烈的地方,例如鲜艳的纯红色:rgb(255 0 0 / 100%) ),低于每个分量 10 位(10 位色)的色彩深度会导致出现色带,其中渐变无法在没有可见颜色阶跃的情况下表示。 |
根据编解码器的不同,较高的色彩深度可能会导致压缩文件大小更大。决定因素是压缩数据使用的内部存储格式。 |
帧速率 | 主要影响图像中运动的感知平滑度。在某种程度上,帧速率越高,运动看起来越流畅和逼真。最终会达到收益递减点。有关详细信息,请参阅下面的帧速率。 | 假设在编码过程中不降低帧速率,则较高的帧速率会导致压缩视频大小更大。 |
运动 | 视频压缩通常通过比较帧、查找它们的不同之处以及构建包含足够信息以更新前一帧以近似于下一帧外观的记录来工作。连续帧之间的差异越大,这些差异就越大,压缩在避免在压缩视频中引入伪影方面就越有效。 | 运动带来的复杂性会导致中间帧更大,因为帧之间存在更多差异)。由于这个和其他原因,视频中的运动越多,输出文件通常就越大。 |
噪声 | 图像噪声(例如胶片颗粒效果、灰尘或图像的其他颗粒感)会引入可变性。可变性通常会使压缩变得更加困难,从而导致由于需要放弃细节以实现相同级别的压缩而导致质量损失更多。 | 图像中的可变性(例如噪声)越多,压缩过程就越复杂,算法成功压缩图像到相同程度的可能性就越小。除非您以忽略噪声引起的一些或所有变化的方式配置编码器,否则压缩视频将更大。 |
分辨率(宽度和高度) | 在相同屏幕尺寸下呈现的更高分辨率视频通常能够更准确地描绘原始场景,除非压缩过程中引入了影响。 | 视频的分辨率越高,它就越大。这在视频的最终大小中起着关键作用。 |
这些因素影响最终编码视频的程度将根据具体情况而有所不同,包括您使用的编码器及其配置方式。除了通用编解码器选项外,还可以配置编码器以降低帧速率、清理噪声和/或在编码过程中降低视频的整体分辨率。
编解码器配置对编码输出的影响
用于视频编码的算法通常会使用一种或多种通用技术来执行编码。一般来说,任何旨在减小视频输出大小的配置选项都可能会对视频的整体质量产生负面影响,或者会在视频中引入某些类型的伪像。也可以选择无损编码形式,这将导致编码文件的大小大大增加,但在解码时可以完美地再现原始视频。
此外,每个编码工具在处理源视频的方式上可能会有所不同,从而导致输出质量和/或大小的差异。
功能 | 对质量的影响 | 对大小的影响 |
---|---|---|
无损压缩 | 无质量损失 | 无损压缩无法像有损压缩那样大幅减少视频总大小;生成的的文件可能仍然太大,不适合一般用途。 |
有损压缩 | 在某种程度上,会发生伪像和其他形式的质量下降,具体取决于特定的编解码器以及应用了多少压缩 | 编码后的视频与源视频的偏差越大,实现更高压缩率就越容易 |
质量设置 | 质量配置越高,编码后的视频看起来就越像原始媒体 | 通常,更高的质量设置会导致更大的编码视频文件;这种程度因编解码器而异 |
比特率 | 更高的比特率通常会提高质量 | 更高的比特率固然会导致更大的输出文件 |
编码视频时可用的选项以及要分配给这些选项的值,不仅因编解码器而异,还取决于您使用的编码软件。编码软件附带的文档将帮助您了解这些选项对编码视频的具体影响。
压缩伪影
伪像是有损编码过程的副作用,其中丢失或重新排列的数据会导致明显的负面影响。一旦出现伪像,它可能会持续一段时间,因为视频的显示方式。视频的每一帧都是通过对当前可见帧应用一组更改来呈现的。这意味着任何错误或伪像都会随着时间的推移而累积,从而导致图像中出现持续一段时间的小故障或其他奇怪或意外的偏差。
为了解决这个问题,并提高对视频数据的查找时间,会定期将关键帧(也称为帧内帧或I帧)放置到视频文件中。关键帧是完整的帧,用于修复当前可见的任何损坏或伪像残留。
混叠
混叠是用于描述任何从编码数据重建后看起来与压缩前不同的内容的通用术语。混叠有很多形式;您可能会看到的常见形式包括
颜色边缘
颜色边缘是一种视觉伪像,表现为在场景中彩色物体边缘引入的杂色。这些颜色与帧内容之间没有任何有意的颜色关系。
清晰度下降
在视频编码过程中删除数据需要丢失一些细节。如果应用了足够的压缩,图像的一部分或全部可能会失去清晰度,导致出现略微模糊或朦胧的外观。
清晰度下降会使图像中的文本难以阅读,因为文本——尤其是小文本——是注重细节的内容,其中微小的改动会显着影响可读性。
振铃
有损压缩算法可能会引入振铃,这是一种效果,其中物体外部的区域被压缩算法生成的彩色像素污染。当使用跨越物体与其背景之间锐利边界的块的算法时,就会发生这种情况。这在较高的压缩级别尤其常见。
请注意上面星星边缘周围的蓝色和粉红色边缘(以及阶梯和其他明显的压缩伪像)。这些边缘是振铃效应。振铃在某些方面类似于蚊式噪声,但振铃效应或多或少是稳定且不变的,而蚊式噪声则闪烁和移动。
振铃是另一种类型的伪像,它会使阅读图像中包含的文本变得特别困难。
色带化
色带化发生在压缩导致渐变颜色细节丢失时。图像不是通过某个区域的各种颜色平滑过渡,而是变得块状,颜色块近似于图像的原始外观。
请注意上面照片中秃鹰羽毛(以及背景中的雪鸮)的颜色块状。由于这些色带化伪像,羽毛的细节大部分都丢失了。
轮廓
轮廓或色带是色带化的一种特定形式,其中颜色块在图像中形成带或条纹。当视频以过粗的量化配置进行编码时,就会发生这种情况。结果,视频内容呈现出“分层”的外观,其中颜色到颜色的过渡是突然的,而不是平滑的渐变和过渡,导致出现颜色条纹。
在上图示例中,请注意天空是如何具有不同深浅的蓝色条带,而不是像天空颜色朝地平线变化那样保持一致的渐变。这就是轮廓效应。
蚊式噪声
蚊式噪声是一种时间伪像,表现为噪声或边缘忙碌,表现为闪烁的朦胧或闪烁,大致沿着具有硬边缘的物体或前景物体与背景之间急剧过渡的外部边缘出现。这种效果在外观上可能类似于振铃。
上图显示了多个地方的蚊式噪声,包括桥周围的天空。在右上角,一个插图显示了图像的一部分特写,该部分表现出蚊式噪声。
蚊式噪声伪像最常见于 MPEG 视频中,但只要使用离散余弦变换 (DCT) 算法,就会发生;例如,包括 JPEG 静止图像。
运动补偿块边界伪像
视频压缩通常通过比较两帧并记录它们之间的差异来工作,一帧接一帧,直到视频结束。当相机固定在适当位置或帧中的物体相对静止时,此技术效果很好,但如果帧中存在大量运动,则帧之间的差异数量可能非常大,以至于压缩没有任何好处。
运动补偿是一种技术,它寻找运动(相机或视野中的物体),并确定运动物体在每个方向上移动了多少像素。然后存储该位移,以及对无法仅通过该位移描述的已移动像素的描述。本质上,编码器找到运动物体,然后构建一个内部帧,该帧看起来像原始帧,但所有物体都平移到它们的新位置。理论上,这近似于新帧的外观。然后,为了完成工作,找到剩余的差异,然后将对象偏移集和像素差异集存储在表示新帧的数据中。描述偏移和像素差异的对象称为残差帧。
原始帧 | 帧间差异 | 运动补偿后的差异 |
---|---|---|
查看者看到的第一个完整帧。 | 在这里,仅看到第一帧和下一帧之间的差异。其他所有内容都是黑色。仔细观察,我们可以看到这些差异的大部分来自水平相机移动,这使得它成为运动补偿的良好候选对象。 | 为了最大程度地减少不同的像素数量,我们首先通过将第一帧向右移动两个像素来考虑相机的平移,然后取差值。这补偿了相机的平移,允许两帧之间有更多重叠。 |
来自维基百科的图像 |
运动补偿主要有两种类型:全局运动补偿和块运动补偿。全局运动补偿通常调整相机运动,例如跟踪、推拉、平移、倾斜、滚动以及上下移动。块运动补偿处理局部变化,查找可以使用运动补偿编码的图像的较小部分。这些块通常具有固定大小,位于网格中,但存在允许可变块大小甚至允许块重叠的运动补偿形式。
但是,由于运动补偿可能会出现伪像。这些伪像出现在块边界处,以产生虚假振铃和其他边缘效应的锐利边缘的形式出现。这些是由于残差帧编码中涉及的数学运算造成的,并且在被下一个关键帧修复之前很容易被注意到。
减少帧大小
在某些情况下,减少视频的尺寸以改善视频文件的最终大小可能很有用。虽然播放的立即尺寸或平滑度损失可能是负面因素,但仔细的决策可以带来良好的最终结果。如果在编码之前将 1080p 视频缩小到 720p,则生成的视频可以小得多,同时具有更高的视觉质量;即使在播放过程中按比例放大后,结果也可能比以全尺寸编码原始视频并接受满足您的尺寸要求所需的质量损失要好。
降低帧率
类似地,您可以完全从视频中删除帧,并降低帧率以进行补偿。这有两个好处:它使整个视频更小,并且更小的尺寸允许运动补偿为您完成更多工作。例如,由于帧间运动,您可能需要计算两个相隔两个像素的帧的运动差异,但跳过每隔一帧可能会导致计算出四像素运动的差异。这样,摄像机的整体运动就可以用更少的残差帧来表示。
视频在内容不再被人眼感知为运动之前的绝对最低帧率约为每秒 12 帧。低于此帧率,视频就会变成一系列静止图像。电影胶片通常为每秒 24 帧,而标准清晰度电视约为每秒 30 帧(略少,但足够接近),高清电视则在每秒 24 到 60 帧之间。任何高于 24 FPS 的帧率通常都会被视为令人满意地流畅;30 或 60 FPS 是理想的目标,具体取决于您的需求。
最终,关于您可以做出哪些牺牲的决定完全取决于您和/或您的设计团队。
编解码器详细信息
AV1
AOMedia 视频 1 (AV1) 编解码器是一种开放格式,由开放媒体联盟专门为互联网视频设计。它实现了比VP9和H.265/HEVC更高的数据压缩率,并且比AVC高出多达 50% 的压缩率。AV1 完全免版税,设计用于<video>
元素和WebRTC。
AV1 目前提供三种配置文件:主要、高级和专业,它们对颜色深度和色度子采样的支持不断增强。此外,还指定了一系列级别,每个级别都定义了视频一系列属性的限制。这些属性包括帧尺寸、图像区域(以像素为单位)、显示和解码速率、平均和最大比特率以及编码/解码过程中使用的图块和图块列数量的限制。
例如,AV1 2.0 级别提供的最大帧宽度为 2048 像素,最大高度为 1152 像素,但其最大帧尺寸(以像素为单位)为 147,456,因此您实际上无法在 2.0 级别获得 2048x1152 的视频。不过,值得注意的是,至少对于 Firefox 和 Chrome 而言,在执行软件解码时,这些级别实际上会被忽略,解码器会尽其所能根据提供的设置播放视频。但是,为了将来保持兼容性,您应该保持在所选级别的限制范围内。
目前 AV1 的主要缺点是它非常新,并且支持仍在逐步集成到大多数浏览器中。此外,编码器和解码器仍在优化性能,硬件编码器和解码器也大多仍处于开发阶段,而不是生产阶段。因此,将视频编码为 AV1 格式需要很长时间,因为所有工作都在软件中完成。
目前,由于这些因素,AV1 尚未准备好成为您的首选视频编解码器,但您应该注意它将来是否可以投入使用。
支持的比特率 |
根据视频的级别而有所不同;理论最大值在 6.3 级别达到 800 Mbps 请参阅 AV1 规范的级别表,其中描述了每个级别的最大分辨率和速率。 |
||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
支持的帧率 | 根据级别而有所不同;例如,2.0 级别最大为 30 FPS,而 6.3 级别可以达到 120 FPS | ||||||||||||||
压缩 | 有损基于 DCT 的算法 | ||||||||||||||
支持的帧尺寸 | 8 x 8 像素到 65,535 x 65535 像素,每个维度允许取这两个值之间的任何值 | ||||||||||||||
支持的颜色模式 |
|
||||||||||||||
HDR 支持 | 是 | ||||||||||||||
可变帧率 (VFR) 支持 | 是 | ||||||||||||||
浏览器兼容性 |
|
||||||||||||||
容器支持 | ISOBMFF、MPEG-TS、MP4、WebM | ||||||||||||||
RTP / WebRTC 兼容 | 是 | ||||||||||||||
支持/维护组织 | 开放媒体联盟 | ||||||||||||||
规范 | https://aomediacodec.github.io/av1-spec/av1-spec.pdf | ||||||||||||||
许可 | 免版税,开放标准 |
AVC (H.264)
MPEG-4 规范套件的高级视频编码 (AVC) 标准由相同的 ITU H.264 规范和 MPEG-4 第 10 部分规范指定。它是一种基于运动补偿的编解码器,目前广泛用于各种媒体,包括广播电视、RTP 视频会议以及蓝光光盘的视频编解码器。
AVC 非常灵活,具有许多功能各异的配置文件;例如,约束基线配置文件旨在用于视频会议和移动场景,使用的带宽低于主配置文件(在某些地区用于标准清晰度数字电视)或高级配置文件(用于蓝光光盘视频)。大多数配置文件使用 8 位颜色分量和 4:2:0 色度子采样;高级 10 配置文件增加了对 10 位颜色的支持,而高级形式的高级 10 则增加了 4:2:2 和 4:4:4 色度子采样。
AVC 还具有特殊功能,例如支持同一场景的多个视图(多视图视频编码),这使得能够制作立体视频等内容。
然而,AVC 是一种专有格式,并且多方拥有其技术的众多专利。AVC 媒体的商业使用需要许可,尽管 Via LA 专利池不要求对以 AVC 格式流式传输的互联网视频收取许可费,只要该视频对最终用户免费即可。
WebRTC 的非网络浏览器实现(任何不包含 JavaScript API 的实现)都需要支持 AVC 作为 WebRTC 调用中的编解码器。虽然网络浏览器不需要这样做,但有些浏览器确实支持。
在 Web 浏览器的 HTML 内容中,AVC 具有广泛的兼容性,并且许多平台支持 AVC 媒体的硬件编码和解码。但是,在选择在您的项目中使用 AVC 之前,请注意其许可要求!
支持的比特率 | 根据级别而有所不同 | ||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
支持的帧率 | 根据级别而有所不同;最高可达 300 FPS | ||||||||||||||||||||||||||||||
压缩 | 有损基于 DCT 的算法,尽管可以在图像中创建无损宏块 | ||||||||||||||||||||||||||||||
支持的帧尺寸 | 最大 8,192 x 4,320 像素 | ||||||||||||||||||||||||||||||
支持的颜色模式 |
一些更常见或更有趣的配置文件
|
||||||||||||||||||||||||||||||
HDR 支持 | 是;混合对数伽马或高级 HDR/SL-HDR;两者都是 ATSC 的一部分 | ||||||||||||||||||||||||||||||
可变帧率 (VFR) 支持 | 是 | ||||||||||||||||||||||||||||||
浏览器兼容性 | 所有版本的 Chrome、Edge、Firefox、Opera 和 Safari Firefox 对 AVC 的支持取决于操作系统的内置或预安装的 AVC 编解码器及其容器,以避免专利问题。 |
||||||||||||||||||||||||||||||
容器支持 | 3GP、MP4 | ||||||||||||||||||||||||||||||
RTP / WebRTC 兼容 | 是 | ||||||||||||||||||||||||||||||
支持/维护组织 | MPEG / ITU | ||||||||||||||||||||||||||||||
规范 | https://mpeg.chiariglione.org/standards/mpeg-4/advanced-video-coding.html https://www.itu.int/rec/T-REC-H.264 |
||||||||||||||||||||||||||||||
许可 | 专有,拥有众多专利。商业使用需要许可。请注意,可能适用多个专利池。 |
H.263
ITU 的H.263编解码器主要设计用于低带宽情况。特别是,它专注于 PSTN(公用交换电话网络)、RTSP 和 SIP(基于 IP 的视频会议)系统上的视频会议。尽管针对低带宽网络进行了优化,但它在 CPU 上的占用率相当高,在低端计算机上可能无法充分发挥性能。数据格式类似于 MPEG-4 第 2 部分。
H.263 从未在 Web 上广泛使用。H.263 的变体已被用作其他专有格式的基础,例如 Flash 视频或 Sorenson 编解码器。但是,没有主要浏览器默认包含 H.263 支持。某些媒体插件启用了对 H.263 媒体的支持。
与大多数编解码器不同,H.263 以每帧(图片)的最大比特率 (BPPmaxKb) 来定义编码视频的基本原理。在编码过程中,会为 BPPmaxKb 选择一个值,然后视频每帧都不能超过此值。最终比特率将取决于此值、帧率、压缩以及所选的分辨率和块格式。
H.263 已被 H.264 取代,因此被认为是一种遗留媒体格式,如果可以,您通常应避免使用。在新项目中使用 H.263 的唯一真正原因是,如果您需要在非常旧的设备上提供支持,而 H.263 是您的最佳选择。
H.263 是一种专有格式,专利由许多组织和公司持有,包括 Telenor、富士通、摩托罗拉、三星、日立、宝利通、高通等等。要使用 H.263,您有法律义务获得相应的许可。
支持的比特率 | 不受限制,但通常低于 64 kbps | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
支持的帧率 | 任何 | ||||||||||||
压缩 | 有损基于 DCT 的算法 | ||||||||||||
支持的帧尺寸 |
最大 1408 x 1152 像素。 H.263 版本 1 指定了一组受支持的图片大小。更高版本可能支持其他分辨率。 |
||||||||||||
支持的颜色模式 | YCbCr;每个图片格式(子 QCIF、QCIF、CIF、4CIF 或 16CIF)都定义了以像素为单位的帧大小,以及每帧使用多少行亮度和色度样本。 | ||||||||||||
HDR 支持 | 否 | ||||||||||||
可变帧率 (VFR) 支持 | 否 | ||||||||||||
浏览器兼容性 |
|
||||||||||||
容器支持 | 3GP、MP4、QuickTime | ||||||||||||
RTP / WebRTC 兼容 | 否 | ||||||||||||
支持/维护组织 | ITU | ||||||||||||
规范 | https://www.itu.int/rec/T-REC-H.263/ | ||||||||||||
许可 | 专有;需要相应的许可证或许可证。请注意,可能适用多个专利池。 |
HEVC (H.265)
高效视频编码 (HEVC) 编解码器由 ITU 的H.265以及 MPEG-H 第 2 部分(MPEG-4 的仍在开发中的后续版本)定义。HEVC 旨在支持对包括超高清分辨率(包括 8K 视频)在内的视频进行高效编码和解码,其结构专门设计为让软件能够利用现代处理器。理论上,HEVC 可以实现比AVC压缩一半的文件大小,但图像质量相当。
例如,每个编码树单元 (CTU)——类似于以前编解码器中使用的宏块——包含每个样本的亮度值树以及同一编码树单元中使用的每个色度样本的色度值树,以及任何所需的语法元素。这种结构支持多核轻松处理。
HEVC 的一个有趣特性是,主配置文件仅支持每个组件 8 位颜色,并使用 4:2:0 色度下采样。另一个有趣的是,4:4:4 视频的处理方式很特殊。它不是将亮度样本(表示图像的灰度像素)和 Cb 和 Cr 样本(指示如何改变灰度以创建彩色像素)分开,而是将这三个通道视为三个单色图像,每个颜色一个,然后在渲染过程中将它们组合起来生成全彩色图像。
HEVC 是一种专有格式,受多项专利保护。许可证由Via LA 管理;费用收取于开发人员而不是内容制作方和发行方。在决定是否在您的应用或网站中使用 HEVC 之前,请务必查看最新的许可条款和要求!
支持的比特率 | 高达 800,000 kbps | ||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
支持的帧率 | 根据级别而有所不同;最高可达 300 FPS | ||||||||||||||||||||||||||||||
压缩 | 有损基于 DCT 的算法 | ||||||||||||||||||||||||||||||
支持的帧尺寸 | 128 x 96 至 8,192 x 4,320 像素;因配置文件和级别而异 | ||||||||||||||||||||||||||||||
支持的颜色模式 |
以下信息适用于主要配置文件。这里未包含其他一些可用的配置文件。
|
||||||||||||||||||||||||||||||
HDR 支持 | 是 | ||||||||||||||||||||||||||||||
可变帧率 (VFR) 支持 | 是 | ||||||||||||||||||||||||||||||
浏览器兼容性 |
Chrome 在 Windows 8+、Linux 和 ChromeOS 上支持具有硬件支持的设备的 HEVC,在 macOS Big Sur 11+ 和 Android 5.0+ 上支持所有设备。 Edge(Chromium)在安装了Microsoft Store 中的 HEVC 视频扩展的 Windows 10 1709+ 上支持具有硬件支持的设备的 HEVC,并且在其他平台上具有与 Chrome 相同的支持状态。Edge(旧版)仅支持具有硬件解码器的设备的 HEVC。 Mozilla 不会支持 HEVC,因为它受到专利限制。 Opera 和其他基于 Chromium 的浏览器具有与 Chrome 相同的支持状态。 Safari 在 macOS High Sierra 或更高版本上支持所有设备的 HEVC。 |
||||||||||||||||||||||||||||||
容器支持 | ISOBMFF、MPEG-TS、MP4 QuickTime | ||||||||||||||||||||||||||||||
RTP / WebRTC 兼容 | 否 | ||||||||||||||||||||||||||||||
支持/维护组织 | ITU/MPEG | ||||||||||||||||||||||||||||||
规格 | http://www.itu.int/rec/T-REC-H.265 https://www.iso.org/standard/69668.html |
||||||||||||||||||||||||||||||
许可 | 专有;确认您符合许可要求。请注意,可能适用多个专利池。 |
MP4V-ES
MPEG-4 视频基本流 (MP4V-ES) 格式是 MPEG-4 第 2 部分视觉标准的一部分。虽然一般来说,由于 MPEG-4 第 2 部分视频与其他编解码器相比缺乏吸引力,因此没有人使用它,但 MP4V-ES 在移动设备上确实有一些应用。MP4V 本质上是 MPEG-4 容器中的 H.263 编码。
其主要目的是用于通过RTP 会话流式传输 MPEG-4 音频和视频。但是,MP4V-ES 也用于通过使用3GP的移动连接传输 MPEG-4 音频和视频。
您几乎肯定不想使用此格式,因为它不受任何主要浏览器以有意义的方式支持,并且已经过时。此类文件应具有扩展名.mp4v
,但有时会被错误地标记为.mp4
。
支持的比特率 | 5 kbps 至 1 Gbps 及更高 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
支持的帧率 | 没有特定限制;仅受数据速率限制 | ||||||||||||
压缩 | 有损基于 DCT 的算法 | ||||||||||||
支持的帧尺寸 | 最多 4,096 x 4,096 像素 | ||||||||||||
支持的颜色模式 | 支持带色度下采样的 YCrCb(4:2:0、4:2:2 和 4:4:4);每个组件最多 12 位 | ||||||||||||
HDR 支持 | 否 | ||||||||||||
可变帧率 (VFR) 支持 | 是 | ||||||||||||
浏览器兼容性 |
Firefox 仅在3GP 容器中支持 MP4V-ES。 Chrome 不支持 MP4V-ES;但是,ChromeOS 支持。 |
||||||||||||
容器支持 | 3GP、MP4 | ||||||||||||
RTP / WebRTC 兼容 | 否 | ||||||||||||
支持/维护组织 | MPEG | ||||||||||||
规范 | RFC 6416 | ||||||||||||
许可 | 专有;通过Via LA 和/或AT&T 根据需要获取许可证 |
MPEG-1 第 2 部分视频
MPEG-1 第 2 部分视频于 1990 年代初推出。与后来的 MPEG 视频标准不同,MPEG-1 是由 MPEG 独自创建的,没有ITU 的参与。
由于任何 MPEG-2 解码器也可以播放 MPEG-1 视频,因此它与各种软件和硬件设备兼容。与 MPEG-1 视频相关的活动专利已不存在,因此可以免费使用它,无需担心任何许可问题。但是,很少有网络浏览器在没有插件支持的情况下支持 MPEG-1 视频,并且由于网络浏览器中插件的使用已弃用,因此这些插件通常不再可用。这使得 MPEG-1 成为在网站和 Web 应用程序中使用的糟糕选择。
支持的比特率 | 高达 1.5 Mbps | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
支持的帧率 | 23.976 FPS、24 FPS、25 FPS、29.97 FPS、30 FPS、50 FPS、59.94 FPS 和 60 FPS | ||||||||||||
压缩 | 有损基于 DCT 的算法 | ||||||||||||
支持的帧尺寸 | 最多 4,095 x 4,095 像素 | ||||||||||||
支持的颜色模式 | Y'CbCr,使用 4:2:0 色度下采样,每个组件最多 12 位 | ||||||||||||
HDR 支持 | 否 | ||||||||||||
可变帧率 (VFR) 支持 | 否 | ||||||||||||
浏览器兼容性 |
|
||||||||||||
容器支持 | MPEG | ||||||||||||
RTP / WebRTC 兼容 | 否 | ||||||||||||
支持/维护组织 | MPEG | ||||||||||||
规范 | https://www.iso.org/standard/22411.html | ||||||||||||
许可 | 专有;但是,所有专利都已过期,因此 MPEG-1 可以免费使用 |
MPEG-2 第 2 部分视频
MPEG-2 第 2 部分 是 MPEG-2 规范中定义的视频格式,有时也称为其ITU 指定,即 H.262。它与 MPEG-1 视频非常相似——事实上,任何 MPEG-2 播放器都可以自动处理 MPEG-1,而无需任何特殊操作——除了它已扩展为支持更高的比特率和增强的编码技术。
目标是允许 MPEG-2 压缩标准清晰度电视,因此也支持隔行扫描视频。标准清晰度压缩率和所得视频的质量足以满足需求,因此 MPEG-2 是 DVD 视频媒体中使用的主要视频编解码器。
MPEG-2 提供了几个具有不同功能的配置文件。然后,每个配置文件都提供四个级别,每个级别都会提高视频的属性,例如帧速率、分辨率、比特率等。大多数配置文件使用带 4:2:0 色度下采样的 Y'CbCr,但更高级别的配置文件也支持 4:2:2。此外,还有四个级别,每个级别都提供对更大帧尺寸和比特率的支持。例如,北美使用的电视ATSC 规范支持高清晰度 MPEG-2 视频,使用主配置文件的高级别,允许 4:2:0 视频以 1920 x 1080(30 FPS)和 1280 x 720(60 FPS)两种格式,最大比特率为 80 Mbps。
但是,很少有网络浏览器在没有插件支持的情况下支持 MPEG-2,并且由于网络浏览器中插件的使用已弃用,因此这些插件通常不再可用。这使得 MPEG-2 成为在网站和 Web 应用程序中使用的糟糕选择。
支持的比特率 | 高达 100 Mbps;因级别和配置文件而异 | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
支持的帧率 |
|
|||||||||||||||
压缩 | 有损基于 DCT 的算法 | |||||||||||||||
支持的帧尺寸 |
|
|||||||||||||||
支持的颜色模式 | 大多数配置文件中使用带 4:2:0 色度下采样的 Y'CbCr;“高”和“4:2:2”配置文件也支持 4:2:2 色度下采样。 | |||||||||||||||
HDR 支持 | 否 | |||||||||||||||
可变帧率 (VFR) 支持 | 否 | |||||||||||||||
浏览器兼容性 |
|
|||||||||||||||
容器支持 | MPEG、MPEG-TS(MPEG 传输流)、MP4、QuickTime | |||||||||||||||
RTP / WebRTC 兼容 | 否 | |||||||||||||||
支持/维护组织 | MPEG / ITU | |||||||||||||||
规范 | https://www.itu.int/rec/T-REC-H.262 https://www.iso.org/standard/61152.html |
|||||||||||||||
许可 | 专有;截至 2019 年 4 月 1 日,除马来西亚和菲律宾外,所有专利在全球范围内均已过期,因此 MPEG-2 可以在这两个国家之外免费使用。专利由Via LA 许可。 |
Theora
警告:此代码不再推荐。它的使用率极低,并且浏览器正在删除对它的支持。
Theora 由Xiph.org 开发,是一种开放且免费的视频编解码器,可以使用,无需支付版税或许可费。Theora 在质量和压缩率方面与 MPEG-4 第 2 部分视觉和 AVC 相当,使其成为非常好的选择,即使不是最佳选择,也可用于视频编码。但它免受任何许可问题的影响,并且其相对较低的 CPU 资源需求使其成为许多软件和 Web 项目的热门选择。低 CPU 影响特别有用,因为 Theora 没有可用的硬件解码器。
Theora 最初基于 On2 Technologies 的 VC3 编解码器。编解码器及其规范在 LGPL 许可下发布,并委托给 Xiph.org,后者随后将其发展为 Theora 标准。
Theora 的一个缺点是它每个颜色组件仅支持 8 位,没有选择使用 10 位或更多位来避免颜色带状现象。也就是说,每个组件 8 位仍然是当今最常用的颜色格式,因此在大多数情况下,这只是一个小的不便。此外,Theora 只能用于 Ogg 容器。然而,最大的缺点是 Safari 不支持它,这使得 Theora 不仅在 macOS 上不可用,而且在数百万台 iPhone 和 iPad 上都不可用。
Theora 食谱 提供了有关 Theora 以及它在其内使用的 Ogg 容器格式的更多详细信息。
支持的比特率 | 高达 2 Gbps | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
支持的帧率 | 任意;支持任何非零值。帧速率指定为 32 位分子和 32 位分母,以允许非整数帧速率。 | ||||||||||||
压缩 | 有损基于 DCT 的算法 | ||||||||||||
支持的帧尺寸 | 高达 1,048,560 x 1,048,560 像素的任何宽高组合 | ||||||||||||
支持的颜色模式 | Y'CbCr,使用 4:2:0、4:2:2 和 4:4:4 色度下采样,每个组件 8 位 | ||||||||||||
HDR 支持 | 否 | ||||||||||||
可变帧率 (VFR) 支持 |
是 虽然 Theora 不支持单个流中的可变帧速率 (VFR),但可以在单个文件中将多个流链接在一起,并且每个流都可以有自己的帧速率,从而实现本质上是 VFR 的效果。但是,如果需要频繁更改帧速率,则这实际上不可行。 |
||||||||||||
浏览器兼容性 |
Edge 使用可选的Web 媒体扩展 加载项支持 Theora。 |
||||||||||||
容器支持 | Ogg | ||||||||||||
RTP / WebRTC 兼容 | 否 | ||||||||||||
支持/维护组织 | Xiph.org | ||||||||||||
规范 | https://www.theora.org/doc/ | ||||||||||||
许可 | 开放且免费,无版税或任何其他许可要求 |
VP8
视频处理器 8 (VP8) 编解码器最初由 On2 Technologies 创建。在收购 On2 后,Google 将 VP8 发布为开放且免版税的视频格式,承诺不执行相关专利。在质量和压缩率方面,VP8 与AVC 相当。
如果浏览器支持,VP8 允许视频包含 Alpha 通道,使视频播放时背景能够透过视频,透过程度由每个像素的 Alpha 分量指定。
VP8 在 HTML 内容中拥有良好的浏览器支持,尤其是在 WebM 文件中。这使得 VP8 成为内容的良好选择,尽管如果可用,VP9 是更好的选择。Web 浏览器**需要**支持 VP8 用于 WebRTC,但并非所有支持 WebRTC 的浏览器也支持 HTML 音频和视频元素中的 VP8。
支持的比特率 | 任意;除非强制执行基于级别的限制,否则没有最大值 |
---|---|
支持的帧率 | 任意 |
压缩 | 有损基于 DCT 的算法 |
支持的帧尺寸 | 最多 16,384 x 16,384 像素 |
支持的颜色模式 | 每个分量 8 位的 4:2:0 色度下采样的 Y'CbCr |
HDR 支持 | 否 |
可变帧率 (VFR) 支持 | 是 |
浏览器兼容性 |
所有版本的 Chrome、Edge、Firefox、Opera 和 Safari iOS:Safari 12.1 及更高版本仅支持 WebRTC 连接中的 VP8。 Firefox 仅在 MSE 中没有 H.264 硬件解码器可用时才支持 VP8。使用 |
容器支持 | 3GP、Ogg、WebM |
RTP / WebRTC 兼容 | 是;VP8 是 WebRTC 的规范要求编解码器之一 |
支持/维护组织 | 谷歌 |
规范 | RFC 6386 |
许可 | 开放且免费,无版税或任何其他许可要求 |
VP9
视频处理器 9(VP9)是谷歌开发的旧版 VP8 标准的继任者。与 VP8 一样,VP9 完全开放且免版税。其编码和解码性能与 AVC 相当或略快,但质量更高。VP9 的编码视频质量与 HEVC 在类似比特率下的质量相当。
VP9 的主要配置文件仅支持 4:2:0 色度下采样级别的 8 位色深,但其配置文件包括对更深色深和全范围色度下采样模式的支持。它支持多种 HDR 实现,并在选择帧率、纵横比和帧大小方面提供了很大的自由度。
VP9 受到浏览器的广泛支持,并且编解码器的硬件实现相当普遍。VP9 是 WebM 规定的两种视频编解码器之一(另一种是 VP8)。但是请注意,Safari 对 WebM 和 VP9 的支持是在 14.1 版本中才引入的,因此,如果您选择使用 VP9,请考虑为 iPhone、iPad 和 Mac 用户提供 AVC 或 HEVC 等备用格式。
如果您能够使用 WebM 容器(并且可以根据需要提供备用视频),那么 VP9 是一个不错的选择。如果您希望使用开放编解码器而不是专有编解码器,尤其如此。
支持的比特率 | 任意;除非强制执行基于级别的限制,否则没有最大值 | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
支持的帧率 | 任意 | |||||||||||||||
压缩 | 有损基于 DCT 的算法 | |||||||||||||||
支持的帧尺寸 | 最多 65,536 x 65,536 像素 | |||||||||||||||
支持的颜色模式 |
支持的色彩空间:Rec. 601、Rec. 709、Rec. 2020、SMPTE C、SMPTE-240M(已过时;由 Rec. 709 替代)和 sRGB。 |
|||||||||||||||
HDR 支持 | 是;HDR10+、HLG 和 PQ | |||||||||||||||
可变帧率 (VFR) 支持 | 是 | |||||||||||||||
浏览器兼容性 |
所有版本的 Chrome、Edge、Firefox、Opera 和 Safari Firefox 仅在 MSE 中没有 H.264 硬件解码器可用时才支持 VP8。使用 |
|||||||||||||||
容器支持 | MP4、Ogg、WebM | |||||||||||||||
RTP / WebRTC 兼容 | 是 | |||||||||||||||
支持/维护组织 | 谷歌 | |||||||||||||||
规范 | https://www.webmproject.org/vp9/ | |||||||||||||||
许可 | 开放且免费,无版税或任何其他许可要求 |
选择视频编解码器
决定使用哪个或哪些编解码器首先要进行一系列问题准备。
- 您希望使用开放格式,还是也要考虑专有格式?
- 您是否有资源为每个视频制作多种格式?提供备用选项的能力极大地简化了决策过程。
- 您是否愿意牺牲与某些浏览器的兼容性?
- 您需要支持的最旧版 Web 浏览器的版本有多旧?例如,您需要在过去五年的每个浏览器版本中都运行,还是只需要过去一年的?
在下面的部分中,我们为特定的用例提供了推荐的编解码器选择。对于每个用例,您最多会找到两个建议。如果被认为最适合该用例的编解码器是专有的或可能需要支付版税,则会提供两个选项:首先是开放且免版税的选项,然后是专有选项。
如果您只能提供每个视频的一个版本,则可以选择最适合您需求的格式。第一个建议是质量、性能和兼容性的良好组合。第二个选项将是最广泛兼容的选择,但会牺牲一定程度的质量、性能和/或大小。
日常视频的建议
首先,让我们看看在典型网站(例如博客、信息网站、小型企业网站,这些网站使用视频来演示产品,但视频本身不是产品)等上展示的视频的最佳选择。
- 使用 WebM 容器,使用 VP9 编解码器进行视频编码,使用 Opus 编解码器进行音频编码。这些都是开放的、免版税的格式,通常得到很好的支持,尽管仅在最近的浏览器中得到支持,这就是为什么备用格式是一个好主意。html
<video controls src="filename.webm"></video>
- MP4 容器和 AVC(H.264)视频编解码器,理想情况下使用 AAC 作为音频编解码器。这是因为带有 AVC 和 AAC 编解码器的 MP4 容器是一种广泛支持的组合——事实上,每个主要浏览器都支持它——并且质量通常对大多数用例来说都很好。但是,请确保您验证自己是否符合许可证要求。html
<video controls> <source type="video/webm" src="filename.webm" /> <source type="video/mp4" src="filename.mp4" /> </video>
高质量视频呈现的建议
如果您的目标是以尽可能高的质量呈现视频,那么您可能受益于提供尽可能多的格式,因为能够提供最佳质量的编解码器往往也是最新的,因此最有可能存在浏览器兼容性差距。
- 使用 AV1 进行视频编码和 Opus 进行音频编码的 WebM 容器。如果您能够在编码 AV1 时使用高或专业配置文件,并在 6.3 等高级别上进行编码,则可以在 4K 或 8K 分辨率下获得非常高的比特率,同时保持出色的视频质量。使用 Opus 的全频带配置文件以 48 kHz 采样率对音频进行编码可以最大限度地提高捕获的音频带宽,捕获几乎所有人类听力范围内的频率。html
<video controls src="filename.webm"></video>
- 使用 HEVC 编解码器(使用高级主配置文件之一,例如具有 10 或 12 位色深的 Main 4:2:2,甚至最多每个分量 16 位的 Main 4:4:4)的 MP4 容器。在高比特率下,这提供了出色的图形质量和卓越的色彩再现。此外,您可以选择包含 HDR 元数据以提供高动态范围视频。对于音频,请使用高采样率(至少 48 kHz,但理想情况下为 96kHz)的 AAC 编解码器,并使用复杂编码而不是快速编码进行编码。html
<video controls> <source type="video/webm" src="filename.webm" /> <source type="video/mp4" src="filename.mp4" /> </video>
归档、编辑或重新混合的建议
目前 Web 浏览器中通常没有可用的无损或接近无损的视频编解码器。原因很简单:视频文件很大。无损压缩的效率必然低于有损压缩。例如,具有 4:2:0 色度下采样的未压缩 1080p 视频(1920 x 1080 像素)至少需要 1.5 Gbps。使用 FFV1 等无损压缩(Web 浏览器不支持)可能会将其降低到大约 600 Mbps,具体取决于内容。这仍然是每秒需要通过连接传输的大量比特,目前对于任何实际应用来说都不切实际。
即使某些有损编解码器提供了无损模式,情况也是如此;任何当前的 Web 浏览器都没有实现无损模式。您能做的最好的事情是选择一个使用有损压缩的高质量编解码器,并将其配置为尽可能少地进行压缩。一种方法是将编解码器配置为使用“快速”压缩,这本质上意味着实现的压缩更少。
在外部准备视频
要从网站或应用程序外部准备用于存档的视频,请使用一个实用程序对原始未压缩的视频数据进行压缩。例如,免费的 x264 实用程序可用于使用非常高的比特率以 AVC 格式编码视频
x264 --crf 18 -preset ultrafast --output outfilename.mp4 infile
虽然其他编解码器在对视频进行大幅压缩时可能具有更好的最佳质量水平,但它们的编码器往往速度慢到足以使您使用这种压缩获得的近乎无损的编码在几乎相同的整体质量水平下速度快得多。
录制视频
考虑到您能够获得的接近无损程度的限制,您可能会考虑使用 AVC 或 AV1。例如,如果您使用 媒体流录制 API 录制视频,则在创建 MediaRecorder
对象时,可以使用以下代码
const kbps = 1024;
const Mbps = kbps * kbps;
const options = {
mimeType: 'video/webm; codecs="av01.2.19H.12.0.000.09.16.09.1, flac"',
bitsPerSecond: 800 * Mbps,
};
let recorder = new MediaRecorder(sourceStream, options);
此示例创建了一个 MediaRecorder
,配置为使用 BT.2100 HDR 以 12 位颜色和 4:4:4 色度下采样录制 AV1 视频,并使用 FLAC 进行无损音频录制。结果文件将使用视频和音频轨道共享的比特率不超过 800 Mbps。您可能需要根据硬件性能、您的要求以及您选择使用的特定编解码器调整这些值。此比特率显然不适用于网络传输,可能仅在本地使用。
将 codecs
参数的值分解成其点分隔的属性,我们看到以下内容
值 | 描述 |
---|---|
av01 |
识别 AV1 编解码器的四字符代码 (4CC)。 |
2 |
配置文件。值为 2 表示专业配置文件。值为 1 是高配置文件,而值为 0 将指定主配置文件。 |
19H |
级别和层级。此值来自 AV1 规范第 A.3 节中的表格,并指示级别 6.3 的高层级。 |
12 |
色深。这表示每个分量 12 位。其他可能的值是 8 和 10,但 12 是 AV1 中可用的最高精度颜色表示。 |
0 |
单色模式标志。如果为 1,则不会记录任何色度平面,并且所有数据都应严格为亮度数据,从而产生灰度图像。我们指定了 0,因为我们想要颜色。 |
000 |
色度下采样模式,取自 AV1 规范第 6.4.2 节。值为 000,结合单色模式值 0,表示我们想要 4:4:4 色度下采样,或不损失任何颜色数据。 |
09 |
要使用的颜色原色。此值来自 AV1 规范第 6.4.2 节;9 表示我们想要使用 BT.2020 颜色,它用于 HDR。 |
16 |
要使用的传输特性。这也来自第 6.4.2 节;16 表示我们想要使用 BT.2100 PQ 颜色的特性。 |
09 |
要使用的矩阵系数,再次来自第 6.4.2 节。值为 9 指定我们想要使用具有可变亮度的 BT.2020;这也被称为 BT.2010 YbCbCr。 |
1 |
视频“全范围”标志。值为 1 表示我们希望使用全色域。 |
您编解码器选择的文档可能会提供在构建 codecs
参数时将使用到的信息。
另请参阅
- Web 音频编解码器指南
- 媒体容器格式(文件类型)
- 处理 Web 内容中的媒体支持问题
- WebRTC 使用的编解码器
- RFC 6381:“Bucket”媒体类型的“编解码器”和“配置文件”参数
- RFC 5334:Ogg 媒体类型
- RFC 3839:3GPP 多媒体文件的 MIME 类型注册
- RFC 4381:3GPP2 多媒体文件的 MIME 类型注册
- RFC 4337:MPEG-4 的 MIME 类型注册
- Chrome 中的视频和音频编解码器