< draft-ietf-avtext-lrr-05.txt   draft-ietf-avtext-lrr-06.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: November 9, 2017 J. Uberti Expires: December 17, 2017 J. Uberti
S. Holmer S. Holmer
M. Flodman M. Flodman
Google Google
May 8, 2017 June 15, 2017
The Layer Refresh Request (LRR) RTCP Feedback Message The Layer Refresh Request (LRR) RTCP Feedback Message
draft-ietf-avtext-lrr-05 draft-ietf-avtext-lrr-06
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 November 9, 2017. This Internet-Draft will expire on December 17, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . 10 7. SDP Definitions . . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12 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
skipping to change at page 5, line 5 skipping to change at page 4, line 49
... <-- T0 <------ T0 <------ T0 <------ T0 <--- ... ... <-- T0 <------ T0 <------ T0 <------ T0 <--- ...
1 2 3 4 5 6 7 1 2 3 4 5 6 7
Figure 4 Figure 4
In Figure 4, the stream is temporally nested in its ordinary In Figure 4, the stream is temporally nested in its ordinary
structure; a decoder receiving layer T0 can begin decoding layer T1 structure; a decoder receiving layer T0 can begin decoding layer T1
at any point. at any point.
A "Layer Index" is a numeric label for a specific spatial and
temporal layer of a scalable stream. It consists of the pair of a
"temporal ID" identifying the temporal layer, and a "layer ID"
identifying the spatial or quality layer. The details of how layers
of a scalable stream are labeled are codec-specific. Details for
several codecs are defined in Section 4.
3. Layer Refresh Request 3. Layer Refresh Request
A layer refresh frame can be requested by sending a Layer Refresh A layer refresh frame can be requested by sending a Layer Refresh
Request (LRR), which is an Real-Time Transport Control Protocol Request (LRR), which is an RTP Control Protocol (RTCP) [RFC3550]
(RTCP) [RFC3550] payload-specific feedback message [RFC4585] asking payload-specific feedback message [RFC4585] asking the encoder to
the encoder to encode a frame which makes it possible to upgrade to a encode a frame which makes it possible to upgrade to a higher layer.
higher layer. The LRR contains one or two tuples, indicating the The LRR contains one or two tuples, indicating the temporal and
layer the decoder wants to upgrade to, and (optionally) the currently spatial layer the decoder wants to upgrade to, and (optionally) the
highest layer the decoder can decode. currently highest temporal and spatial 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]
[RFC5104](Section 3.5.1) for its retransmission, reliability, and use (Section 3.5.1) for its retransmission, reliability, and use in
in multipoint conferences. 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 LRR 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.
[NOTE TO RFC Editor: Please replace "TBD" with the IANA-assigned [NOTE TO RFC Editor: Please replace "TBD" with the IANA-assigned
payload-specific feedback number.] payload-specific feedback number.]
3.1. Message Format 3.1. Message Format
skipping to change at page 6, line 12 skipping to change at page 6, line 15
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
increased by 1 modulo 256 for each new command. A repetition increased by 1 modulo 256 for each new command. A repetition
SHALL NOT increase the sequence number. The initial value is SHALL NOT increase the sequence number. The initial value is
arbitrary. arbitrary.
C (1 bit) A flag bit indicating whether the "Current Layer Index" C (1 bit) A flag bit indicating whether the "Current Temporal Layer
field is present in the FCI. If this bit is false, the sender of ID (CTID)" and "Current Layer ID (CLID)" fields are present in the
the LRR message is requesting refresh of all layers up to and FCI. If this bit is 0, the sender of the LRR message is
including the target layer. requesting refresh of all layers up to and 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 (RES) (16 bits / 5 bits / 5 bits) All bits SHALL be set to Reserved (RES) (16 bits / 5 bits / 5 bits) All bits SHALL be set to
0 by the sender and SHALL be ignored on reception. 0 by the sender and SHALL be ignored on reception.
Target Temporal Layer ID (TTID) (3 bits) The temporal ID of the Target Temporal Layer ID (TTID) (3 bits) The temporal ID of the
target layer for which the receiver wishes a refresh point. target layer for which the receiver wishes a refresh point.
skipping to change at page 6, line 43 skipping to change at page 6, line 47
message is not requesting refresh of layers at or below 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 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.
Current Layer ID (CLID) (8 bits) If C is 1, the layer ID of the Current Layer ID (CLID) (8 bits) If C is 1, the layer ID of the
current spatial or quality layer being decoded by the receiver. current spatial or quality layer being decoded by the receiver.
This message is not requesting refresh of layers at or below this 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 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.
When C is 1, TTID MUST NOT be less than CTID, and TLID MUST NOT be
less than CLID; at least one of TTID or TLID MUST be greater than
CTID or CLID respectively. That is to say, the target layer index
<TTID, TLID> MUST be a layer upgrade from the current layer index
<CTID, CLID>. A sender MAY request an upgrade in both temporal and
spatial/quality layers simultaneously.
Note: the syntax of the TTID, TLID, CTID, and CLID fields match, by Note: the syntax of the TTID, TLID, CTID, and CLID fields match, by
design, the TID and LID fields in [I-D.ietf-avtext-framemarking]. design, the TID and LID fields in [I-D.ietf-avtext-framemarking].
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.
skipping to change at page 7, line 4 skipping to change at page 7, line 15
Note: the syntax of the TTID, TLID, CTID, and CLID fields match, by Note: the syntax of the TTID, TLID, CTID, and CLID fields match, by
design, the TID and LID fields in [I-D.ietf-avtext-framemarking]. design, the TID and LID fields in [I-D.ietf-avtext-framemarking].
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.
Upon reception of LRR, the encoder MUST send a decoder refresh point Upon reception of LRR, the encoder MUST send a decoder refresh point
(see section Section 2.1) as soon as possible. (see Section 2.1) as soon as possible.
The sender MUST consider congestion control as outlined in section 5 The sender MUST respect bandwidth limits provided by the application
of [RFC5104], which MAY restrict its ability to send a layer refresh of congestion control, as described in Section 5 of [RFC5104]. As
point quickly. layer refresh points will often be larger than non-refreshing frames,
this may restrict a sender's ability to send a layer refresh point
quickly.
LRR MUST NOT be sent as a reaction to picture losses -- it is
RECOMMENDED to use PLI [RFC4585] instead. LRR SHOULD be used only in
situations where not sending a layer refresh point would render the
video unusable for the users.
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 temporal and layer ID fields (for both the target and current layer
for that codec's RTP packetization. New RTP packetization indices) needs to be specified for that codec's RTP packetization.
specifications for scalable codecs SHOULD define how this is done. New RTP packetization specifications for scalable codecs SHOULD
(The VP9 payload [I-D.ietf-payload-vp9], for instance, has done so.) define how this is done. (The VP9 payload [I-D.ietf-payload-vp9],
If the payload also specifies how it is used with the Frame Marking for instance, has done so.) If the payload also specifies how it is
RTP Header Extension [I-D.ietf-avtext-framemarking], the syntax MUST used with the Frame Marking RTP Header Extension
be defined in the same manner as the TID and LID fields in that [I-D.ietf-avtext-framemarking], the syntax MUST be defined in the
header. 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | TID |R| DID | QID | | 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 fields for H.264 SVC
streams. The "R" and "RES" fields MUST be set to 0 on transmission streams. The "R" and "RES" fields MUST be set to 0 on transmission
and ignored on reception. See [RFC6190] Section 1.1.3 for details on and ignored on reception. See [RFC6190] Section 1.1.3 for details on
the DID, QID, and TID fields. 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
 End of changes. 18 change blocks. 
38 lines changed or deleted 59 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/