[要約] RFC 7742は、WebRTCのビデオ処理とコーデックの要件に関する規格です。その目的は、WebRTCのビデオ通信における処理とコーデックの要件を定義し、互換性と品質の向上を促進することです。
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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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エンドポイントの主要な機能の1つは、インタラクティブビデオを送受信する機能です。ビデオは、カメラ、画面の記録、保存されたファイル、またはその他のソースから取得される場合があります。この仕様は、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-USAGE]で指定されています。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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互換エンドポイントに与える影響に注意することです。
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]で定義されている「ColourPrimaries」のコードポイント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 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自動光レベル制御o使用中の実際のエンコーディングに基づくビデオキャプチャの動的フレームレート（たとえば、帯域幅の制約、低光量条件、またはアプリケーション設定により15 fpsでエンコーディングする場合、カメラは理想的には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）は、このドキュメントの執筆時に使用されているほとんどのシステムで生成される画面コンテンツの表現に最適ではないことがわかっていることに注意してください。サンプルあたり少なくとも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ビットの解釈をサポートする必要があり（SHOULD）、他のCVOビットをサポートする場合があります（MAY）。
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 "Display Orientation"メッセージ）。 CVOがネゴシエートされている場合、送信者はそのようなコーデック固有のメカニズムを利用してはなりません（MUST NOT）。ただし、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の後継ワーキンググループの使用を促進するために、2つの必須のコーデックに関係する進化するライセンスランドスケープを監視する予定です。 。コーデックの1つが著作権使用料なしで使用できるという説得力のある証拠が生じた場合、ワーキンググループは、ブラウザー以外のユーザーにどのコーデックが必要であるかという問題を再検討することを計画しています。実装は必須で、他はオプションになります。
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ブラウザーに必須のビデオコーデックを少なくとも1つ実装することをお勧めします。実装者は実装することをお勧めします。
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ピクセルx 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.
packetization-mode：Packetization-mode 1をサポートする必要があります。他のモードは交渉され、使用されるかもしれません。
profile-level-id: Implementations MUST include this parameter within SDP and MUST interpret it when receiving it.
profile-level-id：実装は、SDP内にこのパラメーターを含める必要があり、受信時にそれを解釈する必要があります。
max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br:
max-mbps、max-smbps、max-fs、max-cpb、max-dpb、max-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の特定の機能を、それらのレベル（profile-level-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-parameter-sets：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メッセージの適切な解釈をサポートする必要があります（SHOULD）。
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.
実装は、「Rec。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では、ビデオはDatagram Transport Layer Security（DTLS）/ Secure Real-time Transport Protocol（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、「Advanced audiocoding for generic audiovisual services（V9）」、ITU-T Recommendation 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、「RTP Payload Format for H.264 Video」、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、「Session Description Protocol（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.、and Y. Xu、 "VP8 Data Format and Decoding Guide"、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] Westin、P.、Lundin、H.、Glover、M.、Uberti、J。、およびF. Galligan、「VP8ビデオのRTPペイロード形式」、RFC 7741、DOI 10.17487 / RFC7741、2016年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-1、1999年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。、「Overview：Real Time Protocols for Browser-based Applications」、Work in Progress、draft-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-USAGE] Perkins、C.、Westerlund、M.、J。Ott、「Web Real-Time Communication（WebRTC）：Media Transport and Use of RTP」、Work in Progress、draft-ietf-rtcweb- rtp-usage-25、2015年6月。
[WebRTC-SEC] Rescorla, E., "Security Considerations for WebRTC", Work in Progress, draft-ietf-rtcweb-security-08, February 2015.
[WebRTC-SEC] Rescorla、E。、「WebRTCのセキュリティに関する考慮事項」、Work in Progress、draft-ietf-rtcweb-security-08、2015年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 Security Architecture」、Work in Progress、draft-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).
著者は、Gaelle Martin-Cocher、Stephan Wenger、およびBernard Abobaに、このドキュメントに対する詳細なフィードバックと支援に感謝します。テキストとレビューを提供してくれたCullen Jenningsと、慎重な最終レビューをしてくれたRuss Housleyに感謝します。このドキュメントには、「WebRTCコーデックとメディア処理の要件」（2012年3月）で最初に表示されたテキストが含まれています。
Author's Address
著者のアドレス
Adam Roach Mozilla Dallas United States
アダムローチモジラダラスアメリカ合衆国
Phone: +1 650 903 0800 x863
Email: adam@nostrum.com