draft-ietf-avtext-lrr-02.txt   draft-ietf-avtext-lrr-03.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: September 22, 2016 J. Uberti Expires: January 9, 2017 J. Uberti
S. Holmer S. Holmer
M. Flodman M. Flodman
Google Google
March 21, 2016 July 8, 2016
The Layer Refresh Request (LRR) RTCP Feedback Message The Layer Refresh Request (LRR) RTCP Feedback Message
draft-ietf-avtext-lrr-02 draft-ietf-avtext-lrr-03
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 RTP payloads for scalable media formats. its use with several RTP payloads for scalable media formats.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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
3.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Usage with specific codecs . . . . . . . . . . . . . . . . . 7 4. Usage with specific codecs . . . . . . . . . . . . . . . . . 7
4.1. H264 SVC . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. H264 SVC . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. H265 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. H265 . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Usage with different scalability transmission mechanisms . . 10 5. Usage with different scalability transmission mechanisms . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. SDP Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 7. SDP Definitions . . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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] (see also if the receiver sent a Full Intra Request (FIR); [RFC5104] see also
[I-D.wenger-avtext-avpf-ccm-layered]). [I-D.ietf-avtext-avpf-ccm-layered]).
The feedback message is applicable both to temporally and spatially The feedback message is applicable both to temporally and 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].
skipping to change at page 6, line 12 skipping to change at page 6, line 12
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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC | | SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. |C| Payload Type| Reserved | | Seq nr. |C| Payload Type| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Layer Index | Current Layer Index (opt) | | RES | TTID| TLID | RES | CTID| CLID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 Figure 5
SSRC (32 bits) The SSRC value of the media sender that is requested SSRC (32 bits) The SSRC value of the media sender that is requested
to send a layer refresh point. to send a layer refresh point.
Seq nr. (8 bits) Command sequence number. The sequence number space Seq nr. (8 bits) Command sequence number. The sequence number space
is unique for each pairing of the SSRC of command source and the is unique for each pairing of the SSRC of command source and the
SSRC of the command target. The sequence number SHALL be SSRC of the command target. The sequence number SHALL be
skipping to change at page 6, line 36 skipping to change at page 6, line 36
C (1 bit) A flag bit indicating whether the "Current Layer Index" C (1 bit) A flag bit indicating whether the "Current Layer Index"
field is present in the FCI. If this bit is false, the sender of field is present in the FCI. If this bit is false, the sender of
the LRR message is requesting refresh of all layers up to and the LRR message is requesting refresh of all layers up to and
including the target layer. including the target layer.
Payload Type (7 bits) The RTP payload type for which the LRR is Payload Type (7 bits) The RTP payload type for which the LRR is
being requested. This gives the context in which the target layer being requested. This gives the context in which the target layer
index is to be interpreted. index is to be interpreted.
Reserved (16 bits) All bits SHALL be set to 0 by the sender and Reserved (RES) (16 bits / 5 bits / 5 bits) All bits SHALL be set to
0 by the sender and SHALL be ignored on reception.
Target Temporal Layer ID (TTID) (3 bits) The temporal ID of the
target layer for which the receiver wishes a refresh point.
Target Layer ID (TLID) (8 bits) The layer ID of the target layer for
which the receiver wishes a refresh point. Its format is
dependent on the payload type field.
Current Temporal Layer ID (CTID) (3 bits) If C is 1, the ID of the
current temporal layer being 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 set to 0 by the sender and
SHALL be ignored on reception. SHALL be ignored on reception.
Target Layer Index (16 bits) The target layer for which the receiver Current Layer ID (CLID) (8 bits) If C is 1, the layer ID of the
wishes a refresh point. Its format is dependent on the payload current layer being decoded by the receiver. This message is not
type field. requesting refresh 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.
Current Layer Index (16 bits) If C is 1, the current layer being Note: the syntax of the TTID, TLID, CTID, and TLID fields are
decoded by the receiver. This message is not requesting refresh designed to match the TID and LID fields in
of layers at or below this layer. If C is 0, this field SHALL be [I-D.ietf-avtext-framemarking].
set to 0 by the sender and SHALL be ignored on reception.
3.2. Semantics 3.2. Semantics
Within the common packet header for feedback messages (as defined in Within the common packet header for feedback messages (as defined in
section 6.1 of [RFC4585]), the "SSRC of packet sender" field section 6.1 of [RFC4585]), the "SSRC of packet sender" field
indicates the source of the request, and the "SSRC of media source" 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 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. which the LRR command applies are in the corresponding FCI entries.
A LRR message MAY contain requests to multiple media senders, using A LRR message MAY contain requests to multiple media senders, using
one FCI entry per target media sender. one FCI entry per target media sender.
skipping to change at page 7, line 23 skipping to change at page 7, line 39
of [RFC5104], which MAY restrict its ability to send a layer refresh of [RFC5104], which MAY restrict its ability to send a layer refresh
point quickly. 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 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 target layer and current target layer fields needs to be specified
for that codec's RTP packetization. New RTP packetization for that codec's RTP packetization. New RTP packetization
specifications for scalable codecs SHOULD define how this is done. specifications for scalable codecs SHOULD define how this is done.
(The VP9 payload [I-D.ietf-payload-vp9], for instance, has done so.) (The VP9 payload [I-D.ietf-payload-vp9], for instance, has done so.)
This section defines the layer index fields for use with several If the payload also specifies how it is used with the Frame Marking
existing scalable codecs. RTP Header Extension [I-D.ietf-avtext-framemarking], the syntax MUST
be defined in the same manner as the TID and LID fields in that
header.
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 | | RES | TID |R| DID | QID |
+---------------+---------------+ +---------------+---------------+
Figure 6 Figure 6
Figure 6 shows the format of the layer index field for H.264 SVC Figure 6 shows the format of the layer index field for H.264 SVC
streams. This is designed to follow the same layout as the third and streams. The "R" and "RES" fields MUST be set to 0 on transmission
fourth bytes of the H.264 SVC NAL unit extension, which carry the and ignored on reception. See [RFC6190] Section 1.1.3 for details on
stream's layer information. The "R" and "RES" fields MUST be set to the DID, QID, and TID fields.
0 on transmission and ignored on reception. See [RFC6190]
Section 1.1.3 for details on the DID, QID, and TID fields.
A dependency or quality layer refresh of a given layer in H.264 SVC A dependency or quality layer refresh of a given layer in H.264 SVC
can be identified by the "I" bit (idr_flag) in the extended NAL unit can be identified by the "I" bit (idr_flag) in the extended NAL unit
header, present in NAL unit types 14 (prefix NAL unit) and 20 (coded header, present in NAL unit types 14 (prefix NAL unit) and 20 (coded
scalable slice). Layer refresh of the base layer can also be scalable slice). Layer refresh of the base layer can also be
identified by its NAL unit type of its coded slices, which is "5" identified by its NAL unit type of its coded slices, which is "5"
rather than "1". A dependency or quality layer refresh is complete rather than "1". A dependency or quality layer refresh is complete
once this bit has been seen on all the appropriate layers (in once this bit has been seen on all the appropriate layers (in
decoding order) above the current layer index (if any, or beginning decoding order) above the current layer index (if any, or beginning
from the base layer if not) through the target layer index. from the base layer if not) through the target layer index.
skipping to change at page 8, line 38 skipping to change at page 9, line 9
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 refers 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-temporally-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 [RFC7741] defines temporal scalability
scalability modes. It does not support spatial 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 | | 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 be ignored 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 [RFC7741] 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.
Note that in VP8, not every layer switch point can be identified by Note that in VP8, not every layer switch point can be identified by
the Y bit, since the Y bit implies layer switch of all layers, not the Y bit, since the Y bit implies layer switch of all layers, not
just the layer in which it is sent. Thus the use of LRR with VP8 can just the layer in which it is sent. Thus the use of LRR with VP8 can
result in some inefficiency in transmision. However, this is not result in some inefficiency in transmision. However, this is not
expected to be a major issue for temporal structures in normal use. expected to be a major issue for temporal structures in normal use.
4.3. H265 4.3. H265
The initial version of the H.265 payload format The initial version of the H.265 payload format [RFC7798] defines
[I-D.ietf-payload-rtp-h265] defines temporal scalability, with temporal scalability, with protocol elements reserved for spatial or
protocol elements reserved for spatial or other scalability modes other scalability modes (which are expected to be defined in a future
(which are expected to be defined in a future version of the version of the specification).
specification).
+---------------+---------------+ +---------------+---------------+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | LayerId | TID | | RES | TID |RES| LayerId |
+-------------+-----------------+ +---------------+---------------+
Figure 8 Figure 8
Figure 8 shows the format of the layer index field for H.265 streams. Figure 8 shows the format of the layer index field for H.265 streams.
This is designed to follow the same layout as the first and second The "RES" fields MUST be set to 0 on transmission and ignored on
bytes of the H.265 NAL unit header, which carry the stream's layer reception. See [RFC7798] Section 1.1.4 for details on the LayerId
information. The "RES" field MUST be set to 0 on transmission and and TID fields.
ignored on reception. See [I-D.ietf-payload-rtp-h265] Section 1.1.4
for details on the LayerId and TID fields.
H.265 streams signal whether they are temporally nested, using the H.265 streams signal whether they are temporally nested, using the
vps_temporal_id_nesting_flag in the Video Parameter Set (VPS), and vps_temporal_id_nesting_flag in the Video Parameter Set (VPS), and
the sps_temporal_id_nesting_flag in the Sequence Parameter Set (SPS). the sps_temporal_id_nesting_flag in the Sequence Parameter Set (SPS).
If this flag is set in a stream's currently applicable VPS or SPS, If this flag is set in a stream's currently applicable VPS or SPS,
receivers SHOULD NOT send temporal LRR messages for that stream, as receivers SHOULD NOT send temporal LRR messages for that stream, as
every frame is implicitly a temporal layer refresh point. every frame is implicitly a temporal layer refresh point.
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
skipping to change at page 12, line 9 skipping to change at page 12, line 20
Long Name: Layer Refresh Request Command Long Name: Layer Refresh Request Command
Value: TBD Value: TBD
Reference: RFC XXXX Reference: RFC XXXX
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-payload-rtp-h265] [I-D.ietf-avtext-framemarking]
Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. Berger, E., Nandakumar, S., and M. Zanaty, "Frame Marking
Hannuksela, "RTP Payload Format for H.265/HEVC Video", RTP Header Extension", draft-ietf-avtext-framemarking-01
draft-ietf-payload-rtp-h265-15 (work in progress), (work in progress), March 2016.
November 2015.
[I-D.ietf-payload-vp8]
Westin, P., Lundin, H., Glover, M., Uberti, J., and F.
Galligan, "RTP Payload Format for VP8 Video", draft-ietf-
payload-vp8-17 (work in progress), September 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>.
skipping to change at page 13, line 5 skipping to change at page 13, line 10
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
RFC5234, January 2008, RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <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>.
[RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F.
Galligan, "RTP Payload Format for VP8 Video", RFC 7741,
DOI 10.17487/RFC7741, March 2016,
<http://www.rfc-editor.org/info/rfc7741>.
[RFC7798] Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M.
Hannuksela, "RTP Payload Format for High Efficiency Video
Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798, March
2016, <http://www.rfc-editor.org/info/rfc7798>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-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-ietf-
avtext-avpf-ccm-layered-01 (work in progress), May 2016.
[I-D.ietf-payload-vp9] [I-D.ietf-payload-vp9]
Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D. Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D.
Hong, "RTP Payload Format for VP9 Video", draft-ietf- Hong, "RTP Payload Format for VP9 Video", draft-ietf-
payload-vp9-01 (work in progress), October 2015. payload-vp9-02 (work in progress), March 2016.
[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.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015, DOI 10.17487/RFC7656, November 2015,
<http://www.rfc-editor.org/info/rfc7656>. <http://www.rfc-editor.org/info/rfc7656>.
Authors' Addresses Authors' Addresses
Jonathan Lennox Jonathan Lennox
 End of changes. 25 change blocks. 
61 lines changed or deleted 74 lines changed or added

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