--- 1/draft-ietf-avtext-lrr-00.txt 2015-10-19 14:15:16.241928828 -0700 +++ 2/draft-ietf-avtext-lrr-01.txt 2015-10-19 14:15:16.269929514 -0700 @@ -1,89 +1,91 @@ Payload Working Group J. Lennox Internet-Draft D. Hong Intended status: Standards Track Vidyo -Expires: January 7, 2016 J. Uberti +Expires: April 21, 2016 J. Uberti S. Holmer M. Flodman Google - July 6, 2015 + October 19, 2015 The Layer Refresh Request (LRR) RTCP Feedback Message - draft-ietf-avtext-lrr-00 + draft-ietf-avtext-lrr-01 Abstract - This memo describes the RTP 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 of one or more substreams of a layered media stream. It also defines its use with several scalable media formats. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 7, 2016. + This Internet-Draft will expire on April 21, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 2 - 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 - 3. Layer Refresh Request . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Layer Refresh Request . . . . . . . . . . . . . . . . . . . . 5 3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 5 4. Usage with specific codecs . . . . . . . . . . . . . . . . . 6 - 4.1. H264 SVC . . . . . . . . . . . . . . . . . . . . . . . . 6 - 4.2. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.1. H264 SVC . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.2. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. H265 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.4. VP9 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 5. Usage with different scalability transmission mechanisms . . 9 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 8. Normative References . . . . . . . . . . . . . . . . . . . . 10 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.4. VP9 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5. Usage with different scalability transmission mechanisms . . 10 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 8.2. Informative References . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction - This memo describes an RTP Payload-Specific Feedback Message - [RFC4585] "Layer Refresh Request" (LRR). It is designed to 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 by an - endpoint which previously was not receiving those layers, without - requiring that the entire stream be refreshed (as it would be if the - receiver sent a Full Intra Request (FIR) [RFC5104]. + This memo describes an RTCP [RFC3550] Payload-Specific Feedback + Message [RFC4585] "Layer Refresh Request" (LRR). It is designed to + 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 + by an endpoint which previously was not receiving those layers, + without requiring that the entire stream be refreshed (as it would be + if the receiver sent a Full Intra Request (FIR) [RFC5104]. The message is designed to be applicable both to temporally and spatially scaled streams, and to both single-stream and multi-stream scalability modes. 2. Conventions, Definitions and Acronyms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. @@ -323,23 +323,32 @@ |TID| RES | +---------------+---------------+ Figure 7 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 reception. See [I-D.ietf-payload-vp8] Section 4.2 for details on the TID field. - TODO: identifying layer refresh frames in an VP8 bitstream. Is the - "Y" bit sufficient? Or is VP8 required to always be temporally - nested, leaving this unnecessary? + 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 + 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 + 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. + + 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 + 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 + expected to be a major issue for temporal structures in normal use. 4.3. H265 The initial version of the H.265 payload format [I-D.ietf-payload-rtp-h265] defines temporal scalability, with protocol elements reserved for spatial or other scalability modes (which are expected to be defined in a future version of the specification). +---------------+---------------+ @@ -357,22 +366,37 @@ 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 vps_temporal_id_nesting_flag in the Video Parameter Set (VPS), and 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, receivers SHOULD NOT send temporal LRR messages for that stream, as every frame is implicitly a temporal layer refresh point. - TODO: identifying temporal layer refresh frames in a non-temporally- - nested H.265 bitstream. + 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 + 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 + seen. Alternatively, layer refresh to a target temporal layer can be + 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 + 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, + layer referesh to TN can be completely satisfied as soon as a NAL + unit type of 2 or 3 is seen. + + Of course, temporal layer refresh can also be satisfied whenever any + Intra Random Access Point (IRAP) NAL unit type (with values 16-23, + 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 + can start without any older pictures. In the (future) H.265 payloads that support spatial scalability, a 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 21 inclusive. A dependency or quality layer refresh is complete once NAL units of this type have been seen on all the appropriate layers (in decoding order) above the current layer index (if any, or beginning from the base layer if not) through the target layer index. 4.4. VP9 @@ -448,63 +472,76 @@ apply to LRR feedback packets as well. Additionally, media senders receiving LRR feedback packets MUST validate that the payload types and layer indices they are receiving are valid for the stream they are currently sending, and discard the requests if not. 7. IANA Considerations The IANA is requested to register the following values: - TODO: PSFB value for LRR -8. Normative References +8. References - [I-D.ietf-avtext-rtp-grouping-taxonomy] - Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and - B. Burman, "A Taxonomy of Semantics and Mechanisms for - Real-Time Transport Protocol (RTP) Sources", draft-ietf- - avtext-rtp-grouping-taxonomy-07 (work in progress), June - 2015. +8.1. Normative References [I-D.ietf-payload-rtp-h265] Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. - Hannuksela, "RTP Payload Format for High Efficiency Video - Coding", draft-ietf-payload-rtp-h265-13 (work in - progress), June 2015. + Hannuksela, "RTP Payload Format for H.265/HEVC Video", + draft-ietf-payload-rtp-h265-14 (work in progress), August + 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-16 (work in progress), June 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 - Requirement Levels", BCP 14, RFC 2119, March 1997. + Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ + RFC2119, March 1997, + . + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, + July 2003, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control - Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July - 2006. - - [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, - "Codec Control Messages in the RTP Audio-Visual Profile - with Feedback (AVPF)", RFC 5104, February 2008. + Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI + 10.17487/RFC4585, July 2006, + . [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, - May 2011. + DOI 10.17487/RFC6190, May 2011, + . -Authors' Addresses +8.2. Informative References + [I-D.ietf-avtext-rtp-grouping-taxonomy] + Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and + B. Burman, "A Taxonomy of Semantics and Mechanisms for + Real-Time Transport Protocol (RTP) Sources", draft-ietf- + avtext-rtp-grouping-taxonomy-08 (work in progress), July + 2015. + + [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, . + +Authors' Addresses Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 US Email: jonathan@vidyo.com Danny Hong