draft-ietf-rtcweb-video-04.txt   draft-ietf-rtcweb-video-05.txt 
Network Working Group A.B. Roach Network Working Group A.B. Roach
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track February 13, 2015 Intended status: Standards Track March 17, 2015
Expires: August 17, 2015 Expires: September 18, 2015
WebRTC Video Processing and Codec Requirements WebRTC Video Processing and Codec Requirements
draft-ietf-rtcweb-video-04 draft-ietf-rtcweb-video-05
Abstract Abstract
This specification provides the requirements and considerations for This specification provides the requirements and considerations for
WebRTC applications to send and receive video across a network. It WebRTC applications to send and receive video across a network. It
specifies the video processing that is required, as well as video specifies the video processing that is required, as well as video
codecs and their parameters. codecs and their parameters.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Pre and Post Processing . . . . . . . . . . . . . . . . . . . 2 3. Pre and Post Processing . . . . . . . . . . . . . . . . . . . 2
3.1. Camera Source Video . . . . . . . . . . . . . . . . . . . 3 3.1. Camera Source Video . . . . . . . . . . . . . . . . . . . 3
3.2. Screen Source Video . . . . . . . . . . . . . . . . . . . 3 3.2. Screen Source Video . . . . . . . . . . . . . . . . . . . 3
4. Stream Orientation . . . . . . . . . . . . . . . . . . . . . 3 4. Stream Orientation . . . . . . . . . . . . . . . . . . . . . 3
5. Mandatory to Implement Video Codec . . . . . . . . . . . . . 4 5. Mandatory to Implement Video Codec . . . . . . . . . . . . . 4
6. Codec-Specific Considerations . . . . . . . . . . . . . . . . 5 6. Codec-Specific Considerations . . . . . . . . . . . . . . . . 5
6.1. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.2. H.264 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.2. H.264 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
One of the major functions of WebRTC endpoints is the ability to send 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 and receive interactive video. The video might come from a camera, a
screen recording, a stored file, or some other source. This screen recording, a stored file, or some other source. This
specification defines how the video is used and discusses special specification defines how the video is used and discusses special
considerations for processing the video. It also covers the video- considerations for processing the video. It also covers the video-
related algorithms WebRTC devices need to support. related algorithms WebRTC devices need to support.
skipping to change at page 4, line 37 skipping to change at page 4, line 37
Further, some codecs support in-band signaling of orientation (for Further, some codecs support in-band signaling of orientation (for
example, the SEI "Display Orientation" messages in H.264 and H.265). 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 If CVO has been negotiated, then the sender MUST NOT make use of such
codec-specific mechanisms. However, when support for CVO is not codec-specific mechanisms. However, when support for CVO is not
signaled in the SDP, then such implementations MAY make use of the signaled in the SDP, then such implementations MAY make use of the
codec-specific mechanisms instead. codec-specific mechanisms instead.
5. Mandatory to Implement Video Codec 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 "WebRTC-Compatible Endpoint" as they are used in this section, please
refer to [I-D.ietf-rtcweb-overview]. refer to [I-D.ietf-rtcweb-overview].
WebRTC Browsers MUST implement the VP8 video codec as described in WebRTC Browsers MUST implement the VP8 video codec as described in
[RFC6386] and H.264 Constrained Baseline as described in [H264]. [RFC6386] and H.264 Constrained Baseline as described in [H264].
WebRTC Non-Browsers that support transmitting and/or receiving video WebRTC Non-Browsers that support transmitting and/or receiving video
MUST implement the VP8 video codec as described in [RFC6386] and MUST implement the VP8 video codec as described in [RFC6386] and
H.264 Constrained Baseline as described in [H264]. H.264 Constrained Baseline as described in [H264].
skipping to change at page 5, line 23 skipping to change at page 5, line 23
"WebRTC-compatible endpoints" are free to implement any video codecs "WebRTC-compatible endpoints" are free to implement any video codecs
they see fit. This follows logically from the definition of "WebRTC- they see fit. This follows logically from the definition of "WebRTC-
compatible endpoint." It is, of course, advisable to implement at compatible endpoint." It is, of course, advisable to implement at
least one of the video codecs that is mandated for WebRTC Browsers, least one of the video codecs that is mandated for WebRTC Browsers,
and implementors are encouraged to do so. and implementors are encouraged to do so.
6. Codec-Specific Considerations 6. Codec-Specific Considerations
SDP allows for codec-independent indication of preferred video SDP allows for codec-independent indication of preferred video
resolutions using the mechanism described in [RFC6236]. If a resolutions using the mechanism described in [RFC6236]. WebRTC
recipient of video indicates a receiving resolution, the sender endpoints MAY send an "a=imageattr" attribute to indicate the maximum
SHOULD accommodate this resolution, as the receiver may not be resolution they wish to receive. Senders SHOULD interpret and honor
capable of handling higher resolutions. 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 Additionally, codecs may include codec-specific means of signaling
maximum receiver abilities with regards to resolution, frame rate, maximum receiver abilities with regards to resolution, frame rate,
and bitrate. and bitrate.
Unless otherwise signaled in SDP, recipients of video streams MUST be 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 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 at least 320x240. These values are selected based on the
recommendations in [HSUP1]. recommendations in [HSUP1].
skipping to change at page 7, line 11 skipping to change at page 7, line 14
Unless otherwise signaled, implementations that use H.264 MUST encode Unless otherwise signaled, implementations that use H.264 MUST encode
and decode pixels with a implied 1:1 (square) aspect ratio. and decode pixels with a implied 1:1 (square) aspect ratio.
7. Security Considerations 7. Security Considerations
This specification does not introduce any new mechanisms or security This specification does not introduce any new mechanisms or security
concerns beyond what the other documents it references. In WebRTC, concerns beyond what the other documents it references. In WebRTC,
video is protected using DTLS/SRTP. A complete discussion of the video is protected using DTLS/SRTP. A complete discussion of the
security can be found in [I-D.ietf-rtcweb-security] and 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 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 Implementors making use of H.264 are also advised to take careful
note of the "Security Considerations" section of [RFC6184], paying note of the "Security Considerations" section of [RFC6184], paying
special regard to the normative requirement pertaining to SEI special regard to the normative requirement pertaining to SEI
messages. messages.
8. IANA Considerations 8. IANA Considerations
This document requires no actions from IANA. This document requires no actions from IANA.
skipping to change at page 8, line 14 skipping to change at page 8, line 19
[IEC23001-8] [IEC23001-8]
ISO/IEC 23001-8:2013/DCOR1, "Coding independent media ISO/IEC 23001-8:2013/DCOR1, "Coding independent media
description code points", 2013, <http://standards.iso.org/ description code points", 2013, <http://standards.iso.org/
ittf/PubliclyAvailableStandards/ ittf/PubliclyAvailableStandards/
c062088_ISO_IEC_23001-8_2013.zip>. c062088_ISO_IEC_23001-8_2013.zip>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP
Payload Format for H.264 Video", RFC 6184, May 2011. Payload Format for H.264 Video", RFC 6184, May 2011.
[RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image
Attributes in the Session Description Protocol (SDP)", RFC Attributes in the Session Description Protocol (SDP)", RFC
6236, May 2011. 6236, May 2011.
[RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J.,
Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding
Guide", RFC 6386, November 2011. 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 [SRGB] IEC 61966-2-1, "Multimedia systems and equipment - Colour
measurement and management - Part 2-1: Colour management - measurement and management - Part 2-1: Colour management -
Default RGB colour space - sRGB.", October 1999, <http:// Default RGB colour space - sRGB.", October 1999, <http://
www.colour.org/tc8-05/Docs/colorspace/61966-2-1.pdf>. www.colour.org/tc8-05/Docs/colorspace/61966-2-1.pdf>.
[TS26.114] [TS26.114]
3GPP TS 26.114 V12.8.0, "3rd Generation Partnership 3GPP TS 26.114 V12.8.0, "3rd Generation Partnership
Project; Technical Specification Group Services and System Project; Technical Specification Group Services and System
Aspects; IP Multimedia Subsystem (IMS); Multimedia Aspects; IP Multimedia Subsystem (IMS); Multimedia
Telephony; Media handling and interaction (Release 12)", Telephony; Media handling and interaction (Release 12)",
 End of changes. 11 change blocks. 
28 lines changed or deleted 17 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/