draft-ietf-rtcweb-video-05.txt   draft-ietf-rtcweb-video-06.txt 
Network Working Group A.B. Roach Network Working Group A.B. Roach
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track March 17, 2015 Intended status: Standards Track June 12, 2015
Expires: September 18, 2015 Expires: December 14, 2015
WebRTC Video Processing and Codec Requirements WebRTC Video Processing and Codec Requirements
draft-ietf-rtcweb-video-05 draft-ietf-rtcweb-video-06
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 September 18, 2015. This Internet-Draft will expire on December 14, 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 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . 8 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 provides the requirements and considerations for WebRTC
considerations for processing the video. It also covers the video- applications to send and receive video across a network. It
related algorithms WebRTC devices need to support. 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 Note that this document only discusses those issues dealing with
video codec handling. Issues that are related to transport of media video codec handling. Issues that are related to transport of media
streams across the network are specified in streams across the network are specified in
[I-D.ietf-rtcweb-rtp-usage]. [I-D.ietf-rtcweb-rtp-usage].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Pre and Post Processing 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. streams.
Unless specified otherwise by the SDP or codec, the color space Unless specified otherwise by the SDP or codec, the color space
SHOULD be sRGB [SRGB]. For clarity, this the color space indicated SHOULD be sRGB [SRGB]. For clarity, this is the color space
by codepoint 1 from "ColourPrimaries" as defined in [IEC23001-8]. indicated by codepoint 1 from "ColourPrimaries" as defined in
[IEC23001-8].
Unless specified otherwise by the SDP or codec, the video scan Unless specified otherwise by the SDP or codec, the video scan
pattern for video codecs is Y'CbCr 4:2:0. pattern for video codecs is Y'CbCr 4:2:0.
3.1. Camera Source Video 3.1. Camera Source Video
This document imposes no normative requirements on camera capture; This document imposes no normative requirements on camera capture;
however, implementors are encouraged to take advantage of the however, implementors are encouraged to take advantage of the
following features, if feasible for their platform: following features, if feasible for their platform:
skipping to change at page 4, line 48 skipping to change at page 4, line 51
"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].
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 participants in the RTCWEB working group, and any successor
working groups in the IETF, intend to monitor the evolving working groups in the IETF, intend to monitor the evolving
licensing landscape as it pertains to the two mandatory-to- licensing landscape as it pertains to the two mandatory-to-
implement codecs. If compelling evidence arises that one of the implement codecs. If compelling evidence arises that one of the
codecs is available for use on a royalty-free basis, the working codecs is available for use on a royalty-free basis, the working
group plans to revisit the question of which codecs are required group plans to revisit the question of which codecs are required
for Non-Browsers, with the intention being that the royalty-free for Non-Browsers, with the intention being that the royalty-free
codec will remain mandatory to implement, and the other will codec will remain mandatory to implement, and the other will
become optional. become optional.
skipping to change at page 5, line 36 skipping to change at page 5, line 38
this attribute by limiting the encoded resolution to the indicated this attribute by limiting the encoded resolution to the indicated
maximum size, as the receiver may not be capable of handling higher maximum size, as the receiver may not be capable of handling higher
resolutions. 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 320 pixels by 240 pixels. These values are selected based
recommendations in [HSUP1]. on the recommendations in [HSUP1].
Encoders are encouraged to support encoding media with at least the Encoders are encouraged to support encoding media with at least the
same resolution and frame rates cited above. same resolution and frame rates cited above.
6.1. VP8 6.1. VP8
For the VP8 codec, defined in [RFC6386], endpoints MUST support the For the VP8 codec, defined in [RFC6386], endpoints MUST support the
payload formats defined in [I-D.ietf-payload-vp8]. payload formats defined in [I-D.ietf-payload-vp8].
In addition to the [RFC6236] mechanism, VP8 encoders MUST limit the In addition to the [RFC6236] mechanism, VP8 encoders MUST limit the
streams they send to conform to the values indicated by receivers in streams they send to conform to the values indicated by receivers in
the corresponding max-fr and max-fs SDP attributes. 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 6.2. H.264
For the [H264] codec, endpoints MUST support the payload formats For the [H264] codec, endpoints MUST support the payload formats
defined in [RFC6184]. In addition, they MUST support Constrained defined in [RFC6184]. In addition, they MUST support Constrained
Baseline Profile Level 1.2, and they SHOULD support H.264 Constrained Baseline Profile Level 1.2, and they SHOULD support H.264 Constrained
High Profile Level 1.3. High Profile Level 1.3.
Implementations of the H.264 codec have utilized a wide variety of Implementations of the H.264 codec have utilized a wide variety of
optional parameters. To improve interoperability the following optional parameters. To improve interoperability the following
parameter settings are specified: parameter settings are specified:
skipping to change at page 7, line 11 skipping to change at page 7, line 13
ITU-T T.35" and "User data unregistered" messages. Even if they do ITU-T T.35" and "User data unregistered" messages. Even if they do
not act on them, implementations MUST be prepared to receive such not act on them, implementations MUST be prepared to receive such
messages without any ill effects. messages without any ill effects.
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 is in the other documents it references. In
video is protected using DTLS/SRTP. A complete discussion of the WebRTC, video is protected using DTLS/SRTP. A complete discussion of
security can be found in [I-D.ietf-rtcweb-security] and the security considerations can be found in
[I-D.ietf-rtcweb-security-arch]. Implementors should consider [I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch].
whether the use of variable bit rate video codecs are appropriate for Implementors should consider whether the use of variable bit rate
their application, keeping in mind that the degree of inter-frame video codecs are appropriate for their application, keeping in mind
change (and, by inference, the amount of motion in the frame) may be that the degree of inter-frame change (and, by inference, the amount
deduced by an eavesdropper based on the video stream's bit rate. 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.
9. Acknowledgements 9. Acknowledgements
The author would like to thank Gaelle Martin-Cocher, Stephan Wenger, The author would like to thank Gaelle Martin-Cocher, Stephan Wenger,
and Bernard Aboba for their detailed feedback and assistance with and Bernard Aboba for their detailed feedback and assistance with
this document. Thanks to Cullen Jennings for providing text and 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. References
10.1. Normative References 10.1. Normative References
[H264] ITU-T Recommendation H.264, "Advanced video coding for [H264] ITU-T Recommendation H.264, "Advanced video coding for
generic audiovisual services (V9)", February 2014, generic audiovisual services (V9)", February 2014,
<http://www.itu.int/rec/T-REC-H.264-201304-I>. <http://www.itu.int/rec/T-REC-H.264>.
[HSUP1] ITU-T Recommendation H.Sup1, "Application profile - Sign [HSUP1] ITU-T Recommendation H.Sup1, "Application profile - Sign
language and lip-reading real-time conversation using low language and lip-reading real-time conversation using low
bit rate video communication", May 1999, bit rate video communication", May 1999,
<http://www.itu.int/rec/T-REC-H.Sup1>. <http://www.itu.int/rec/T-REC-H.Sup1>.
[I-D.ietf-payload-vp8] [I-D.ietf-payload-vp8]
Westin, P., Lundin, H., Glover, M., Uberti, J., and F. Westin, P., Lundin, H., Glover, M., Uberti, J., and F.
Galligan, "RTP Payload Format for VP8 Video", draft-ietf- 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] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-12 Browser-based Applications", draft-ietf-rtcweb-overview-13
(work in progress), October 2014. (work in progress), November 2014.
[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.
skipping to change at page 8, line 47 skipping to change at page 9, line 6
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)",
December 2014, <http://www.3gpp.org/DynaReport/26114.htm>. December 2014, <http://www.3gpp.org/DynaReport/26114.htm>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-rtcweb-rtp-usage] [I-D.ietf-rtcweb-rtp-usage]
Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
Communication (WebRTC): Media Transport and Use of RTP", Communication (WebRTC): Media Transport and Use of RTP",
draft-ietf-rtcweb-rtp-usage-06 (work in progress), draft-ietf-rtcweb-rtp-usage-24 (work in progress), May
February 2013. 2015.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- 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] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", draft- 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 Author's Address
Adam Roach Adam Roach
Mozilla Mozilla
\ \
Dallas Dallas
US US
Phone: +1 650 903 0800 x863 Phone: +1 650 903 0800 x863
 End of changes. 18 change blocks. 
31 lines changed or deleted 38 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/