doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc7742.txt b/doc/rfc/rfc7742.txt
new file mode 100644
index 0000000..dd96427
--- /dev/null
+++ b/doc/rfc/rfc7742.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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
+
+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.
+
+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.
+
+   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.
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+
+
+
+
+
+
+
+Roach                        Standards Track                    [Page 1]
+
+RFC 7742                      WebRTC Video                    March 2016
+
+
+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
+
+   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.
+
+   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].
+
+2.  Terminology
+
+   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].
+
+   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]).
+
+
+
+
+
+
+
+Roach                        Standards Track                    [Page 2]
+
+RFC 7742                      WebRTC Video                    March 2016
+
+
+   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  A WebRTC endpoint is either a WebRTC browser or a WebRTC non-
+      browser.  It conforms to the protocol specification.
+
+   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.
+
+   These definitions are also found in [RTCWEB-OVERVIEW] and that
+   document should be consulted for additional information.
+
+3.  Pre- and Post-Processing
+
+   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].
+
+   Unless specified otherwise by the SDP or codec, the video scan
+   pattern for video codecs is Y'CbCr 4:2:0.
+
+3.1.  Camera-Source Video
+
+   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  Automatic white balance
+
+   o  Automatic light-level control
+
+
+
+
+
+
+
+Roach                        Standards Track                    [Page 3]
+
+RFC 7742                      WebRTC Video                    March 2016
+
+
+   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).
+
+3.2.  Screen-Source Video
+
+   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.
+
+   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.
+
+   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].
+
+4.  Stream Orientation
+
+   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.
+
+
+
+
+
+
+Roach                        Standards Track                    [Page 4]
+
+RFC 7742                      WebRTC Video                    March 2016
+
+
+   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.
+
+   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.
+
+5.  Mandatory-to-Implement Video Codec
+
+   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 Browsers MUST implement the VP8 video codec as described in
+   [RFC6386] and H.264 Constrained Baseline as described in [H264].
+
+   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].
+
+      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.
+
+      These provisions apply to WebRTC Non-Browsers only.  There is no
+      plan to revisit the codecs required for WebRTC Browsers.
+
+
+
+
+
+
+
+
+Roach                        Standards Track                    [Page 5]
+
+RFC 7742                      WebRTC Video                    March 2016
+
+
+   "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.
+
+6.  Codec-Specific Considerations
+
+   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.
+
+   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].
+
+   Encoders are encouraged to support encoding media with at least the
+   same resolution and frame rates cited above.
+
+6.1.  VP8
+
+   For the VP8 codec, defined in [RFC6386], endpoints MUST support the
+   payload formats defined in [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.
+
+   Unless otherwise signaled, implementations that use VP8 MUST encode
+   and decode pixels with an implied 1:1 (square) aspect ratio.
+
+6.2.  H.264
+
+   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.
+
+
+
+
+
+Roach                        Standards Track                    [Page 6]
+
+RFC 7742                      WebRTC Video                    March 2016
+
+
+   Implementations of the H.264 codec have utilized a wide variety of
+   optional parameters.  To improve interoperability, the following
+   parameter settings are specified:
+
+   packetization-mode:  Packetization-mode 1 MUST be supported.  Other
+      modes MAY be negotiated and used.
+
+   profile-level-id:  Implementations MUST include this parameter within
+      SDP and MUST interpret it when receiving it.
+
+   max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and 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.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   Unless otherwise signaled, implementations that use H.264 MUST encode
+   and decode pixels with an implied 1:1 (square) aspect ratio.
+
+
+
+
+
+
+
+
+Roach                        Standards Track                    [Page 7]
+
+RFC 7742                      WebRTC Video                    March 2016
+
+
+7.  Security Considerations
+
+   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.
+
+   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.
+
+8.  References
+
+8.1.  Normative References
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+
+Roach                        Standards Track                    [Page 8]
+
+RFC 7742                      WebRTC Video                    March 2016
+
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+8.2.  Informative References
+
+   [H265]     ITU-T, "High efficiency video coding",
+              ITU-T Recommendation H.265, April 2015,
+              <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.
+
+   [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-SEC]
+              Rescorla, E., "Security Considerations for WebRTC", Work
+              in Progress, draft-ietf-rtcweb-security-08, February 2015.
+
+
+
+
+
+
+Roach                        Standards Track                    [Page 9]
+
+RFC 7742                      WebRTC Video                    March 2016
+
+
+   [WebRTC-SEC-ARCH]
+              Rescorla, E., "WebRTC Security Architecture", Work in
+              Progress, draft-ietf-rtcweb-security-arch-11, March 2015.
+
+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).
+
+Author's Address
+
+   Adam Roach
+   Mozilla
+   Dallas
+   United States
+
+   Phone: +1 650 903 0800 x863
+   Email: adam@nostrum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Roach                        Standards Track                   [Page 10]
+