draft-ietf-avt-rtp-rfc3984bis-03.txt   draft-ietf-avt-rtp-rfc3984bis-04.txt 
Audio/Video Transport WG Y.-K. Wang Audio/Video Transport WG Y.-K. Wang
Internet Draft Huawei Technologies Internet Draft Huawei Technologies
Intended status: Standards track R. Even Intended status: Standards track R. Even
Expires: August 2009 Self-employed Expires: September 2009 Self-employed
T. Kristensen T. Kristensen
Tandberg Tandberg
February 23, 2009 March 6, 2009
RTP Payload Format for H.264 Video RTP Payload Format for H.264 Video
draft-ietf-avt-rtp-rfc3984bis-03.txt draft-ietf-avt-rtp-rfc3984bis-04.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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."
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 August 23, 2009. This Internet-Draft will expire on September 6, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 35, line 11 skipping to change at page 35, line 11
mode. STAP-Bs, MTAPs, FU-As, and FU-Bs MAY be used. STAP-As and mode. STAP-Bs, MTAPs, FU-As, and FU-Bs MAY be used. STAP-As and
single NAL unit packets MUST NOT be used. The transmission order of single NAL unit packets MUST NOT be used. The transmission order of
packets and NAL units is constrained as specified in section 5.5. packets and NAL units is constrained as specified in section 5.5.
7. De-Packetization Process 7. De-Packetization Process
The de-packetization process is implementation dependent. Therefore, The de-packetization process is implementation dependent. Therefore,
the following description should be seen as an example of a suitable the following description should be seen as an example of a suitable
implementation. Other schemes may be used as well as long as the implementation. Other schemes may be used as well as long as the
output for the same input is the same as the process described below. output for the same input is the same as the process described below.
The same output means that the number of NAL units and their order The same output means that the resulting NAL units, and their order,
are both identical respectively. Optimizations relative to the are identical. Optimizations relative to the described algorithms
described algorithms are likely possible. Section 7.1 presents the are likely possible. Section 7.1 presents the de-packetization
de-packetization process for the single NAL unit and non-interleaved process for the single NAL unit and non-interleaved packetization
packetization modes, whereas section 7.2 describes the process for modes, whereas section 7.2 describes the process for the interleaved
the interleaved mode. Section 7.3 includes additional de- mode. Section 7.3 includes additional de-packetization guidelines
packetization guidelines for intelligent receivers. for intelligent receivers.
All normal RTP mechanisms related to buffer management apply. In All normal RTP mechanisms related to buffer management apply. In
particular, duplicated or outdated RTP packets (as indicated by the particular, duplicated or outdated RTP packets (as indicated by the
RTP sequences number and the RTP timestamp) are removed. To RTP sequences number and the RTP timestamp) are removed. To
determine the exact time for decoding, factors such as a possible determine the exact time for decoding, factors such as a possible
intentional delay to allow for proper inter-stream synchronization intentional delay to allow for proper inter-stream synchronization
must be factored in. must be factored in.
7.1. Single NAL Unit and Non-Interleaved Mode 7.1. Single NAL Unit and Non-Interleaved Mode
skipping to change at page 50, line 13 skipping to change at page 50, line 13
to know that in-band transport of parameter sets is needed. to know that in-band transport of parameter sets is needed.
in-band-parameter-sets: in-band-parameter-sets:
This parameter MAY be used to indicate a receiver capability. This parameter MAY be used to indicate a receiver capability.
The value MAY be equal to either 0 or 1. The value 1 The value MAY be equal to either 0 or 1. The value 1
indicates that receiver discards out-of-band parameter sets in indicates that receiver discards out-of-band parameter sets in
sprop-parameter-sets and sprop-level-parameter-sets, therefore sprop-parameter-sets and sprop-level-parameter-sets, therefore
the sender MUST transmit all parameter sets in-band. The the sender MUST transmit all parameter sets in-band. The
value 0 indicates that the receiver utilizes out-of-band value 0 indicates that the receiver utilizes out-of-band
parameter sets included in sprop-parameter-sets and sprop- parameter sets included in sprop-parameter-sets and sprop-
level-parameter-sets. When in-band-parameter-sets is equal to level-parameter-sets. However, in this case, the sender MAY
1, use-level-src-parameter-sets MUST NOT be present or MUST be still choose to send parameter sets in-band. When in-band-
equal to 0. When the parameter is not present, this receiver parameter-sets is equal to 1, use-level-src-parameter-sets
capability is not specified, and therefore the sender MAY send MUST NOT be present or MUST be equal to 0. When the parameter
out-of-band parameter sets only, or it MAY send in-band- is not present, this receiver capability is not specified, and
parameter-sets only, or it MAY send both to make sure the therefore the sender MAY send out-of-band parameter sets only,
system work. or it MAY send in-band-parameter-sets only, or it MAY send
both.
packetization-mode: packetization-mode:
This parameter signals the properties of an RTP payload type This parameter signals the properties of an RTP payload type
or the capabilities of a receiver implementation. Only a or the capabilities of a receiver implementation. Only a
single configuration point can be indicated; thus, when single configuration point can be indicated; thus, when
capabilities to support more than one packetization-mode are capabilities to support more than one packetization-mode are
declared, multiple configuration points (RTP payload types) declared, multiple configuration points (RTP payload types)
must be used. must be used.
When the value of packetization-mode is equal to 0 or When the value of packetization-mode is equal to 0 or
skipping to change at page 59, line 48 skipping to change at page 60, line 30
the sender MUST transmit parameter sets in-band. the sender MUST transmit parameter sets in-band.
Otherwise, the following applies. Otherwise, the following applies.
o When an offered payload type is accepted without level o When an offered payload type is accepted without level
downgrade, i.e. the default level is accepted, the following downgrade, i.e. the default level is accepted, the following
applies. applies.
o When there is a "sprop-parameter-sets" included in the o When there is a "sprop-parameter-sets" included in the
"a=fmtp" line of SDP, the answerer MUST be prepared to "a=fmtp" line of SDP, the answerer MUST be prepared to
use the parameter sets included in "sprop-parameter-sets" use the parameter sets included in "sprop-parameter-
for decoding the incoming NAL unit stream. sets" for decoding the incoming NAL unit stream.
o When there is a "sprop-parameter-sets" conveyed using the o When there is a "sprop-parameter-sets" conveyed using
"fmtp" source attribute as specified in section 6.3 of the "fmtp" source attribute as specified in section 6.3
[9], and the answerer understands the "fmtp" source of [9], and the answerer understands the "fmtp" source
attribute, it MUST be prepared to use the parameter sets attribute, it MUST be prepared to use the parameter
included in "sprop-parameter-sets" for decoding the sets included in "sprop-parameter-sets" for decoding
incoming NAL unit stream, and it MUST include either the incoming NAL unit stream, and it MUST include
"use-level-src-parameter-sets" equal to 1 or the "fmtp" either "use-level-src-parameter-sets" equal to 1 or the
source attribute in the answer. "fmtp" source attribute in the answer.
o When there is a "sprop-parameter-sets" conveyed using the o When there is a "sprop-parameter-sets" conveyed using
"fmtp" source attribute as specified in section 6.3 of the "fmtp" source attribute as specified in section 6.3
[9], and the answerer does not understand the "fmtp" of [9], and the answerer does not understand the "fmtp"
source attribute, the sender MUST transmit parameter sets source attribute, the sender MUST transmit parameter
in-band, and the answerer MUST NOT include "use-level- sets in-band, and the answerer MUST NOT include "use-
src-parameter-sets" equal to 1 or the "fmtp" source level-src-parameter-sets" equal to 1 or the "fmtp"
attribute in the answer. source attribute in the answer.
o When "sprop-parameter-sets" is not present, the sender o When "sprop-parameter-sets" is not present, the sender
MUST transmit parameter sets in-band. MUST transmit parameter sets in-band.
o The answerer MUST ignore "sprop-level-parameter-sets", o The answerer MUST ignore "sprop-level-parameter-sets",
when present (either included in the "a=fmtp" line of SDP when present (either included in the "a=fmtp" line of
or conveyed using the "fmtp" source attribute). SDP or conveyed using the "fmtp" source attribute).
o When level downgrade is in use, i.e., a level lower than the o When level downgrade is in use, i.e., a level lower than the
default level offered is accepted, the following applies. default level offered is accepted, the following applies.
o The answerer MUST ignore "sprop-parameter-sets", when o The answerer MUST ignore "sprop-parameter-sets", when
present (either included in the "a=fmtp" line of SDP or present (either included in the "a=fmtp" line of SDP or
conveyed using the "fmtp" source attribute). conveyed using the "fmtp" source attribute).
o When "use-level-src-parameter-sets" equal to 1 and the o When "use-level-src-parameter-sets" equal to 1 and the
"fmtp" source attribute are not present in the answer for "fmtp" source attribute are not present in the answer
the accepted payload type, the answerer MUST ignore for the accepted payload type, the answerer MUST ignore
"sprop-level-parameter-sets", when present, and the "sprop-level-parameter-sets", when present, and the
sender MUST transmit parameter sets in-band. sender MUST transmit parameter sets in-band.
o When "use-level-src-parameter-sets" equal to 1 or the o When "use-level-src-parameter-sets" equal to 1 or the
"fmtp" source attribute is present in the answer for the "fmtp" source attribute is present in the answer for
accepted payload type, the answerer MUST be prepared to the accepted payload type, the answerer MUST be
use the parameter sets that are included in "sprop-level- prepared to use the parameter sets that are included in
parameter-sets" for the accepted level, when present, for "sprop-level-parameter-sets" for the accepted level,
decoding the incoming NAL unit stream, and ignore all when present, for decoding the incoming NAL unit stream,
other parameter sets included in "sprop-level-parameter- and ignore all other parameter sets included in "sprop-
sets". level-parameter-sets".
o When no parameter sets for the accepted level are present o When no parameter sets for the accepted level are
in the "sprop-level-parameter-sets", the sender MUST present in the "sprop-level-parameter-sets", the sender
transmit parameter sets in-band. MUST transmit parameter sets in-band.
The answerer MAY or MAY not include "sprop-parameter-sets", i.e., The answerer MAY or MAY not include "sprop-parameter-sets", i.e.,
the answerer MAY use either out-of-band or in-band transport of the answerer MAY use either out-of-band or in-band transport of
parameter sets for the stream it is sending, regardless of parameter sets for the stream it is sending, regardless of
whether out-of-band parameter sets transport has been used in the whether out-of-band parameter sets transport has been used in the
offerer-to-answerer direction. When the offer includes "in-band- offerer-to-answerer direction. When the offer includes "in-band-
parameter-sets" equal to 1, the answerer MUST not include "sprop- parameter-sets" equal to 1, the answerer MUST not include "sprop-
parameter-sets" and MUST transmit parameter sets in-band. All parameter-sets" and MUST transmit parameter sets in-band. All
parameter sets included in the "sprop-parameter-sets", when parameter sets included in the "sprop-parameter-sets", when
present, for the accepted payload type in an answer MUST be present, for the accepted payload type in an answer MUST be
 End of changes. 13 change blocks. 
49 lines changed or deleted 50 lines changed or added

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