draft-ietf-payload-rtp-h265-11.txt   draft-ietf-payload-rtp-h265-12.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: December 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
June 2, 2015 June 3, 2015
RTP Payload Format for High Efficiency Video Coding RTP Payload Format for High Efficiency Video Coding
draft-ietf-payload-rtp-h265-11.txt draft-ietf-payload-rtp-h265-12.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 2, 2015. This Internet-Draft will expire on December 3, 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 25 skipping to change at page 3, line 25
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....................................................18 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 Used to identify the source of the RTP packets. When 4.2 Payload Header Usage......................................27
using SRST, by definition a single SSRC is used for all parts 4.3 Transmission Modes........................................28
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 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
4.2Used to identify the source of the RTP packets. When using SRST, Used to identify the source of the RTP packets. When using
by definition a single SSRC is used for all parts of a single SRST, by definition a single SSRC is used for all parts of a
bitstream. In MRST or MRMT, different SSRCs are used for each single bitstream. In MRST or MRMT, different SSRCs are used
RTP stream containing a subset of the sub-layers of the single for each RTP stream containing a subset of the sub-layers of
(temporally scalable) bitstream. A receiver is required to the single (temporally scalable) bitstream. A receiver is
correctly associate the set of SSRCs that are included parts of required to correctly associate the set of SSRCs that are
the same bitstream. Payload Header Usage included parts of the same bitstream.
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 39, line 4 skipping to change at page 39, line 4
The PACI packet structure is based on a payload header extension The PACI packet structure is based on a payload header extension
mechanism that is generic and extensible to carry payload header mechanism that is generic and extensible to carry payload header
extensions. In this section, the focus lies on the use within extensions. In this section, the focus lies on the use within
this specification. Section 4.4.4.2 below provides guidance for this specification. Section 4.4.4.2 below provides guidance for
the specification designers in how to employ the extension the specification designers in how to employ the extension
mechanism in future specifications. mechanism in future specifications.
A PACI packet consists of a payload header (denoted as A PACI packet consists of a payload header (denoted as
PayloadHdr), for which the structure follows what is described in PayloadHdr), for which the structure follows what is described in
Section 4.2 above. The payload header is followed by the fields Section 0 above. The payload header is followed by the fields A,
A, cType, PHSsize, F[0..2] and Y. cType, PHSsize, F[0..2] and Y.
Figure 11 shows a PACI packet in compliance with this memo; that Figure 11 shows a PACI packet in compliance with this memo; that
is, without any extensions. is, without any extensions.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=50) |A| cType | PHSsize |F0..2|Y| | PayloadHdr (Type=50) |A| cType | PHSsize |F0..2|Y|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Header Extension Structure (PHES) | | Payload Header Extension Structure (PHES) |
 End of changes. 6 change blocks. 
20 lines changed or deleted 16 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/