Internet Engineering Task Force (IETF) A.B. Roach
Request for Comments: 7742 Mozilla
Category: Standards Track March 2016
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A.B. Roach
Request for Comments: 7742 Mozilla
Category: Standards Track March 2016
ISSN: 2070-1721
WebRTC Video Processing and Codec Requirements
WebRTC视频处理和编解码器要求
Abstract
摘要
This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required as well as video codecs and their parameters.
本规范提供了WebRTC应用程序在网络上发送和接收视频的要求和注意事项。它指定所需的视频处理以及视频编解码器及其参数。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7742.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7742.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Pre- and Post-Processing . . . . . . . . . . . . . . . . . . 3
3.1. Camera-Source Video . . . . . . . . . . . . . . . . . . . 3
3.2. Screen-Source Video . . . . . . . . . . . . . . . . . . . 4
4. Stream Orientation . . . . . . . . . . . . . . . . . . . . . 4
5. Mandatory-to-Implement Video Codec . . . . . . . . . . . . . 5
6. Codec-Specific Considerations . . . . . . . . . . . . . . . . 6
6.1. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. H.264 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Pre- and Post-Processing . . . . . . . . . . . . . . . . . . 3
3.1. Camera-Source Video . . . . . . . . . . . . . . . . . . . 3
3.2. Screen-Source Video . . . . . . . . . . . . . . . . . . . 4
4. Stream Orientation . . . . . . . . . . . . . . . . . . . . . 4
5. Mandatory-to-Implement Video Codec . . . . . . . . . . . . . 5
6. Codec-Specific Considerations . . . . . . . . . . . . . . . . 6
6.1. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. H.264 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
One of the major functions of WebRTC endpoints is the ability to send and receive interactive video. The video might come from a camera, a screen recording, a stored file, or some other source. This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required as well as video codecs and their parameters.
WebRTC端点的主要功能之一是能够发送和接收交互式视频。视频可能来自摄像机、屏幕录制、存储的文件或其他来源。本规范提供了WebRTC应用程序在网络上发送和接收视频的要求和注意事项。它指定所需的视频处理以及视频编解码器及其参数。
Note that this document only discusses those issues dealing with video-codec handling. Issues that are related to transport of media streams across the network are specified in [WebRTC-RTP-USAGE].
请注意，本文档仅讨论处理视频编解码器处理的问题。与跨网络传输媒体流相关的问题在[WebRTC RTP用法]中指定。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The following definitions are used in this document:
本文件中使用了以下定义：
o A WebRTC browser (also called a WebRTC User Agent or WebRTC UA) is something that conforms to both the protocol specification and the Javascript API (see [RTCWEB-OVERVIEW]).
o WebRTC浏览器（也称为WebRTC用户代理或WebRTC UA）符合协议规范和Javascript API（请参见[RTCWEB-OVERVIEW]）。
o A WebRTC non-browser is something that conforms to the protocol specification, but it does not claim to implement the Javascript API. This can also be called a "WebRTC device" or "WebRTC native application".
o WebRTC非浏览器符合协议规范，但它并不声称实现Javascript API。这也可以称为“WebRTC设备”或“WebRTC本机应用程序”。
o A WebRTC endpoint is either a WebRTC browser or a WebRTC non-browser. It conforms to the protocol specification.
o WebRTC端点是WebRTC浏览器或WebRTC非浏览器。它符合协议规范。
o A WebRTC-compatible endpoint is an endpoint that is able to successfully communicate with a WebRTC endpoint but may fail to meet some requirements of a WebRTC endpoint. This may limit where in the network such an endpoint can be attached, or it may limit the security guarantees that it offers to others. It is not constrained by this specification; when it is mentioned at all, it is to note the implications on WebRTC-compatible endpoints of the requirements placed on WebRTC endpoints.
o WebRTC兼容端点是能够成功与WebRTC端点通信但可能无法满足WebRTC端点某些要求的端点。这可能会限制端点在网络中的连接位置，也可能会限制它向其他人提供的安全保证。不受本规范约束；当提到WebRTC端点时，需要注意WebRTC端点上的需求对WebRTC兼容端点的影响。
These definitions are also found in [RTCWEB-OVERVIEW] and that document should be consulted for additional information.
这些定义也可在[RTCWEB-OVERVIEW]中找到，更多信息请参考该文件。
This section provides guidance on pre- and post-processing of video streams.
本节提供有关视频流预处理和后处理的指导。
Unless specified otherwise by the Session Description Protocol (SDP) or codec, the color space SHOULD be sRGB [SRGB]. For clarity, this is the color space indicated by codepoint 1 from "ColourPrimaries" as defined in [IEC23001-8].
除非会话描述协议（SDP）或编解码器另有规定，否则颜色空间应为sRGB[sRGB]。为清楚起见，这是由[IEC23001-8]中定义的“原色”中的代码点1表示的颜色空间。
Unless specified otherwise by the SDP or codec, the video scan pattern for video codecs is Y'CbCr 4:2:0.
除非SDP或编解码器另有规定，否则视频编解码器的视频扫描模式为Y'CbCr 4:2:0。
This document imposes no normative requirements on camera capture; however, implementors are encouraged to take advantage of the following features, if feasible for their platform:
本文件对摄像机拍摄没有任何规范性要求；但是，如果平台可行，则鼓励实施者利用以下功能：
o Automatic focus, if applicable for the camera in use
o 自动对焦，如果适用于使用中的相机
o Automatic white balance
o 自动白平衡
o Automatic light-level control
o 自动灯光控制
o Dynamic frame rate for video capture based on actual encoding in use (e.g., if encoding at 15 fps due to bandwidth constraints, low light conditions, or application settings, the camera will ideally capture at 15 fps rather than a higher rate).
o 基于使用中的实际编码进行视频捕获的动态帧速率（例如，如果由于带宽限制、低光照条件或应用程序设置，以15 fps的速度进行编码，则相机最好以15 fps的速度而不是更高的速度进行捕获）。
If the video source is some portion of a computer screen (e.g., desktop or application sharing), then the considerations in this section also apply.
如果视频源是计算机屏幕的某个部分（例如，桌面或应用程序共享），则本节中的注意事项也适用。
Because screen-sourced video can change resolution (due to, e.g., window resizing and similar operations), WebRTC-video recipients MUST be prepared to handle midstream resolution changes in a way that preserves their utility. Precise handling (e.g., resizing the element a video is rendered in versus scaling down the received stream; decisions around letter/pillarboxing) is left to the discretion of the application.
由于源于屏幕的视频可能会更改分辨率（例如，由于窗口大小调整和类似操作），因此WebRTC视频收件人必须准备好以保留其效用的方式处理中游分辨率更改。精确的处理（例如，调整视频所呈现的元素的大小，而不是缩小接收到的流；关于字母/柱状图的决定）由应用程序自行决定。
Note that the default video-scan format (Y'CbCr 4:2:0) is known to be less than optimal for the representation of screen content produced by most systems in use at the time of this document's writing, which generally use RGB with at least 24 bits per sample. In the future, it may be advisable to use video codecs optimized for screen content for the representation of this type of content.
请注意，已知默认视频扫描格式（Y'CbCr 4:2:0）对于在编写本文档时使用的大多数系统生成的屏幕内容的表示不太理想，这些系统通常使用RGB，每个样本至少有24位。在将来，可能建议使用针对屏幕内容优化的视频编解码器来表示这种类型的内容。
Additionally, attention is drawn to the requirements in Section 5.2 of [WebRTC-SEC-ARCH] and the considerations in Section 4.1.1. of [WebRTC-SEC].
此外，还应注意[WebRTC SEC ARCH]第5.2节中的要求和第4.1.1节中的注意事项。属于[WebRTC SEC]。
In some circumstances -- and notably those involving mobile devices -- the orientation of the camera may not match the orientation used by the encoder. Of more importance, the orientation may change over the course of a call, requiring the receiver to change the orientation in which it renders the stream.
在某些情况下，尤其是涉及移动设备的情况下，摄像机的方向可能与编码器使用的方向不匹配。更重要的是，方向可能在呼叫过程中改变，要求接收方改变呈现流的方向。
While the sender may elect to simply change the pre-encoding orientation of frames, this may not be practical or efficient (in particular, in cases where the interface to the camera returns pre-compressed video frames). Note that the potential for this behavior adds another set of circumstances under which the resolution of a screen might change in the middle of a video stream, in addition to those mentioned in Section 3.2.
虽然发送方可以选择简单地改变帧的预编码方向，但这可能不实用或不有效（特别是在相机接口返回预压缩视频帧的情况下）。注意，这种行为的潜在性增加了另一组场景，在该情况下，除了第3.2节中提到的之外，屏幕的分辨率可能在视频流的中间改变。
To accommodate these circumstances, WebRTC implementations that can generate media in orientations other than the default MUST support generating the R0 and R1 bits of the Coordination of Video Orientation (CVO) mechanism described in Section 7.4.5 of [TS26.114] and MUST send them for all orientations when the peer indicates support for the mechanism. They MAY support sending the other bits in the CVO extension, including the higher-resolution rotation bits. All implementations SHOULD support interpretation of the R0 and R1 bits and MAY support the other CVO bits.
为了适应这些情况，能够以非默认方向生成媒体的WebRTC实现必须支持生成[TS26.114]第7.4.5节中所述的视频方向协调（CVO）机制的R0和R1位当对等方表示支持该机制时，必须向所有方向发送它们。它们可能支持发送CVO扩展中的其他位，包括更高分辨率的旋转位。所有实现都应支持R0和R1位的解释，并可能支持其他CVO位。
Further, some codecs support in-band signaling of orientation (for example, the SEI "Display Orientation" messages in H.264 and H.265 [H265]). If CVO has been negotiated, then the sender MUST NOT make use of such codec-specific mechanisms. However, when support for CVO is not signaled in the SDP, then such implementations MAY make use of the codec-specific mechanisms instead.
此外，一些编解码器支持方向的带内信令（例如，H.264和H.265[H265]中的SEI“显示方向”消息）。如果已协商CVO，则发送方不得使用此类特定于编解码器的机制。然而，当在SDP中没有发出对CVO的支持的信号时，这样的实现可以改为使用特定于编解码器的机制。
For the definitions of "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible endpoint" as they are used in this section, please refer to Section 2.
有关本节中使用的“WebRTC浏览器”、“WebRTC非浏览器”和“WebRTC兼容端点”的定义，请参阅第2节。
WebRTC Browsers MUST implement the VP8 video codec as described in [RFC6386] and H.264 Constrained Baseline as described in [H264].
WebRTC浏览器必须实现[RFC6386]中所述的VP8视频编解码器和[H264]中所述的H.264约束基线。
WebRTC Non-Browsers that support transmitting and/or receiving video MUST implement the VP8 video codec as described in [RFC6386] and H.264 Constrained Baseline as described in [H264].
支持传输和/或接收视频的WebRTC非浏览器必须实现[RFC6386]中所述的VP8视频编解码器和[H264]中所述的H.264约束基线。
NOTE: To promote the use of non-royalty-bearing video codecs, participants in the RTCWEB working group, and any successor working groups in the IETF, intend to monitor the evolving licensing landscape as it pertains to the two mandatory-to-implement codecs. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, the working group plans to revisit the question of which codecs are required for Non-Browsers, with the intention being that the royalty-free codec will remain mandatory to implement and the other will become optional.
注：为了促进使用非版权费视频编解码器，RTCWEB工作组的参与者以及IETF中的任何后续工作组打算监控不断演变的许可环境，因为它涉及到两种强制实施编解码器的情况。如果有令人信服的证据表明其中一个编解码器可免费使用，工作组计划重新探讨非浏览器需要哪些编解码器的问题，目的是免费编解码器仍将是强制性的，另一个将成为可选的。
These provisions apply to WebRTC Non-Browsers only. There is no plan to revisit the codecs required for WebRTC Browsers.
这些规定仅适用于WebRTC非浏览器。没有计划重新访问WebRTC浏览器所需的编解码器。
"WebRTC-compatible endpoints" are free to implement any video codecs they see fit. This follows logically from the definition of "WebRTC-compatible endpoint". It is, of course, advisable to implement at least one of the video codecs that is mandated for WebRTC browsers, and implementors are encouraged to do so.
“WebRTC兼容端点”可以免费实施他们认为合适的任何视频编解码器。这在逻辑上遵循“WebRTC兼容端点”的定义。当然，建议至少实现一个WebRTC浏览器强制使用的视频编解码器，并鼓励实现者这样做。
SDP allows for codec-independent indication of preferred video resolutions using the mechanism described in [RFC6236]. WebRTC endpoints MAY send an "a=imageattr" attribute to indicate the maximum resolution they wish to receive. Senders SHOULD interpret and honor this attribute by limiting the encoded resolution to the indicated maximum size, as the receiver may not be capable of handling higher resolutions.
SDP允许使用[RFC6236]中描述的机制独立于编解码器指示首选视频分辨率。WebRTC端点可能会发送“a=imageattr”属性，以指示它们希望接收的最大分辨率。发送方应通过将编码分辨率限制在指定的最大大小来解释和遵守此属性，因为接收方可能无法处理更高的分辨率。
Additionally, codecs may include codec-specific means of signaling maximum receiver abilities with regard to resolution, frame rate, and bitrate.
另外，编解码器可以包括编解码器特定的装置，用于在分辨率、帧速率和比特率方面向最大接收机能力发送信号。
Unless otherwise signaled in SDP, recipients of video streams MUST be able to decode video at a rate of at least 20 fps at a resolution of at least 320 pixels by 240 pixels. These values are selected based on the recommendations in [HSUP1].
除非SDP中另有指示，否则视频流的接收者必须能够以至少320像素×240像素的分辨率以至少20 fps的速率解码视频。这些值是根据[HSUP1]中的建议选择的。
Encoders are encouraged to support encoding media with at least the same resolution and frame rates cited above.
鼓励编码器支持至少具有上述相同分辨率和帧速率的编码媒体。
For the VP8 codec, defined in [RFC6386], endpoints MUST support the payload formats defined in [RFC7741].
对于[RFC6386]中定义的VP8编解码器，端点必须支持[RFC7741]中定义的有效负载格式。
In addition to the [RFC6236] mechanism, VP8 encoders MUST limit the streams they send to conform to the values indicated by receivers in the corresponding max-fr and max-fs SDP attributes.
除了[RFC6236]机制外，VP8编码器必须限制其发送的流，以符合接收器在相应的max fr和max fs SDP属性中指示的值。
Unless otherwise signaled, implementations that use VP8 MUST encode and decode pixels with an implied 1:1 (square) aspect ratio.
除非另有指示，否则使用VP8的实现必须以隐含的1:1（平方）纵横比对像素进行编码和解码。
For the [H264] codec, endpoints MUST support the payload formats defined in [RFC6184]. In addition, they MUST support Constrained Baseline Profile Level 1.2 and SHOULD support H.264 Constrained High Profile Level 1.3.
对于[H264]编解码器，端点必须支持[RFC6184]中定义的有效负载格式。此外，它们必须支持受约束的基线配置文件级别1.2，并应支持受H.264约束的高配置文件级别1.3。
Implementations of the H.264 codec have utilized a wide variety of optional parameters. To improve interoperability, the following parameter settings are specified:
H.264编解码器的实现使用了多种可选参数。为了提高互操作性，指定了以下参数设置：
packetization-mode: Packetization-mode 1 MUST be supported. Other modes MAY be negotiated and used.
打包模式：必须支持打包模式1。可以协商和使用其他模式。
profile-level-id: Implementations MUST include this parameter within SDP and MUST interpret it when receiving it.
概要文件级别id：实现必须在SDP中包含此参数，并且在接收时必须对其进行解释。
max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br:
最大mbps、最大smbps、最大fs、最大cpb、最大dpb和最大br：
These parameters allow the implementation to specify that they can support certain features of H.264 at higher rates and values than those signaled by their level (set with profile-level-id). Implementations MAY include these parameters in their SDP, but they SHOULD interpret them when receiving them, allowing them to send the highest quality of video possible.
这些参数允许实现指定它们可以支持H.264的某些功能，其速率和值高于它们的级别（使用配置文件级别id设置）所表示的速率和值。实现可能会在SDP中包含这些参数，但在接收这些参数时应该对其进行解释，从而使它们能够发送尽可能高质量的视频。
sprop-parameter-sets: H.264 allows sequence and picture information to be sent both in-band and out-of-band. WebRTC implementations MUST signal this information in-band. This means that WebRTC implementations MUST NOT include this parameter in the SDP they generate.
sprop参数设置：H.264允许带内和带外发送序列和图片信息。WebRTC实施必须在频带内发出此信息的信号。这意味着WebRTC实现不能在生成的SDP中包含此参数。
H.264 codecs MAY send and MUST support proper interpretation of Supplemental Enhancement Information (SEI) "filler payload" and "full frame freeze" messages. The "full frame freeze" messages are used in video-switching MCUs, to ensure a stable decoded displayed picture while switching among various input streams.
H.264编解码器可以发送并且必须支持对补充增强信息（SEI）“填充有效载荷”和“全帧冻结”消息的正确解释。“全帧冻结”消息用于视频切换MCU，以确保在各种输入流之间切换时稳定解码显示的图片。
When the use of the video orientation (CVO) RTP header extension is not signaled as part of the SDP, H.264 implementations MAY send and SHOULD support proper interpretation of Display Orientation SEI messages.
当视频定向（CVO）RTP报头扩展的使用未作为SDP的一部分发出信号时，H.264实现可发送并应支持对显示定向SEI消息的正确解释。
Implementations MAY send and act upon "User data registered by Rec. ITU-T T.35" and "User data unregistered" messages. Even if they do not act on them, implementations MUST be prepared to receive such messages without any ill effects.
实施可发送“由记录ITU-T T.35注册的用户数据”和“未注册的用户数据”消息并对其采取行动。即使它们不采取行动，实现也必须准备好接收这样的消息，而不会产生任何不良影响。
Unless otherwise signaled, implementations that use H.264 MUST encode and decode pixels with an implied 1:1 (square) aspect ratio.
除非另有指示，否则使用H.264的实现必须以隐含的1:1（平方）纵横比对像素进行编码和解码。
This specification does not introduce any new mechanisms or security concerns beyond what is in the other documents it references. In WebRTC, video is protected using Datagram Transport Layer Security (DTLS) / Secure Real-time Transport Protocol (SRTP). A complete discussion of the security considerations can be found in [WebRTC-SEC] and [WebRTC-SEC-ARCH]. Implementors should consider whether the use of variable bitrate video codecs are appropriate for their application, keeping in mind that the degree of inter-frame change (and, by inference, the amount of motion in the frame) may be deduced by an eavesdropper based on the video stream's bitrate.
本规范不引入任何新的机制或安全问题，超出其引用的其他文档中的内容。在WebRTC中，使用数据报传输层安全（DTLS）/安全实时传输协议（SRTP）保护视频。有关安全注意事项的完整讨论，请参见[WebRTC SEC]和[WebRTC SEC ARCH]。实现者应该考虑可变比特率视频编解码器的使用是否适合于它们的应用，记住帧间变化的程度（并且，通过推断，帧中的运动量）可以由基于视频流比特率的窃听者推断。
Implementors making use of H.264 are also advised to take careful note of the "Security Considerations" section of [RFC6184], paying special regard to the normative requirement pertaining to SEI messages.
还建议使用H.264的实施者仔细注意[RFC6184]中的“安全注意事项”部分，特别注意与SEI消息相关的规范性要求。
[H264] ITU-T, "Advanced video coding for generic audiovisual services (V9)", ITU-T Recommendation H.264, February 2014, <http://www.itu.int/rec/T-REC-H.264>.
[H264]ITU-T，“通用视听服务的高级视频编码（V9）”，ITU-T建议H.264，2014年2月<http://www.itu.int/rec/T-REC-H.264>.
[HSUP1] ITU-T, "Application profile - Sign language and lip-reading real-time conversation using low bit rate video communication", ITU-T Recommendation H.Sup1, May 1999, <http://www.itu.int/rec/T-REC-H.Sup1>.
[HSUP1]ITU-T，“应用程序配置文件-使用低比特率视频通信的手语和唇读实时对话”，ITU-T建议H.Sup1，1999年5月<http://www.itu.int/rec/T-REC-H.Sup1>.
[IEC23001-8] ISO/IEC, "Coding independent media description code points", ISO/IEC 23001-8:2013/DCOR1, 2013, <http://standards.iso.org/ittf/PubliclyAvailableStandards/ c062088_ISO_IEC_23001-8_2013.zip>.
[IEC23001-8]ISO/IEC，“编码独立媒体描述码点”，ISO/IEC 23001-8:2013/DCOR1，2013<http://standards.iso.org/ittf/PubliclyAvailableStandards/ c062088_ISO_IEC_23001-8_2013.zip>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, DOI 10.17487/RFC6184, May 2011, <http://www.rfc-editor.org/info/rfc6184>.
[RFC6184]Wang，Y.，Even，R.，Kristensen，T.，和R.Jesup，“H.264视频的RTP有效载荷格式”，RFC 6184，DOI 10.17487/RFC6184，2011年5月<http://www.rfc-editor.org/info/rfc6184>.
[RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)", RFC 6236, DOI 10.17487/RFC6236, May 2011, <http://www.rfc-editor.org/info/rfc6236>.
[RFC6236]Johansson，I.和K.Jung，“会话描述协议（SDP）中通用图像属性的协商”，RFC 6236，DOI 10.17487/RFC6236，2011年5月<http://www.rfc-editor.org/info/rfc6236>.
[RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011, <http://www.rfc-editor.org/info/rfc6386>.
[RFC6386]Bankoski，J.，Koleszar，J.，Quillio，L.，Salonen，J.，Wilkins，P.，和Y.Xu，“VP8数据格式和解码指南”，RFC 6386，DOI 10.17487/RFC6386，2011年11月<http://www.rfc-editor.org/info/rfc6386>.
[RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. Galligan, "RTP Payload Format for VP8 Video", RFC 7741, DOI 10.17487/RFC7741, March 2016, <http://www.rfc-editor.org/info/rfc7741>.
[RFC7741]威斯汀，P.，伦丁，H.，格洛弗，M.，尤伯蒂，J.，和F.加里根，“VP8视频的RTP有效载荷格式”，RFC 7741，DOI 10.17487/RFC77412016年3月<http://www.rfc-editor.org/info/rfc7741>.
[SRGB] IEC, "Multimedia systems and equipment - Colour measurement and management - Part 2-1: Colour management - Default RGB colour space - sRGB.", IEC 61966-2-1, October 1999, <https://webstore.iec.ch/publication/6169>.
[SRGB]IEC，“多媒体系统和设备-颜色测量和管理-第2-1部分：颜色管理-默认RGB颜色空间-SRGB”，IEC 61966-2-11999年10月<https://webstore.iec.ch/publication/6169>.
[TS26.114] 3GPP, "IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction", TS 26.114, Version 13.2.0, December 2015, <http://www.3gpp.org/DynaReport/26114.htm>.
[TS26.114]3GPP，“IP多媒体子系统（IMS）；多媒体电话；媒体处理和交互”，TS 26.114，版本13.2.0，2015年12月<http://www.3gpp.org/DynaReport/26114.htm>.
[H265] ITU-T, "High efficiency video coding", ITU-T Recommendation H.265, April 2015, <http://www.itu.int/rec/T-REC-H.265>.
[H265]ITU-T，“高效视频编码”，ITU-T建议H.265，2015年4月<http://www.itu.int/rec/T-REC-H.265>.
[RTCWEB-OVERVIEW] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", Work in Progress, draft-ietf-rtcweb-overview-14, June 2015.
[RTCWEB-OVERVIEW]Alvestrand，H.，“概述：基于浏览器的应用程序的实时协议”，正在进行的工作，草稿-ietf-RTCWEB-OVERVIEW-14，2015年6月。
[WebRTC-RTP-USAGE] Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", Work in Progress, draft-ietf-rtcweb-rtp-usage-25, June 2015.
[WebRTC RTP使用]Perkins，C.，Westerlund，M.，和J.Ott，“网络实时通信（WebRTC）：媒体传输和RTP的使用”，在建工程，草案-ietf-rtcweb-RTP-USAGE-252015年6月。
[WebRTC-SEC] Rescorla, E., "Security Considerations for WebRTC", Work in Progress, draft-ietf-rtcweb-security-08, February 2015.
[WebRTC SEC]Rescorla，E.，“WebRTC的安全注意事项”，正在进行的工作，草稿-ietf-rtcweb-Security-082015年2月。
[WebRTC-SEC-ARCH] Rescorla, E., "WebRTC Security Architecture", Work in Progress, draft-ietf-rtcweb-security-arch-11, March 2015.
[WebRTC SEC ARCH]Rescorla，E.，“WebRTC安全架构”，正在进行的工作，草稿-ietf-rtcweb-Security-ARCH-11，2015年3月。
Acknowledgements
致谢
The author would like to thank Gaelle Martin-Cocher, Stephan Wenger, and Bernard Aboba for their detailed feedback and assistance with this document. Thanks to Cullen Jennings for providing text and review and to Russ Housley for a careful final review. This document includes text that originally appeared in "WebRTC Codec and Media Processing Requirements" (March 2012).
作者要感谢盖尔·马丁·科彻、斯蒂芬·温格和伯纳德·阿博巴对本文件的详细反馈和帮助。感谢Cullen Jennings提供了文本和评论，感谢Russ Housley提供了仔细的最终评论。本文档包含最初出现在“WebRTC编解码器和媒体处理要求”（2012年3月）中的文本。
Author's Address
作者地址
Adam Roach Mozilla Dallas United States
Adam Roach Mozilla美国达拉斯
Phone: +1 650 903 0800 x863
Email: adam@nostrum.com
Phone: +1 650 903 0800 x863
Email: adam@nostrum.com