draft-ietf-avtext-lrr-01.txt   draft-ietf-avtext-lrr-02.txt 
Payload Working Group J. Lennox Payload Working Group J. Lennox
Internet-Draft D. Hong Internet-Draft D. Hong
Intended status: Standards Track Vidyo Intended status: Standards Track Vidyo
Expires: April 21, 2016 J. Uberti Expires: September 22, 2016 J. Uberti
S. Holmer S. Holmer
M. Flodman M. Flodman
Google Google
October 19, 2015 March 21, 2016
The Layer Refresh Request (LRR) RTCP Feedback Message The Layer Refresh Request (LRR) RTCP Feedback Message
draft-ietf-avtext-lrr-01 draft-ietf-avtext-lrr-02
Abstract Abstract
This memo describes the RTCP Payload-Specific Feedback Message "Layer This memo describes the RTCP Payload-Specific Feedback Message "Layer
Refresh Request" (LRR), which can be used to request a state refresh Refresh Request" (LRR), which can be used to request a state refresh
of one or more substreams of a layered media stream. It also defines of one or more substreams of a layered media stream. It also defines
its use with several scalable media formats. its use with several RTP payloads for scalable media formats.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 21, 2016. This Internet-Draft will expire on September 22, 2016.
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. Conventions, Definitions and Acronyms . . . . . . . . . . . . 2 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 2
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Layer Refresh Request . . . . . . . . . . . . . . . . . . . . 5 3. Layer Refresh Request . . . . . . . . . . . . . . . . . . . . 5
3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 5 3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 5
4. Usage with specific codecs . . . . . . . . . . . . . . . . . 6 3.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Usage with specific codecs . . . . . . . . . . . . . . . . . 7
4.1. H264 SVC . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. H264 SVC . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. H265 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. H265 . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. VP9 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Usage with different scalability transmission mechanisms . . 10 5. Usage with different scalability transmission mechanisms . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. SDP Definitions . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This memo describes an RTCP [RFC3550] Payload-Specific Feedback This memo describes an RTCP [RFC3550] Payload-Specific Feedback
Message [RFC4585] "Layer Refresh Request" (LRR). It is designed to Message [RFC4585] "Layer Refresh Request" (LRR). It is designed to
allow a receiver of a layered media stream to request that one or allow a receiver of a layered media stream to request that one or
more of its substreams be refreshed, such that it can then be decoded more of its substreams be refreshed, such that it can then be decoded
by an endpoint which previously was not receiving those layers, by an endpoint which previously was not receiving those layers,
without requiring that the entire stream be refreshed (as it would be without requiring that the entire stream be refreshed (as it would be
if the receiver sent a Full Intra Request (FIR) [RFC5104]. if the receiver sent a Full Intra Request (FIR) [RFC5104] (see also
[I-D.wenger-avtext-avpf-ccm-layered]).
The message is designed to be applicable both to temporally and The feedback message is applicable both to temporally and spatially
spatially scaled streams, and to both single-stream and multi-stream scaled streams, and to both single-stream and multi-stream
scalability modes. scalability modes.
2. Conventions, Definitions and Acronyms 2. Conventions, Definitions and Acronyms
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].
2.1. Terminology 2.1. Terminology
skipping to change at page 5, line 36 skipping to change at page 5, line 36
possible to upgrade to a higher layer. The LRR contains one or two possible to upgrade to a higher layer. The LRR contains one or two
tuples, indicating the layer the decoder wants to upgrade to, and tuples, indicating the layer the decoder wants to upgrade to, and
(optionally) the currently highest layer the decoder can decode. (optionally) the currently highest layer the decoder can decode.
The specific format of the tuples, and the mechanism by which a The specific format of the tuples, and the mechanism by which a
receiver recognizes a refresh frame, is codec-dependent. Usage for receiver recognizes a refresh frame, is codec-dependent. Usage for
several codecs is discussed in Section 4. several codecs is discussed in Section 4.
LRR follows the model of the Full Intra Request (FIR) LRR follows the model of the Full Intra Request (FIR)
[RFC5104](Section 3.5.1) for its retransmission, reliability, and use [RFC5104](Section 3.5.1) for its retransmission, reliability, and use
in multipoint conferences. TODO: expand these here. in multipoint conferences.
The LRR message is identified by RTCP packet type value PT=PSFB and The LRR message is identified by RTCP packet type value PT=PSFB and
FMT=TBD. The FCI field MUST contain one or more FIR entries. Each FMT=TBD. The FCI field MUST contain one or more LRR entries. Each
entry applies to a different media sender, identified by its SSRC. entry applies to a different media sender, identified by its SSRC.
3.1. Message Format 3.1. Message Format
The Feedback Control Information (FCI) for the Layer Refresh Request The Feedback Control Information (FCI) for the Layer Refresh Request
consists of one or more FCI entries, the content of which is depicted consists of one or more FCI entries, the content of which is depicted
in Figure 5. The length of the LRR feedback message MUST be set to in Figure 5. The length of the LRR feedback message MUST be set to
2+3*N, where N is the number of FCI entries. 2+3*N, where N is the number of FCI entries.
0 1 2 3 0 1 2 3
skipping to change at page 6, line 48 skipping to change at page 6, line 48
Target Layer Index (16 bits) The target layer for which the receiver Target Layer Index (16 bits) The target layer for which the receiver
wishes a refresh point. Its format is dependent on the payload wishes a refresh point. Its format is dependent on the payload
type field. type field.
Current Layer Index (16 bits) If C is 1, the current layer being Current Layer Index (16 bits) If C is 1, the current layer being
decoded by the receiver. This message is not requesting refresh decoded by the receiver. This message is not requesting refresh
of layers at or below this layer. If C is 0, this field SHALL be of layers at or below this layer. If C is 0, this field SHALL be
set to 0 by the sender and SHALL be ignored on reception. set to 0 by the sender and SHALL be ignored on reception.
3.2. Semantics
Within the common packet header for feedback messages (as defined in
section 6.1 of [RFC4585]), the "SSRC of packet sender" field
indicates the source of the request, and the "SSRC of media source"
is not used and SHALL be set to 0. The SSRCs of the media senders to
which the LRR command applies are in the corresponding FCI entries.
A LRR message MAY contain requests to multiple media senders, using
one FCI entry per target media sender.
Upon reception of LRR, the encoder MUST send a decoder refresh point
(see section Section 2.1) as soon as possible.
The sender MUST consider congestion control as outlined in section 5
of [RFC5104], which MAY restrict its ability to send a layer refresh
point quickly.
4. Usage with specific codecs 4. Usage with specific codecs
In order for LRR to be used with a scalable codec, the format of the
target layer and current target layer fields needs to be specified
for that codec's RTP packetization. New RTP packetization
specifications for scalable codecs SHOULD define how this is done.
(The VP9 payload [I-D.ietf-payload-vp9], for instance, has done so.)
This section defines the layer index fields for use with several
existing scalable codecs.
4.1. H264 SVC 4.1. H264 SVC
H.264 SVC [RFC6190] defines temporal, dependency (spatial), and H.264 SVC [RFC6190] defines temporal, dependency (spatial), and
quality scalability modes. quality scalability modes.
+---------------+---------------+ +---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| DID | QID | TID |RES | |R| DID | QID | TID |RES |
+---------------+---------------+ +---------------+---------------+
skipping to change at page 8, line 4 skipping to change at page 8, line 25
bitstream. bitstream.
Whether an H.264 SVC stream is scalably nested can be determined from Whether an H.264 SVC stream is scalably nested can be determined from
the Scalability Information SEI message's temporal_id_nesting flag. the Scalability Information SEI message's temporal_id_nesting flag.
If this flag is set in a stream's currently applicable Scalability If this flag is set in a stream's currently applicable Scalability
Information SEI, receivers SHOULD NOT send temporal LRR messages for Information SEI, receivers SHOULD NOT send temporal LRR messages for
that stream, as every frame is implicitly a temporal layer refresh that stream, as every frame is implicitly a temporal layer refresh
point. (The Scalability Information SEI message may also be point. (The Scalability Information SEI message may also be
available in the signaling negotiation of H.264 SVC, as the sprop- available in the signaling negotiation of H.264 SVC, as the sprop-
scalability-info parameter.) scalability-info parameter.)
If a stream's temporal_id_nesting flag is not set, the Temporal Level If a stream's temporal_id_nesting flag is not set, the Temporal Level
Switching Point SEI message identifies temporal layer switching Switching Point SEI message identifies temporal layer switching
points. A temporal layer refresh is satisfied when this SEI message points. A temporal layer refresh is satisfied when this SEI message
is present in a frame with the target layer index, if the message's is present in a frame with the target layer index, if the message's
delta_frame_num refer to a frame with the requested current layer delta_frame_num refers to a frame with the requested current layer
index. (Alternately, temporal layer refresh can also be satisfied by index. (Alternately, temporal layer refresh can also be satisfied by
a complete state refresh, such as an IDR.) Senders which support a complete state refresh, such as an IDR.) Senders which support
receiving LRR for non-scalably-nested streams MUST insert Temporal receiving LRR for non-temporally-nested streams MUST insert Temporal
Level Switching Point SEI messages as appropriate. Level Switching Point SEI messages as appropriate.
4.2. VP8 4.2. VP8
The VP8 RTP payload format [I-D.ietf-payload-vp8] defines temporal The VP8 RTP payload format [I-D.ietf-payload-vp8] defines temporal
scalability modes. It does not support spatial scalability. scalability modes. It does not support spatial scalability.
+---------------+---------------+ +---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TID| RES | |TID| RES |
+---------------+---------------+ +---------------+---------------+
Figure 7 Figure 7
Figure 7 shows the format of the layer index field for VP8 streams. Figure 7 shows the format of the layer index field for VP8 streams.
The "RES" fields MUST be set to 0 on transmission and ingnored on The "RES" fields MUST be set to 0 on transmission and be ignored on
reception. See [I-D.ietf-payload-vp8] Section 4.2 for details on the reception. See [I-D.ietf-payload-vp8] Section 4.2 for details on the
TID field. TID field.
A VP8 layer refresh point can be identified by the presence of the A VP8 layer refresh point can be identified by the presence of the
"Y" bit in the VP8 payload header. When this bit is set, this and "Y" bit in the VP8 payload header. When this bit is set, this and
all subsequent frames depend only on the current base temporal layer. all subsequent frames depend only on the current base temporal layer.
On receipt of an LRR for a VP8 stream, A sender which supports LRR On receipt of an LRR for a VP8 stream, A sender which supports LRR
MUST encode the stream so it can set the Y bit in a packet whose MUST encode the stream so it can set the Y bit in a packet whose
temporal layer is at or below the target layer index. temporal layer is at or below the target layer index.
skipping to change at page 9, line 36 skipping to change at page 10, line 11
If a stream's sps_temporal_id_nesting_flag is not set, the NAL unit If a stream's sps_temporal_id_nesting_flag is not set, the NAL unit
types 2 to 5 inclusively identify temporal layer switching points. A types 2 to 5 inclusively identify temporal layer switching points. A
layer refresh to any higher target temporal layer is satisfied when a layer refresh to any higher target temporal layer is satisfied when a
NAL unit type of 4 or 5 with TID equal to 1 more than current TID is NAL unit type of 4 or 5 with TID equal to 1 more than current TID is
seen. Alternatively, layer refresh to a target temporal layer can be seen. Alternatively, layer refresh to a target temporal layer can be
incrementally satisfied with NAL unit type of 2 or 3. In this case, incrementally satisfied with NAL unit type of 2 or 3. In this case,
given current TID = TO and target TID = TN, layer refresh to TN is given current TID = TO and target TID = TN, layer refresh to TN is
satisfied when NAL unit type of 2 or 3 is seen for TID = T1, then TID satisfied when NAL unit type of 2 or 3 is seen for TID = T1, then TID
= T2, all the way up to TID = TN. During this incremental process, = T2, all the way up to TID = TN. During this incremental process,
layer referesh to TN can be completely satisfied as soon as a NAL layer refresh to TN can be completely satisfied as soon as a NAL unit
unit type of 2 or 3 is seen. type of 2 or 3 is seen.
Of course, temporal layer refresh can also be satisfied whenever any Of course, temporal layer refresh can also be satisfied whenever any
Intra Random Access Point (IRAP) NAL unit type (with values 16-23, Intra Random Access Point (IRAP) NAL unit type (with values 16-23,
inclusively) is seen. An IRAP picture is similar to an IDR picture inclusively) is seen. An IRAP picture is similar to an IDR picture
in H.264 (NAL unit type of 5 in H.264) where decoding of the picture in H.264 (NAL unit type of 5 in H.264) where decoding of the picture
can start without any older pictures. can start without any older pictures.
In the (future) H.265 payloads that support spatial scalability, a In the (future) H.265 payloads that support spatial scalability, a
spatial layer refresh of a specific layer can be identified by NAL spatial layer refresh of a specific layer can be identified by NAL
units with the requested layer ID and NAL unit types between 16 and units with the requested layer ID and NAL unit types between 16 and
21 inclusive. A dependency or quality layer refresh is complete once 21 inclusive. A dependency or quality layer refresh is complete once
NAL units of this type have been seen on all the appropriate layers NAL units of this type have been seen on all the appropriate layers
(in decoding order) above the current layer index (if any, or (in decoding order) above the current layer index (if any, or
beginning from the base layer if not) through the target layer index. beginning from the base layer if not) through the target layer index.
4.4. VP9
The RTP payload format for VP9 [I-D.uberti-payload-vp9] defines how
it can be used for spatial and temporal scalability.
+---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-------------+-----------------+
| T |R| S | RES |
+-------------+-----------------+
Figure 9
Figure 9 shows the format of the layer index field for VP9 streams.
This is designed to follow the same layout as the "L" byte of the VP9
payload header, which carries the stream's layer information. The
"R" and "RES" fields MUST be set to 0 on transmission and ingnored on
reception. See [I-D.uberti-payload-vp9] for details on the T and S
fields.
Identification of a layer refresh frame can be derived from the
reference IDs of each frame by backtracking the dependency chain
until reaching a point where only decodable frames are being
referenced. Therefore it's recommended for both the flexible and the
non-flexible mode that, when upgrade frames are being encoded in
response to a LRR, those packets should contain layer indices and the
reference fields so that the decoder or an MCU can make this
derivation.
Example:
LRR {1,0}, {2,1} is sent by an MCU when it is currently relaying
{1,0} to a receiver and which wants to upgrade to {2,1}. In response
the encoder should encode the next frames in layers {1,1} and {2,1}
by only referring to frames in {1,0}, or {0,0}.
In the non-flexible mode, periodic upgrade frames can be defined by
the layer structure of the SS, thus periodic upgrade frames can be
automatically identified by the picture ID.
5. Usage with different scalability transmission mechanisms 5. Usage with different scalability transmission mechanisms
Several different mechanisms are defined for how scalable streams can Several different mechanisms are defined for how scalable streams can
be transmitted in RTP. The RTP Taxonomy be transmitted in RTP. The RTP Taxonomy [RFC7656] Section 3.7
[I-D.ietf-avtext-rtp-grouping-taxonomy] Section 3.7 defines three defines three mechanisms: Single RTP Stream on a Single Media
mechanisms: Single RTP Stream on a Single Media Transport (SRST), Transport (SRST), Multiple RTP Streams on a Single Media Transport
Multiple RTP Streams on a Single Media Transport (MRST), and Multiple (MRST), and Multiple RTP Streams on Multiple Media Transports (MRMT).
RTP Streams on Multiple Media Transports (MRMT).
The LRR message is applicable to all these mechanisms. For MRST and The LRR message is applicable to all these mechanisms. For MRST and
MRMT mechanisms, the "media source" field of the LRR FCI is set to MRMT mechanisms, the "media source" field of the LRR FCI is set to
the SSRC of the RTP stream containing the layer indicated by the the SSRC of the RTP stream containing the layer indicated by the
Current Layer Index (if "C" is 1), or the stream containing the base Current Layer Index (if "C" is 1), or the stream containing the base
encoded stream (if "C" is 0). For MRMT, it is sent on the RTP encoded stream (if "C" is 0). For MRMT, it is sent on the RTP
session on which this stream is sent. On receipt, the sender MUST session on which this stream is sent. On receipt, the sender MUST
refresh all the layers requested in the stream, simultaneously in refresh all the layers requested in the stream, simultaneously in
decode order. decode order.
Note: arguably, for the MRST and MRMT mechanisms, FIR feedback
messages could instead be used to refresh specific individual layers.
However, the usage of FIR for MRSR/MRMT is not explicitly specified
anywhere, and if FIR is interpreted as refreshing layers, there is no
way to request an actual full, synchronized refresh of all the layers
of an MRST/MRMT layered source. Thus, the authors feel that
interpreting FIR as refreshing the entire source, and using LRR for
the individual layers, would be more useful.
6. Security Considerations 6. Security Considerations
All the security considerations of FIR feedback packets [RFC5104] All the security considerations of FIR feedback packets [RFC5104]
apply to LRR feedback packets as well. Additionally, media senders apply to LRR feedback packets as well. Additionally, media senders
receiving LRR feedback packets MUST validate that the payload types receiving LRR feedback packets MUST validate that the payload types
and layer indices they are receiving are valid for the stream they and layer indices they are receiving are valid for the stream they
are currently sending, and discard the requests if not. are currently sending, and discard the requests if not.
7. IANA Considerations 7. SDP Definitions
The IANA is requested to register the following values: Section 7 of [RFC5104] defines SDP procedures for indicating and
- TODO: PSFB value for LRR negotiating support for codec control messages (CCM) in SDP. This
document extends this with a new codec control command, "lrr", which
indicates support of the Layer Refresh Request (LRR).
8. References Figure 9 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234]
showing this grammar extension, extending the grammar defined in
[RFC5104].
8.1. Normative References rtcp-fb-ccm-param =/ SP "lrr" ; Layer Refresh Request
Figure 9: Syntax of the "lrr" ccm
The Offer-Answer considerations defined in [RFC5104] Section 7.2
apply.
8. IANA Considerations
This document defines a new entry to the "Codec Control Messages"
subregistry of the "Session Description Protocol (SDP) Parameters"
registry, according to the following data:
Value name: lrr
Long name: Layer Refresh Request Command
Usable with: ccm
Reference: RFC XXXX
This document also defines a new entry to the "FMT Values for PSFB
Payload Types" subregistry of the "Real-Time Transport Protocol (RTP)
Parameters" registry, according to the following data:
Name: LRR
Long Name: Layer Refresh Request Command
Value: TBD
Reference: RFC XXXX
9. References
9.1. Normative References
[I-D.ietf-payload-rtp-h265] [I-D.ietf-payload-rtp-h265]
Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M.
Hannuksela, "RTP Payload Format for H.265/HEVC Video", Hannuksela, "RTP Payload Format for H.265/HEVC Video",
draft-ietf-payload-rtp-h265-14 (work in progress), August draft-ietf-payload-rtp-h265-15 (work in progress),
2015. November 2015.
[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-17 (work in progress), September 2015. payload-vp8-17 (work in progress), September 2015.
[I-D.uberti-payload-vp9]
Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D.
Hong, "RTP Payload Format for VP9 Video", draft-uberti-
payload-vp9-01 (work in progress), March 2015.
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/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, <http://www.rfc-editor.org/info/rfc3550>.
[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,
<http://www.rfc-editor.org/info/rfc4585>. <http://www.rfc-editor.org/info/rfc4585>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
"RTP Payload Format for Scalable Video Coding", RFC 6190, "RTP Payload Format for Scalable Video Coding", RFC 6190,
DOI 10.17487/RFC6190, May 2011, DOI 10.17487/RFC6190, May 2011,
<http://www.rfc-editor.org/info/rfc6190>. <http://www.rfc-editor.org/info/rfc6190>.
8.2. Informative References 9.2. Informative References
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-payload-vp9]
Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D.
B. Burman, "A Taxonomy of Semantics and Mechanisms for Hong, "RTP Payload Format for VP9 Video", draft-ietf-
Real-Time Transport Protocol (RTP) Sources", draft-ietf- payload-vp9-01 (work in progress), October 2015.
avtext-rtp-grouping-taxonomy-08 (work in progress), July
[I-D.wenger-avtext-avpf-ccm-layered]
Wenger, S., Lennox, J., Burman, B., and M. Westerlund,
"Using Codec Control Messages in the RTP Audio-Visual
Profile with Feedback with Layered Codecs", draft-wenger-
avtext-avpf-ccm-layered-00 (work in progress), December
2015. 2015.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
"Codec Control Messages in the RTP Audio-Visual Profile B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
February 2008, <http://www.rfc-editor.org/info/rfc5104>. DOI 10.17487/RFC7656, November 2015,
<http://www.rfc-editor.org/info/rfc7656>.
Authors' Addresses Authors' Addresses
Jonathan Lennox Jonathan Lennox
Vidyo, Inc. Vidyo, Inc.
433 Hackensack Avenue 433 Hackensack Avenue
Seventh Floor Seventh Floor
Hackensack, NJ 07601 Hackensack, NJ 07601
US US
Email: jonathan@vidyo.com Email: jonathan@vidyo.com
Danny Hong Danny Hong
 End of changes. 34 change blocks. 
101 lines changed or deleted 131 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/