draft-ietf-payload-vp9-04.txt   draft-ietf-payload-vp9-05.txt 
Payload Working Group J. Uberti Payload Working Group J. Uberti
Internet-Draft S. Holmer Internet-Draft S. Holmer
Intended status: Standards Track M. Flodman Intended status: Standards Track M. Flodman
Expires: January 4, 2018 Google Expires: September 6, 2018 Google
J. Lennox J. Lennox
D. Hong D. Hong
Vidyo Vidyo
July 3, 2017 March 5, 2018
RTP Payload Format for VP9 Video RTP Payload Format for VP9 Video
draft-ietf-payload-vp9-04 draft-ietf-payload-vp9-05
Abstract Abstract
This memo describes an RTP payload format for the VP9 video codec. This memo describes an RTP payload format for the VP9 video codec.
The payload format has wide applicability, as it supports The payload format has wide applicability, as it supports
applications from low bit-rate peer-to-peer usage, to high bit-rate applications from low bit-rate peer-to-peer usage, to high bit-rate
video conferences. It includes provisions for temporal and spatial video conferences. It includes provisions for temporal and spatial
scalability. scalability.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 January 4, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3
3. Media Format Description . . . . . . . . . . . . . . . . . . 3 3. Media Format Description . . . . . . . . . . . . . . . . . . 3
4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 5 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 5 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 5
4.2. VP9 Payload Description . . . . . . . . . . . . . . . . . 6 4.2. VP9 Payload Description . . . . . . . . . . . . . . . . . 7
4.2.1. Scalability Structure (SS): . . . . . . . . . . . . . 10 4.2.1. Scalability Structure (SS): . . . . . . . . . . . . . 11
4.3. VP9 Payload Header . . . . . . . . . . . . . . . . . . . 12 4.3. VP9 Payload Header . . . . . . . . . . . . . . . . . . . 13
4.4. Frame Fragmentation . . . . . . . . . . . . . . . . . . . 12 4.4. Frame Fragmentation . . . . . . . . . . . . . . . . . . . 13
4.5. Scalable encoding considerations . . . . . . . . . . . . 12 4.5. Scalable encoding considerations . . . . . . . . . . . . 13
4.6. Examples of VP9 RTP Stream . . . . . . . . . . . . . . . 13 4.6. Examples of VP9 RTP Stream . . . . . . . . . . . . . . . 14
4.6.1. Reference picture use for scalable structure . . . . 13 4.6.1. Reference picture use for scalable structure . . . . 14
5. Feedback Messages and Header Extensions . . . . . . . . . . . 14 5. Feedback Messages and Header Extensions . . . . . . . . . . . 15
5.1. Reference Picture Selection Indication (RPSI) . . . . . . 14 5.1. Reference Picture Selection Indication (RPSI) . . . . . . 15
5.2. Slice Loss Indication (SLI) . . . . . . . . . . . . . . . 14 5.2. Slice Loss Indication (SLI) . . . . . . . . . . . . . . . 15
5.3. Full Intra Request (FIR) . . . . . . . . . . . . . . . . 15 5.3. Full Intra Request (FIR) . . . . . . . . . . . . . . . . 16
5.4. Layer Refresh Request (LRR) . . . . . . . . . . . . . . . 15 5.4. Layer Refresh Request (LRR) . . . . . . . . . . . . . . . 16
5.5. Frame Marking . . . . . . . . . . . . . . . . . . . . . . 16 5.5. Frame Marking . . . . . . . . . . . . . . . . . . . . . . 17
6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 16 6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 17
6.1. Media Type Definition . . . . . . . . . . . . . . . . . . 16 6.1. Media Type Definition . . . . . . . . . . . . . . . . . . 18
6.2. SDP Parameters . . . . . . . . . . . . . . . . . . . . . 18 6.2. SDP Parameters . . . . . . . . . . . . . . . . . . . . . 19
6.2.1. Mapping of Media Subtype Parameters to SDP . . . . . 18 6.2.1. Mapping of Media Subtype Parameters to SDP . . . . . 19
6.2.2. Offer/Answer Considerations . . . . . . . . . . . . . 18 6.2.2. Offer/Answer Considerations . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 19 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
This memo describes an RTP payload specification applicable to the This memo describes an RTP payload specification applicable to the
transmission of video streams encoded using the VP9 video codec transmission of video streams encoded using the VP9 video codec
[VP9-BITSTREAM]. The format described in this document can be used [VP9-BITSTREAM]. The format described in this document can be used
both in peer-to-peer and video conferencing applications. both in peer-to-peer and video conferencing applications.
TODO: VP9 description. Please see [VP9-BITSTREAM]. TODO: VP9 description. Please see [VP9-BITSTREAM].
skipping to change at page 3, line 16 skipping to change at page 3, line 16
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].
TODO: Cite terminology from [VP9-BITSTREAM]. TODO: Cite terminology from [VP9-BITSTREAM].
3. Media Format Description 3. Media Format Description
The VP9 codec can maintain up to eight reference frames, of which up The VP9 codec can maintain up to eight reference frames, of which up
to three can be referenced or updated by any new frame. to three can be referenced by any new frame.
VP9 also allows a reference frame to be resampled and used as a VP9 also allows a frame to use another frame of a different
reference for another frame of a different resolution. This allows resolution as a reference frame. (Specifically, a frame may use any
internal resolution changes without requiring the use of key frames. references whose width and height are between 1/16th that of the
current frame and twice that of the current frame, inclusive.) This
allows internal resolution changes without requiring the use of key
frames.
These features together enable an encoder to implement various forms These features together enable an encoder to implement various forms
of coarse-grained scalability, including temporal, spatial and of coarse-grained scalability, including temporal, spatial and
quality scalability modes, as well as combinations of these, without quality scalability modes, as well as combinations of these, without
the need for explicit scalable coding tools. the need for explicit scalable coding tools.
Temporal layers define different frame rates of video; spatial and Temporal layers define different frame rates of video; spatial and
quality layers define different and possibly dependent quality layers define different and possibly dependent
representations of a single input frame. Spatial layers allow a representations of a single input frame. Spatial layers allow a
frame to be encoded at different resolutions, whereas quality layers frame to be encoded at different resolutions, whereas quality layers
skipping to change at page 4, line 14 skipping to change at page 4, line 18
instant in time. A picture thus consists of one or more frames, instant in time. A picture thus consists of one or more frames,
encoding different spatial layers. encoding different spatial layers.
Within a picture, a frame with spatial layer ID equal to S, where S > Within a picture, a frame with spatial layer ID equal to S, where S >
0, can depend on a frame of the same picture with a lower spatial 0, can depend on a frame of the same picture with a lower spatial
layer ID. This "inter-layer" dependency can result in additional layer ID. This "inter-layer" dependency can result in additional
coding gain compared to the case where only traditional "inter- coding gain compared to the case where only traditional "inter-
picture" dependency is used, where a frame depends on previously picture" dependency is used, where a frame depends on previously
coded frame in time. For simplicity, this payload format assumes coded frame in time. For simplicity, this payload format assumes
that, within a picture and if inter-layer dependency is used, a that, within a picture and if inter-layer dependency is used, a
spatial layer S frame can only depend on spatial layer S-1 frame when spatial layer S frame can depend only on the immediately previous
S > 0. Additionally, if inter-picture dependency is used, spatial spatial layer S-1 frame, when S > 0. Additionally, if inter-picture
layer S frame is assumed to only depend on a previously coded spatial dependency is used, a spatial layer S frame is assumed to only depend
layer S frame. on a previously coded spatial layer S frame.
Given above simplifications for inter-layer and inter-picture Given above simplifications for inter-layer and inter-picture
dependencies, a flag (the D bit described below) is used to indicate dependencies, a flag (the D bit described below) is used to indicate
whether a spatial layer S frame depends on spatial layer S-1 frame. whether a spatial layer S frame depends on the spatial layer S-1
Given the D bit, a receiver only needs to additionally know the frame. Given the D bit, a receiver only needs to additionally know
inter-picture dependency structure for a given spatial layer frame in the inter-picture dependency structure for a given spatial layer
order to determine its decodability. Two modes of describing the frame in order to determine its decodability. Two modes of
inter-picture dependency structure are possible: "flexible mode" and describing the inter-picture dependency structure are possible:
"non-flexible mode". An encoder can only switch between the two on "flexible mode" and "non-flexible mode". An encoder can only switch
the first packet of a key frame with temporal layer ID equal to 0. between the two on the first packet of a key frame with temporal
layer ID equal to 0.
In flexible mode, each packet can contain up to 3 reference indices, In flexible mode, each packet can contain up to 3 reference indices,
which identify all frames referenced by the frame transmitted in the which identify all frames referenced by the frame transmitted in the
current packet for inter-picture prediction. This (along with the D current packet for inter-picture prediction. This (along with the D
bit) enables a receiver to identify if a frame is decodable or not bit) enables a receiver to identify if a frame is decodable or not
and helps it understand the temporal layer structure. Since this is and helps it understand the temporal layer structure. Since this is
signaled in each packet it makes it possible to have very flexible signaled in each packet it makes it possible to have very flexible
temporal layer hierarchies and patterns which are changing temporal layer hierarchies and patterns which are changing
dynamically. dynamically.
In non-flexible mode, the inter-picture dependency (the reference In non-flexible mode, the inter-picture dependency (the reference
indices) of a Picture Group (PG) MUST be pre-specified as part of the indices) of a Picture Group (PG) MUST be pre-specified as part of the
scalability structure (SS) data. In this mode, each packet MUST have scalability structure (SS) data. In this mode, each packet has an
an index to refer to one of the described pictures in the PG, from index to refer to one of the described pictures in the PG, from which
which the pictures referenced by the picture transmitted in the the pictures referenced by the picture transmitted in the current
current packet for inter-picture prediction can be identified. packet for inter-picture prediction can be identified.
(Editor's Note: A "Picture Group", as used in this document, is not (Editor's Note: A "Picture Group", as used in this document, is not
the same thing as a "Group of Pictures" as traditionally used in the same thing as a the term "Group of Pictures" as it is
video coding. Suggestions for better terminology are welcome.) traditionally used in video coding, i.e. to mean an independently-
decoadable run of pictures beginning with a keyframe. Suggestions
for better terminology are welcome.)
The SS data can also be used to specify the resolution of each The SS data can also be used to specify the resolution of each
spatial layer present in the VP9 stream for both flexible and non- spatial layer present in the VP9 stream for both flexible and non-
flexible modes. flexible modes.
4. Payload Format 4. Payload Format
This section describes how the encoded VP9 bitstream is encapsulated This section describes how the encoded VP9 bitstream is encapsulated
in RTP. To handle network losses usage of RTP/AVPF [RFC4585] is in RTP. To handle network losses usage of RTP/AVPF [RFC4585] is
RECOMMENDED. All integer fields in the specifications are encoded as RECOMMENDED. All integer fields in the specifications are encoded as
skipping to change at page 6, line 20 skipping to change at page 7, line 12
assign a dynamic payload type number to be used in each RTP assign a dynamic payload type number to be used in each RTP
session and provide a mechanism to indicate the mapping. See session and provide a mechanism to indicate the mapping. See
Section 6.2 for the mechanism to be used with the Session Section 6.2 for the mechanism to be used with the Session
Description Protocol (SDP) [RFC4566]. Description Protocol (SDP) [RFC4566].
Timestamp: The RTP timestamp indicates the time when the input frame Timestamp: The RTP timestamp indicates the time when the input frame
was sampled, at a clock rate of 90 kHz. If the input picture is was sampled, at a clock rate of 90 kHz. If the input picture is
encoded with multiple layer frames, all of the frames of the encoded with multiple layer frames, all of the frames of the
picture MUST have the same timestamp. picture MUST have the same timestamp.
If a frame has the VP9 show_frame field set to 0 (i.e., it is
meant only to populate a reference buffer, without being output)
its timestamp MAY alternately be set to be the same as the
subsequent frame with show_frame equal to 1. (This will be
convenient for playing out pre-encoded content packaged with VP9
"superframes", which typically bundle show_frame==0 frames with a
subsequent show_frame==1 frame.) Every frame with show_frame==1,
however, MUST have a unique timestamp modulo the 2^32 wrap of the
field.
The remaining RTP Fixed Header Fields (V, P, X, CC, sequence number, The remaining RTP Fixed Header Fields (V, P, X, CC, sequence number,
SSRC and CSRC identifiers) are used as specified in Section 5.1 of SSRC and CSRC identifiers) are used as specified in Section 5.1 of
[RFC3550]. [RFC3550].
4.2. VP9 Payload Description 4.2. VP9 Payload Description
In flexible mode (with the F bit below set to 1), The first octets In flexible mode (with the F bit below set to 1), The first octets
after the RTP header are the VP9 payload descriptor, with the after the RTP header are the VP9 payload descriptor, with the
following structure. following structure.
skipping to change at page 7, line 29 skipping to change at page 8, line 29
| TL0PICIDX | (CONDITIONALLY REQUIRED) | TL0PICIDX | (CONDITIONALLY REQUIRED)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
V: | SS | V: | SS |
| .. | | .. |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3 Figure 3
I: Picture ID (PID) present. When set to one, the OPTIONAL PID MUST I: Picture ID (PID) present. When set to one, the OPTIONAL PID MUST
be present after the mandatory first octet and specified as below. be present after the mandatory first octet and specified as below.
Otherwise, PID MUST NOT be present. Otherwise, PID MUST NOT be present. If the SS field was present
in the stream's most recent start of a keyframe (i.e., non-
flexible scalability mode is in use), then the PID MUST also be
present in every packet.
P: Inter-picture predicted picture. When set to zero, the picture P: Inter-picture predicted frame. When set to zero, the frame does
does not utilize inter-picture prediction. In this case, up- not utilize inter-picture prediction. In this case, up-switching
switching to a current spatial layer's frame is possible from to a current spatial layer's frame is possible from directly lower
directly lower spatial layer frame. P SHOULD also be set to zero spatial layer frame. P SHOULD also be set to zero when encoding a
when encoding a layer synchronization frame in response to an LRR layer synchronization frame in response to an LRR
[I-D.ietf-avtext-lrr] message (see Section 5.4). When P is set to [I-D.ietf-avtext-lrr] message (see Section 5.4). When P is set to
zero, the T field (described below) MUST also be set to 0 (if zero, the T field (described below) MUST also be set to 0 (if
present). Note that the P bit does not forbid intra-picture, present). Note that the P bit does not forbid intra-picture,
inter-layer prediction from earlier frames of the same picture, if inter-layer prediction from earlier frames of the same picture, if
any. any.
L: Layer indices present. When set to one, the one or two octets L: Layer indices present. When set to one, the one or two octets
following the mandatory first octet and the PID (if present) is as following the mandatory first octet and the PID (if present) is as
described by "Layer indices" below. If the F bit (described described by "Layer indices" below. If the F bit (described
below) is set to 1 (indicating flexible mode), then only one octet below) is set to 1 (indicating flexible mode), then only one octet
skipping to change at page 9, line 12 skipping to change at page 10, line 14
assume that the number of bits in PID stay the same through the assume that the number of bits in PID stay the same through the
session. session.
In the non-flexible mode (when the F bit is set to 0), this PID is In the non-flexible mode (when the F bit is set to 0), this PID is
used as an index to the picture group (PG) specified in the SS used as an index to the picture group (PG) specified in the SS
data below. In this mode, the PID of the key frame corresponds to data below. In this mode, the PID of the key frame corresponds to
the first specified frame in the PG. Then subsequent PIDs are the first specified frame in the PG. Then subsequent PIDs are
mapped to subsequently specified frames in the PG (modulo N_G, mapped to subsequently specified frames in the PG (modulo N_G,
specified in the SS data below), respectively. specified in the SS data below), respectively.
All frames of the same picture MUST have the same PID value.
Frames (and their corresponding pictures) with the VP9 show_frame
field equal to 0 MUST have distinct PID values from subsequent
pictures with show_frame equal to 1. Thus, a Picture as defined
in this specification is different than a VP9 Superframe.
All frames of the same picture MUST have the same value for
show_frame.
Layer indices: This information is optional but recommended whenever Layer indices: This information is optional but recommended whenever
encoding with layers. For both flexible and non-flexible modes, encoding with layers. For both flexible and non-flexible modes,
one octet is used to specify a layer frame's temporal layer ID (T) one octet is used to specify a layer frame's temporal layer ID (T)
and spatial layer ID (S) as shown both in Figure 2 and Figure 3. and spatial layer ID (S) as shown both in Figure 2 and Figure 3.
Additionally, a bit (U) is used to indicate that the current frame Additionally, a bit (U) is used to indicate that the current frame
is a "switching up point" frame. Another bit (D) is used to is a "switching up point" frame. Another bit (D) is used to
indicate whether inter-layer prediction is used for the current indicate whether inter-layer prediction is used for the current
frame. frame.
In the non-flexible mode (when the F bit is set to 0), another In the non-flexible mode (when the F bit is set to 0), another
skipping to change at page 9, line 45 skipping to change at page 11, line 9
U: Switching up point. If this bit is set to 1 for the current U: Switching up point. If this bit is set to 1 for the current
picture with temporal layer ID equal to T, then "switch up" to picture with temporal layer ID equal to T, then "switch up" to
a higher frame rate is possible as subsequent higher temporal a higher frame rate is possible as subsequent higher temporal
layer pictures will not depend on any picture before the layer pictures will not depend on any picture before the
current picture (in coding order) with temporal layer ID current picture (in coding order) with temporal layer ID
greater than T. greater than T.
S: The spatial layer ID of current frame. Note that frames with S: The spatial layer ID of current frame. Note that frames with
spatial layer S > 0 may be dependent on decoded spatial layer spatial layer S > 0 may be dependent on decoded spatial layer
S-1 frame within the same picture. S-1 frame within the same picture. Different frames of the
same picture MUST have distinct spatial layer IDs, and frames'
spatial layers MUST appear in increasing order within the
frame.
D: Inter-layer dependency used. MUST be set to one if current D: Inter-layer dependency used. MUST be set to one if current
spatial layer S frame depends on spatial layer S-1 frame of the spatial layer S frame depends on spatial layer S-1 frame of the
same picture. MUST only be set to zero if current spatial same picture. MUST only be set to zero if current spatial
layer S frame does not depend on spatial layer S-1 frame of the layer S frame does not depend on spatial layer S-1 frame of the
same picture. For the base layer frame (with S equal to 0), same picture. For the base layer frame (with S equal to 0),
this D bit MUST be set to zero. this D bit MUST be set to zero.
TL0PICIDX: 8 bits temporal layer zero index. TL0PICIDX is only TL0PICIDX: 8 bits temporal layer zero index. TL0PICIDX is only
present in the non-flexible mode (F = 0). This is a running present in the non-flexible mode (F = 0). This is a running
skipping to change at page 20, line 4 skipping to change at page 21, line 6
order to reduce network congestion. Note that discarding of non- order to reduce network congestion. Note that discarding of non-
reference frames cannot be done if the stream is encrypted (because reference frames cannot be done if the stream is encrypted (because
the non-reference marker is encrypted). the non-reference marker is encrypted).
9. IANA Considerations 9. IANA Considerations
The IANA is requested to register the following values: The IANA is requested to register the following values:
- Media type registration as described in Section 6.1. - Media type registration as described in Section 6.1.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-avtext-framemarking] [I-D.ietf-avtext-framemarking]
Berger, E., Nandakumar, S., and M. Zanaty, "Frame Marking Zanaty, M., Berger, E., and S. Nandakumar, "Frame Marking
RTP Header Extension", draft-ietf-avtext-framemarking-04 RTP Header Extension", draft-ietf-avtext-framemarking-06
(work in progress), March 2017. (work in progress), October 2017.
[I-D.ietf-avtext-lrr] [I-D.ietf-avtext-lrr]
Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. Lennox, J., Hong, D., Uberti, J., Holmer, S., and M.
Flodman, "The Layer Refresh Request (LRR) RTCP Feedback Flodman, "The Layer Refresh Request (LRR) RTCP Feedback
Message", draft-ietf-avtext-lrr-06 (work in progress), Message", draft-ietf-avtext-lrr-07 (work in progress),
June 2017. July 2017.
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997, <https://www.rfc-editor.org/info/
<http://www.rfc-editor.org/info/rfc2119>. rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI
10.17487/RFC4585, July 2006, 10.17487/RFC4585, July 2006, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc4585>. editor.org/info/rfc4585>.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
<http://www.rfc-editor.org/info/rfc4855>. <https://www.rfc-editor.org/info/rfc4855>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <http://www.rfc-editor.org/info/rfc5104>. February 2008, <https://www.rfc-editor.org/info/rfc5104>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC Specifications and Registration Procedures", BCP 13, RFC
6838, DOI 10.17487/RFC6838, January 2013, 6838, DOI 10.17487/RFC6838, January 2013,
<http://www.rfc-editor.org/info/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
[VP9-BITSTREAM] [VP9-BITSTREAM]
Grange, A., de Rivaz, P., and J. Hunt, "VP9 Bitstream & Grange, A., de Rivaz, P., and J. Hunt, "VP9 Bitstream &
Decoding Process Specification", Version 0.6, March 2016, Decoding Process Specification", Version 0.6, March 2016,
<https://storage.googleapis.com/downloads.webmproject.org/ <https://storage.googleapis.com/downloads.webmproject.org/
docs/vp9/vp9-bitstream-specification- docs/vp9/vp9-bitstream-specification-
v0.6-20160331-draft.pdf>. v0.6-20160331-draft.pdf>.
10.2. Informative References 10.2. Informative References
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003, DOI 10.17487/RFC3551, July 2003, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3551>. editor.org/info/rfc3551>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <http://www.rfc-editor.org/info/rfc5124>. 2008, <https://www.rfc-editor.org/info/rfc5124>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<http://www.rfc-editor.org/info/rfc7201>. <https://www.rfc-editor.org/info/rfc7201>.
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP
Framework: Why RTP Does Not Mandate a Single Media Framework: Why RTP Does Not Mandate a Single Media
Security Solution", RFC 7202, DOI 10.17487/RFC7202, April Security Solution", RFC 7202, DOI 10.17487/RFC7202, April
2014, <http://www.rfc-editor.org/info/rfc7202>. 2014, <https://www.rfc-editor.org/info/rfc7202>.
Authors' Addresses Authors' Addresses
Justin Uberti Justin Uberti
Google, Inc. Google, Inc.
747 6th Street South 747 6th Street South
Kirkland, WA 98033 Kirkland, WA 98033
USA USA
Email: justin@uberti.name Email: justin@uberti.name
 End of changes. 32 change blocks. 
78 lines changed or deleted 111 lines changed or added

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