draft-ietf-rtcweb-video-06.txt   rfc7742.txt 
Network Working Group A.B. Roach Internet Engineering Task Force (IETF) A.B. Roach
Internet-Draft Mozilla Request for Comments: 7742 Mozilla
Intended status: Standards Track June 12, 2015 Category: Standards Track March 2016
Expires: December 14, 2015 ISSN: 2070-1721
WebRTC Video Processing and Codec Requirements WebRTC Video Processing and Codec Requirements
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
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on December 14, 2015. 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 Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . 3
3.1. Camera Source Video . . . . . . . . . . . . . . . . . . . 3 3.1. Camera-Source Video . . . . . . . . . . . . . . . . . . . 3
3.2. Screen Source Video . . . . . . . . . . . . . . . . . . . 3 3.2. Screen-Source Video . . . . . . . . . . . . . . . . . . . 4
4. Stream Orientation . . . . . . . . . . . . . . . . . . . . . 4 4. Stream Orientation . . . . . . . . . . . . . . . . . . . . . 4
5. Mandatory to Implement Video Codec . . . . . . . . . . . . . 4 5. Mandatory-to-Implement Video Codec . . . . . . . . . . . . . 5
6. Codec-Specific Considerations . . . . . . . . . . . . . . . . 5 6. Codec-Specific Considerations . . . . . . . . . . . . . . . . 6
6.1. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. H.264 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2. H.264 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
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 provides the requirements and considerations for WebRTC specification provides the requirements and considerations for WebRTC
applications to send and receive video across a network. It 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.
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 [WebRTC-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 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]).
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 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 Session Description Protocol (SDP)
SHOULD be sRGB [SRGB]. For clarity, this is the color space or codec, the color space SHOULD be sRGB [SRGB]. For clarity, this
indicated by codepoint 1 from "ColourPrimaries" as defined in is the color space indicated by codepoint 1 from "ColourPrimaries" as
[IEC23001-8]. 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:
o Automatic focus, if applicable for the camera in use o Automatic focus, if applicable for the camera in use
o Automatic white balance o Automatic white balance
o Automatic light level control o Automatic light-level control
o Dynamic frame rate for video capture based on actual encoding in 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 use (e.g., if encoding at 15 fps due to bandwidth constraints, low
light conditions, or application settings, the camera will ideally light conditions, or application settings, the camera will ideally
capture at 15 fps rather than a higher rate). capture at 15 fps rather than a higher rate).
3.2. Screen Source Video 3.2. Screen-Source Video
If the video source is some portion of a computer screen (e.g., If the video source is some portion of a computer screen (e.g.,
desktop or application sharing), then the considerations in this desktop or application sharing), then the considerations in this
section also apply. section also apply.
Because screen-sourced video can change resolution (due to, e.g., Because screen-sourced video can change resolution (due to, e.g.,
window resizing and similar operations), WebRTC video recipients MUST window resizing and similar operations), WebRTC-video recipients MUST
be prepared to handle mid-stream resolution changes in a way that be prepared to handle midstream resolution changes in a way that
preserves their utility. Precise handling (e.g., resizing the preserves their utility. Precise handling (e.g., resizing the
element a video is rendered in versus scaling down the received element a video is rendered in versus scaling down the received
stream; decisions around letter/pillarboxing) is left to the stream; decisions around letter/pillarboxing) is left to the
discretion of the application. discretion of the application.
Note that the default video scan format (Y'CbCr 4:2:0) is known to be 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 less than optimal for the representation of screen content produced
by most systems in use at the time of this document's publication, by most systems in use at the time of this document's writing, which
which generally use RGB with at least 24 bits per sample. In the generally use RGB with at least 24 bits per sample. In the future,
future, it may be advisable to use video codecs optimized for screen it may be advisable to use video codecs optimized for screen content
content for the representation of this type of content. for the representation of this type of content.
Additionally, attention is drawn to the requirements in Additionally, attention is drawn to the requirements in Section 5.2
[I-D.ietf-rtcweb-security-arch] section 5.2 and the considerations in of [WebRTC-SEC-ARCH] and the considerations in Section 4.1.1. of
[I-D.ietf-rtcweb-security] section 4.1.1. [WebRTC-SEC].
4. Stream Orientation 4. Stream Orientation
In some circumstances - and notably those involving mobile devices - In some circumstances -- and notably those involving mobile devices
the orientation of the camera may not match the orientation used by -- the orientation of the camera may not match the orientation used
the encoder. Of more importance, the orientation may change over the by the encoder. Of more importance, the orientation may change over
course of a call, requiring the receiver to change the orientation in the course of a call, requiring the receiver to change the
which it renders the stream. orientation in which it renders the stream.
While the sender may elect to simply change the pre-encoding While the sender may elect to simply change the pre-encoding
orientation of frames, this may not be practical or efficient (in orientation of frames, this may not be practical or efficient (in
particular, in cases where the interface to the camera returns pre- particular, in cases where the interface to the camera returns pre-
compressed video frames). Note that the potential for this behavior compressed video frames). Note that the potential for this behavior
adds another set of circumstances under which the resolution of a adds another set of circumstances under which the resolution of a
screen might change in the middle of a video stream, in addition to screen might change in the middle of a video stream, in addition to
those mentioned under "Screen Sourced Video," above. those mentioned in Section 3.2.
To accommodate these circumstances, RTCWEB implementations that can To accommodate these circumstances, WebRTC implementations that can
generate media in orientations other than the default MUST support generate media in orientations other than the default MUST support
generating the R0 and R1 bits of the Coordination of Video generating the R0 and R1 bits of the Coordination of Video
Orientation (CVO) mechanism described in section 7.4.5 of [TS26.114], Orientation (CVO) mechanism described in Section 7.4.5 of [TS26.114]
and MUST send them for all orientations when the peer indicates and MUST send them for all orientations when the peer indicates
support for the mechanism. They MAY support sending the other bits support for the mechanism. They MAY support sending the other bits
in the CVO extension, including the higher-resolution rotation bits. in the CVO extension, including the higher-resolution rotation bits.
All implementations SHOULD support interpretation of the R0 and R1 All implementations SHOULD support interpretation of the R0 and R1
bits, and MAY support the other CVO bits. bits and MAY support the other CVO bits.
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 [H265]). If CVO has been negotiated, then the sender MUST NOT make
codec-specific mechanisms. However, when support for CVO is not use of such codec-specific mechanisms. However, when support for CVO
signaled in the SDP, then such implementations MAY make use of the is not signaled in the SDP, then such implementations MAY make use of
codec-specific mechanisms instead. the codec-specific mechanisms instead.
5. Mandatory to Implement Video Codec 5. Mandatory-to-Implement Video Codec
For the definitions of "WebRTC Browser," "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 Section 2.
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].
NOTE: 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
become optional. optional.
These provisions apply to WebRTC Non-Browsers only. There is no These provisions apply to WebRTC Non-Browsers only. There is no
plan to revisit the codecs required for WebRTC Browsers. plan to revisit the codecs required for WebRTC Browsers.
"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]. WebRTC resolutions using the mechanism described in [RFC6236]. WebRTC
endpoints MAY send an "a=imageattr" attribute to indicate the maximum endpoints MAY send an "a=imageattr" attribute to indicate the maximum
resolution they wish to receive. Senders SHOULD interpret and honor resolution they wish to receive. Senders SHOULD interpret and honor
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 regard to resolution, frame rate, and
and bitrate. 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 320 pixels by 240 pixels. These values are selected based at least 320 pixels by 240 pixels. These values are selected based
on the 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 [RFC7741].
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 Unless otherwise signaled, implementations that use VP8 MUST encode
and decode pixels with a implied 1:1 (square) aspect ratio. and decode pixels with an 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 SHOULD support H.264 Constrained High
High Profile Level 1.3. 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:
packetization-mode: Packetization-mode 1 MUST be supported. Other packetization-mode: Packetization-mode 1 MUST be supported. Other
modes MAY be negotiated and used. modes MAY be negotiated and used.
profile-level-id: Implementations MUST include this parameter within profile-level-id: Implementations MUST include this parameter within
SDP and MUST interpret it when receiving it. SDP and MUST interpret it when receiving it.
max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br: These max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br:
parameters allow the implementation to specify that they can These parameters allow the implementation to specify that they can
support certain features of H.264 at higher rates and values than support certain features of H.264 at higher rates and values than
those signalled by their level (set with profile-level-id). those signaled by their level (set with profile-level-id).
Implementations MAY include these parameters in their SDP, but Implementations MAY include these parameters in their SDP, but
SHOULD interpret them when receiving them, allowing them to send they SHOULD interpret them when receiving them, allowing them to
the highest quality of video possible. send the highest quality of video possible.
sprop-parameter-sets: H.264 allows sequence and picture information sprop-parameter-sets: H.264 allows sequence and picture information
to be sent both in-band, and out-of-band. WebRTC implementations to be sent both in-band and out-of-band. WebRTC implementations
MUST signal this information in-band. This means that WebRTC MUST signal this information in-band. This means that WebRTC
implementations MUST NOT include this parameter in the SDP they implementations MUST NOT include this parameter in the SDP they
generate. generate.
H.264 codecs MAY send and MUST support proper interpretation of SEI H.264 codecs MAY send and MUST support proper interpretation of
"filler payload" and "full frame freeze" messages. "Full frame Supplemental Enhancement Information (SEI) "filler payload" and "full
freeze" messages are used in video switching MCUs, to ensure a stable frame freeze" messages. The "full frame freeze" messages are used in
decoded displayed picture while switching among various input video-switching MCUs, to ensure a stable decoded displayed picture
streams. while switching among various input streams.
When the use of the video orientation (CVO) RTP header extension is 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 not signaled as part of the SDP, H.264 implementations MAY send and
SHOULD support proper interpretation of Display Orientation SEI SHOULD support proper interpretation of Display Orientation SEI
messages. messages.
Implementations MAY send and act upon "User data registered by Rec. Implementations MAY send and act upon "User data registered by Rec.
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 an 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 is in the other documents it references. In concerns beyond what is in the other documents it references. In
WebRTC, video is protected using DTLS/SRTP. A complete discussion of WebRTC, video is protected using Datagram Transport Layer Security
the security considerations can be found in (DTLS) / Secure Real-time Transport Protocol (SRTP). A complete
[I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch]. discussion of the security considerations can be found in
Implementors should consider whether the use of variable bit rate [WebRTC-SEC] and [WebRTC-SEC-ARCH]. Implementors should consider
video codecs are appropriate for their application, keeping in mind whether the use of variable bitrate video codecs are appropriate for
that the degree of inter-frame change (and, by inference, the amount their application, keeping in mind that the degree of inter-frame
of motion in the frame) may be deduced by an eavesdropper based on change (and, by inference, the amount of motion in the frame) may be
the video stream's bit rate. deduced by an eavesdropper based on the video stream's bitrate.
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. References
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, and to Russ Housley for a careful final review. This draft
includes text from draft-cbran-rtcweb-codec.
10. References
10.1. Normative References 8.1. Normative References
[H264] ITU-T Recommendation H.264, "Advanced video coding for [H264] ITU-T, "Advanced video coding for generic audiovisual
generic audiovisual services (V9)", February 2014, services (V9)", ITU-T Recommendation H.264, February 2014,
<http://www.itu.int/rec/T-REC-H.264>. <http://www.itu.int/rec/T-REC-H.264>.
[HSUP1] ITU-T Recommendation H.Sup1, "Application profile - Sign [HSUP1] ITU-T, "Application profile - Sign language and lip-
language and lip-reading real-time conversation using low reading real-time conversation using low bit rate video
bit rate video communication", May 1999, communication", ITU-T Recommendation H.Sup1, 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]
Westin, P., Lundin, H., Glover, M., Uberti, J., and F.
Galligan, "RTP Payload Format for VP8 Video", draft-ietf-
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-13
(work in progress), November 2014.
[IEC23001-8] [IEC23001-8]
ISO/IEC 23001-8:2013/DCOR1, "Coding independent media ISO/IEC, "Coding independent media description code
description code points", 2013, <http://standards.iso.org/ points", ISO/IEC 23001-8:2013/DCOR1, 2013,
ittf/PubliclyAvailableStandards/ <http://standards.iso.org/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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP [RFC6184] Wang, Y., 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,
DOI 10.17487/RFC6184, May 2011,
<http://www.rfc-editor.org/info/rfc6184>.
[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)",
6236, May 2011. RFC 6236, DOI 10.17487/RFC6236, May 2011,
<http://www.rfc-editor.org/info/rfc6236>.
[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, DOI 10.17487/RFC6386, November 2011,
<http://www.rfc-editor.org/info/rfc6386>.
[SRGB] IEC 61966-2-1, "Multimedia systems and equipment - Colour [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 - measurement and management - Part 2-1: Colour management -
Default RGB colour space - sRGB.", October 1999, <http:// Default RGB colour space - sRGB.", IEC 61966-2-1, October
www.colour.org/tc8-05/Docs/colorspace/61966-2-1.pdf>. 1999, <https://webstore.iec.ch/publication/6169>.
[TS26.114] [TS26.114] 3GPP, "IP Multimedia Subsystem (IMS); Multimedia
3GPP TS 26.114 V12.8.0, "3rd Generation Partnership Telephony; Media handling and interaction", TS 26.114,
Project; Technical Specification Group Services and System Version 13.2.0, December 2015,
Aspects; IP Multimedia Subsystem (IMS); Multimedia <http://www.3gpp.org/DynaReport/26114.htm>.
Telephony; Media handling and interaction (Release 12)",
December 2014, <http://www.3gpp.org/DynaReport/26114.htm>.
10.2. Informative References 8.2. Informative References
[I-D.ietf-rtcweb-rtp-usage] [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 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-24 (work in progress), May Work in Progress, draft-ietf-rtcweb-rtp-usage-25, June
2015. 2015.
[I-D.ietf-rtcweb-security-arch] [WebRTC-SEC]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "Security Considerations for WebRTC", Work
rtcweb-security-arch-11 (work in progress), March 2015. in Progress, draft-ietf-rtcweb-security-08, February 2015.
[I-D.ietf-rtcweb-security] [WebRTC-SEC-ARCH]
Rescorla, E., "Security Considerations for WebRTC", draft- Rescorla, E., "WebRTC Security Architecture", Work in
ietf-rtcweb-security-08 (work in progress), February 2015. 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 Author's Address
Adam Roach Adam Roach
Mozilla Mozilla
\
Dallas Dallas
US United States
Phone: +1 650 903 0800 x863 Phone: +1 650 903 0800 x863
Email: adam@nostrum.com Email: adam@nostrum.com
 End of changes. 65 change blocks. 
163 lines changed or deleted 186 lines changed or added

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