From 310fd066e91f454b990372ffa30e803cc8120975 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 12:56:40 +0100 Subject: unslug zh-cn: move --- files/zh-cn/web/media/autoplay_guide/index.html | 265 ++++ .../index.html | 100 ++ .../web/media/formats/video_codecs/index.html | 1673 ++++++++++++++++++++ .../index.html" | 1673 -------------------- files/zh-cn/web/media/index.html | 76 + 5 files changed, 2114 insertions(+), 1673 deletions(-) create mode 100644 files/zh-cn/web/media/autoplay_guide/index.html create mode 100644 files/zh-cn/web/media/dash_adaptive_streaming_for_html_5_video/index.html create mode 100644 files/zh-cn/web/media/formats/video_codecs/index.html delete mode 100644 "files/zh-cn/web/media/formats/\350\247\206\351\242\221\347\274\226\350\247\243\347\240\201\345\231\250/index.html" create mode 100644 files/zh-cn/web/media/index.html (limited to 'files/zh-cn/web/media') diff --git a/files/zh-cn/web/media/autoplay_guide/index.html b/files/zh-cn/web/media/autoplay_guide/index.html new file mode 100644 index 0000000000..db2ac88dc0 --- /dev/null +++ b/files/zh-cn/web/media/autoplay_guide/index.html @@ -0,0 +1,265 @@ +--- +title: Autoplay guide for media and Web Audio APIs +slug: Web/媒体/Autoplay_guide +translation_of: Web/Media/Autoplay_guide +--- +

Automatically starting the playback of audio (or videos with audio tracks) immediately upon page load can be an unwelcome surprise to users. While autoplay of media serves a useful purpose, it should be used carefully and only when needed. In order to give users control over this, browsers often provide various forms of autoplay blocking. In this guide, we'll cover autoplay functionality in the various media and Web Audio APIs, including a brief overview of how to use autoplay and how to work with browsers to handle autoplay blocking gracefully.

+ +

Autoplay blocking is not applied to {{HTMLElement("video")}} elements when the source media does not have an audio track, or if the audio track is muted. Media with an active audio track are considered to be audible, and autoplay blocking applies to them. Inaudible media are not affected by autoplay blocking.

+ +

自动播放 和 自动播放暂停

+ +

The term autoplay refers to any feature that causes audio to begin to play without the user specifically requesting that playback begin. This includes both the use of HTML attributes to autoplay media as well as the user of JavaScript code to start playback outside the context of handling user input.

+ +

That means that both of the following are considered autoplay behavior, and are therefore subject to the browser's autoplay blocking policy:

+ +
<audio src="/music.mp4" autoplay>
+ +

+ +
audioElement.play();
+
+ +

以下网络功能和API可能会受到自动播放阻止的影响:

+ + + +

从用户的角度来看,网页或应用程序自动地发出噪音而没有警告可能会令人讨厌、不便或令人反感。因此,浏览器通常仅允许在特定情况下进行自动播放。

+ +

Autoplay功能

+ +

据新政策,媒体内容将在满足以下至少一个的条件下自动播放:

+ + + +

否则,播放可能会被阻止。导致播放被阻塞的确切情况以及将网站列入白名单的具体方法因浏览器而异,但最好是遵循以上的原则。

+ +

详情,请参阅 Google Chrome 和 WebKit 的自动播放政策。

+ +
+

注意: 换句话说,如果在尚无任何用户交互的页面中通过编程方式启动播放,则通常会阻止任何包含音频在内的媒体的播放。

+
+ +

能自动播放的媒体元素

+ +

既然我们已经介绍了什么是自动播放以及什么可以阻止自动播放,接下来我们将介绍您的网站或应用程序如何在页面加载时自动播放媒体,如何检测何时自动播放失败,以及当自动播放被浏览器拒绝时的应对技巧。

+ +

autoplay 属性

+ +

想让内容自动播放的最简单方法是将{{htmlattrxref("autoplay", "audio")}}属性添加到{{HTMLElement("audio")}}或{{HTMLElement("video")}}元素。并将{{domxref("HTMLMediaElement.autoplay", "autoplay")}}属性设置为 true ,当 autoplay 的属性为 true 时,媒体元素将在发生以下情况后尽快自动开始播放:

+ + + +

例子1: autoplay属性

+ +

使用 autoplay 属性的{{HTMLElement("audio")}}元素就像如下:

+ +
<audio id="musicplayer" autoplay>
+  <source src="/music/chapter1.mp4"
+</audio>
+
+ +

例子2:检测自动播放失败

+ +

如果你依靠自动播放功能去做一些重要的事情,或者自动播放失败会以任何方式影响你的应用程序,那你可能会想知道自动播放什么时候没有开始。不幸的是,对于{{htmlattrxref("autoplay", "audio")}}属性,识别自动播放是否成功开始是很棘手的。自动播放失败时不会触发任何事件。也没有抛出异常或可以设置回调,甚至在媒体元素上都没有标记来告诉你自动播放是否起作用。你实际能做的就是检查一些值,然后根据这些值猜测自动播放是否起作用。

+ +

如果您能够调整查看内容的方向,那么更好的方法是,依靠知道媒体播放已成功开始,而不是在媒体启动失败时知道。您可以通过侦听要在媒体元素上触发的{{event("play")}}事件来轻松实现此目的。

+ +

The play event is sent both when the media is resumed after being paused and when autoplay occurs. That means that the first time the play event is fired, you know your media is being started for the first time after the page is opened.

+ +

Consider this HTML for a media element:

+ +
<video src="myvideo.mp4" autoplay onplay=handleFirstPlay(event)">
+ +

Here we have a {{HTMLElement("video")}} element whose {{htmlattrxref("autoplay", "video")}} attribute is set, with an {{domxref("HTMLMediaElement.onplay", "onplay")}} event handler set up; the event is handled by a function called handleFirstPlay(), which receives as input the play event.

+ +

handleFirstPlay() looks like this:

+ +
function handleFirstPlay(event) {
+  let vid = event.target;
+
+  vid.onplay = null;
+
+  // Start whatever you need to do after playback has started
+}
+ +

After getting a reference to the video element from the {{domxref("Event")}} object's {{domxref("Event.target", "target")}}, the element's onplay handler is set to null. This will prevent any future play events from being delivered to the handler. That could happen if the video is paused and resumed by the user or automatically by the browser when the document is in a background tab.

+ +

At this point, your site or app can begin whatever it needs to do that relies upon the video having been started up.

+ +
+

Note: This approach doesn't differentiate between autoplay and the user starting playback manually.

+
+ +

The play() method

+ +

The term "autoplay" also refers to scenarios in which a script tries to trigger the playback of media that includes audio, outside the context of handling a user input event. This is done by calling the media element's {{domxref("HTMLMediaElement.play", "play()")}} method.

+ +
+

Note: It is strongly recommended that you use the autoplay attribute whenever possible, because support for autoplay preferences are more widespread for the autoplay attribute than for other means of playing media automatically. It also lets the browser take responsibility for starting playback, letting it optimize the timing of that taking place.

+
+ +

Example: Playing video

+ +

This simple example plays the first {{HTMLElement("video")}} element found in the document. play() won't let the playback begin unless the document has permission to automatically play media.

+ +
document.querySelector("video").play();
+ +

Example: Handling play() failures

+ +

It's much easier to detect a failure to autoplay media when you use the {{domxref("HTMLMediaElement.play", "play()")}} method to start it. play() returns a {{jsxref("Promise")}} which is resolved once the media successfully begins to play, and is rejected when playback fails to begin (such as if autoplay is denied). When autoplay fails, you likely will want to offer a way for the user to manually tell the browser to ask the user to grant permission to play media.

+ +

You might use code like this to accomplish the job:

+ +
let startPlayPromise = videoElem.play();
+
+if (startPlayPromise !== undefined) {
+  startPlayPromise.catch(error => {
+    if (error.name === "NotAllowedError") {
+      showPlayButton(videoElem);
+    } else {
+      // Handle a load or playback error
+    }
+  }).then(() => {
+    // Start whatever you need to do only after playback
+    // has begun.
+  });
+}
+
+ +

The first thing we do with the result of play() is make sure it's not undefined. We check for this because in earlier versions of the HTML specification, play() didn't return a value. Returning a promise to allow you to determine success or failure of the operation was added more recently. Checking for undefined prevents this code from failing with an error on older versions of web browsers.

+ +

We then add a {{jsxref("Promise.catch", "catch()")}} handler to the promise. This looks at the error's {{domxref("DOMException.name", "name")}} to see if it's NotAllowedError. This indicates that playback failed due to a permission issue, such as autoplay being denied. If that's the case, we should present a user interface to let the user manually start playback; that's handled here by a function showPlayButton().

+ +

Any other errors are handled as appropriate.

+ +

If the promise returned by play() is resolved without error, the then() clause is run and can begin whatever needs to be done when autoplay has begun.

+ +

Autoplay using the Web Audio API

+ +

In the Web Audio API, a web site or app can start playing audio using the start() method on a source node linked to the {{domxref("AudioContext")}}. Doing so outside the context of handling a user input event is subject to autoplay rules.

+ +

More content will come soon; autoplay blocking is still being worked on at Mozilla. If others have it already, they are welcome to pitch in with this section...

+ +

The autoplay feature policy

+ +

In addition to the browser-side management and control over autoplay functionality described above, a web server can also express its willingness to allow autoplay to function. The {{Glossary("HTTP")}} {{HTTPHeader("Feature-Policy")}} header's autoplay directive is used to control which domains, if any, can be used to autoplay media. By default, the autoplay feature policy is set to 'self' (including the single quote characters), indicating that autoplay is permitted as they're hosted on the same domain as the document.

+ +

You can also specify 'none' to disable autoplay entirely, '*' to allow autoplay from all domains, or one or more specific origins from which media can be automatically played. These origins are separated by space characters.

+ +
+

Note: The specified feature policy applies to the document and every {{HTMLElement("iframe")}} nested within it, unless those frames include an {{htmlattrxref("allow", "iframe")}}, which sets a new feature policy for that frame and all frames nested within it.

+
+ +

When using the {{htmlattrxref("allow", "iframe")}} attribute on an <iframe> to specify a feature policy for that frame and its nested frames, you can also specify the value 'src' to allow autoplay of media only from the same domain as that specified by the frame's {{htmlattrxref("src", "iframe")}} attribute.

+ +

Example: Allowing autoplay only from the document's domain

+ +

To use the {{HTTPHeader("Feature-Policy")}} header to only allow media to autoplay from the document's {{Glossary("origin")}}:

+ +
Feature-Policy: autoplay 'self'
+ +

To do the same for an {{HTMLElement("iframe")}}:

+ +
<iframe src="mediaplayer.html"
+        allow="autoplay 'src'">
+</iframe>
+
+ +

Example: Allowing autoplay and fullscreen mode

+ +

Adding Fullscreen API permission to the previous example results in a Feature-Policy header like the following if fullscreen access is allowed regardless of the domain; a domain restriction can be added as well as needed.

+ +
Feature-Policy: autoplay 'self'; fullscreen
+ +

The same permissions, grated using the <iframe> element's allow property, look like this:

+ +
<iframe src="mediaplayer.html"
+        allow="autoplay 'src'; fullscreen">
+</iframe>
+
+ +

Example: Allowing autoplay from specific sources

+ +

The Feature-Policy header to allow media to be played from both the document's (or <iframe>'s) own domain and https://example.media looks like this:

+ +
Feature-Policy: autoplay 'self' https://example.media
+ +

An {{HTMLElement("iframe")}} can be written to specify that this autoplay policy should be applied to itself and any child frames would be written thusly:

+ +
<iframe width="300" height="200"
+        src="mediaplayer.html"
+        allow="autoplay 'src' https://example.media">
+</iframe>
+
+ +

Example: Disabling autoplay

+ +

Setting the autoplay feature policy to 'none' disables autoplay entirely for the document or <iframe> and all nested frames. The HTTP header is:

+ +
Feature-Policy: autoplay 'none'
+ +

Using the <iframe>'s allow attribute:

+ +
<iframe src="mediaplayer.html"
+        allow="autoplay 'none'">
+</iframe>
+
+ +

Best practices

+ +

Tips and recommended best practices to help you make the most of working with autoplay are offered here.

+ +

Handling autoplay failure with media controls

+ +

A common use case for autoplay is to automatically begin to play a video clip that goes along with an article, an advertisement, or a preview of the page's main functionality. To autoplay videos like these, you have two options: don't have an audio track, or have an audio track but configure the {{HTMLElement("video")}} element to mute the audio by default, like this:

+ +
<video src="/videos/awesomevid.webm" controls autoplay muted>
+ +

