--- 1/draft-ietf-rtcweb-video-04.txt 2015-03-19 12:14:37.427425741 -0700 +++ 2/draft-ietf-rtcweb-video-05.txt 2015-03-19 12:14:37.451426329 -0700 @@ -1,18 +1,18 @@ Network Working Group A.B. Roach Internet-Draft Mozilla -Intended status: Standards Track February 13, 2015 -Expires: August 17, 2015 +Intended status: Standards Track March 17, 2015 +Expires: September 18, 2015 WebRTC Video Processing and Codec Requirements - draft-ietf-rtcweb-video-04 + draft-ietf-rtcweb-video-05 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 August 17, 2015. + This Internet-Draft will expire on September 18, 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 @@ -50,27 +50,27 @@ 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 5. Mandatory to Implement Video Codec . . . . . . . . . . . . . 4 6. Codec-Specific Considerations . . . . . . . . . . . . . . . . 5 6.1. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 6.2. H.264 . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 9 + 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. @@ -167,21 +167,21 @@ Further, some codecs support in-band signaling of orientation (for example, the SEI "Display Orientation" messages in H.264 and H.265). 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 Brower," "WebRTC Non-Browser", and + For the definitions of "WebRTC Browser," "WebRTC Non-Browser", and "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]. @@ -201,24 +201,26 @@ "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]. If a - recipient of video indicates a receiving resolution, the sender - SHOULD accommodate this resolution, as the receiver may not be - capable of handling higher resolutions. + 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 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]. @@ -283,23 +286,25 @@ 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]. Implementers should consider + [I-D.ietf-rtcweb-security-arch]. Implementors should consider whether the use of variable bit rate video codecs are appropriate for - their application based on [RFC6562]. + 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. @@ -335,46 +340,31 @@ [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. - [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for - Uncompressed Video", RFC 4175, September 2005. - - [RFC4421] Perkins, C., "RTP Payload Format for Uncompressed Video: - Additional Colour Sampling Modes", RFC 4421, February - 2006. - - [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, - "Codec Control Messages in the RTP Audio-Visual Profile - with Feedback (AVPF)", RFC 5104, February 2008. - [RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, May 2011. [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)", RFC 6236, May 2011. [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding Guide", RFC 6386, November 2011. - [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of - Variable Bit Rate Audio with Secure RTP", RFC 6562, March - 2012. - [SRGB] IEC 61966-2-1, "Multimedia systems and equipment - Colour measurement and management - Part 2-1: Colour management - Default RGB colour space - sRGB.", October 1999, . [TS26.114] 3GPP TS 26.114 V12.8.0, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction (Release 12)",