--- 1/draft-ietf-rtcweb-video-05.txt 2015-06-12 08:15:56.993319540 -0700 +++ 2/draft-ietf-rtcweb-video-06.txt 2015-06-12 08:15:57.041320715 -0700 @@ -1,18 +1,18 @@ Network Working Group A.B. Roach Internet-Draft Mozilla -Intended status: Standards Track March 17, 2015 -Expires: September 18, 2015 +Intended status: Standards Track June 12, 2015 +Expires: December 14, 2015 WebRTC Video Processing and Codec Requirements - draft-ietf-rtcweb-video-05 + draft-ietf-rtcweb-video-06 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 @@ -22,21 +22,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 18, 2015. + This Internet-Draft will expire on December 14, 2015. Copyright Notice Copyright (c) 2015 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 @@ -46,61 +46,63 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Pre and Post Processing . . . . . . . . . . . . . . . . . . . 2 3.1. Camera Source Video . . . . . . . . . . . . . . . . . . . 3 3.2. Screen Source Video . . . . . . . . . . . . . . . . . . . 3 - 4. Stream Orientation . . . . . . . . . . . . . . . . . . . . . 3 + 4. Stream Orientation . . . . . . . . . . . . . . . . . . . . . 4 5. Mandatory to Implement Video Codec . . . . . . . . . . . . . 4 6. Codec-Specific Considerations . . . . . . . . . . . . . . . . 5 6.1. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.2. H.264 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 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 defines how the video is used and discusses special - considerations for processing the video. It also covers the video- - related algorithms WebRTC devices need to support. + 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 [I-D.ietf-rtcweb-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]. 3. Pre and Post Processing - This section provides guidance on pre- or post-processing of video + This section provides guidance on pre- and post-processing of video streams. Unless specified otherwise by the SDP or codec, the color space - SHOULD be sRGB [SRGB]. For clarity, this the color space indicated - by codepoint 1 from "ColourPrimaries" as defined in [IEC23001-8]. + 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: @@ -178,21 +181,21 @@ "WebRTC-Compatible Endpoint" as they are used in this section, please refer to [I-D.ietf-rtcweb-overview]. 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]. - To promote the use of non-royalty bearing video codecs, + 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. @@ -214,35 +217,38 @@ 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 regards 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 320x240. These values are selected based on the - recommendations in [HSUP1]. + 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 [I-D.ietf-payload-vp8]. 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 a 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 they SHOULD support H.264 Constrained High Profile Level 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: @@ -283,67 +289,69 @@ 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 a implied 1:1 (square) aspect ratio. 7. Security Considerations This specification does not introduce any new mechanisms or security - concerns beyond what the other documents it references. In WebRTC, - video is protected using DTLS/SRTP. A complete discussion of the - security can be found in [I-D.ietf-rtcweb-security] and - [I-D.ietf-rtcweb-security-arch]. Implementors should consider - whether the use of variable bit rate 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 bit rate. + concerns beyond what is in the other documents it references. In + WebRTC, video is protected using DTLS/SRTP. A complete discussion of + the security considerations can be found in + [I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch]. + Implementors should consider whether the use of variable bit rate + 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 bit rate. 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. IANA Considerations This document requires no actions from IANA. 9. 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. This draft includes text from draft-cbran-rtcweb-codec. + review, and to Russ Housley for a careful final review. This draft + includes text from draft-cbran-rtcweb-codec. 10. References 10.1. Normative References [H264] ITU-T Recommendation H.264, "Advanced video coding for generic audiovisual services (V9)", February 2014, - . + . [HSUP1] ITU-T Recommendation H.Sup1, "Application profile - Sign language and lip-reading real-time conversation using low bit rate video communication", May 1999, . [I-D.ietf-payload-vp8] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. Galligan, "RTP Payload Format for VP8 Video", draft-ietf- - payload-vp8-11 (work in progress), February 2014. + payload-vp8-16 (work in progress), June 2015. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for - Browser-based Applications", draft-ietf-rtcweb-overview-12 - (work in progress), October 2014. + Browser-based Applications", draft-ietf-rtcweb-overview-13 + (work in progress), November 2014. [IEC23001-8] ISO/IEC 23001-8:2013/DCOR1, "Coding independent media description code points", 2013, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -368,30 +376,30 @@ Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction (Release 12)", December 2014, . 10.2. Informative References [I-D.ietf-rtcweb-rtp-usage] Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", - draft-ietf-rtcweb-rtp-usage-06 (work in progress), - February 2013. + draft-ietf-rtcweb-rtp-usage-24 (work in progress), May + 2015. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- - rtcweb-security-arch-09 (work in progress), February 2014. + rtcweb-security-arch-11 (work in progress), March 2015. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- - ietf-rtcweb-security-06 (work in progress), January 2014. + ietf-rtcweb-security-08 (work in progress), February 2015. Author's Address Adam Roach Mozilla \ Dallas US Phone: +1 650 903 0800 x863