draft-ietf-rtcweb-video-03.txt | draft-ietf-rtcweb-video-04.txt | |||
---|---|---|---|---|
Network Working Group A.B. Roach | Network Working Group A.B. Roach | |||
Internet-Draft Mozilla | Internet-Draft Mozilla | |||
Intended status: Standards Track November 25, 2014 | Intended status: Standards Track February 13, 2015 | |||
Expires: May 29, 2015 | Expires: August 17, 2015 | |||
WebRTC Video Processing and Codec Requirements | WebRTC Video Processing and Codec Requirements | |||
draft-ietf-rtcweb-video-03 | draft-ietf-rtcweb-video-04 | |||
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 May 29, 2015. | This Internet-Draft will expire on August 17, 2015. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2014 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 | |||
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 | |||
skipping to change at page 2, line 17 | skipping to change at page 2, line 17 | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 | 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 . . . . . . . . . . . . . . . . . 9 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 | 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 2, line 51 | skipping to change at page 2, line 51 | |||
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- or 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]. | SHOULD be sRGB [SRGB]. For clarity, this the color space indicated | |||
by codepoint 1 from "ColourPrimaries" as defined in [IEC23001-8]. | ||||
TODO: I'm just throwing this out there to see if a specific proposal, | Unless specified otherwise by the SDP or codec, the video scan | |||
even if wrong, might draw more comment than "TBD". If you don't like | pattern for video codecs is Y'CbCr 4:2:0. | |||
sRGB for this purpose, comment on the rtcweb@ietf.org mailing list. | ||||
It has been suggested that the MPEG "Coding independent media | ||||
description code points" specification [IEC23001-8] may have | ||||
applicability here. | ||||
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 | ||||
use (e.g., if encoding at 15 fps due to bandwidth constraints, low | ||||
light conditions, or application settings, the camera will ideally | ||||
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 mid-stream 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 | ||||
less than optimal for the representation of screen content produced | ||||
by most systems in use at the time of this document's publication, | ||||
which generally use RGB with at least 24 bits per sample. In the | ||||
future, it may be advisable to use video codecs optimized for screen | ||||
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 | |||
[I-D.ietf-rtcweb-security-arch] section 5.2 and the considerations in | [I-D.ietf-rtcweb-security-arch] section 5.2 and the considerations in | |||
[I-D.ietf-rtcweb-security] section 4.1.1. | [I-D.ietf-rtcweb-security] section 4.1.1. | |||
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 by | |||
the encoder. Of more importance, the orientation may change over the | the encoder. Of more importance, the orientation may change over the | |||
course of a call, requiring the receiver to change the orientation in | course of a call, requiring the receiver to change the orientation in | |||
which it renders the stream. | 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 | |||
skipping to change at page 4, line 33 | skipping to change at page 4, line 42 | |||
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 Brower," "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 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 as described in [H264]. | H.264 Constrained Baseline as described in [H264]. | |||
To promote the use of non-royalty bearing video codecs, | 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 | |||
skipping to change at page 5, line 23 | skipping to change at page 5, line 32 | |||
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]. If a | |||
recipient of video indicates a receiving resolution, the sender | recipient of video indicates a receiving resolution, the sender | |||
SHOULD accommodate this resolution, as the receiver may not be | SHOULD accommodate this resolution, as the receiver may not be | |||
capable of handling higher resolutions. | 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 are | Unless otherwise signaled in SDP, recipients of video streams MUST be | |||
MUST be able to decode video at a rate of at least 20 fps at a | able to decode video at a rate of at least 20 fps at a resolution of | |||
resolution of at least 320x240. These values are selected based on | at least 320x240. These values are selected based on the | |||
the recommendations in [HSUP1]. | 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]. In addition they | payload formats defined in [I-D.ietf-payload-vp8]. | |||
MUST support the 'bilinear' and 'none' reconstruction filters. | ||||
TODO: There have been claims that VP8 already requires supporting | ||||
both filters; if true, these do not need to be reiterated here. | ||||
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. | |||
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: | |||
packetization-mode: Packetization-mode 1 MUST be supported. Other | packetization-mode: Packetization-mode 1 MUST be supported. Other | |||
skipping to change at page 6, line 13 | skipping to change at page 6, line 17 | |||
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: | |||
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 SHOULD 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 par | max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br: These | |||
ameters allow the implementation to specify that they can support | ||||
certain features of H.264 at higher rates and values than those | parameters allow the implementation to specify that they can | |||
signalled by their level (set with profile-level-id). | support certain features of H.264 at higher rates and values than | |||
those signalled 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 | SHOULD interpret them when receiving them, allowing them to send | |||
the highest quality of video possible. | 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; as a result, this parameter | MUST signal this information in-band. This means that WebRTC | |||
will not be present in SDP. | implementations MUST NOT include this parameter in the SDP they | |||
generate. | ||||
TODO: Do we need to require the handling of specific SEI messages? | H.264 codecs MAY send and MUST support proper interpretation of SEI | |||
One example that has been raised is freeze-frame messages. | "filler payload" and "full frame freeze" messages. "Full frame | |||
freeze" messages are used in video switching MCUs, to ensure a stable | ||||
decoded displayed picture while switching among various input | ||||
streams. | ||||
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 | ||||
SHOULD support proper interpretation of Display Orientation SEI | ||||
messages. | ||||
Implementations MAY send and act upon "User data registered by Rec. | ||||
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 | 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]. Implementers 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 based on [RFC6562]. | |||
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 | 8. IANA Considerations | |||
This document requires no actions from IANA. | This document requires no actions from IANA. | |||
9. Acknowledgements | 9. Acknowledgements | |||
The authors 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. 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", April 2013. | generic audiovisual services (V9)", February 2014, | |||
<http://www.itu.int/rec/T-REC-H.264-201304-I>. | ||||
[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>. | ||||
[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-11 (work in progress), February 2014. | |||
[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-12 | |||
(work in progress), October 2014. | (work in progress), October 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. | description code points", 2013, <http://standards.iso.org/ | |||
ittf/PubliclyAvailableStandards/ | ||||
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 | [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for | |||
Uncompressed Video", RFC 4175, September 2005. | Uncompressed Video", RFC 4175, September 2005. | |||
[RFC4421] Perkins, C., "RTP Payload Format for Uncompressed Video: | [RFC4421] Perkins, C., "RTP Payload Format for Uncompressed Video: | |||
Additional Colour Sampling Modes", RFC 4421, February | Additional Colour Sampling Modes", RFC 4421, February | |||
2006. | 2006. | |||
skipping to change at page 8, line 15 | skipping to change at page 8, line 42 | |||
[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 | [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of | |||
Variable Bit Rate Audio with Secure RTP", RFC 6562, March | Variable Bit Rate Audio with Secure RTP", RFC 6562, March | |||
2012. | 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. | Default RGB colour space - sRGB.", October 1999, <http:// | |||
www.colour.org/tc8-05/Docs/colorspace/61966-2-1.pdf>. | ||||
[TS26.114] | [TS26.114] | |||
3GPP TS 26.114 V12.7.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)", | |||
September 2014. | 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-06 (work in progress), | |||
February 2013. | February 2013. | |||
[I-D.ietf-rtcweb-security-arch] | [I-D.ietf-rtcweb-security-arch] | |||
End of changes. 28 change blocks. | ||||
46 lines changed or deleted | 77 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/ |