This video element is configured to include the user controls (typically play/pause, scrubbing through the video's timeline, volume control, and muting); also, since the {{htmlattrxref("muted", "video")}} attribute is included, the video will autoplay but with the audio muted. The user has the option, however, of re-enabling the audio by clicking on the unmute button in the controls.

+ +

Browser configuration options

+ +

Browsers may have preferences that control the way autoplay works, or how autoplay blocking is handled. Here, any such preferences that may be of special significance or importance to you as a web developer are listed. These include any that may aid in testing or debugging as well as any that could be set in a way that you need to be prepared to handle.

+ +

Firefox

+ +
+
media.allowed-to-play.enabled
+
A Boolean preference which specifies whether or not the {{domxref("HTMLMediaElement.allowedToPlay")}} property is exposed to the web. This is currently false by default (except in nightly builds, where it's true by default). If this is false, the allowedToPlay property is missing from the HTMLMediaElement interface, and is thus not present on either {{HTMLElement("audio")}} or {{HTMLElement("video")}} elements.
+
media.autoplay.allow-extension-background-pages
+
This Boolean preference, if true, allows browser extensions' background scripts to autoplay audio media. Setting this value to false disables this capability. The default value is true.
+
media.autoplay.allow-muted
+
A Boolean preference which if true (the default) allows audio media which is currently muted to be automatically played. If this has been changed to false, media with an audio track will not be permitted to play even if muted.
+
media.autoplay.block-webaudio
+
A Boolean preference which indicates whether or not to apply autoplay blocking to the Web Audio API. The default is true.
+
media.autoplay.default
+
An integer preference which specifies whether per-domain configuration for autoplay support by default is allowed (0), blocked (1), or prompt-on-use (2). The default value is 0.
+
media.autoplay.enabled.user-gestures-needed (Nightly builds only)
+
A Boolean preference which controls whether or not detection of user gestures is allowed to override the setting of media.autoplay.default. If media.autoplay.default is not set to 0 (autoplay allowed by default), this preference being true allows autoplay of media with audio tracks anyway if the page has been activated by user gestures, and media that isn't audible is not restricted at all.
+
media.block-autoplay-until-in-foreground
+
A Boolean preference which indicates whether or not media playback is blocked when started on a background tab. The default value, true, means that even when otherwise available, autoplay won't take place until after a tab is brought to the foreground. This prevents the distracting situation in which a tab begins playing sound and the user can't find the tab among all their tabs and windows.
+
+ +

See also

+ + diff --git a/files/zh-cn/web/media/dash_adaptive_streaming_for_html_5_video/index.html b/files/zh-cn/web/media/dash_adaptive_streaming_for_html_5_video/index.html new file mode 100644 index 0000000000..aed7160371 --- /dev/null +++ b/files/zh-cn/web/media/dash_adaptive_streaming_for_html_5_video/index.html @@ -0,0 +1,100 @@ +--- +title: 为 HTML 5 视频提供的 DASH 自适应串流 +slug: Web/HTML/DASH_Adaptive_Streaming_for_HTML_5_Video +tags: + - DASH + - HTML + - HTML5 + - 指南 + - 视频流 +translation_of: Web/Media/DASH_Adaptive_Streaming_for_HTML_5_Video +--- +

经由 HTTP 的动态自适应串流(DASH)是一种自适应串流协议。 这意味着它使得视频串流能基于网络性能来调整比特率,以保证视频流畅播放。

+ +

浏览器支持

+ +

Firefox 21 包含了针对 HTM5 WebM 视频的 DASH 实现,但默认没有启用。可以通过在“about:config”里调整“media.dash.enabled”首选项来开启。

+ +

Firefox 23 移除了针对 HTML5 WebM 视频的 DASH 实现。此功能将被 媒体源扩展 API(MSE) 的实现取代。MSE 可实现通过 JavaScript 库(例如 dash.js)来提供对 DASH 的支持。详情参见 Bug 778617

+ +

使用 DASH - 服务端

+ +

首先,您需要将WebM视频转换为带有不同比特率的随附视频文件的DASH清单。根据您的需求,启动从 ffmpeg.org 的 ffmpeg 程序,就可以使用 libvpx 和 libbvorbis 支持的 WebM 视频和音频(版本2.5以上,3.2.5版本已通过测试)。

+ +

1. 使用现有的WebM文件创建一个音频文件和多个视频文件。

+ +

例如:

+ +

文件in.video可以是任何包含至少一个音频和一个视频流的容器,这些容器可以由ffmpeg解码,

+ +

创建音频:

+ +
ffmpeg -i in.video -vn -acodec libvorbis -ab 128k my_audio.webm
+
+
+ +

创建不同的视频

+ +
ffmpeg -i in.video -c:v libvpx-vp9 -keyint_min 150 -g 150 -tile-columns 4 -frame-parallel 1  -f webm -dash 1 \
+-an -vf scale=160:190 -b:v 250k video_160x90_250k.webm
+
+ffmpeg -i in.video -c:v libvpx-vp9 -keyint_min 150 -g 150 -tile-columns 4 -frame-parallel 1  -f webm -dash 1 \
+-an -vf scale=320:180 -b:v 500k video_320x180_500k.webm
+
+ffmpeg -i in.video -c:v libvpx-vp9 -keyint_min 150 -g 150 -tile-columns 4 -frame-parallel 1  -f webm -dash 1 \
+-an -vf scale=640:360 -b:v 750k  video_640x360_750k.webm
+
+ffmpeg -i in.video -c:v libvpx-vp9 -keyint_min 150 -g 150 -tile-columns 4 -frame-parallel 1  -f webm -dash 1 \
+-an -vf scale=640:360 -b:v 1000k  video_640x360_1000k.webm
+
+ffmpeg -i in.video -c:v libvpx-vp9 -keyint_min 150 -g 150 -tile-columns 4 -frame-parallel 1  -f webm -dash 1 \
+-an -vf scale=1280:720 -b:v 1500k  video_1280x720_1500k.webm
+
+ +

或使用命令创建以上视频:

+ +
ffmpeg -i in.video -c:v libvpx-vp9 -keyint_min 150 \
+-g 150 -tile-columns 4 -frame-parallel 1  -f webm -dash 1 \
+-an -vf scale=160:190 -b:v 250k video_160x90_250k.webm \
+-an -vf scale=320:180 -b:v 500k video_320x180_500k.webm \
+-an -vf scale=640:360 -b:v 750k  video_640x360_750k.webm \
+-an -vf scale=640:360 -b:v 1000k  video_640x360_1000k.webm \
+-an -vf scale=1280:720 -b:v 1500k  video_1280x720_1500k.webm
+ +

2. 创建清单文件

+ +
ffmpeg \
+  -f webm_dash_manifest -i video_160x90_250k.webm \
+  -f webm_dash_manifest -i video_320x180_500k.webm \
+  -f webm_dash_manifest -i video_640x360_750k.webm \
+  -f webm_dash_manifest -i video_1280x720_1500k.webm \
+  -f webm_dash_manifest -i my_audio.webm \
+  -c copy \
+  -map 0 -map 1 -map 2 -map 3 -map 4 \
+  -f webm_dash_manifest \
+  -adaptation_sets "id=0,streams=0,1,2,3 id=1,streams=4" \
+  my_video_manifest.mpd
+ +

-map 参数对应输入文件的顺序(每个文件只对应一个参数)。-adaptation_sets 参数将它们分配给适配集;例如,以上命令创建一个包含 0,1,2,3 的视频集(0),而另一个(1)仅仅包含视频流 4 和音频流。

+ +

将清单和相关的视频文件放在Web服务器或CDN上。 DASH通过HTTP来完成,因此只要您的HTTP服务器支持字节范围请求,并且DASH设置为使用 mimetype="application/dash+xml" 来支持 .mpd 文件即可。

+ +

使用DASH-客户端

+ +

您将需要修改网页,使其首先指向DASH清单,而不是直接指向特定的视频文件:

+ +
<video>
+  <source src="movie.mpd">
+  <source src="movie.webm">
+  Your browser does not support the video tag.
+</video>
+ +

如果浏览器支持DASH,则您的视频现在将自适应地流式传输。

+ + + +

WebM DASH Specification at The WebM Project

+ +

DASH Industry Forum

+ +

WebM project description of how to create DASH files with FFMPEG

diff --git a/files/zh-cn/web/media/formats/video_codecs/index.html b/files/zh-cn/web/media/formats/video_codecs/index.html new file mode 100644 index 0000000000..d299975762 --- /dev/null +++ b/files/zh-cn/web/media/formats/video_codecs/index.html @@ -0,0 +1,1673 @@ +--- +title: 网络视频编解码器指南 +slug: Web/Media/Formats/视频编解码器 +translation_of: Web/Media/Formats/Video_codecs +--- +
{{QuickLinksWithSubpages("/en-US/docs/Web/Media")}}
+ +

未经压缩的视频的数据量太大了,我们有必要进行很多压缩处理来存储视频,就更不用说通过网络传输视频的时候了。想象一下我们需要多少数据来存储未经压缩的视频:

+ + + +

不仅仅是需要的存储空间很大的问题,以 249MB 每秒的速度传输这样的未压缩的视频所需要的网络带宽也很大(不包括音频和开销)。这就是为什么我们需要视频编解码器。就像音频编解码器对声音数据所做的处理一样,视频编解码器会压缩视频数据并将其编码为一种格式,以后我们可以对其进行解码,播放或者编辑。

+ +

大多数的视频编解码器是有损的(解码后的视频与原来的视频不完全匹配)。一些细节可能会丢失,丢失的数量取决于编解码器和它的配置方式。通常来说,压缩程度越高,细节丢失的越多,视频失真更严重。虽然现在也有一些无损编解码器,但是通常都是用于存档和存储在本地来进行本地回放的,而不是在网络上使用。

+ +

本指南介绍了一些你可能遇到或者考虑去使用的网络视频编解码器的功能以及一些兼容性和实用性问题。并且帮助您为项目视频选择正确的编解码器提供一些建议。

+ +

通用编解码器

+ +

以下视频编解码器是网上最常用的视频编解码器。每个编解码器都列出了它们可以支持的文件类型。每个编解码器都提供了一个指向下文相关部分详细内容的快捷链接,包含一些您可能需要了解的特定功能和兼容性问题。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
编解码器名称 (简称)编解码器全称支持文件类型
AV1AOMedia Video 1MP4, WebM
AVC (H.264)Advanced Video Coding3GP, MP4, WebM
H.263H.263 Video3GP
HEVC (H.265)High Efficiency Video CodingMP4
{{anch("MP4V-ES")}}MPEG-4 Video Elemental Stream3GP, MP4
{{anch("MPEG-1")}}MPEG-1 Part 2 VisualMPEG, QuickTime
{{anch("MPEG-2")}}MPEG-2 Part 2 VisualMP4, MPEG, QuickTime
TheoraTheoraOgg
VP8Video Processor 83GP, Ogg, WebM
VP9Video Processor 9MP4, Ogg, WebM
+ +

影响编码视频的因素

+ +

和任何编码器一样,有两个会影响到编码视频大小和质量的因素:源视频的格式和内容,以及在对视频进行编码时候使用的编解码器的特性和配置。

+ +

最简单的原则是:如果要让编码视频看起来更像原始的未压缩过的视频,那么通常得到的视频会更大。因此我们始终要在尺寸和质量之间进行权衡。在某些情况下,我们会为了降低数据大小而接受质量的损失。但是其他时候,我们不能接受质量损失,所以我们必须接受会导致文件相应增大的编码器配置。

+ +

源视频格式对编码输出的影响

+ +

源视频格式影响编码输出的程度取决于编解码器及其工作方式。如果编解码器将视频媒体转换为内部像素的格式,或者使用使用简单像素以外的方法表示图像,那么原始图像的格式对编码输出没有什么影响。但是,诸如帧频和分辨率之类始终会对媒体视频的输出大小产生影响。

+ +

Additionally, all codecs have their strengths and weaknesses. Some have trouble with specific kinds of shapes and patterns, or aren't good at replicating sharp edges, or tend to lose detail in dark areas, or any number of possibilities. It all depends on the underlying algorithms and mathematics.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
The potential effect of source video format and contents on the encoded video quality and size
Feature对质量的影响对尺寸的影响
Color depth (bit depth)颜色位深越高,视频中颜色保真度质量就越高。除此之外,在图像饱和部分(颜色纯而强烈的,例如明亮纯红色[rgba(255,0,0,1)),低于每分量10色深(10bits色彩)允许条带化,其中,如果没有可见色阶跃就无法表示渐变。Depending on the codec, higher color depths may result in larger compressed file sizes. The determining factor is what internal storage format is used for the compressed data.
Frame ratePrimarily affects the perceived smoothness of the motion in the image. To a point, the higher the frame rate, the smoother and more realistic the motion will appear. Eventually the point of diminishing returns is reached. See {{anch("Frame rate")}} below for details.Assuming the frame rate is not reduced during encoding, higher frame rates cause larger compressed video sizes.
MotionCompression of video typically works by comparing frames, finding where they differ, and constructing records containing enough information to update the previous frame to approximate the appearance of the following frame. The more successive frames differ from one another, the larger these differences are, and the less effective the compression is at avoiding the introduction of artifacts into the compressed video.The complexity introduced by motion results in larger intermediate frames due to the higher number of differences between frames). For this and other reasons, the more motion there is in a video, the larger the output file will typically be.
NoisePicture noise (such as film grain effects, dust, or other grittiness to the image) introduces variability. Variability generally makes compression more difficult, resulting in more lost quality due to the need to drop details to achieve the same level of compression.The more variability—such as noise—there is in the image, the more complex the compression process and the less success the algorithm is likely to have compressing the image to the same degree. Unless you configure the encoder in a way that ignores some or all of the variations caused by noise, the compressed video will be larger.
Resolution (width and height)Higher resolution video, presented in the same screen size, will typically be able to more accurately portray the original scene, barring effects introduced during compression.The higher the resolution of a video, the larger it gets. This plays a key role in the final size of the video.
+ +

The degree to which these affect the resulting encoded video will vary depending on the precise details of the situation, including which encoder you use and how it's configured. In addition to general codec options, the encoder could be configured to reduce the frame rate, to clean up noise, and/or to reduce the overall resolution of the video during encoding.

+ +

Effect of codec configuration on encoded output

+ +

The algorithms used do encode video typically use one or more of a number of general techniques to perform their encoding. Generally speaking, any configuration option that is intended to reduce the output size of the video will probably have a negative impact on the overall quality of the video, or will introduce certain types of artifacts into the video. It's also possible to select a lossless form of encoding, which will result in a much larger encoded file but with perfect reproduction of the original video upon decoding.

+ +

In addition, each encoder utility may have variations in how they process the source video, resulting in differences in the output quality and/or size.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Video encoder configuration effects on quality and size
FeatureEffect on qualityEffect on size
Lossless compressionNo loss of qualityLossless compression cannot reduce the overall video size nearly as much as lossy compression; the resulting files are likely to still be too large for general usage.
Lossy compressionTo some degree, artifacts and other forms of quality degradation wil occur, depending on the specific codec and how much compression is being appliedThe more the encoded video is allowed to deviate from the source, the easier it is to accomplish higher compression rates
Quality settingThe higher the quality configuration, the more like the original media the encoded video will lookIn general, higher quality settings will result in larger encoded video files; the degree to which this is true varies depending on the codec
Bit rateQuality generally improves with higher bit ratesHigher bit rates inherently lead to larger output files
+ +

The options available when encoding video, and the values to be assigned to those options, will vary not only from one codec to another but depending on the encoding software you use. The documentation included with your encoding software will help you to understand the specific impact of these options on the encoded video.

+ +

Compression artifacts

+ +

Artifacts are side effects of a lossy encoding process in which the lost or rearranged data results in visibly negative effects. Once an artifact has appeared, it may linger for a while, because of how video is displayed. Each frame of video is presented by applying a set of changes to the currently-visible frame. This means that any errors or artifacts will compound over time, resulting in glitches or otherwise strange or unexpected deviations in the image that linger for a time.

+ +

To resolve this, and to improve seek time through the video data, periodic key frames (also known as intra-frames or i-frames) are placed into the video file. The key frames are full frames, which are used to repair any damage or artifact residue that's currently visible.

+ +

Aliasing

+ +

Aliasing is a general term for anything that upon being reconstructed from the encoded data does not look the same as it did before compression. There are many forms of aliasing; the most common ones you may see include:

+ + + + + + + + + + + + + + + + +
+

Moiré patterns

+ +

A {{interwiki("Moiré pattern")}} is a large-scale spatial interference pattern produced when a pattern in the source image and the manner in which the encoder operates are slightly out of alignment spatially. The artifacts generated by the encoder then introduce strange, swirling effects in the source image's pattern upon decoding.

+
+

Staircase effect

+ +

The staircase effect is a spatial artifact that occurs when diagonal straight or curved edges that should be smooth take on a jagged appearance, looking somewhat like a set of stair steps. This is the effect that is being reduced by "anti-aliasing" filters.

+
+

Wagon-wheel effect

+ +

The wagon-wheel effect (or {{interwiki("wikipedia", "stroboscopic effect")}}) is the visual effect that's commonly seen in film, in which a turning wheel appears to rotate at the wrong speed, or even in reverse, due to an interaction between the frame rate and the compression algorithm. The same effect can occur with any repeating pattern that moves, such as the ties on a railway line, posts along the side of a road, and so forth. This is a temporal (time-based) aliasing issue; the speed of the rotation interferes with the frequency of the sampling performed during compression or encoding.

+
+ +

Color edging

+ +

Color edging is a type of visual artifact that presents as spurious colors introduced along the edges of colored objects within the scene. These colors have no intentional color relationship to the contents of the frame.

+ +

 Loss of sharpness

+ +

The act of removing data in the process of encoding video requires that some details be lost. If enough compression is applied, parts or potentially all of the image could lose sharpness, resulting in a slightly fuzzy or hazy appearance.

+ +

Lost sharpness can make text in the image difficult to read, as text—especially small text—is very detail-oriented content, where minor alterations can significantly impact legibility.

+ +

Ringing

+ +

Lossy compression algorithms can introduce {{interwiki("wikipedia", "ringing artifacts", "ringing")}}, an effect where areas outside an object are contaminated with colored pixels generated by the compression algorithm. This happens when an algorithm that uses blocks that span across a sharp boundary between an object and its background. This is particularly common at higher compression levels.

+ +

Example of the ringing effect

+ +

Note the blue and pink fringes around the edges of the star above (as well as the stepping and other significant compression artifacts). Those fringes are the ringing effect. Ringing is similar in some respects to {{anch("Mosquito noise", "mosquito noise")}}, except that while the ringing effect is more or less steady and unchanging, mosquito noise shimmers and moves.

+ +

RInging is another type of artifact that can make it particularly difficult to read text contained in your images.

+ +

Posterizing

+ +

Posterization occurs when the compression results in the loss of color detail in gradients. Instead of smooth transitions through the various colors in a region, the image becomes blocky, with blobs of color that approximate the original appearance of the image.

+ +

+ +

Note the blockiness of the colors in the plumage of the bald eagle in the photo above (and the snowy owl in the background). The details of the feathers is largely lost due to these posterization artifacts.

+ +

Contouring

+ +

Contouring or color banding is a specific form of posterization in which the color blocks form bands or stripes in the image. This occurs when the video is encoded with too coarse a quantization configuration. As a result, the video's contents show a "layered" look, where instead of smooth gradients and transitions, the transitions from color to color are abrupt, causing strips of color to appear.

+ +

Example of an image whose compression has introduced contouring

+ +

In the example image above, note how the sky has bands of different shades of blue, instead of being a consistent gradient as the sky color changes toward the horizon. This is the contouring effect.

+ +

Mosquito noise

+ +

Mosquito noise is a temporal artifact which presents as noise or edge busyness that appears as a flickering haziness or shimmering that roughly follows outside the edges of objects with hard edges or sharp transitions between foreground objects and the background. The effect can be similar in appearance to {{anch("Ringing", "ringing")}}.

+ +

+ +

The photo above shows mosquito noise in a number of places, including in the sky surrounding the bridge. In the upper-right corner, an inset shows a close-up of a portion of the image that exhibits mosquito noise.

+ +

Mosquito noise artifacts are most commonly found in MPEG video, but can occur whenever a discrete cosine transform (DCT) algorithm is used; this includes, for example, JPEG still images.

+ +

Motion compensation block boundary artifacts

+ +

Compression of video generally works by comparing two frames and recording the differences between them, one frame after another, until the end of the video. This technique works well when the camera is fixed in place, or the objects in the frame are relatively stationary, but if there is a great deal of motion in the frame, the number of differences between frames can be so great that compression doesn't do any good.

+ +

{{interwiki("wikipedia", "Motion compensation")}} is a technique that looks for motion (either of the camera or of objects in the frame of view) and determines how many pixels the moving object has moved in each direction. Then that shift is stored, along with a description of the pixels that have moved that can't be described just by that shift. In essence, the encoder finds the moving objects, then builds an internal frame of sorts that looks like the original but with all the objects translated to their new locations. In theory, this approximates the new frame's appearance. Then, to finish the job, the remaining differences are found, then the set of object shifts and the set of pixel differences are stored in the data representing the new frame. This object that describes the shift and the pixel differences is called a residual frame.

+ + + + + + + + + + + + + + + + + + + + + + + + +
Original frameInter-frame differencesDifference after motion compensation
Original frame of videoDifferences between the frames after shifting two pixels right
The first full frame as seen by the viewer.Here, only the differences between the first frame and the following frame are seen. Everything else is black. Looking closely, we can see that the majority of these differences come from a horizontal camera move, making this a good candidate for motion compensation.To minimize the number of pixels that are different, here we take into account the panning of the camera by first shifting the first frame to the right by two pixels, then by taking the difference. This compensates for the panning of the camera, allowing for more overlap between the two frames.
Images from Wikipedia
+ +

There are two general types of motion compensation: global motion compensation and block motion compensation. Global motion compensation generally adjusts for camera movements such as tracking, dolly movements, panning, tilting, rolling, and up and down movements. Block motion compensation handles localized changes, looking for smaller sections of the image that can be encoded using motion compensation. These blocks are normally of a fixed size, in a grid, but there are forms of motion compensation that allow for variable block sizes, and even for blocks to overlap.

+ +

There are, however, artifacts that can occur due to motion compensation. These occur along block borders, in the form of sharp edges that produce false ringing and other edge effects. These are due to the mathematics involved in the coding of the residual frames, and can be easily noticed before being repaired by the next key frame.

+ +

Reduced frame size

+ +

In certain situations, it may be useful to reduce the video's dimensions in order to improve the final size of the video file. While the immediate loss of size or smoothness of playback may be a negative factor, careful decision-making can result in a good end result. If a 1080p video is reduced to 720p prior to encoding, the resulting video can be much smaller while having much higher visual quality; even after scaling back up during playback, the result may be better than encoding the original video at full size and accepting the quality hit needed to meet your size requirements.

+ +

Reduced frame rate

+ +

Similarly, you can remove frames from the video entirely and decrease the frame rate to compensate. This has two benefits: it makes the overall video smaller, and that smaller size allows motion compensation to accomplish even more for you. For exmaple, instead of computing motion differences for two frames that are two pixels apart due to inter-frame motion, skipping every other frame could lead to computing a difference that comes out to four pixels of movement. This lets the overall movement of the camera be represented by fewer residual frames.

+ +

The absolute minimum frame rate that a video can be before its contents are no longer perceived as motion by the human eye is about 12 frames per second. Less than that, and the video becomes a series of still images. Motion picture film is typically 24 frames per second, while standard definition television is about 30 frames per second (slightly less, but close enough) and high definition television is between 24 and 60 frames per second. Anything from 24 FPS upward will generally be seen as satisfactorily smooth; 30 or 60 FPS is an ideal target, depending on your needs.

+ +

In the end, the decisions about what sacrifices you're able to make are entirely up to you and/or your design team.

+ +

Codec details

+ +

AV1

+ +

The AOMedia Video 1 (AV1) codec is an open format designed by the Alliance for Open Media specifically for internet video. It achieves higher data compression rates than {{anch("VP9")}} and {{anch("HEVC", "H.265/HEVC")}}, and as much as 50% higher rates than AVC. AV1 is fully royalty-free and is designed for use by both the {{HTMLElement("video")}} element and by WebRTC.

+ +

AV1 currently offers three profiles: main, high, and professional with increasing support for color depths and chroma subsampling. In addition, a series of levels are specified, each defining limits on a range of attributes of the video. These attributes include frame dimensions, image area in pixels, display and decode rates, average and maximum bit rates, and limits on the number of tiles and tile columns used in the encoding/decoding process.

+ +

For example, level AV1 level 2.0 offers a maximum frame width of 2048 pixels and a maximum height of 1152 pixels, but its maximum frame size in pixels is 147,456, so you can't actually have a 2048x1152 video at level 2.0. It's worth noting, however, that at least for Firefox and Chrome, the levels are actually ignored at this time when performing software decoding, and the decoder just does the best it can to play the video given the settings provided. For compatibility's sake going forward, however, you should stay within the limits of the level you choose.

+ +

The primary drawback to AV1 at this time is that it is very new, and support is still in the process of being integrated into most browsers. Additionally, encoders and decoders are still being optimized for performance, and hardware encoders and decoders are still mostly in development rather than production. For this reason, encoding a video into AV1 format takes a very long time, since all the work is done in software.

+ +

For the time being, because of these factors, AV1 is not yet ready to be your first choice of video codec, but you should watch for it to be ready to use in the future.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Supported bit ratesVaries depending on the video's level; theoretical maximum reaches 800 Mbps at level 6.3[2]
Supported frame ratesVaries by level; for example, level 2.0 has a maximum of 30 FPS while level 6.3 can reach 120 FPS
CompressionLossy DCT-based algorithm
Supported frame sizes8 x 8 pixels to 65,535 x 65535 pixels with each dimension allowed to take any value between these
Supported color modes + + + + + + + + + + + + + + + + + + + + + + + + + +
ProfileColor depthsChroma subsampling
Main8 or 104:0:0 (greyscale) or 4:2:0
High8 or 104:0:0 (greyscale), 4:2:0, or 4:4:4
Professional8, 10, or 124:0:0 (greyscale), 4:2:0, 4:2:2, or 4:4:4
+
HDR supportYes
Variable Frame Rate (VFR) supportYes
Browser compatibility + + + + + + + + + + + + + + + + + + + + + +
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
AV1 support707567No57No
+
Container supportISOBMFF[1], MPEG-TS, MP4, WebM
{{Glossary("RTP")}} / WebRTC compatibleYes
Supporting/Maintaining organizationAlliance for Open Media
Specificationhttps://aomediacodec.github.io/av1-spec/av1-spec.pdf
LicensingRoyalty-free, open standard
+ +

[1] {{interwiki("wikipedia", "ISO Base Media File Format")}}

+ +

[2] See the AV1 specification's tables of levels, which describe the maximum resolutions and rates at each level.

+ +

AVC (H.264)

+ +

The MPEG-4 specification suite's Advanced Video Coding (AVC) standard is specified by the identical ITU H.264 specification and the MPEG-4 Part 10 specification. It's a motion compensation based codec that is widely used today for all sorts of media, including broadcast television, {{Glossary("RTP")}} videoconferencing, and as the video codec for Blu-Ray discs.

+ +

AVC is highly flexible, with a number of profiles with varying capabilities; for example, the Constrained Baseline Profile is designed for use in videoconferencing and mobile scenarios, using less bandwidth than the Main Profile (which is used for standard definition digital TV in some regions) or the High Profile (used for Blu-Ray Disc video). Most of the profiles use 8-bit color components and 4:2:0 chroma subsampling; The High 10 Profile adds support for 10-bit color, and advanced forms of High 10 add 4:2:2 and 4:4:4 chroma subsampling.

+ +

AVC also has special features such as support for multiple views of the same scene (Multiview Video Coding), which allows, among other things, the production of stereoscopic video.

+ +

AVC is a proprietary format, however, and numerous patents are owned by multiple parties regarding its technologies. Commercial use of AVC media requires a license, though the MPEG LA patent pool does not require license fees for streaming internet video in AVC format as long as the video is free for end users.

+ +

Non-web browser implementations of WebRTC (any implementation which doesn't include the JavaScript APIs) are required to support AVC as a codec in WebRTC calls. While web browsers are not required to do so, some do.

+ +

In HTML content for web browsers, AVC is broadly compatible and many platforms support hardware encoding and decoding of AVC media. However, be aware of its licensing requirements before choosing to use AVC in your project!

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Supported bit ratesVaries by level
Supported frame ratesVaries by level; up to 300 FPS is possible
CompressionLossy DCT-based algorithm, though it's possible to create lossless macroblocks within the image
Supported frame sizesUp to 8,192 x 4,320 pixels
Supported color modes +

Some of the more common or interesting profiles:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ProfileColor depthsChroma subsampling
Constrained Baseline (CBP)84:2:0
Baseline (BP)84:2:0
Extended (XP)84:2:0
Main (MP)84:2:0
High (HiP)84:0:0 (greyscale) and 4:2:0
Progressive High (ProHiP)84:0:0 (greyscale) and 4:2:0
High 10 (Hi10P)8 to 104:0:0 (greyscale) and 4:2:0
High 4:2:2 (Hi422P)8 to 104:0:0 (greyscale), 4:2:0, and 4:2:2
High 4:4:4 Predictive8 to 144:0:0 (greyscale), 4:2:0, 4:2:2, and 4:4:4
+
HDR supportYes; {{interwiki("wikipedia", "Hybrid Log-Gamma")}} or Advanced HDR/SL-HDR; both are part of ATSC
Variable Frame Rate (VFR) supportYes
Browser compatibility + + + + + + + + + + + + + + + + + + + + + +
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
AVC/H.265 support41235[1]9253.2
+
Container support3GP, MP4, WebM
{{Glossary("RTP")}} / WebRTC compatibleYes
Supporting/Maintaining organizationMPEG / ITU
Specificationhttps://mpeg.chiariglione.org/standards/mpeg-4/advanced-video-coding
+ https://www.itu.int/rec/T-REC-H.264
LicensingProprietary with numerous patents. Commercial use requires a license. Note that multiple patent pools may apply.
+ +

[1] Firefox support for AVC is dependent upon the operating system's built-in or preinstalled codecs for AVC and its container in order to avoid patent concerns.

+ +

H.263

+ +

ITU's H.263 codec was designed primarily for use in low-bandwidth situations. In particular, its focus is for video conferencing on PSTN (Public Switched Telephone Networks), {{Glossary("RTSP")}}, and SIP (IP-based videoconferencing) systems. Despite being optimized for low-bandwidth networks, it is fairly CPU intensive and may not perform adequately on lower-end computers. The data format is similar to that of MPEG-4 Part 2.

+ +

H.263 has never been widely used on the web. Variations on H.263 have been used as the basis for other proprietary formats, such as Flash video or the Sorenson codec. However, no major browser has ever included H.263 support by default. Certain media plugins have enabled support for H.263 media.

+ +

Unlike most codecs, H.263 defines fundamentals of an encoded video in terms of the maximum bit rate per frame (picture), or BPPmaxKb. During encoding, a value is selected for BPPmaxKb, and then the video cannot exceed this value for each frame. The final bit rate will depend on this, the frame rate, the compression, and the chosen resolution and block format.

+ +

H.263 has been superseded by H.264 and is therefore considered a legacy media format which you generally should avoid using if you can. The only real reason to use H.263 in new projects is if you require support on very old devices on which H.263 is your best choice.

+ +

H.263 is a proprietary format, with patents held by a number of organizations and companies, including Telenor, Fujitsu, Motorola, Samsung, Hitachi, Polycom, Qualcomm, and so on. To use H.263, you are legally obligated to obtain the appropriate licenses.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Supported bit ratesUnrestricted, but typically below 64 Kbps
Supported frame ratesAny
CompressionLossy DCT-based algorithm
Supported frame sizesUp to 1408 x 1152 pixels[2]
Supported color modesYCbCr; each picture format (sub-QCIF, QCIF, CIF, 4CIF, or 16CIF)  defines the frame size in pixels as well as how many rows each of luminance and chrominance samples are used for each frame
HDR supportNo
Variable Frame Rate (VFR) supportNo
Browser compatibility + + + + + + + + + + + + + + + + + + + + + +
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
H.263 supportNoNoNo[1]NoNoNo
+
Container support3GP, MP4, QuickTime
{{Glossary("RTP")}} / WebRTC compatibleNo
Supporting/Maintaining organizationITU
Specificationhttps://www.itu.int/rec/T-REC-H.263/
LicensingProprietary; appropriate license or licenses are required. Note that multiple patent pools may apply.
+ +

[1] While Firefox does not generally support H.263, the OpenMax platform implementation (used for the Boot to Gecko project upon which Firefox OS was based) did support H.263 in 3GP files.

+ +

[2] Version 1 of H.263 specifies a set of picture sizes which are supported. Later versions may support additional resolutions.

+ +

HEVC (H.265)

+ +

The High Efficiency Video Coding (HVEC) codec is defined by ITU's H.265 as well as by MPEG-H Part 2 (the still in-development follow-up to MPEG-4). HEVC was designed to support efficient encoding and decoding of video in sizes including very high resolutions (including 8K video), with a structure specifically designed to let software take advantage of modern processors. Theoretically, HEVC can achieve compressed file sizes half that of {{anch("AVC")}} but with comparable image quality.

+ +

For example, each coding tree unit (CTU)—similar to the macroblock used in previous codecs—consists of a tree of luma values for each sample as well as a tree of chroma values for each chroma sample used in the same coding tree unit, as well as any required syntax elements. This structure supports easy processing by multiple cores.

+ +

An interesting feature of HEVC is that the main profile supports only 8 bit per component color with 4:2:0 chroma subsampling. Also interesting is that 4:4:4 video is handled specially. Instead of having the luma samples (representing the image's pixels in grayscale) and the Cb and Cr samples (indicating how to alter the grays to create color pixels), the three channels are instead treated as three monochrome images, one for each color, which are then combined during rendering to produce a full-color image.

+ +

HEVC is a proprietary format and is covered by a number of patents.  Licensing is managed by MPEG LA; fees are charged to developers rather than to content producers and distributors. Be sure to review the latest license terms and requirements before making a decision on whether or not to use HEVC in your app or web site!

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Supported bit ratesUp to 800,000 Kbps
Supported frame ratesVaries by level; up to 300 FPS is possible
CompressionLossy DCT-based algorithm
Supported frame sizes128 x 96 to 8,192 x 4,320 pixels; varies by profile and level
Supported color modes +

Information below is provided for the major profiles. There are a number of other profiles available that are not included here.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ProfileColor depthsChroma subsampling
Main84:2:0
Main 108 to 104:2:0
Main 128 to 124:0:0 and 4:2:0
Main 4:2:2 108 to 104:0:0, 4:2:0, and 4:2:2
Main 4:2:2 128 to 124:0:0, 4:2:0, and 4:2:2
Main 4:4:484:0:0, 4:2:0, 4:2:2, and 4:4:4
Main 4:4:4 108 to 104:0:0, 4:2:0, 4:2:2, and 4:4:4
Main 4:4:4 128 to 124:0:0, 4:2:0, 4:2:2, and 4:4:4
Main 4:4:4 16 Intra8 to 164:0:0, 4:2:0, 4:2:2, and 4:4:4
+
HDR supportYes
Variable Frame Rate (VFR) supportYes
Browser compatibility + + + + + + + + + + + + + + + + + + + + + +
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
HEVC / H.265 supportNo18[1]No[2]11[1]No11
+
Container supportMP4
{{Glossary("RTP")}} / WebRTC compatibleNo
Supporting/Maintaining organizationITU / MPEG
Specificationshttp://www.itu.int/rec/T-REC-H.265
+ https://www.iso.org/standard/69668.html
LicensingProprietary; confirm your compliance with the licensing requirements. Note that multiple patent pools may apply.
+ +

[1] Internet Explorer and Edge only supports HEVC on devices with a hardware codec.

+ +

[2] Mozilla will not support HEVC while it is encumbered by patents.

+ +

MP4V-ES

+ +

The MPEG-4 Video Elemental Stream (MP4V-ES) format is part of the MPEG-4 Part 2 Visual standard. While in general, MPEG-4 part 2 video is not used by anyone because of its lack of compelling value related to other codecs, MP4V-ES does have some usage on mobile. MP4V is essentially H.263 encoding in an MPEG-4 container.

+ +

Its primary purpose is to be used to stream MPEG-4 audio and video over an {{Glossary("RTP")}} session. However, MP4V-ES is also used to transmit MPEG-4 audio and video over a mobile connection using 3GP.

+ +

You almost certainly don't want to use this format, since it isn't supported in a meaningful way by any major browsers, and is quite obsolete. Files of this type should have the extension .mp4v, but sometimes are inaccurately labeled .mp4.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Supported bit rates5 Kbps to 1 Gbps and more
Supported frame ratesNo specific limit; restricted only by the data rate
CompressionLossy DCT-based algorithm
Supported frame sizesUp to 4,096 x 4,096 pixels
Supported color modesYCrCb with chroma subsampling (4:2:0, 4:2:2, and 4:4:4) supported; up to 12 bits per component
HDR supportNo
Variable Frame Rate (VFR) supportYes
Browser compatibility + + + + + + + + + + + + + + + + + + + + + +
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
MP4V-ES supportNo[2]NoYes[1]NoNoNo
+
Container support3GP, MP4
{{Glossary("RTP")}} / WebRTC compatibleNo
Supporting/Maintaining organizationMPEG
Specification{{RFC(6416)}}
LicensingProprietary; obtain a license through MPEG LA and/or AT&T as needed
+ +

[1] Firefox supports MP4V-ES in 3GP containers only.

+ +

[2] Chrome does not support MP4V-ES; however, Chrome OS does.

+ +

MPEG-1 Part 2 Video

+ +

MPEG-1 Part 2 Video was unveiled at the beginning of the 1990s. Unlike the later MPEG video standards, MPEG-1 was created solely by MPEG, without the {{Glossary("ITU", "ITU's")}} involvement.

+ +

Because any MPEG-2 decoder can also play MPEG-1 video, it's compatible with a wide variety of software and hardware devices. There are no active patents remaining in relation to MPEG-1 video, so it may be used free of any licensing concerns. However, few web browsers support MPEG-1 video without the support of a plugin, and with plugin use deprecated in web browsers, these are generally no longer available. This makes MPEG-1 a poor choice for use in web sites and web applications.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Supported bit ratesUp to 1.5 Mbps
Supported frame rates23.976 FPS, 24 FPS, 25 FPS, 29.97 FPS, 30 FPS, 50 FPS, 59.94 FPS, and 60 FPS
CompressionLossy DCT-based algorithm
Supported frame sizesUp to 4,095 x 4,095 pixels
Supported color modesY'CbCr with 4:2:0 chroma subsampling with up to 12 bits per component
HDR supportNo
Variable Frame Rate (VFR) supportNo
Browser compatibility + + + + + + + + + + + + + + + + + + + + + +
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
MPEG-1 supportNoNoNoNoNoYes
+
Container supportMPEG
{{Glossary("RTP")}} / WebRTC compatibleNo
Supporting/Maintaining organizationMPEG
Specificationhttps://www.iso.org/standard/22411.html
LicensingProprietary; however, all patents have expired, so MPEG-1 may be used freely
+ +

MPEG-2 Part 2 Video

+ +

MPEG-2 Part 2 is the video format defined by the MPEG-2 specification, and is also occasionally referred to by its {{Glossary("ITU")}} designation, H.262. It is very similar to MPEG-1 video—in fact, any MPEG-2 player can automatically handle MPEG-1 without any special work—except it has been expanded to support higher bit rates and enhanced encoding techniques.

+ +

The goal was to allow MPEG-2 to compress standard definition television, so interlaced video is also supported. The standard definition compression rate and the quality of the resulting video met needs well enough that MPEG-2 is the primary video codec used for DVD video media.

+ +

MPEG-2 has several profiles available with different capabilities. Each profile is then available four levels, each of which increases attributes of the video, such as frame rate, resolution, bit rate, and so forth. Most profiles use Y'CbCr with 4:2:0 chroma subsampling, but more advanced profiles support 4:2:2 as well. In addition, there are four levels, each of which offers  support for larger frame dimensions and bit rates. For example, the {{interwiki("wikipedia", "ATSC standards", "ATSC")}} specification for television used in North America supports MPEG-2 video in high definition using the Main Profile at High Level, allowing 4:2:0 video at both 1920 x 1080 (30 FPS) and 1280 x 720 (60 FPS), at a maximum bit rate of 80 Mbps.

+ +

However, few web browsers support MPEG-2 without the support of a plugin, and with plugin use deprecated in web browsers, these are generally no longer available. This makes MPEG-2 a poor choice for use in web sites and web applications.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Supported bit ratesUp to 100 Mbps; varies by level and profile
Supported frame rates + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Abbr.Level nameFrame rates supported
LLLow Level23.9, 24, 25, 29.97, 30
MLMain Level23.976, 24, 25, 29.97, 30
H-14High 144023.976, 24, 26, 29.97, 30, 50, 59.94, 60
HLHigh Level23.976, 24, 26, 29.97, 30, 50, 59.94, 60
+
CompressionLossy DCT-based algorithm
Supported frame sizes + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Abbr.Level nameMaximum frame size
LLLow Level352 x 288 pixels
MLMain Level720 x 576 pixels
H-14High 14401440 x 1152 pixels
HLHigh Level1920 x 1152 pixels
+
Supported color modesY'CbCr with 4:2:0 chroma subsampling in most profiles; the "High" and "4:2:2" profiles support 4:2:2 chroma subsampling as well.
HDR supportNo
Variable Frame Rate (VFR) supportNo
Browser compatibility + + + + + + + + + + + + + + + + + + + + + +
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
MPEG-2 supportNoNoNoNoNoYes
+
Container supportMPEG, MPEG-TS (MPEG Transport Stream), MP4, QuickTime
{{Glossary("RTP")}} / WebRTC compatibleNo
Supporting/Maintaining organizationMPEG / ITU
Specificationhttps://www.itu.int/rec/T-REC-H.262
+ https://www.iso.org/standard/61152.html
LicensingProprietary; all patents have expired worldwide with the exception of in Malaysia and the Philippines as of April 1, 2019, so MPEG-2 can be used freely outside those two countries. Patents are licensed by MPEG LA.
+ +

Theora

+ +

{{interwiki("wikipedia", "Theora")}}, developed by Xiph.org, is an open and free video codec which may be used without royalties  or licensing. Theora is comparable in quality and compression rates to MPEG-4 Part 2 Visual and AVC, making it a very good if not top-of-the-line choice for video encoding. But its status as being free from any licensing concerns and its relatively low CPU resource requirements make it a popular choice for many software and web projects. The low CPU impact is particularly useful since there are no hardware decoders available for Theora.

+ +

Theora was originally based upon the VC3 codec by On2 Technologies. The codec and its specification were released under the LGPL license and entrusted to Xiph.org, which then developed it into the Theora standard.

+ +

One drawback to Theora is that it only supports 8 bits per color component, with no option to use 10 or more in order to avoid color banding. That said, 8 bits per component is still the most commonly-used color format in use today, so this is only a minor inconvenience in most cases. Also, Theora can only be used in an Ogg container. The biggest drawback of all, however, is that it is not supported by Safari, leaving Theora unavailable not only on macOS but on all those millions and millions of iPhones and iPads.

+ +

The Theora Cookbook offers additional details about Theora as well as the Ogg container format it is used within.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Supported bit ratesUp to 2 Gbps
Supported frame ratesArbitrary; any non-zero value is supported. The frame rate is specified as a 32-bit numerator and a 32-bit denominator, to allow for non-integer frame rates.
CompressionLossy DCT-based algorithm
Supported frame sizesAny combination of width and height up to 1,048,560 x 1,048,560 pixels
Supported color modesY'CbCr with 4:2:0, 4:2:2, and 4:4:4 chroma subsampling at 8 bits per component
HDR supportNo
Variable Frame Rate (VFR) supportYes[1]
Browser compatibility + + + + + + + + + + + + + + + + + + + + + +
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
Theora support3Yes[2]3.5No10.5No
+
Container supportOgg
{{Glossary("RTP")}} / WebRTC compatibleNo
Supporting/Maintaining organizationXiph.org
Specificationhttps://www.theora.org/doc/
LicensingOpen and free of royalties and any other licensing requirements
+ +

[1] While Theora doesn't support Variable Frame Rate (VFR) within a single stream, multiple streams can be chained together within a single file, and each of those can have its own frame rate, thus allowing what is essentially VFR. However, this is impractical if the frame rate needs to change frequently.

+ +

[2] Edge supports Theora with the optional Web Media Extensions add-on.

+ +

VP8

+ +

The Video Processor 8 (VP8) codec was initially created by On2 Technologies. Following their purchase of On2, Google released VP8 as an open and royalty-free video format under a promise not to enforce the relevant patents. In terms of quality and compression rate, VP8 is comparable to {{anch("AVC")}}.

+ +

If supported by the browser, VP8 allows video with an alpha channel, allowing the video to play with the background able to be seen through the video to a degree specified by each pixel's alpha component.

+ +

There is good browser support for VP8 in HTML content, especially within WebM files. This makes VP8 a good candidate for your content, although VP9 is an even better choice if available to you. Web browsers are required to support VP8 for WebRTC, but not all browsers that do so also support it in HTML audio and video elements.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Supported bit ratesArbitrary; no maximum unless level-based limitations are enforced
Supported frame ratesArbitrary
CompressionLossy DCT-based algorithm
Supported frame sizesUp to 16,384 x 16,384 pixels
Supported color modesY'CbCr with 4:2:0 chroma subsampling at 8 bits per component
HDR supportNo
Variable Frame Rate (VFR) supportYes
Browser compatibility + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
VP8 support2514[1]491612.1[2]
MSE compatibilityYes3
+
Container support3GP, Ogg, WebM
{{Glossary("RTP")}} / WebRTC compatibleYes; VP8 is one of the spec-required codecs for WebRTC
Supporting/Maintaining organizationGoogle
Specification{{RFC(6386)}}
LicensingOpen and free of royalties and any other licensing requirements
+ +

[1] Edge support for VP8 requires the use of Media Source Extensions.

+ +

[2] Safari only supports VP8 in WebRTC connections.

+ +

[3] Firefox only supports VP8 in MSE when no H.264 hardware decoder is available. Use {{domxref("MediaSource.isTypeSupported()")}} to check for availability.

+ +

VP9

+ +

Video Processor 9 (VP9) is the successor to the older VP8 standard developed by Google. Like VP8, VP9 is entirely open and royalty-free. Its encoding and decoding performance is comparable to or slightly faster than that of AVC, but with better quality. VP9's encoded video quality is comparable to that of HEVC at similar bit rates.

+ +

VP9's main profile supports only 8-bit color depth at 4:2:0 chroma subsampling levels, but its profiles include support for deeper color and the full range of chroma subsampling modes. It supports several HDR imiplementations, and offers substantial freedom in selecting frame rates, aspect ratios, and frame sizes.

+ +

VP9 is widely supported by browsers, and hardware implementations of the codec are fairly common. VP9 is one of the two video codecs mandated by WebM (the other being {{anch("VP8")}}). Of note, however, is that Safari supports neither WebM nor VP9, so if you choose to use VP9, be sure to offer a fallback format such as AVC or HEVC for iPhone, iPad, and Mac users.

+ +

Aside from the lack of Safari support, VP9 is a good choice if you are able to use a WebM container and are able to provide a fallback video in a format such as AVC or HEVC for Safari users. This is especially true if you wish to use an open codec rather than a proprietary one. If you can't provide a fallback and aren't willing to sacrifice Safari compatibility, VP9 in WebM is a good option. Otherwise, you should probably consider a different codec.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Supported bit ratesArbitrary; no maximum unless level-based limitations are enforced
Supported frame ratesArbitrary
CompressionLossy DCT-based algorithm
Supported frame sizesUp to 65,536 x 65,536 pixels
Supported color modes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ProfileColor depthsChroma subsampling
Profile 084:2:0
Profile 184:2:0, 4:2:2, and 4:4:4
Profile 210 to 124:2:0
Profile 310 to 124:2:0, 4:2:2, and f:4:4
+ +

Color spaces supported: {{interwiki("wikipedia", "Rec. 601")}}, {{interwiki("wikipedia", "Rec. 709")}}, {{interwiki("wikipedia", "Rec. 2020")}}, {{interwiki("wikipedia", "SMPTE C")}}, SMPTE-240M (obsolete; replaced by Rec. 709), and {{interwiki("wikipedia", "sRGB")}}.

+
HDR supportYes; HDR10+, HLG, and PQ
Variable Frame Rate (VFR) supportYes
Browser compatibility + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
VP9 support291428No10.6No
MSE compatibilityYes1
+
Container supportMP4, Ogg, WebM
{{Glossary("RTP")}} / WebRTC compatibleYes
Supporting/Maintaining organizationGoogle
Specificationhttps://www.webmproject.org/vp9/
LicensingOpen and free of royalties and any other licensing requirements
+ +

[1] Firefox only supports VP8 in MSE when no H.264 hardware decoder is available. Use {{domxref("MediaSource.isTypeSupported()")}} to check for availability.

+ +

Choosing a video codec

+ +

The decision as to which codec or codecs to use begins with a series of questions to prepare yourself:

+ + + +

In the sections below, we offer recommended codec selections for specific use cases. For each use case, you'll find up to two reccommendations. If the codec which is considered best for the use case is proprietary or may require royalty payments, then two options are provided: first, an open and royalty-free option, followed by the proprietary one.

+ +

If you are only able to offer a single version of each video, you can choose the format that's most appropriate for your needs.The first one is recommended as being a good combnination of quality, performance, and compatibility. The second option will be the most broadly compatible choice, at the expense of some amount of quality, preformance, and/or size.

+ +

Recommendations for everyday videos

+ +

First, let's look at the best options for videos presented on a typical web site such as a blog, informational site, small business web site where videos are used to demonstrate products (but not where the videos themselves are a product), and so forth.

+ +
    +
  1. +

    A WebM container using the {{anch("VP8")}} codec for video and the Opus codec for audio. These are all open, royalty-free formats which are generally well-supported, although only in quite recent browsers, which is why a fallback is a good idea.

    + +
    <video controls src="filename.webm"></video>
    +
    +
  2. +
  3. +

    An MP4 container and the {{anch("AVC")}} (H.264) video codec, ideally with AAC as your audio codec. This is because the MP4 container with AVC and AAC codecs within is a broadly-supported combination—by every major browser, in fact—and the quality is typically good for most use cases. Make sure you verify your compliance with the license requirements, however.

    + +
    <video controls>
    +  <source type="video/webm"
    +          src="filename.webm">
    +  <source type="video/mp4"
    +          src="filename.mp4">
    +</video>
    +
    +
  4. +
+ +
+

Note: Keep in mind that the {{HTMLElement("<video>")}} element requires a closing </video> tag, whether or not you have any {{HTMLElement("source")}} elements inside it.

+
+ +

Recommendations for high-quality video presentation

+ +

If your mission is to present video at the highest possible quality, you will probably benefit from offering as many formats as possible, as the codecs capable of the best quality tend also to be the newest, and thus the most likely to have gaps in browser compatibility.

+ +
    +
  1. +

    A WebM container using AV1 for video and Opus for audio. If you're able to use the High or Professional profile when encoding AV1, at a high level like 6.3, you can get very high bit rates at 4K or 8K resolution, while maintaining excellent video quality. Encoding your audio using Opus's Fullband profile at a 48 kHz sample rate maximizes the audio bandwidth captured, capturing nearly the entire frequency range that's within human hearing.

    + +
    <video controls src="filename.webm"></video>
    +
    +
  2. +
  3. +

    An MP4 container using the {{anch("HEVC")}} codec using one of the advanced Main profiles, such as Main 4:2:2 with 10 or 12 bits of color depth, or even the Main 4:4:4 profile at up to 16 bits per component. At a high bit rate, this provides excellent graphics quality with remarkable color reproduction.  In addition, you can optionally include HDR metadata to provide high dynamic range video. For audio, use the AAC codec at a high sample rate (at least 48 kHz but ideally 96kHz) and encoded with complex encoding rather than fast encoding.

    + +
    <video controls>
    +  <source type="video/webm"
    +          src="filename.webm">
    +  <source type="video/mp4"
    +          src="filename.mp4">
    +</video>
    +
    +
  4. +
+ +

Recommendations for archival, editing, or remixing

+ +

There are not currently any lossless—or even near-lossless—video codecs generally available in web browsers. The reason for this is simple: video is huge. Lossless compression is by definition less effective than lossy compression. For example, uncompressed 1080p video (1920 by 1080 pixels) with 4:2:0 chroma subsampling needs at least 1.5 Gbps. Using lossless compression such as FFV1 (which is not supported by web browsers) could perhaps reduce that to somewhere around 600 Mbps, depending on the content. That's still a huge number of bits to pump through a connection every second, and is not currently practical for any real-world use.

+ +

This is the case even though some of the lossy codecs have a lossless mode available; the lossless modes are not implemented in any current web browsers. The best you can do is to select a high-quality codec that uses lossy compression and configure it to perform as little compression as possible. One way to do this is to configure the codec to use "fast" compression, which inherently means less compression is achieved.

+ +

Preparing video externally

+ +

To prepare video for archival purposes from outside your web site or app, use a utility that performs compression on the original uncompressed video data. For example, the free x264 utility can be used to encode video in {{anch("AVC")}} format using a very high bit rate:

+ +
x264 --crf 18 -preset ultrafast --output outfilename.mp4 infile
+ +

While other codecs may have better best-case quality levels when compressing the video by a significant margin, their encoders tend to be slow enough that the nearly-lossless encoding you get with this compression is vastly faster at about the same overall quality level.

+ +

Recording video

+ +

Given the constraints on how close to lossless you can get, you might consider using {{anch("AVC")}} or {{anch("AV1")}}. For example, if you're using the MediaStream Recording API to record video, you might use code like the following when creating your {{domxref("MediaRecorder")}} object:

+ +
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);
+ +

This example creates a MediaRecorder configured to record {{anch("AV1")}} video using BT.2100 HDR in 12-bit color with 4:4:4 chroma subsampling and FLAC for lossless audio. The resulting file will use a bit rate of no more than 800 Mbps shared between the video and audio tracks. You will likely need to adjust these values depending on hardware performance, your requirements, and the specific codecs you choose to use. This bit rate is obviously not realistic for network transmission and would likely only be used locally.

+ +

Breaking down the value of the codecs parameter into its dot-delineated properties, we see the following:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ValueDesccription
av01The four-character code (4CC) designation identifying the {{anch("AV1")}} codec.
2The profile. A value of 2 indicates the Professional profile. A value of 1 is the High profile, while a value of 0 would specify the Main profile.
19HThe level and tier. This value comes from the table in section A.3 of the AV1 specification, and indicates the high tier of Level 6.3.
12The color depth. This indicates 12 bits per component. Other possible values are 8 and 10, but 12 is the highest-accuracy color representation available in AV1.
0The monochrome mode flag. If 1, then no chroma planes would be recorded, and all data should be structly luma data, resulting in a greyscale image. We've specified 0 because we want color.
000The chroma subsampling mode, taken from section 6.4.2 in the AV1 specification. A value of 000, combined with the monochrome mode value 0, indicates that we want 4:4:4 chroma subsampling, or no loss of color data.
09The color primaries to use. This value comes from section 6.4.2 in the AV1 specification; 9 indicates that we want to use BT.2020 color, which is used for HDR.
16The transfer characteristics to use. This comes from section 6.4.2 as well; 16 indicates that we want to use the characteristics for BT.2100 PQ color.
09The matrix coefficents to use, from the section 6.4.2 again. A value of 9 specifies that we want to use BT.2020 with variable luminance; this is also known as BT.2010 YbCbCr.
1The video "full range" flag. A value of 1 indicates that we want the full color range to be used.
+ +

The documentation for your codec choices will probably offer information you'll use when constructing your codecs parameter.

+ +

See also

+ + diff --git "a/files/zh-cn/web/media/formats/\350\247\206\351\242\221\347\274\226\350\247\243\347\240\201\345\231\250/index.html" "b/files/zh-cn/web/media/formats/\350\247\206\351\242\221\347\274\226\350\247\243\347\240\201\345\231\250/index.html" deleted file mode 100644 index d299975762..0000000000 --- "a/files/zh-cn/web/media/formats/\350\247\206\351\242\221\347\274\226\350\247\243\347\240\201\345\231\250/index.html" +++ /dev/null @@ -1,1673 +0,0 @@ ---- -title: 网络视频编解码器指南 -slug: Web/Media/Formats/视频编解码器 -translation_of: Web/Media/Formats/Video_codecs ---- -
{{QuickLinksWithSubpages("/en-US/docs/Web/Media")}}
- -

未经压缩的视频的数据量太大了,我们有必要进行很多压缩处理来存储视频,就更不用说通过网络传输视频的时候了。想象一下我们需要多少数据来存储未经压缩的视频:

- - - -

不仅仅是需要的存储空间很大的问题,以 249MB 每秒的速度传输这样的未压缩的视频所需要的网络带宽也很大(不包括音频和开销)。这就是为什么我们需要视频编解码器。就像音频编解码器对声音数据所做的处理一样,视频编解码器会压缩视频数据并将其编码为一种格式,以后我们可以对其进行解码,播放或者编辑。

- -

大多数的视频编解码器是有损的(解码后的视频与原来的视频不完全匹配)。一些细节可能会丢失,丢失的数量取决于编解码器和它的配置方式。通常来说,压缩程度越高,细节丢失的越多,视频失真更严重。虽然现在也有一些无损编解码器,但是通常都是用于存档和存储在本地来进行本地回放的,而不是在网络上使用。

- -

本指南介绍了一些你可能遇到或者考虑去使用的网络视频编解码器的功能以及一些兼容性和实用性问题。并且帮助您为项目视频选择正确的编解码器提供一些建议。

- -

通用编解码器

- -

以下视频编解码器是网上最常用的视频编解码器。每个编解码器都列出了它们可以支持的文件类型。每个编解码器都提供了一个指向下文相关部分详细内容的快捷链接,包含一些您可能需要了解的特定功能和兼容性问题。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
编解码器名称 (简称)编解码器全称支持文件类型
AV1AOMedia Video 1MP4, WebM
AVC (H.264)Advanced Video Coding3GP, MP4, WebM
H.263H.263 Video3GP
HEVC (H.265)High Efficiency Video CodingMP4
{{anch("MP4V-ES")}}MPEG-4 Video Elemental Stream3GP, MP4
{{anch("MPEG-1")}}MPEG-1 Part 2 VisualMPEG, QuickTime
{{anch("MPEG-2")}}MPEG-2 Part 2 VisualMP4, MPEG, QuickTime
TheoraTheoraOgg
VP8Video Processor 83GP, Ogg, WebM
VP9Video Processor 9MP4, Ogg, WebM
- -

影响编码视频的因素

- -

和任何编码器一样,有两个会影响到编码视频大小和质量的因素:源视频的格式和内容,以及在对视频进行编码时候使用的编解码器的特性和配置。

- -

最简单的原则是:如果要让编码视频看起来更像原始的未压缩过的视频,那么通常得到的视频会更大。因此我们始终要在尺寸和质量之间进行权衡。在某些情况下,我们会为了降低数据大小而接受质量的损失。但是其他时候,我们不能接受质量损失,所以我们必须接受会导致文件相应增大的编码器配置。

- -

源视频格式对编码输出的影响

- -

源视频格式影响编码输出的程度取决于编解码器及其工作方式。如果编解码器将视频媒体转换为内部像素的格式,或者使用使用简单像素以外的方法表示图像,那么原始图像的格式对编码输出没有什么影响。但是,诸如帧频和分辨率之类始终会对媒体视频的输出大小产生影响。

- -

Additionally, all codecs have their strengths and weaknesses. Some have trouble with specific kinds of shapes and patterns, or aren't good at replicating sharp edges, or tend to lose detail in dark areas, or any number of possibilities. It all depends on the underlying algorithms and mathematics.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The potential effect of source video format and contents on the encoded video quality and size
Feature对质量的影响对尺寸的影响
Color depth (bit depth)颜色位深越高,视频中颜色保真度质量就越高。除此之外,在图像饱和部分(颜色纯而强烈的,例如明亮纯红色[rgba(255,0,0,1)),低于每分量10色深(10bits色彩)允许条带化,其中,如果没有可见色阶跃就无法表示渐变。Depending on the codec, higher color depths may result in larger compressed file sizes. The determining factor is what internal storage format is used for the compressed data.
Frame ratePrimarily affects the perceived smoothness of the motion in the image. To a point, the higher the frame rate, the smoother and more realistic the motion will appear. Eventually the point of diminishing returns is reached. See {{anch("Frame rate")}} below for details.Assuming the frame rate is not reduced during encoding, higher frame rates cause larger compressed video sizes.
MotionCompression of video typically works by comparing frames, finding where they differ, and constructing records containing enough information to update the previous frame to approximate the appearance of the following frame. The more successive frames differ from one another, the larger these differences are, and the less effective the compression is at avoiding the introduction of artifacts into the compressed video.The complexity introduced by motion results in larger intermediate frames due to the higher number of differences between frames). For this and other reasons, the more motion there is in a video, the larger the output file will typically be.
NoisePicture noise (such as film grain effects, dust, or other grittiness to the image) introduces variability. Variability generally makes compression more difficult, resulting in more lost quality due to the need to drop details to achieve the same level of compression.The more variability—such as noise—there is in the image, the more complex the compression process and the less success the algorithm is likely to have compressing the image to the same degree. Unless you configure the encoder in a way that ignores some or all of the variations caused by noise, the compressed video will be larger.
Resolution (width and height)Higher resolution video, presented in the same screen size, will typically be able to more accurately portray the original scene, barring effects introduced during compression.The higher the resolution of a video, the larger it gets. This plays a key role in the final size of the video.
- -

The degree to which these affect the resulting encoded video will vary depending on the precise details of the situation, including which encoder you use and how it's configured. In addition to general codec options, the encoder could be configured to reduce the frame rate, to clean up noise, and/or to reduce the overall resolution of the video during encoding.

- -

Effect of codec configuration on encoded output

- -

The algorithms used do encode video typically use one or more of a number of general techniques to perform their encoding. Generally speaking, any configuration option that is intended to reduce the output size of the video will probably have a negative impact on the overall quality of the video, or will introduce certain types of artifacts into the video. It's also possible to select a lossless form of encoding, which will result in a much larger encoded file but with perfect reproduction of the original video upon decoding.

- -

In addition, each encoder utility may have variations in how they process the source video, resulting in differences in the output quality and/or size.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Video encoder configuration effects on quality and size
FeatureEffect on qualityEffect on size
Lossless compressionNo loss of qualityLossless compression cannot reduce the overall video size nearly as much as lossy compression; the resulting files are likely to still be too large for general usage.
Lossy compressionTo some degree, artifacts and other forms of quality degradation wil occur, depending on the specific codec and how much compression is being appliedThe more the encoded video is allowed to deviate from the source, the easier it is to accomplish higher compression rates
Quality settingThe higher the quality configuration, the more like the original media the encoded video will lookIn general, higher quality settings will result in larger encoded video files; the degree to which this is true varies depending on the codec
Bit rateQuality generally improves with higher bit ratesHigher bit rates inherently lead to larger output files
- -

The options available when encoding video, and the values to be assigned to those options, will vary not only from one codec to another but depending on the encoding software you use. The documentation included with your encoding software will help you to understand the specific impact of these options on the encoded video.

- -

Compression artifacts

- -

Artifacts are side effects of a lossy encoding process in which the lost or rearranged data results in visibly negative effects. Once an artifact has appeared, it may linger for a while, because of how video is displayed. Each frame of video is presented by applying a set of changes to the currently-visible frame. This means that any errors or artifacts will compound over time, resulting in glitches or otherwise strange or unexpected deviations in the image that linger for a time.

- -

To resolve this, and to improve seek time through the video data, periodic key frames (also known as intra-frames or i-frames) are placed into the video file. The key frames are full frames, which are used to repair any damage or artifact residue that's currently visible.

- -

Aliasing

- -

Aliasing is a general term for anything that upon being reconstructed from the encoded data does not look the same as it did before compression. There are many forms of aliasing; the most common ones you may see include:

- - - - - - - - - - - - - - - - -
-

Moiré patterns

- -

A {{interwiki("Moiré pattern")}} is a large-scale spatial interference pattern produced when a pattern in the source image and the manner in which the encoder operates are slightly out of alignment spatially. The artifacts generated by the encoder then introduce strange, swirling effects in the source image's pattern upon decoding.

-
-

Staircase effect

- -

The staircase effect is a spatial artifact that occurs when diagonal straight or curved edges that should be smooth take on a jagged appearance, looking somewhat like a set of stair steps. This is the effect that is being reduced by "anti-aliasing" filters.

-
-

Wagon-wheel effect

- -

The wagon-wheel effect (or {{interwiki("wikipedia", "stroboscopic effect")}}) is the visual effect that's commonly seen in film, in which a turning wheel appears to rotate at the wrong speed, or even in reverse, due to an interaction between the frame rate and the compression algorithm. The same effect can occur with any repeating pattern that moves, such as the ties on a railway line, posts along the side of a road, and so forth. This is a temporal (time-based) aliasing issue; the speed of the rotation interferes with the frequency of the sampling performed during compression or encoding.

-
- -

Color edging

- -

Color edging is a type of visual artifact that presents as spurious colors introduced along the edges of colored objects within the scene. These colors have no intentional color relationship to the contents of the frame.

- -

 Loss of sharpness

- -

The act of removing data in the process of encoding video requires that some details be lost. If enough compression is applied, parts or potentially all of the image could lose sharpness, resulting in a slightly fuzzy or hazy appearance.

- -

Lost sharpness can make text in the image difficult to read, as text—especially small text—is very detail-oriented content, where minor alterations can significantly impact legibility.

- -

Ringing

- -

Lossy compression algorithms can introduce {{interwiki("wikipedia", "ringing artifacts", "ringing")}}, an effect where areas outside an object are contaminated with colored pixels generated by the compression algorithm. This happens when an algorithm that uses blocks that span across a sharp boundary between an object and its background. This is particularly common at higher compression levels.

- -

Example of the ringing effect

- -

Note the blue and pink fringes around the edges of the star above (as well as the stepping and other significant compression artifacts). Those fringes are the ringing effect. Ringing is similar in some respects to {{anch("Mosquito noise", "mosquito noise")}}, except that while the ringing effect is more or less steady and unchanging, mosquito noise shimmers and moves.

- -

RInging is another type of artifact that can make it particularly difficult to read text contained in your images.

- -

Posterizing

- -

Posterization occurs when the compression results in the loss of color detail in gradients. Instead of smooth transitions through the various colors in a region, the image becomes blocky, with blobs of color that approximate the original appearance of the image.

- -

- -

Note the blockiness of the colors in the plumage of the bald eagle in the photo above (and the snowy owl in the background). The details of the feathers is largely lost due to these posterization artifacts.

- -

Contouring

- -

Contouring or color banding is a specific form of posterization in which the color blocks form bands or stripes in the image. This occurs when the video is encoded with too coarse a quantization configuration. As a result, the video's contents show a "layered" look, where instead of smooth gradients and transitions, the transitions from color to color are abrupt, causing strips of color to appear.

- -

Example of an image whose compression has introduced contouring

- -

In the example image above, note how the sky has bands of different shades of blue, instead of being a consistent gradient as the sky color changes toward the horizon. This is the contouring effect.

- -

Mosquito noise

- -

Mosquito noise is a temporal artifact which presents as noise or edge busyness that appears as a flickering haziness or shimmering that roughly follows outside the edges of objects with hard edges or sharp transitions between foreground objects and the background. The effect can be similar in appearance to {{anch("Ringing", "ringing")}}.

- -

- -

The photo above shows mosquito noise in a number of places, including in the sky surrounding the bridge. In the upper-right corner, an inset shows a close-up of a portion of the image that exhibits mosquito noise.

- -

Mosquito noise artifacts are most commonly found in MPEG video, but can occur whenever a discrete cosine transform (DCT) algorithm is used; this includes, for example, JPEG still images.

- -

Motion compensation block boundary artifacts

- -

Compression of video generally works by comparing two frames and recording the differences between them, one frame after another, until the end of the video. This technique works well when the camera is fixed in place, or the objects in the frame are relatively stationary, but if there is a great deal of motion in the frame, the number of differences between frames can be so great that compression doesn't do any good.

- -

{{interwiki("wikipedia", "Motion compensation")}} is a technique that looks for motion (either of the camera or of objects in the frame of view) and determines how many pixels the moving object has moved in each direction. Then that shift is stored, along with a description of the pixels that have moved that can't be described just by that shift. In essence, the encoder finds the moving objects, then builds an internal frame of sorts that looks like the original but with all the objects translated to their new locations. In theory, this approximates the new frame's appearance. Then, to finish the job, the remaining differences are found, then the set of object shifts and the set of pixel differences are stored in the data representing the new frame. This object that describes the shift and the pixel differences is called a residual frame.

- - - - - - - - - - - - - - - - - - - - - - - - -
Original frameInter-frame differencesDifference after motion compensation
Original frame of videoDifferences between the frames after shifting two pixels right
The first full frame as seen by the viewer.Here, only the differences between the first frame and the following frame are seen. Everything else is black. Looking closely, we can see that the majority of these differences come from a horizontal camera move, making this a good candidate for motion compensation.To minimize the number of pixels that are different, here we take into account the panning of the camera by first shifting the first frame to the right by two pixels, then by taking the difference. This compensates for the panning of the camera, allowing for more overlap between the two frames.
Images from Wikipedia
- -

There are two general types of motion compensation: global motion compensation and block motion compensation. Global motion compensation generally adjusts for camera movements such as tracking, dolly movements, panning, tilting, rolling, and up and down movements. Block motion compensation handles localized changes, looking for smaller sections of the image that can be encoded using motion compensation. These blocks are normally of a fixed size, in a grid, but there are forms of motion compensation that allow for variable block sizes, and even for blocks to overlap.

- -

There are, however, artifacts that can occur due to motion compensation. These occur along block borders, in the form of sharp edges that produce false ringing and other edge effects. These are due to the mathematics involved in the coding of the residual frames, and can be easily noticed before being repaired by the next key frame.

- -

Reduced frame size

- -

In certain situations, it may be useful to reduce the video's dimensions in order to improve the final size of the video file. While the immediate loss of size or smoothness of playback may be a negative factor, careful decision-making can result in a good end result. If a 1080p video is reduced to 720p prior to encoding, the resulting video can be much smaller while having much higher visual quality; even after scaling back up during playback, the result may be better than encoding the original video at full size and accepting the quality hit needed to meet your size requirements.

- -

Reduced frame rate

- -

Similarly, you can remove frames from the video entirely and decrease the frame rate to compensate. This has two benefits: it makes the overall video smaller, and that smaller size allows motion compensation to accomplish even more for you. For exmaple, instead of computing motion differences for two frames that are two pixels apart due to inter-frame motion, skipping every other frame could lead to computing a difference that comes out to four pixels of movement. This lets the overall movement of the camera be represented by fewer residual frames.

- -

The absolute minimum frame rate that a video can be before its contents are no longer perceived as motion by the human eye is about 12 frames per second. Less than that, and the video becomes a series of still images. Motion picture film is typically 24 frames per second, while standard definition television is about 30 frames per second (slightly less, but close enough) and high definition television is between 24 and 60 frames per second. Anything from 24 FPS upward will generally be seen as satisfactorily smooth; 30 or 60 FPS is an ideal target, depending on your needs.

- -

In the end, the decisions about what sacrifices you're able to make are entirely up to you and/or your design team.

- -

Codec details

- -

AV1

- -

The AOMedia Video 1 (AV1) codec is an open format designed by the Alliance for Open Media specifically for internet video. It achieves higher data compression rates than {{anch("VP9")}} and {{anch("HEVC", "H.265/HEVC")}}, and as much as 50% higher rates than AVC. AV1 is fully royalty-free and is designed for use by both the {{HTMLElement("video")}} element and by WebRTC.

- -

AV1 currently offers three profiles: main, high, and professional with increasing support for color depths and chroma subsampling. In addition, a series of levels are specified, each defining limits on a range of attributes of the video. These attributes include frame dimensions, image area in pixels, display and decode rates, average and maximum bit rates, and limits on the number of tiles and tile columns used in the encoding/decoding process.

- -

For example, level AV1 level 2.0 offers a maximum frame width of 2048 pixels and a maximum height of 1152 pixels, but its maximum frame size in pixels is 147,456, so you can't actually have a 2048x1152 video at level 2.0. It's worth noting, however, that at least for Firefox and Chrome, the levels are actually ignored at this time when performing software decoding, and the decoder just does the best it can to play the video given the settings provided. For compatibility's sake going forward, however, you should stay within the limits of the level you choose.

- -

The primary drawback to AV1 at this time is that it is very new, and support is still in the process of being integrated into most browsers. Additionally, encoders and decoders are still being optimized for performance, and hardware encoders and decoders are still mostly in development rather than production. For this reason, encoding a video into AV1 format takes a very long time, since all the work is done in software.

- -

For the time being, because of these factors, AV1 is not yet ready to be your first choice of video codec, but you should watch for it to be ready to use in the future.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Supported bit ratesVaries depending on the video's level; theoretical maximum reaches 800 Mbps at level 6.3[2]
Supported frame ratesVaries by level; for example, level 2.0 has a maximum of 30 FPS while level 6.3 can reach 120 FPS
CompressionLossy DCT-based algorithm
Supported frame sizes8 x 8 pixels to 65,535 x 65535 pixels with each dimension allowed to take any value between these
Supported color modes - - - - - - - - - - - - - - - - - - - - - - - - - -
ProfileColor depthsChroma subsampling
Main8 or 104:0:0 (greyscale) or 4:2:0
High8 or 104:0:0 (greyscale), 4:2:0, or 4:4:4
Professional8, 10, or 124:0:0 (greyscale), 4:2:0, 4:2:2, or 4:4:4
-
HDR supportYes
Variable Frame Rate (VFR) supportYes
Browser compatibility - - - - - - - - - - - - - - - - - - - - - -
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
AV1 support707567No57No
-
Container supportISOBMFF[1], MPEG-TS, MP4, WebM
{{Glossary("RTP")}} / WebRTC compatibleYes
Supporting/Maintaining organizationAlliance for Open Media
Specificationhttps://aomediacodec.github.io/av1-spec/av1-spec.pdf
LicensingRoyalty-free, open standard
- -

[1] {{interwiki("wikipedia", "ISO Base Media File Format")}}

- -

[2] See the AV1 specification's tables of levels, which describe the maximum resolutions and rates at each level.

- -

AVC (H.264)

- -

The MPEG-4 specification suite's Advanced Video Coding (AVC) standard is specified by the identical ITU H.264 specification and the MPEG-4 Part 10 specification. It's a motion compensation based codec that is widely used today for all sorts of media, including broadcast television, {{Glossary("RTP")}} videoconferencing, and as the video codec for Blu-Ray discs.

- -

AVC is highly flexible, with a number of profiles with varying capabilities; for example, the Constrained Baseline Profile is designed for use in videoconferencing and mobile scenarios, using less bandwidth than the Main Profile (which is used for standard definition digital TV in some regions) or the High Profile (used for Blu-Ray Disc video). Most of the profiles use 8-bit color components and 4:2:0 chroma subsampling; The High 10 Profile adds support for 10-bit color, and advanced forms of High 10 add 4:2:2 and 4:4:4 chroma subsampling.

- -

AVC also has special features such as support for multiple views of the same scene (Multiview Video Coding), which allows, among other things, the production of stereoscopic video.

- -

AVC is a proprietary format, however, and numerous patents are owned by multiple parties regarding its technologies. Commercial use of AVC media requires a license, though the MPEG LA patent pool does not require license fees for streaming internet video in AVC format as long as the video is free for end users.

- -

Non-web browser implementations of WebRTC (any implementation which doesn't include the JavaScript APIs) are required to support AVC as a codec in WebRTC calls. While web browsers are not required to do so, some do.

- -

In HTML content for web browsers, AVC is broadly compatible and many platforms support hardware encoding and decoding of AVC media. However, be aware of its licensing requirements before choosing to use AVC in your project!

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Supported bit ratesVaries by level
Supported frame ratesVaries by level; up to 300 FPS is possible
CompressionLossy DCT-based algorithm, though it's possible to create lossless macroblocks within the image
Supported frame sizesUp to 8,192 x 4,320 pixels
Supported color modes -

Some of the more common or interesting profiles:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ProfileColor depthsChroma subsampling
Constrained Baseline (CBP)84:2:0
Baseline (BP)84:2:0
Extended (XP)84:2:0
Main (MP)84:2:0
High (HiP)84:0:0 (greyscale) and 4:2:0
Progressive High (ProHiP)84:0:0 (greyscale) and 4:2:0
High 10 (Hi10P)8 to 104:0:0 (greyscale) and 4:2:0
High 4:2:2 (Hi422P)8 to 104:0:0 (greyscale), 4:2:0, and 4:2:2
High 4:4:4 Predictive8 to 144:0:0 (greyscale), 4:2:0, 4:2:2, and 4:4:4
-
HDR supportYes; {{interwiki("wikipedia", "Hybrid Log-Gamma")}} or Advanced HDR/SL-HDR; both are part of ATSC
Variable Frame Rate (VFR) supportYes
Browser compatibility - - - - - - - - - - - - - - - - - - - - - -
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
AVC/H.265 support41235[1]9253.2
-
Container support3GP, MP4, WebM
{{Glossary("RTP")}} / WebRTC compatibleYes
Supporting/Maintaining organizationMPEG / ITU
Specificationhttps://mpeg.chiariglione.org/standards/mpeg-4/advanced-video-coding
- https://www.itu.int/rec/T-REC-H.264
LicensingProprietary with numerous patents. Commercial use requires a license. Note that multiple patent pools may apply.
- -

[1] Firefox support for AVC is dependent upon the operating system's built-in or preinstalled codecs for AVC and its container in order to avoid patent concerns.

- -

H.263

- -

ITU's H.263 codec was designed primarily for use in low-bandwidth situations. In particular, its focus is for video conferencing on PSTN (Public Switched Telephone Networks), {{Glossary("RTSP")}}, and SIP (IP-based videoconferencing) systems. Despite being optimized for low-bandwidth networks, it is fairly CPU intensive and may not perform adequately on lower-end computers. The data format is similar to that of MPEG-4 Part 2.

- -

H.263 has never been widely used on the web. Variations on H.263 have been used as the basis for other proprietary formats, such as Flash video or the Sorenson codec. However, no major browser has ever included H.263 support by default. Certain media plugins have enabled support for H.263 media.

- -

Unlike most codecs, H.263 defines fundamentals of an encoded video in terms of the maximum bit rate per frame (picture), or BPPmaxKb. During encoding, a value is selected for BPPmaxKb, and then the video cannot exceed this value for each frame. The final bit rate will depend on this, the frame rate, the compression, and the chosen resolution and block format.

- -

H.263 has been superseded by H.264 and is therefore considered a legacy media format which you generally should avoid using if you can. The only real reason to use H.263 in new projects is if you require support on very old devices on which H.263 is your best choice.

- -

H.263 is a proprietary format, with patents held by a number of organizations and companies, including Telenor, Fujitsu, Motorola, Samsung, Hitachi, Polycom, Qualcomm, and so on. To use H.263, you are legally obligated to obtain the appropriate licenses.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Supported bit ratesUnrestricted, but typically below 64 Kbps
Supported frame ratesAny
CompressionLossy DCT-based algorithm
Supported frame sizesUp to 1408 x 1152 pixels[2]
Supported color modesYCbCr; each picture format (sub-QCIF, QCIF, CIF, 4CIF, or 16CIF)  defines the frame size in pixels as well as how many rows each of luminance and chrominance samples are used for each frame
HDR supportNo
Variable Frame Rate (VFR) supportNo
Browser compatibility - - - - - - - - - - - - - - - - - - - - - -
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
H.263 supportNoNoNo[1]NoNoNo
-
Container support3GP, MP4, QuickTime
{{Glossary("RTP")}} / WebRTC compatibleNo
Supporting/Maintaining organizationITU
Specificationhttps://www.itu.int/rec/T-REC-H.263/
LicensingProprietary; appropriate license or licenses are required. Note that multiple patent pools may apply.
- -

[1] While Firefox does not generally support H.263, the OpenMax platform implementation (used for the Boot to Gecko project upon which Firefox OS was based) did support H.263 in 3GP files.

- -

[2] Version 1 of H.263 specifies a set of picture sizes which are supported. Later versions may support additional resolutions.

- -

HEVC (H.265)

- -

The High Efficiency Video Coding (HVEC) codec is defined by ITU's H.265 as well as by MPEG-H Part 2 (the still in-development follow-up to MPEG-4). HEVC was designed to support efficient encoding and decoding of video in sizes including very high resolutions (including 8K video), with a structure specifically designed to let software take advantage of modern processors. Theoretically, HEVC can achieve compressed file sizes half that of {{anch("AVC")}} but with comparable image quality.

- -

For example, each coding tree unit (CTU)—similar to the macroblock used in previous codecs—consists of a tree of luma values for each sample as well as a tree of chroma values for each chroma sample used in the same coding tree unit, as well as any required syntax elements. This structure supports easy processing by multiple cores.

- -

An interesting feature of HEVC is that the main profile supports only 8 bit per component color with 4:2:0 chroma subsampling. Also interesting is that 4:4:4 video is handled specially. Instead of having the luma samples (representing the image's pixels in grayscale) and the Cb and Cr samples (indicating how to alter the grays to create color pixels), the three channels are instead treated as three monochrome images, one for each color, which are then combined during rendering to produce a full-color image.

- -

HEVC is a proprietary format and is covered by a number of patents.  Licensing is managed by MPEG LA; fees are charged to developers rather than to content producers and distributors. Be sure to review the latest license terms and requirements before making a decision on whether or not to use HEVC in your app or web site!

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Supported bit ratesUp to 800,000 Kbps
Supported frame ratesVaries by level; up to 300 FPS is possible
CompressionLossy DCT-based algorithm
Supported frame sizes128 x 96 to 8,192 x 4,320 pixels; varies by profile and level
Supported color modes -

Information below is provided for the major profiles. There are a number of other profiles available that are not included here.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ProfileColor depthsChroma subsampling
Main84:2:0
Main 108 to 104:2:0
Main 128 to 124:0:0 and 4:2:0
Main 4:2:2 108 to 104:0:0, 4:2:0, and 4:2:2
Main 4:2:2 128 to 124:0:0, 4:2:0, and 4:2:2
Main 4:4:484:0:0, 4:2:0, 4:2:2, and 4:4:4
Main 4:4:4 108 to 104:0:0, 4:2:0, 4:2:2, and 4:4:4
Main 4:4:4 128 to 124:0:0, 4:2:0, 4:2:2, and 4:4:4
Main 4:4:4 16 Intra8 to 164:0:0, 4:2:0, 4:2:2, and 4:4:4
-
HDR supportYes
Variable Frame Rate (VFR) supportYes
Browser compatibility - - - - - - - - - - - - - - - - - - - - - -
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
HEVC / H.265 supportNo18[1]No[2]11[1]No11
-
Container supportMP4
{{Glossary("RTP")}} / WebRTC compatibleNo
Supporting/Maintaining organizationITU / MPEG
Specificationshttp://www.itu.int/rec/T-REC-H.265
- https://www.iso.org/standard/69668.html
LicensingProprietary; confirm your compliance with the licensing requirements. Note that multiple patent pools may apply.
- -

[1] Internet Explorer and Edge only supports HEVC on devices with a hardware codec.

- -

[2] Mozilla will not support HEVC while it is encumbered by patents.

- -

MP4V-ES

- -

The MPEG-4 Video Elemental Stream (MP4V-ES) format is part of the MPEG-4 Part 2 Visual standard. While in general, MPEG-4 part 2 video is not used by anyone because of its lack of compelling value related to other codecs, MP4V-ES does have some usage on mobile. MP4V is essentially H.263 encoding in an MPEG-4 container.

- -

Its primary purpose is to be used to stream MPEG-4 audio and video over an {{Glossary("RTP")}} session. However, MP4V-ES is also used to transmit MPEG-4 audio and video over a mobile connection using 3GP.

- -

You almost certainly don't want to use this format, since it isn't supported in a meaningful way by any major browsers, and is quite obsolete. Files of this type should have the extension .mp4v, but sometimes are inaccurately labeled .mp4.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Supported bit rates5 Kbps to 1 Gbps and more
Supported frame ratesNo specific limit; restricted only by the data rate
CompressionLossy DCT-based algorithm
Supported frame sizesUp to 4,096 x 4,096 pixels
Supported color modesYCrCb with chroma subsampling (4:2:0, 4:2:2, and 4:4:4) supported; up to 12 bits per component
HDR supportNo
Variable Frame Rate (VFR) supportYes
Browser compatibility - - - - - - - - - - - - - - - - - - - - - -
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
MP4V-ES supportNo[2]NoYes[1]NoNoNo
-
Container support3GP, MP4
{{Glossary("RTP")}} / WebRTC compatibleNo
Supporting/Maintaining organizationMPEG
Specification{{RFC(6416)}}
LicensingProprietary; obtain a license through MPEG LA and/or AT&T as needed
- -

[1] Firefox supports MP4V-ES in 3GP containers only.

- -

[2] Chrome does not support MP4V-ES; however, Chrome OS does.

- -

MPEG-1 Part 2 Video

- -

MPEG-1 Part 2 Video was unveiled at the beginning of the 1990s. Unlike the later MPEG video standards, MPEG-1 was created solely by MPEG, without the {{Glossary("ITU", "ITU's")}} involvement.

- -

Because any MPEG-2 decoder can also play MPEG-1 video, it's compatible with a wide variety of software and hardware devices. There are no active patents remaining in relation to MPEG-1 video, so it may be used free of any licensing concerns. However, few web browsers support MPEG-1 video without the support of a plugin, and with plugin use deprecated in web browsers, these are generally no longer available. This makes MPEG-1 a poor choice for use in web sites and web applications.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Supported bit ratesUp to 1.5 Mbps
Supported frame rates23.976 FPS, 24 FPS, 25 FPS, 29.97 FPS, 30 FPS, 50 FPS, 59.94 FPS, and 60 FPS
CompressionLossy DCT-based algorithm
Supported frame sizesUp to 4,095 x 4,095 pixels
Supported color modesY'CbCr with 4:2:0 chroma subsampling with up to 12 bits per component
HDR supportNo
Variable Frame Rate (VFR) supportNo
Browser compatibility - - - - - - - - - - - - - - - - - - - - - -
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
MPEG-1 supportNoNoNoNoNoYes
-
Container supportMPEG
{{Glossary("RTP")}} / WebRTC compatibleNo
Supporting/Maintaining organizationMPEG
Specificationhttps://www.iso.org/standard/22411.html
LicensingProprietary; however, all patents have expired, so MPEG-1 may be used freely
- -

MPEG-2 Part 2 Video

- -

MPEG-2 Part 2 is the video format defined by the MPEG-2 specification, and is also occasionally referred to by its {{Glossary("ITU")}} designation, H.262. It is very similar to MPEG-1 video—in fact, any MPEG-2 player can automatically handle MPEG-1 without any special work—except it has been expanded to support higher bit rates and enhanced encoding techniques.

- -

The goal was to allow MPEG-2 to compress standard definition television, so interlaced video is also supported. The standard definition compression rate and the quality of the resulting video met needs well enough that MPEG-2 is the primary video codec used for DVD video media.

- -

MPEG-2 has several profiles available with different capabilities. Each profile is then available four levels, each of which increases attributes of the video, such as frame rate, resolution, bit rate, and so forth. Most profiles use Y'CbCr with 4:2:0 chroma subsampling, but more advanced profiles support 4:2:2 as well. In addition, there are four levels, each of which offers  support for larger frame dimensions and bit rates. For example, the {{interwiki("wikipedia", "ATSC standards", "ATSC")}} specification for television used in North America supports MPEG-2 video in high definition using the Main Profile at High Level, allowing 4:2:0 video at both 1920 x 1080 (30 FPS) and 1280 x 720 (60 FPS), at a maximum bit rate of 80 Mbps.

- -

However, few web browsers support MPEG-2 without the support of a plugin, and with plugin use deprecated in web browsers, these are generally no longer available. This makes MPEG-2 a poor choice for use in web sites and web applications.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Supported bit ratesUp to 100 Mbps; varies by level and profile
Supported frame rates - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Abbr.Level nameFrame rates supported
LLLow Level23.9, 24, 25, 29.97, 30
MLMain Level23.976, 24, 25, 29.97, 30
H-14High 144023.976, 24, 26, 29.97, 30, 50, 59.94, 60
HLHigh Level23.976, 24, 26, 29.97, 30, 50, 59.94, 60
-
CompressionLossy DCT-based algorithm
Supported frame sizes - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Abbr.Level nameMaximum frame size
LLLow Level352 x 288 pixels
MLMain Level720 x 576 pixels
H-14High 14401440 x 1152 pixels
HLHigh Level1920 x 1152 pixels
-
Supported color modesY'CbCr with 4:2:0 chroma subsampling in most profiles; the "High" and "4:2:2" profiles support 4:2:2 chroma subsampling as well.
HDR supportNo
Variable Frame Rate (VFR) supportNo
Browser compatibility - - - - - - - - - - - - - - - - - - - - - -
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
MPEG-2 supportNoNoNoNoNoYes
-
Container supportMPEG, MPEG-TS (MPEG Transport Stream), MP4, QuickTime
{{Glossary("RTP")}} / WebRTC compatibleNo
Supporting/Maintaining organizationMPEG / ITU
Specificationhttps://www.itu.int/rec/T-REC-H.262
- https://www.iso.org/standard/61152.html
LicensingProprietary; all patents have expired worldwide with the exception of in Malaysia and the Philippines as of April 1, 2019, so MPEG-2 can be used freely outside those two countries. Patents are licensed by MPEG LA.
- -

Theora

- -

{{interwiki("wikipedia", "Theora")}}, developed by Xiph.org, is an open and free video codec which may be used without royalties  or licensing. Theora is comparable in quality and compression rates to MPEG-4 Part 2 Visual and AVC, making it a very good if not top-of-the-line choice for video encoding. But its status as being free from any licensing concerns and its relatively low CPU resource requirements make it a popular choice for many software and web projects. The low CPU impact is particularly useful since there are no hardware decoders available for Theora.

- -

Theora was originally based upon the VC3 codec by On2 Technologies. The codec and its specification were released under the LGPL license and entrusted to Xiph.org, which then developed it into the Theora standard.

- -

One drawback to Theora is that it only supports 8 bits per color component, with no option to use 10 or more in order to avoid color banding. That said, 8 bits per component is still the most commonly-used color format in use today, so this is only a minor inconvenience in most cases. Also, Theora can only be used in an Ogg container. The biggest drawback of all, however, is that it is not supported by Safari, leaving Theora unavailable not only on macOS but on all those millions and millions of iPhones and iPads.

- -

The Theora Cookbook offers additional details about Theora as well as the Ogg container format it is used within.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Supported bit ratesUp to 2 Gbps
Supported frame ratesArbitrary; any non-zero value is supported. The frame rate is specified as a 32-bit numerator and a 32-bit denominator, to allow for non-integer frame rates.
CompressionLossy DCT-based algorithm
Supported frame sizesAny combination of width and height up to 1,048,560 x 1,048,560 pixels
Supported color modesY'CbCr with 4:2:0, 4:2:2, and 4:4:4 chroma subsampling at 8 bits per component
HDR supportNo
Variable Frame Rate (VFR) supportYes[1]
Browser compatibility - - - - - - - - - - - - - - - - - - - - - -
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
Theora support3Yes[2]3.5No10.5No
-
Container supportOgg
{{Glossary("RTP")}} / WebRTC compatibleNo
Supporting/Maintaining organizationXiph.org
Specificationhttps://www.theora.org/doc/
LicensingOpen and free of royalties and any other licensing requirements
- -

[1] While Theora doesn't support Variable Frame Rate (VFR) within a single stream, multiple streams can be chained together within a single file, and each of those can have its own frame rate, thus allowing what is essentially VFR. However, this is impractical if the frame rate needs to change frequently.

- -

[2] Edge supports Theora with the optional Web Media Extensions add-on.

- -

VP8

- -

The Video Processor 8 (VP8) codec was initially created by On2 Technologies. Following their purchase of On2, Google released VP8 as an open and royalty-free video format under a promise not to enforce the relevant patents. In terms of quality and compression rate, VP8 is comparable to {{anch("AVC")}}.

- -

If supported by the browser, VP8 allows video with an alpha channel, allowing the video to play with the background able to be seen through the video to a degree specified by each pixel's alpha component.

- -

There is good browser support for VP8 in HTML content, especially within WebM files. This makes VP8 a good candidate for your content, although VP9 is an even better choice if available to you. Web browsers are required to support VP8 for WebRTC, but not all browsers that do so also support it in HTML audio and video elements.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Supported bit ratesArbitrary; no maximum unless level-based limitations are enforced
Supported frame ratesArbitrary
CompressionLossy DCT-based algorithm
Supported frame sizesUp to 16,384 x 16,384 pixels
Supported color modesY'CbCr with 4:2:0 chroma subsampling at 8 bits per component
HDR supportNo
Variable Frame Rate (VFR) supportYes
Browser compatibility - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
VP8 support2514[1]491612.1[2]
MSE compatibilityYes3
-
Container support3GP, Ogg, WebM
{{Glossary("RTP")}} / WebRTC compatibleYes; VP8 is one of the spec-required codecs for WebRTC
Supporting/Maintaining organizationGoogle
Specification{{RFC(6386)}}
LicensingOpen and free of royalties and any other licensing requirements
- -

[1] Edge support for VP8 requires the use of Media Source Extensions.

- -

[2] Safari only supports VP8 in WebRTC connections.

- -

[3] Firefox only supports VP8 in MSE when no H.264 hardware decoder is available. Use {{domxref("MediaSource.isTypeSupported()")}} to check for availability.

- -

VP9

- -

Video Processor 9 (VP9) is the successor to the older VP8 standard developed by Google. Like VP8, VP9 is entirely open and royalty-free. Its encoding and decoding performance is comparable to or slightly faster than that of AVC, but with better quality. VP9's encoded video quality is comparable to that of HEVC at similar bit rates.

- -

VP9's main profile supports only 8-bit color depth at 4:2:0 chroma subsampling levels, but its profiles include support for deeper color and the full range of chroma subsampling modes. It supports several HDR imiplementations, and offers substantial freedom in selecting frame rates, aspect ratios, and frame sizes.

- -

VP9 is widely supported by browsers, and hardware implementations of the codec are fairly common. VP9 is one of the two video codecs mandated by WebM (the other being {{anch("VP8")}}). Of note, however, is that Safari supports neither WebM nor VP9, so if you choose to use VP9, be sure to offer a fallback format such as AVC or HEVC for iPhone, iPad, and Mac users.

- -

Aside from the lack of Safari support, VP9 is a good choice if you are able to use a WebM container and are able to provide a fallback video in a format such as AVC or HEVC for Safari users. This is especially true if you wish to use an open codec rather than a proprietary one. If you can't provide a fallback and aren't willing to sacrifice Safari compatibility, VP9 in WebM is a good option. Otherwise, you should probably consider a different codec.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Supported bit ratesArbitrary; no maximum unless level-based limitations are enforced
Supported frame ratesArbitrary
CompressionLossy DCT-based algorithm
Supported frame sizesUp to 65,536 x 65,536 pixels
Supported color modes - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ProfileColor depthsChroma subsampling
Profile 084:2:0
Profile 184:2:0, 4:2:2, and 4:4:4
Profile 210 to 124:2:0
Profile 310 to 124:2:0, 4:2:2, and f:4:4
- -

Color spaces supported: {{interwiki("wikipedia", "Rec. 601")}}, {{interwiki("wikipedia", "Rec. 709")}}, {{interwiki("wikipedia", "Rec. 2020")}}, {{interwiki("wikipedia", "SMPTE C")}}, SMPTE-240M (obsolete; replaced by Rec. 709), and {{interwiki("wikipedia", "sRGB")}}.

-
HDR supportYes; HDR10+, HLG, and PQ
Variable Frame Rate (VFR) supportYes
Browser compatibility - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FeatureChromeEdgeFirefoxInternet ExplorerOperaSafari
VP9 support291428No10.6No
MSE compatibilityYes1
-
Container supportMP4, Ogg, WebM
{{Glossary("RTP")}} / WebRTC compatibleYes
Supporting/Maintaining organizationGoogle
Specificationhttps://www.webmproject.org/vp9/
LicensingOpen and free of royalties and any other licensing requirements
- -

[1] Firefox only supports VP8 in MSE when no H.264 hardware decoder is available. Use {{domxref("MediaSource.isTypeSupported()")}} to check for availability.

- -

Choosing a video codec

- -

The decision as to which codec or codecs to use begins with a series of questions to prepare yourself:

- - - -

In the sections below, we offer recommended codec selections for specific use cases. For each use case, you'll find up to two reccommendations. If the codec which is considered best for the use case is proprietary or may require royalty payments, then two options are provided: first, an open and royalty-free option, followed by the proprietary one.

- -

If you are only able to offer a single version of each video, you can choose the format that's most appropriate for your needs.The first one is recommended as being a good combnination of quality, performance, and compatibility. The second option will be the most broadly compatible choice, at the expense of some amount of quality, preformance, and/or size.

- -

Recommendations for everyday videos

- -

First, let's look at the best options for videos presented on a typical web site such as a blog, informational site, small business web site where videos are used to demonstrate products (but not where the videos themselves are a product), and so forth.

- -
    -
  1. -

    A WebM container using the {{anch("VP8")}} codec for video and the Opus codec for audio. These are all open, royalty-free formats which are generally well-supported, although only in quite recent browsers, which is why a fallback is a good idea.

    - -
    <video controls src="filename.webm"></video>
    -
    -
  2. -
  3. -

    An MP4 container and the {{anch("AVC")}} (H.264) video codec, ideally with AAC as your audio codec. This is because the MP4 container with AVC and AAC codecs within is a broadly-supported combination—by every major browser, in fact—and the quality is typically good for most use cases. Make sure you verify your compliance with the license requirements, however.

    - -
    <video controls>
    -  <source type="video/webm"
    -          src="filename.webm">
    -  <source type="video/mp4"
    -          src="filename.mp4">
    -</video>
    -
    -
  4. -
- -
-

Note: Keep in mind that the {{HTMLElement("<video>")}} element requires a closing </video> tag, whether or not you have any {{HTMLElement("source")}} elements inside it.

-
- -

Recommendations for high-quality video presentation

- -

If your mission is to present video at the highest possible quality, you will probably benefit from offering as many formats as possible, as the codecs capable of the best quality tend also to be the newest, and thus the most likely to have gaps in browser compatibility.

- -
    -
  1. -

    A WebM container using AV1 for video and Opus for audio. If you're able to use the High or Professional profile when encoding AV1, at a high level like 6.3, you can get very high bit rates at 4K or 8K resolution, while maintaining excellent video quality. Encoding your audio using Opus's Fullband profile at a 48 kHz sample rate maximizes the audio bandwidth captured, capturing nearly the entire frequency range that's within human hearing.

    - -
    <video controls src="filename.webm"></video>
    -
    -
  2. -
  3. -

    An MP4 container using the {{anch("HEVC")}} codec using one of the advanced Main profiles, such as Main 4:2:2 with 10 or 12 bits of color depth, or even the Main 4:4:4 profile at up to 16 bits per component. At a high bit rate, this provides excellent graphics quality with remarkable color reproduction.  In addition, you can optionally include HDR metadata to provide high dynamic range video. For audio, use the AAC codec at a high sample rate (at least 48 kHz but ideally 96kHz) and encoded with complex encoding rather than fast encoding.

    - -
    <video controls>
    -  <source type="video/webm"
    -          src="filename.webm">
    -  <source type="video/mp4"
    -          src="filename.mp4">
    -</video>
    -
    -
  4. -
- -

Recommendations for archival, editing, or remixing

- -

There are not currently any lossless—or even near-lossless—video codecs generally available in web browsers. The reason for this is simple: video is huge. Lossless compression is by definition less effective than lossy compression. For example, uncompressed 1080p video (1920 by 1080 pixels) with 4:2:0 chroma subsampling needs at least 1.5 Gbps. Using lossless compression such as FFV1 (which is not supported by web browsers) could perhaps reduce that to somewhere around 600 Mbps, depending on the content. That's still a huge number of bits to pump through a connection every second, and is not currently practical for any real-world use.

- -

This is the case even though some of the lossy codecs have a lossless mode available; the lossless modes are not implemented in any current web browsers. The best you can do is to select a high-quality codec that uses lossy compression and configure it to perform as little compression as possible. One way to do this is to configure the codec to use "fast" compression, which inherently means less compression is achieved.

- -

Preparing video externally

- -

To prepare video for archival purposes from outside your web site or app, use a utility that performs compression on the original uncompressed video data. For example, the free x264 utility can be used to encode video in {{anch("AVC")}} format using a very high bit rate:

- -
x264 --crf 18 -preset ultrafast --output outfilename.mp4 infile
- -

While other codecs may have better best-case quality levels when compressing the video by a significant margin, their encoders tend to be slow enough that the nearly-lossless encoding you get with this compression is vastly faster at about the same overall quality level.

- -

Recording video

- -

Given the constraints on how close to lossless you can get, you might consider using {{anch("AVC")}} or {{anch("AV1")}}. For example, if you're using the MediaStream Recording API to record video, you might use code like the following when creating your {{domxref("MediaRecorder")}} object:

- -
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);
- -

This example creates a MediaRecorder configured to record {{anch("AV1")}} video using BT.2100 HDR in 12-bit color with 4:4:4 chroma subsampling and FLAC for lossless audio. The resulting file will use a bit rate of no more than 800 Mbps shared between the video and audio tracks. You will likely need to adjust these values depending on hardware performance, your requirements, and the specific codecs you choose to use. This bit rate is obviously not realistic for network transmission and would likely only be used locally.

- -

Breaking down the value of the codecs parameter into its dot-delineated properties, we see the following:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDesccription
av01The four-character code (4CC) designation identifying the {{anch("AV1")}} codec.
2The profile. A value of 2 indicates the Professional profile. A value of 1 is the High profile, while a value of 0 would specify the Main profile.
19HThe level and tier. This value comes from the table in section A.3 of the AV1 specification, and indicates the high tier of Level 6.3.
12The color depth. This indicates 12 bits per component. Other possible values are 8 and 10, but 12 is the highest-accuracy color representation available in AV1.
0The monochrome mode flag. If 1, then no chroma planes would be recorded, and all data should be structly luma data, resulting in a greyscale image. We've specified 0 because we want color.
000The chroma subsampling mode, taken from section 6.4.2 in the AV1 specification. A value of 000, combined with the monochrome mode value 0, indicates that we want 4:4:4 chroma subsampling, or no loss of color data.
09The color primaries to use. This value comes from section 6.4.2 in the AV1 specification; 9 indicates that we want to use BT.2020 color, which is used for HDR.
16The transfer characteristics to use. This comes from section 6.4.2 as well; 16 indicates that we want to use the characteristics for BT.2100 PQ color.
09The matrix coefficents to use, from the section 6.4.2 again. A value of 9 specifies that we want to use BT.2020 with variable luminance; this is also known as BT.2010 YbCbCr.
1The video "full range" flag. A value of 1 indicates that we want the full color range to be used.
- -

The documentation for your codec choices will probably offer information you'll use when constructing your codecs parameter.

- -

See also

- - diff --git a/files/zh-cn/web/media/index.html b/files/zh-cn/web/media/index.html new file mode 100644 index 0000000000..5a66bbe303 --- /dev/null +++ b/files/zh-cn/web/media/index.html @@ -0,0 +1,76 @@ +--- +title: Web 媒体技术 +slug: Web/媒体 +tags: + - 视频 + - 音频 +translation_of: Web/Media +--- +
+ +

逐年来,Web 呈现、创建并管理音频、视频和其他媒体的能力以不断增长的步伐发展。今日有着大量的 API、HTML 元素、DOM 界面和其他不仅仅限于完成这些任务,而是为了将媒体和其他技术联合使用以实现非凡事物的特性可供使用。这篇文章列出了可能对您掌握这些技术有帮助的多种 API 与其文档链接。

+ +
+
+

参考文献

+ +

HTML

+ +

这些文章含括了供媒体开发者使用的 HTML 特性。

+ +
+
{{HTMLElement("audio")}}
+
<audio> 元素用于在 Web 上下文中播放音频。这可以用于复杂媒体的隐性目标,亦或是用户控制播放音频的可见控制。可以从 JavaScript {{domxref("HTMLAudioElement")}} 对象中访问。
+
{{HTMLElement("video")}}
+
<video> 元素是 Web 上下文中视频内容的端点。其可以简单地用于呈现视频,亦或是流式视频的目标。<video> 也可以用于连接媒体 API 和其他 HTML 与 DOM 技术,比如 {{HTMLElement("canvas")}} (用于抓取并控制框中内容),例如,可以通过 JavaScript {{domxref("HTMLVideoElement")}} 对象访问。
+
{{HTMLElement("track")}}
+
<track> 元素可以被放置在 {{HTMLElement("audio")}} 或者 {{HTMLElement("video")}} 元素内部,当在媒体播放时,以提供 WebVTT 格式化字幕或标题轨道的参考。可以通过 JavaScript {{domxref("HTMLTrackElement")}} 对象访问。
+
{{HTMLElement("source")}}
+
<source> 元素可以放在 {{HTMLElement("audio")}} 或者 {{HTMLElement("video")}} 元素内部,以指定当前显示的源媒体。可以使用多个不同格式、大小、分辨率的媒体源。可以从通过 JavaScript {{domxref("HTMLSourceElement")}} 对象中访问。
+
+ +

API

+ +
+
媒体捕获和流媒体 API
+
使得串流、播放和控制本地和网络媒体成为可能的 API 参考文献。包括使用本地摄像头与麦克风来抓取视频、音频和静止图片。
+
网络音频 API
+
网络音频 API 允许您生成、过滤并调节实时与预录的音频材料,并将其发送至 <audio> 元素、媒体流或磁盘中。
+
WebRTC
+
WebRTC (网页即时通信) 可以使互联网上任意两位用户在无需媒介的情况下中串流实时音频、视频和任意数据。
+
+
+ +
+

指南

+ +
+
Web 上的媒体技术概览
+
概览提供音频、视频播放与录制的开放网络技术和 API。若您不了解该使用哪种 API,这就是您的开始。
+
Web 设计中的媒体无障碍指南
+
在本指南中,我们将介绍 web 设计人员和开发人员创建的内容能让具有不同能力的人可以访问的方法。这个范围包括从 {{HTMLElement("image")}} 元素上简单地使用 {{htmlattrxref("alt", "img")}} 属性到为屏幕阅读者提供字幕标记的媒体。
+
Web 媒体类型和格式指南
+
关于文件类型和编解码器对于 web 上的图像、音频和视频媒体有效的指南。这包括使用何种格式处理什么内容的建议、最佳实践,以及如何提供后备方案和如何对媒体类型进行优先排序,还包括针对每个媒体容器和编解码器的一般浏览器支持信息。
+
媒体和 Web 音频 APIs 自动播放指南
+
出乎意料的自动播放媒体或音频对用户来说可能是一个不受欢迎的惊喜。虽然自动播放是有目的的,但应该谨慎使用。为了让用户控制这一点,许多浏览器现在都提供了自动播放阻塞的形式。本文是关于自动播放的指南,提供了一些技巧,告诉您何时以及如何使用它,以及如何使用浏览器优雅地处理自动播放阻塞。
+
+ +
+
+ +

其他主题

+ +

您可能会感兴趣的相关主题,这些技术可以用有趣的方式与媒体 API 共同使用。

+ +
+
Canvas API
+
Canvas API 允许您在 {{HTMLElement("canvas")}} 上绘画、操纵并改变图像内容。这样可以与媒体以多种方式使用,包括设置 <canvas> 元素作为视频播放或摄像头捕获的终点以捕获或操纵视频帧。
+
WebGL
+
WebGL 在已存在的 Canvas API 上提供了与 OpenGL ES 兼容的 API,使得在 Web 上制作强大的 3D 图像成为可能。通过一张画布,这可以用于为媒体内容添加 3D 图像。
+
WebVR
+
Web Virtual Reality API 支持虚拟现实 (VR) 设备,如 Oculus Rift 或 HTC Vive,使开发人员能够将用户的位置和移动转换为 3D 场景中的移动,然后在设备上显示。WebVR 有望逐渐被 WebXR 所取代,后者涵盖了更广泛的用例。
+
WebXR
+
WebXR 旨在最终取代 WebVR,是一种支持创建虚拟现实 (VR) 和增强现实 (AR) 内容的技术。混合现实内容可以显示在设备的屏幕上,或者是显示在目镜或耳机内。
+
+
+
-- cgit v1.2.3-54-g00ecf