draft-ietf-payload-rtp-h265-10.txt   draft-ietf-payload-rtp-h265-11.txt 
Network Working Group Y.-K. Wang Network Working Group Y.-K. Wang
Internet Draft Qualcomm Internet Draft Qualcomm
Intended status: Standards track Y. Sanchez Intended status: Standards track Y. Sanchez
Expires: November 2015 T. Schierl Expires: December 2015 T. Schierl
Fraunhofer HHI Fraunhofer HHI
S. Wenger S. Wenger
Vidyo Vidyo
M. M. Hannuksela M. M. Hannuksela
Nokia Nokia
May 29, 2015 June 2, 2015
RTP Payload Format for High Efficiency Video Coding RTP Payload Format for High Efficiency Video Coding
draft-ietf-payload-rtp-h265-10.txt draft-ietf-payload-rtp-h265-11.txt
Abstract Abstract
This memo describes an RTP payload format for the video coding This memo describes an RTP payload format for the video coding
standard ITU-T Recommendation H.265 and ISO/IEC International standard ITU-T Recommendation H.265 and ISO/IEC International
Standard 23008-2, both also known as High Efficiency Video Coding Standard 23008-2, both also known as High Efficiency Video Coding
(HEVC) and developed by the Joint Collaborative Team on Video (HEVC) and developed by the Joint Collaborative Team on Video
Coding (JCT-VC). The RTP payload format allows for packetization Coding (JCT-VC). The RTP payload format allows for packetization
of one or more Network Abstraction Layer (NAL) units in each RTP of one or more Network Abstraction Layer (NAL) units in each RTP
packet payload, as well as fragmentation of a NAL unit into packet payload, as well as fragmentation of a NAL unit into
skipping to change at page 2, line 22 skipping to change at page 2, line 22
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work Drafts as reference material or to cite them other than as "work
in progress." in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 29, 2015. This Internet-Draft will expire on November 2, 2015.
Copyright and License Notice Copyright and License 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
skipping to change at page 3, line 17 skipping to change at page 3, line 17
Abstract..........................................................1 Abstract..........................................................1
Status of this Memo...............................................1 Status of this Memo...............................................1
Table of Contents.................................................3 Table of Contents.................................................3
1 Introduction....................................................5 1 Introduction....................................................5
1.1 Overview of the HEVC Codec.................................5 1.1 Overview of the HEVC Codec.................................5
1.1.1 Coding-Tool Features..................................5 1.1.1 Coding-Tool Features..................................5
1.1.2 Systems and Transport Interfaces......................7 1.1.2 Systems and Transport Interfaces......................7
1.1.3 Parallel Processing Support..........................14 1.1.3 Parallel Processing Support..........................14
1.1.4 NAL Unit Header......................................16 1.1.4 NAL Unit Header......................................16
1.2 Overview of the Payload Format............................18 1.2 Overview of the Payload Format............................18
2 Conventions....................................................19 2 Conventions....................................................18
3 Definitions and Abbreviations..................................19 3 Definitions and Abbreviations..................................19
3.1 Definitions...............................................19 3.1 Definitions...............................................19
3.1.1 Definitions from the HEVC Specification..............19 3.1.1 Definitions from the HEVC Specification..............19
3.1.2 Definitions Specific to This Memo....................21 3.1.2 Definitions Specific to This Memo....................21
3.2 Abbreviations.............................................23 3.2 Abbreviations.............................................23
4 RTP Payload Format.............................................25 4 RTP Payload Format.............................................25
4.1 RTP Header Usage..........................................25 4.1 RTP Header Usage..........................................25
4.2 Payload Header Usage......................................27 4.2 Used to identify the source of the RTP packets. When
4.3 Transmission Modes........................................28 using SRST, by definition a single SSRC is used for all parts
of a single bitstream. In MRST or MRMT, different SSRCs are
used for each RTP stream containing a subset of the sub-layers
of the single (temporally scalable) bitstream. A receiver is
required to correctly associate the set of SSRCs that are
included parts of the same bitstream. Payload Header Usage....27
4.3 Transmission Modes........................................27
4.4 Payload Structures........................................29 4.4 Payload Structures........................................29
4.4.1 Single NAL Unit Packets..............................29 4.4.1 Single NAL Unit Packets..............................29
4.4.2 Aggregation Packets (APs)............................30 4.4.2 Aggregation Packets (APs)............................30
4.4.3 Fragmentation Units (FUs)............................35 4.4.3 Fragmentation Units (FUs)............................35
4.4.4 PACI packets.........................................38 4.4.4 PACI packets.........................................38
4.4.4.1 Reasons for the PACI rules (informative)........41 4.4.4.1 Reasons for the PACI rules (informative)........41
4.4.4.2 PACI extensions (Informative)...................42 4.4.4.2 PACI extensions (Informative)...................42
4.5 Temporal Scalability Control Information..................43 4.5 Temporal Scalability Control Information..................43
4.6 Decoding Order Number.....................................45 4.6 Decoding Order Number.....................................45
5 Packetization Rules............................................47 5 Packetization Rules............................................47
skipping to change at page 17, line 23 skipping to change at page 17, line 23
The semantics of the fields in the NAL unit header are as The semantics of the fields in the NAL unit header are as
specified in [HEVC] and described briefly below for convenience. specified in [HEVC] and described briefly below for convenience.
In addition to the name and size of each field, the corresponding In addition to the name and size of each field, the corresponding
syntax element name in [HEVC] is also provided. syntax element name in [HEVC] is also provided.
F: 1 bit F: 1 bit
forbidden_zero_bit. Required to be zero in [HEVC]. Note that forbidden_zero_bit. Required to be zero in [HEVC]. Note that
the inclusion of this bit in the NAL unit header was to enable the inclusion of this bit in the NAL unit header was to enable
transport of HEVC video over MPEG-2 transport systems transport of HEVC video over MPEG-2 transport systems
(avoidance of start code emulations) [MPEG2S]. In the context (avoidance of start code emulations) [MPEG2S]. In the context
of this memo, the value 1 MAY be used to indicate a syntax of this memo, the value 1 may be used to indicate a syntax
violation. For example, when RTP is transported over UDP-lite violation, e.g. for a NAL unit resulted from aggregating a
[RFC3828] and the receiver decides to feed the video decoder number of fragmented units of a NAL unit but missing the last
NAL unit(s) where the corresponding UDP-lite packet failed a fragment, as described in Section 4.4.3.
checksum test, then this bit can be set to alarm the decoder
of possible bit errors.
Type: 6 bits Type: 6 bits
nal_unit_type. This field specifies the NAL unit type as nal_unit_type. This field specifies the NAL unit type as
defined in Table 7-1 of [HEVC]. If the most significant bit defined in Table 7-1 of [HEVC]. If the most significant bit
of this field of a NAL unit is equal to 0 (i.e. the value of of this field of a NAL unit is equal to 0 (i.e. the value of
this field is less than 32), the NAL unit is a VCL NAL unit. this field is less than 32), the NAL unit is a VCL NAL unit.
Otherwise, the NAL unit is a non-VCL NAL unit. For a Otherwise, the NAL unit is a non-VCL NAL unit. For a
reference of all currently defined NAL unit types and their reference of all currently defined NAL unit types and their
semantics, please refer to Section 7.4.1 in [HEVC]. semantics, please refer to Section 7.4.1 in [HEVC].
skipping to change at page 25, line 38 skipping to change at page 25, line 38
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 RTP header according to [RFC3550] Figure 2 RTP header according to [RFC3550]
The RTP header information to be set according to this RTP The RTP header information to be set according to this RTP
payload format is set as follows: payload format is set as follows:
Marker bit (M): 1 bit Marker bit (M): 1 bit
Set for the last packet carried in the current RTP stream of Set for the last packet of the access unit, carried in the
the access unit. This is in line with the normal use of the M current RTP stream. This is in line with the normal use of
bit in video formats to allow an efficient playout buffer the M bit in video formats to allow an efficient playout
handling. When MRST or MRMT is in use, if an access unit buffer handling. When MRST or MRMT is in use, if an access
appears in multiple RTP streams, the marker bit is set on each unit appears in multiple RTP streams, the marker bit is set on
RTP stream's last packet of the access unit. each RTP stream's last packet of the access unit.
Informative note: The content of a NAL unit does not tell Informative note: The content of a NAL unit does not tell
whether or not the NAL unit is the last NAL unit, in whether or not the NAL unit is the last NAL unit, in
decoding order, of an access unit. An RTP sender decoding order, of an access unit. An RTP sender
implementation may obtain these information from the video implementation may obtain these information from the video
encoder. If, however, the implementation cannot obtain encoder. If, however, the implementation cannot obtain
these information directly from the encoder, e.g. when the these information directly from the encoder, e.g. when the
bitstream was pre-encoded, and also there is no timestamp bitstream was pre-encoded, and also there is no timestamp
allocated for each NAL unit, then the sender implementation allocated for each NAL unit, then the sender implementation
can inspect subsequent NAL units in decoding order to can inspect subsequent NAL units in decoding order to
skipping to change at page 27, line 21 skipping to change at page 27, line 21
Receivers MUST use the RTP timestamp for the display process, Receivers MUST use the RTP timestamp for the display process,
even when the bitstream contains picture timing SEI messages even when the bitstream contains picture timing SEI messages
or decoding unit information SEI messages as specified in or decoding unit information SEI messages as specified in
[HEVC]. However, this does not mean that picture timing SEI [HEVC]. However, this does not mean that picture timing SEI
messages in the bitstream should be discarded, as picture messages in the bitstream should be discarded, as picture
timing SEI messages may contain frame-field information that timing SEI messages may contain frame-field information that
is important in appropriately rendering interlaced video. is important in appropriately rendering interlaced video.
Synchronization source (SSRC): 32-bits Synchronization source (SSRC): 32-bits
Used to identify the source of the RTP packets. When using 4.2Used to identify the source of the RTP packets. When using SRST,
SRST, by definition a single SSRC is used for all parts of a by definition a single SSRC is used for all parts of a single
single bitstream. In MRST or MRMT, different SSRCs are used bitstream. In MRST or MRMT, different SSRCs are used for each
for each RTP stream containing a subset of the sub-layers of RTP stream containing a subset of the sub-layers of the single
the single (temporally scalable) bitstream. A receiver is (temporally scalable) bitstream. A receiver is required to
required to correctly associate the set of SSRCs that are correctly associate the set of SSRCs that are included parts of
included parts of the same bitstream. the same bitstream. Payload Header Usage
4.2 Payload Header Usage
The first two bytes of the payload of an RTP packet are referred The first two bytes of the payload of an RTP packet are referred
to as the payload header. The payload header consists of the to as the payload header. The payload header consists of the
same fields (F, Type, LayerId, and TID) as the NAL unit header as same fields (F, Type, LayerId, and TID) as the NAL unit header as
shown in Section 1.1.4, irrespective of the type of the payload shown in Section 1.1.4, irrespective of the type of the payload
structure. structure.
The TID value indicates (among other things) the relative The TID value indicates (among other things) the relative
importance of an RTP packet, for example because NAL units importance of an RTP packet, for example because NAL units
belonging to higher temporal sub-layers are not used for the belonging to higher temporal sub-layers are not used for the
skipping to change at page 95, line 21 skipping to change at page 95, line 21
Muhammed Coban and Marta Karczewicz are thanked for discussions Muhammed Coban and Marta Karczewicz are thanked for discussions
on the specification of the use with feedback messages and other on the specification of the use with feedback messages and other
aspects in this memo. Jonathan Lennox and Jill Boyce are thanked aspects in this memo. Jonathan Lennox and Jill Boyce are thanked
for their contributions to the PACI design included in this memo. for their contributions to the PACI design included in this memo.
Rickard Sjoberg, Arild Fuldseth, Bo Burman, Magnus Westerlund, Rickard Sjoberg, Arild Fuldseth, Bo Burman, Magnus Westerlund,
and Tom Kristensen are thanked for their contributions to and Tom Kristensen are thanked for their contributions to
parallel processing related signalling. Magnus Westerlund, parallel processing related signalling. Magnus Westerlund,
Jonathan Lennox, Bernard Aboba, Jonatan Samuelsson, Roni Even, Jonathan Lennox, Bernard Aboba, Jonatan Samuelsson, Roni Even,
Rickard Sjoberg, Sachin Deshpande, Woo Johnman, Mo Zanaty, Ross Rickard Sjoberg, Sachin Deshpande, Woo Johnman, Mo Zanaty, Ross
Finlayson, and Danny Hong made valuable reviewing comments that Finlayson, Danny Hong, Bo Burman, and Ben Campbell made valuable
led to improvements. reviewing comments that led to improvements.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
13 References 13 References
13.1 Normative References 13.1 Normative References
[HEVC] ITU-T Recommendation H.265, "High efficiency video [HEVC] ITU-T Recommendation H.265, "High efficiency video
coding", April 2013. coding", April 2013.
skipping to change at page 98, line 43 skipping to change at page 98, line 43
[MPEGDASH] ISO/IEC 23009-1, "Information technology - Dynamic [MPEGDASH] ISO/IEC 23009-1, "Information technology - Dynamic
adaptive streaming over HTTP (DASH) - Part 1: Media adaptive streaming over HTTP (DASH) - Part 1: Media
presentation description and segment formats", 2012. presentation description and segment formats", 2012.
[RFC2326] Schulzrinne, H., Rao, A., and Lanphier R., "Real Time [RFC2326] Schulzrinne, H., Rao, A., and Lanphier R., "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2974] Handley, M., Perkins C., and Whelan E., "Session [RFC2974] Handley, M., Perkins C., and Whelan E., "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E.,
and Fairhurst, G., "The Lightweight User Datagram
Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC5117] Westerlund, M. and Wenger, S., "RTP Topologies", RFC [RFC5117] Westerlund, M. and Wenger, S., "RTP Topologies", RFC
5117, January 2008. 5117, January 2008.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of
RTP Flows", RFC 6051, November 2010. RTP Flows", RFC 6051, November 2010.
[RFC7201] Westerlund, M. and Perkins, C., "Options for Securing [RFC7201] Westerlund, M. and Perkins, C., "Options for Securing
RTP Sessions", RFC 7201, April 2014. RTP Sessions", RFC 7201, April 2014.
[RFC7202] Perkins, C. and Westerlund, M., "Securing the RTP [RFC7202] Perkins, C. and Westerlund, M., "Securing the RTP
 End of changes. 11 change blocks. 
34 lines changed or deleted 32 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/