draft-ietf-avtext-lrr-00.txt   draft-ietf-avtext-lrr-01.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: January 7, 2016 J. Uberti Expires: April 21, 2016 J. Uberti
S. Holmer S. Holmer
M. Flodman M. Flodman
Google Google
July 6, 2015 October 19, 2015
The Layer Refresh Request (LRR) RTCP Feedback Message The Layer Refresh Request (LRR) RTCP Feedback Message
draft-ietf-avtext-lrr-00 draft-ietf-avtext-lrr-01
Abstract 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 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 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 January 7, 2016. This Internet-Draft will expire on April 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Layer Refresh Request . . . . . . . . . . . . . . . . . . . . 4 3. Layer Refresh Request . . . . . . . . . . . . . . . . . . . . 5
3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 5 3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 5
4. Usage with specific codecs . . . . . . . . . . . . . . . . . 6 4. Usage with specific codecs . . . . . . . . . . . . . . . . . 6
4.1. H264 SVC . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. H264 SVC . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. H265 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. H265 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. VP9 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. VP9 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Usage with different scalability transmission mechanisms . . 9 5. Usage with different scalability transmission mechanisms . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This memo describes an RTP Payload-Specific Feedback Message This memo describes an RTCP [RFC3550] Payload-Specific Feedback
[RFC4585] "Layer Refresh Request" (LRR). It is designed to allow a Message [RFC4585] "Layer Refresh Request" (LRR). It is designed to
receiver of a layered media stream to request that one or more of its allow a receiver of a layered media stream to request that one or
substreams be refreshed, such that it can then be decoded by an more of its substreams be refreshed, such that it can then be decoded
endpoint which previously was not receiving those layers, without by an endpoint which previously was not receiving those layers,
requiring that the entire stream be refreshed (as it would be if the without requiring that the entire stream be refreshed (as it would be
receiver sent a Full Intra Request (FIR) [RFC5104]. if the receiver sent a Full Intra Request (FIR) [RFC5104].
The message is designed to be applicable both to temporally and The message is designed to be applicable both to temporally and
spatially scaled streams, and to both single-stream and multi-stream spatially 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 8, line 5 skipping to change at page 8, line 32
|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 ingnored 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.
TODO: identifying layer refresh frames in an VP8 bitstream. Is the A VP8 layer refresh point can be identified by the presence of the
"Y" bit sufficient? Or is VP8 required to always be temporally "Y" bit in the VP8 payload header. When this bit is set, this and
nested, leaving this unnecessary? 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 4.3. H265
The initial version of the H.265 payload format The initial version of the H.265 payload format
[I-D.ietf-payload-rtp-h265] defines temporal scalability, with [I-D.ietf-payload-rtp-h265] defines temporal scalability, with
protocol elements reserved for spatial or other scalability modes protocol elements reserved for spatial or other scalability modes
(which are expected to be defined in a future version of the (which are expected to be defined in a future version of the
specification). specification).
+---------------+---------------+ +---------------+---------------+
skipping to change at page 8, line 39 skipping to change at page 9, line 27
ignored on reception. See [I-D.ietf-payload-rtp-h265] Section 1.1.4 ignored on reception. See [I-D.ietf-payload-rtp-h265] Section 1.1.4
for details on the LayerId and TID fields. 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.
TODO: identifying temporal layer refresh frames in a non-temporally- If a stream's sps_temporal_id_nesting_flag is not set, the NAL unit
nested H.265 bitstream. 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 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 4.4. VP9
skipping to change at page 10, line 36 skipping to change at page 11, line 36
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. IANA Considerations
The IANA is requested to register the following values: The IANA is requested to register the following values:
- TODO: PSFB value for LRR - TODO: PSFB value for LRR
8. Normative References 8. References
[I-D.ietf-avtext-rtp-grouping-taxonomy] 8.1. Normative References
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.
[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 High Efficiency Video Hannuksela, "RTP Payload Format for H.265/HEVC Video",
Coding", draft-ietf-payload-rtp-h265-13 (work in draft-ietf-payload-rtp-h265-14 (work in progress), August
progress), June 2015. 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-16 (work in progress), June 2015. payload-vp8-17 (work in progress), September 2015.
[I-D.uberti-payload-vp9] [I-D.uberti-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-uberti- Hong, "RTP Payload Format for VP9 Video", draft-uberti-
payload-vp9-01 (work in progress), March 2015. 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, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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, <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, July Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI
2006. 10.17487/RFC4585, July 2006,
<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, February 2008.
[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,
May 2011. DOI 10.17487/RFC6190, May 2011,
<http://www.rfc-editor.org/info/rfc6190>.
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, <http://www.rfc-editor.org/info/rfc5104>.
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. 20 change blocks. 
47 lines changed or deleted 86 lines changed or added

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