draft-ietf-avt-rtp-rfc3984bis-07.txt   draft-ietf-avt-rtp-rfc3984bis-08.txt 
Obsoletes RFC 3984 Obsoletes RFC 3984
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: March 2010 Self-employed Expires: March 2010 Self-employed
T. Kristensen T. Kristensen
Tandberg Tandberg
R. Jesup R. Jesup
WorldGate Communications WorldGate Communications
September 10, 2009 September 21, 2009
RTP Payload Format for H.264 Video RTP Payload Format for H.264 Video
draft-ietf-avt-rtp-rfc3984bis-07.txt draft-ietf-avt-rtp-rfc3984bis-08.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. This document may contain the provisions of BCP 78 and BCP 79. This document may contain
material from IETF Documents or IETF Contributions published or material from IETF Documents or IETF Contributions published or
made publicly available before November 10, 2008. The person(s) made publicly available before November 10, 2008. The person(s)
controlling the copyright in some of this material may not have controlling the copyright in some of this material may not have
granted the IETF Trust the right to allow modifications of such granted the IETF Trust the right to allow modifications of such
material outside the IETF Standards Process. Without obtaining an material outside the IETF Standards Process. Without obtaining an
skipping to change at page 2, line 8 skipping to change at page 2, line 8
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress". 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 January 10, 2009. This Internet-Draft will expire on March 21, 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your Please review these documents carefully, as they describe your
rights and restrictions with respect to this document. 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
BSD License.
Abstract Abstract
This memo describes an RTP Payload format for the ITU-T This memo describes an RTP Payload format for the ITU-T
Recommendation H.264 video codec and the technically identical Recommendation H.264 video codec and the technically identical
ISO/IEC International Standard 14496-10 video codec, excluding the ISO/IEC International Standard 14496-10 video codec, excluding the
Scalable Video Coding (SVC) extension and the Multivew Video Coding Scalable Video Coding (SVC) extension and the Multivew Video Coding
extension, for which the RTP payload formats are defined elsewhere. extension, for which the RTP payload formats are defined elsewhere.
The RTP payload format allows for packetization of one or more The RTP payload format allows for packetization of one or more
Network Abstraction Layer Units (NALUs), produced by an H.264 video Network Abstraction Layer Units (NALUs), produced by an H.264 video
skipping to change at page 2, line 42 skipping to change at page 3, line 8
conversational usage, to Internet video streaming with interleaved conversational usage, to Internet video streaming with interleaved
transmission, to high bit-rate video-on-demand. transmission, to high bit-rate video-on-demand.
This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized
in section 18. Issues on backward compatibility to RFC 3984 are in section 18. Issues on backward compatibility to RFC 3984 are
discussed in section 17. discussed in section 17.
Table of Contents Table of Contents
Abstract.........................................................2 Abstract.........................................................2
1. Introduction..................................................4 1. Introduction..................................................5
1.1. The H.264 Codec..........................................5 1.1. The H.264 Codec..........................................5
1.2. Parameter Set Concept....................................6 1.2. Parameter Set Concept....................................6
1.3. Network Abstraction Layer Unit Types.....................7 1.3. Network Abstraction Layer Unit Types.....................7
2. Conventions...................................................8 2. Conventions...................................................8
3. Scope.........................................................8 3. Scope.........................................................8
4. Definitions and Abbreviations.................................8 4. Definitions and Abbreviations.................................8
4.1. Definitions..............................................8 4.1. Definitions..............................................8
4.2. Abbreviations...........................................10 4.2. Abbreviations...........................................10
5. RTP Payload Format...........................................11 5. RTP Payload Format...........................................11
5.1. RTP Header Usage........................................11 5.1. RTP Header Usage........................................11
5.2. Payload Structures......................................13 5.2. Payload Structures......................................13
5.3. NAL Unit Header Usage...................................14 5.3. NAL Unit Header Usage...................................15
5.4. Packetization Modes.....................................17 5.4. Packetization Modes.....................................17
5.5. Decoding Order Number (DON).............................18 5.5. Decoding Order Number (DON).............................19
5.6. Single NAL Unit Packet..................................21 5.6. Single NAL Unit Packet..................................21
5.7. Aggregation Packets.....................................22 5.7. Aggregation Packets.....................................22
Table 4. Type field for STAPs and MTAPs........................23 Table 4. Type field for STAPs and MTAPs........................23
5.7.1. Single-Time Aggregation Packet.....................23 5.7.1. Single-Time Aggregation Packet.....................24
5.7.2. Multi-Time Aggregation Packets (MTAPs).............26 5.7.2. Multi-Time Aggregation Packets (MTAPs).............26
5.7.3. Fragmentation Units (FUs)..........................30 5.7.3. Fragmentation Units (FUs)..........................30
6. Packetization Rules..........................................34 6. Packetization Rules..........................................34
6.1. Common Packetization Rules..............................34 6.1. Common Packetization Rules..............................34
6.2. Single NAL Unit Mode....................................35 6.2. Single NAL Unit Mode....................................35
6.3. Non-Interleaved Mode....................................35 6.3. Non-Interleaved Mode....................................35
6.4. Interleaved Mode........................................36 6.4. Interleaved Mode........................................36
7. De-Packetization Process.....................................36 7. De-Packetization Process.....................................36
7.1. Single NAL Unit and Non-Interleaved Mode................36 7.1. Single NAL Unit and Non-Interleaved Mode................36
7.2. Interleaved Mode........................................37 7.2. Interleaved Mode........................................37
7.2.1. Size of the De-interleaving Buffer.................37 7.2.1. Size of the De-interleaving Buffer.................37
7.2.2. De-interleaving Process............................38 7.2.2. De-interleaving Process............................38
7.3. Additional De-Packetization Guidelines..................39 7.3. Additional De-Packetization Guidelines..................39
8. Payload Format Parameters....................................40 8. Payload Format Parameters....................................40
8.1. Media Type Registration.................................40 8.1. Media Type Registration.................................40
8.2. SDP Parameters..........................................59 8.2. SDP Parameters..........................................59
8.2.1. Mapping of Payload Type Parameters to SDP..........59 8.2.1. Mapping of Payload Type Parameters to SDP..........59
8.2.2. Usage with the SDP Offer/Answer Model..............60 8.2.2. Usage with the SDP Offer/Answer Model..............60
8.2.3. Usage in Declarative Session Descriptions..........69 8.2.3. Usage in Declarative Session Descriptions..........69
8.3. Examples................................................70 8.3. Examples................................................71
Offer SDP:......................................................76 Offer SDP:......................................................76
Answer SDP:.....................................................76 Answer SDP:.....................................................77
8.4. Parameter Set Considerations............................77 8.4. Parameter Set Considerations............................78
8.5. Decoder Refresh Point Procedure using In-Band Transport of 8.5. Decoder Refresh Point Procedure using In-Band Transport of
Parameter Sets (Informative).................................80 Parameter Sets (Informative).................................81
8.5.1. IDR Procedure to Respond to a Request for a Decoder 8.5.1. IDR Procedure to Respond to a Request for a Decoder
Refresh Point.............................................80 Refresh Point.............................................81
8.5.2. Gradual Recovery Procedure to Respond to a Request for 8.5.2. Gradual Recovery Procedure to Respond to a Request for
a Decoder Refresh Point...................................81 a Decoder Refresh Point...................................82
9. Security Considerations......................................82 9. Security Considerations......................................82
10. Congestion Control..........................................82 10. Congestion Control..........................................83
11. IANA Consideration..........................................83 11. IANA Consideration..........................................84
12. Informative Appendix: Application Examples..................83 12. Informative Appendix: Application Examples..................84
12.1. Video Telephony according to ITU-T Recommendation H.241 12.1. Video Telephony according to ITU-T Recommendation H.241
Annex A......................................................84 Annex A......................................................84
12.2. Video Telephony, No Slice Data Partitioning, No NAL Unit 12.2. Video Telephony, No Slice Data Partitioning, No NAL Unit
Aggregation..................................................84 Aggregation..................................................85
12.3. Video Telephony, Interleaved Packetization Using NAL Unit 12.3. Video Telephony, Interleaved Packetization Using NAL Unit
Aggregation..................................................84 Aggregation..................................................85
12.4. Video Telephony with Data Partitioning.................85 12.4. Video Telephony with Data Partitioning.................86
12.5. Video Telephony or Streaming with FUs and Forward Error 12.5. Video Telephony or Streaming with FUs and Forward Error
Correction...................................................86 Correction...................................................86
12.6. Low Bit-Rate Streaming.................................88 12.6. Low Bit-Rate Streaming.................................89
12.7. Robust Packet Scheduling in Video Streaming............89 12.7. Robust Packet Scheduling in Video Streaming............90
13. Informative Appendix: Rationale for Decoding Order Number...90 13. Informative Appendix: Rationale for Decoding Order Number...91
13.1. Introduction...........................................90 13.1. Introduction...........................................91
13.2. Example of Multi-Picture Slice Interleaving............90 13.2. Example of Multi-Picture Slice Interleaving............91
13.3. Example of Robust Packet Scheduling....................91 13.3. Example of Robust Packet Scheduling....................92
13.4. Robust Transmission Scheduling of Redundant Coded Slices95 13.4. Robust Transmission Scheduling of Redundant Coded Slices96
13.5. Remarks on Other Design Possibilities..................96 13.5. Remarks on Other Design Possibilities..................97
14. Acknowledgements............................................97 14. Acknowledgements............................................98
15. References..................................................97 15. References..................................................98
15.1. Normative References...................................97 15.1. Normative References...................................98
15.2. Informative References.................................98 15.2. Informative References.................................99
16. Authors' Addresses.........................................100 16. Authors' Addresses.........................................101
Phone: +1-908-541-3518.........................................100 Phone: +1-908-541-3518.........................................101
Phone: +972-545481099..........................................100 Phone: +972-545481099..........................................101
Tom Kristensen.................................................100 Tom Kristensen.................................................101
Phone: +47 67125125............................................100 Phone: +47 67125125............................................101
Phone: +1-215-354-5166.........................................100 Phone: +1-215-354-5166.........................................101
Email: rjesup@wgate.com........................................100 Email: rjesup@wgate.com........................................101
17. Backward Compatibility to RFC 3984.........................100 17. Backward Compatibility to RFC 3984.........................101
18. Changes from RFC 3984......................................102 18. Changes from RFC 3984......................................103
1. Introduction 1. Introduction
This memo specifies an RTP payload specification for the video This memo specifies an RTP payload specification for the video
coding standard known as ITU-T Recommendation H.264 [1] and ISO/IEC coding standard known as ITU-T Recommendation H.264 [1] and ISO/IEC
International Standard 14496 Part 10 [2] (both also known as International Standard 14496 Part 10 [2] (both also known as
Advanced Video Coding, or AVC). In this memo the name H.264 is Advanced Video Coding, or AVC). In this memo the name H.264 is
used for the codec and the standard, but the memo is equally used for the codec and the standard, but the memo is equally
applicable to the ISO/IEC counterpart of the coding standard. applicable to the ISO/IEC counterpart of the coding standard.
skipping to change at page 10, line 34 skipping to change at page 10, line 44
default sub-profile: The subset of coding tools, which may be default sub-profile: The subset of coding tools, which may be
all coding tools of one profile or the common subset of coding all coding tools of one profile or the common subset of coding
tools of more than one profile, indicated by the profile-level- tools of more than one profile, indicated by the profile-level-
id parameter. id parameter.
default level: The level indicated by the profile-level-id default level: The level indicated by the profile-level-id
parameter, which consists of three octets, profile_idc, profile- parameter, which consists of three octets, profile_idc, profile-
iop, and level_idc. The default level is indicated by level_idc iop, and level_idc. The default level is indicated by level_idc
in most cases, and, in some cases, additionally by profile-iop. in most cases, and, in some cases, additionally by profile-iop.
maximum receive level: The higher of the default level (from
profile-level-id) and max-recv-level (if specified).
4.2. Abbreviations 4.2. Abbreviations
DON: Decoding Order Number DON: Decoding Order Number
DONB: Decoding Order Number Base DONB: Decoding Order Number Base
DOND: Decoding Order Number Difference DOND: Decoding Order Number Difference
FEC: Forward Error Correction FEC: Forward Error Correction
FU: Fragmentation Unit FU: Fragmentation Unit
IDR: Instantaneous Decoding Refresh IDR: Instantaneous Decoding Refresh
IEC: International Electrotechnical Commission IEC: International Electrotechnical Commission
ISO: International Organization for Standardization ISO: International Organization for Standardization
skipping to change at page 43, line 20 skipping to change at page 43, line 20
to support is the default sub-profile, and the lowest level to support is the default sub-profile, and the lowest level
the decoder has to support is the default level. the decoder has to support is the default level.
If the profile-level-id parameter is used for capability If the profile-level-id parameter is used for capability
exchange or session setup procedure, it indicates the subset exchange or session setup procedure, it indicates the subset
of coding tools, which is equal to the default sub-profile, of coding tools, which is equal to the default sub-profile,
that the codec supports for both receiving and sending. If that the codec supports for both receiving and sending. If
max-recv-level is not present, the default level from max-recv-level is not present, the default level from
profile-level-id indicates the highest level the codec wishes profile-level-id indicates the highest level the codec wishes
to support. If max-recv-level is present it indicates the to support. If max-recv-level is present it indicates the
highest level the codec supports for receiving, for use in highest level the codec supports for receiving. For either
asymmetric exchanges. For either receiving or sending, all receiving or sending, all levels that are lower than the
levels that are lower than the highest level supported MUST highest level supported MUST also be supported.
also be supported.
Informative note: Capability exchange and session setup Informative note: Capability exchange and session setup
procedures should provide means to list the capabilities procedures should provide means to list the capabilities
for each supported sub-profile separately. For example, for each supported sub-profile separately. For example,
the one-of-N codec selection procedure of the SDP the one-of-N codec selection procedure of the SDP
Offer/Answer model can be used (section 10.2 of [8]). Offer/Answer model can be used (section 10.2 of [8]).
The one-of-N codec selection procedure may also be used The one-of-N codec selection procedure may also be used
to provide different combinations of profile_idc and to provide different combinations of profile_idc and
profile-iop that represent the same sub-profile. When profile-iop that represent the same sub-profile. When
there are many different combinations of profile_idc and there are many different combinations of profile_idc and
skipping to change at page 44, line 6 skipping to change at page 44, line 5
If no profile-level-id is present, the Baseline Profile If no profile-level-id is present, the Baseline Profile
without additional constraints at Level 1 MUST be inferred. without additional constraints at Level 1 MUST be inferred.
max-recv-level: max-recv-level:
This parameter MAY be used to indicate the highest level a This parameter MAY be used to indicate the highest level a
receiver supports when the highest level is higher than the receiver supports when the highest level is higher than the
default level (the level indicated by profile-level-id). The default level (the level indicated by profile-level-id). The
value of max-recv-level is a base16 (hexadecimal) value of max-recv-level is a base16 (hexadecimal)
representation of the two bytes after the syntax element representation of the two bytes after the syntax element
profile_idc in the sequence parameter set NAL unit specified profile_idc in the sequence parameter set NAL unit specified
in [1]: profile-iop (as defined above) and level_idc. If the in [1]: profile-iop (as defined above) and level_idc. If
level_idc byte of max-recv-level is equal to 11, and bit 4 of (the level_idc byte of max-recv-level is equal to 11 and bit
the profile-iop byte of max-recv-level is equal to 1, the 4 of the profile-iop byte of max-recv-level is equal to 1) or
highest level the receiver supports is level 1b. If bit 4 of (the level_idc byte of max-recv-level is equal to 9 and bit 4
the profile-iop byte of max-recv-level is equal to 0, the of the profile-iop byte of max-recv-level is equal to 0), the
highest level the receiver supports is equal to the level_idc highest level the receiver supports is level 1b. Otherwise,
byte of max-recv-level divided by 10. the highest level the receiver supports is equal to the
level_idc byte of max-recv-level divided by 10.
max-recv-level MUST NOT be present if the highest level the max-recv-level MUST NOT be present if the highest level the
receiver supports is not higher than the default level. receiver supports is not higher than the default level.
max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br: max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br:
These parameters MAY be used to signal the capabilities of a These parameters MAY be used to signal the capabilities of a
receiver implementation. These parameters MUST NOT be used receiver implementation. These parameters MUST NOT be used
for any other purpose. The highest level conveyed in the for any other purpose. The highest level conveyed in the
value of the profile-level-id parameter or the max-recv-level value of the profile-level-id parameter or the max-recv-level
parameter MUST be such that the receiver is fully capable of parameter MUST be such that the receiver is fully capable of
skipping to change at page 46, line 5 skipping to change at page 46, line 5
o Set a variable P_non-static to the proportion of non- o Set a variable P_non-static to the proportion of non-
static macroblocks in picture n. static macroblocks in picture n.
o Set a variable P_static to the proportion of static o Set a variable P_static to the proportion of static
macroblocks in picture n. macroblocks in picture n.
o The value of MaxMBPS in Table A-1 of [1] should be o The value of MaxMBPS in Table A-1 of [1] should be
considered by the encoder to be equal to: considered by the encoder to be equal to:
MaxMacroblocksPerSecond * max-smbps / ( P_non-static * MaxMacroblocksPerSecond * max-smbps / (P_non-static *
max-smbps + P_static * MaxMacroblocksPerSecond) max-smbps + P_static * MaxMacroblocksPerSecond)
The encoder should recompute this value for each picture. The The encoder should recompute this value for each picture. The
value of max-smbps MUST be greater than the value of MaxMBPS value of max-smbps MUST be greater than the value of MaxMBPS
given in Table A-1 of [1] for the highest level. Senders MAY given in Table A-1 of [1] for the highest level. Senders MAY
use this knowledge to send pictures of a given size at a use this knowledge to send pictures of a given size at a
higher picture rate than is indicated in the signaled highest higher picture rate than is indicated in the signaled highest
level. level.
max-fs: The value of max-fs is an integer indicating the maximum max-fs: The value of max-fs is an integer indicating the maximum
skipping to change at page 48, line 26 skipping to change at page 48, line 26
receiver is capable of decoding video at a higher bit rate receiver is capable of decoding video at a higher bit rate
than is required by the signaled highest level conveyed in than is required by the signaled highest level conveyed in
the value of the profile-level-id parameter or the max-recv- the value of the profile-level-id parameter or the max-recv-
level parameter. level parameter.
When max-br is signaled, the video codec of the receiver MUST When max-br is signaled, the video codec of the receiver MUST
be able to decode NAL unit streams that conform to the be able to decode NAL unit streams that conform to the
signaled highest level, with the following exceptions in the signaled highest level, with the following exceptions in the
limits specified by the highest level: limits specified by the highest level:
o The value of max-br replaces the MaxBR value n Table A-1 o The value of max-br replaces the MaxBR value in Table A-1
of [1] for the highest level. of [1] for the highest level.
o When the max-cpb parameter is not present, the result of o When the max-cpb parameter is not present, the result of
the following formula replaces the value of MaxCPB in the following formula replaces the value of MaxCPB in
Table A-1 of [1]: (MaxCPB of the signaled level) * max-br Table A-1 of [1]: (MaxCPB of the signaled level) * max-br
/ (MaxBR of the signaled highest level). / (MaxBR of the signaled highest level).
For example, if a receiver signals capability for Level 1.2 For example, if a receiver signals capability for Level 1.2
with max-br equal to 1550, this indicates a maximum video with max-br equal to 1550, this indicates a maximum video
bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum
skipping to change at page 61, line 30 skipping to change at page 61, line 30
configuration parameters with any payload types it has configuration parameters with any payload types it has
already declared. This will enable it to determine whether already declared. This will enable it to determine whether
the configuration in question is new or if it is equivalent the configuration in question is new or if it is equivalent
to configuration already offered, since a different payload to configuration already offered, since a different payload
type number may be used in the answer. type number may be used in the answer.
o The parameter "max-recv-level", when present, declares the o The parameter "max-recv-level", when present, declares the
highest level supported for receiving. In case "max-recv-level" highest level supported for receiving. In case "max-recv-level"
is not present, the highest level supported for receiving is is not present, the highest level supported for receiving is
equal to the default level indicated by the level part of equal to the default level indicated by the level part of
"profile-level-id". "max-recv-level" MUST be higher than the "profile-level-id". "max-recv-level", when present, MUST be
default level. higher than the default level.
o The parameter "level-asymmetry-allowed" indicates whether level o The parameter "level-asymmetry-allowed" indicates whether level
asymmetry is allowed. asymmetry is allowed.
If "level-asymmetry-allowed" is equal to 0 (or not present) in If "level-asymmetry-allowed" is equal to 0 (or not present) in
either the offer or the answer, level asymmetry is not allowed. either the offer or the answer, level asymmetry is not allowed.
In this case, the level to use in the direction from the offerer In this case, the level to use in the direction from the offerer
to the answerer MUST be the same as the level to use in the to the answerer MUST be the same as the level to use in the
opposite direction, and the common level to use is equal to the opposite direction, and the common level to use is equal to the
lower value of the default level in the offer and the default lower value of the default level in the offer and the default
skipping to change at page 64, line 19 skipping to change at page 64, line 19
offer, the offerer MUST transmit parameter sets offer, the offerer MUST transmit parameter sets
in-band. in-band.
The answerer MUST ignore "sprop-level-parameter- The answerer MUST ignore "sprop-level-parameter-
sets", when present (either included in the sets", when present (either included in the
"a=fmtp" line or conveyed using the "fmtp" source "a=fmtp" line or conveyed using the "fmtp" source
attribute) in the offer. attribute) in the offer.
o Otherwise (the level to use in the offerer-to-answerer o Otherwise (the level to use in the offerer-to-answerer
direction is not equal to the default level in the direction is not equal to the default level in the
offer, the following applies. offer), the following applies.
The answerer MUST ignore "sprop-parameter-sets", The answerer MUST ignore "sprop-parameter-sets",
when present (either included in the "a=fmtp" when present (either included in the "a=fmtp"
line or conveyed using the "fmtp" source line or conveyed using the "fmtp" source
attribute) in the offer. attribute) in the offer.
When neither "use-level-src-parameter-sets" equal When neither "use-level-src-parameter-sets" equal
to 1 nor the "fmtp" source attribute is present to 1 nor the "fmtp" source attribute is present
in the answer, the answerer MUST ignore "sprop- in the answer, the answerer MUST ignore "sprop-
level-parameter-sets", when present in the offer, level-parameter-sets", when present in the offer,
skipping to change at page 65, line 48 skipping to change at page 65, line 48
answer, the answerer MUST transmit parameter sets answer, the answerer MUST transmit parameter sets
in-band. in-band.
The offerer MUST ignore "sprop-level-parameter- The offerer MUST ignore "sprop-level-parameter-
sets", when present (either included in the sets", when present (either included in the
"a=fmtp" line or conveyed using the "fmtp" source "a=fmtp" line or conveyed using the "fmtp" source
attribute) in the answer. attribute) in the answer.
o Otherwise (the level to use in the answerer-to-offerer o Otherwise (the level to use in the answerer-to-offerer
direction is not equal to the default level in the direction is not equal to the default level in the
answer, the following applies. answer), the following applies.
The offerer MUST ignore "sprop-parameter-sets", The offerer MUST ignore "sprop-parameter-sets",
when present (either included in the "a=fmtp" when present (either included in the "a=fmtp"
line of SDP or conveyed using the "fmtp" source line of SDP or conveyed using the "fmtp" source
attribute) in the answer. attribute) in the answer.
When neither "use-level-src-parameter-sets" equal When neither "use-level-src-parameter-sets" equal
to 1 nor the "fmtp" source attribute is present to 1 nor the "fmtp" source attribute is present
in the offer, the offerer MUST ignore "sprop- in the offer, the offerer MUST ignore "sprop-
level-parameter-sets", when present, and the level-parameter-sets", when present, and the
skipping to change at page 66, line 33 skipping to change at page 66, line 33
stream, and ignore all other parameter sets stream, and ignore all other parameter sets
included in "sprop-level-parameter-sets" in the included in "sprop-level-parameter-sets" in the
answer. answer.
When no parameter sets for the level to use in When no parameter sets for the level to use in
the answerer-to-offerer direction are present in the answerer-to-offerer direction are present in
"sprop-level-parameter-sets" in the answer, the "sprop-level-parameter-sets" in the answer, the
answerer MUST transmit parameter sets in-band. answerer MUST transmit parameter sets in-band.
When "sprop-parameter-sets" or "sprop-level-parameter-sets" is When "sprop-parameter-sets" or "sprop-level-parameter-sets" is
conveyed using the "fmtp" source attribute in as specified in conveyed using the "fmtp" source attribute as specified in
section 6.3 of [9], the receiver of the parameters MUST store section 6.3 of [9], the receiver of the parameters MUST store
the parameter sets included in the "sprop-parameter-sets" or the parameter sets included in the "sprop-parameter-sets" or
"sprop-level-parameter-sets" for the accepted level and "sprop-level-parameter-sets" for the accepted level and
associate them to the source given as a part of the "fmtp" associate them to the source given as a part of the "fmtp"
source attribute. Parameter sets associated with one source source attribute. Parameter sets associated with one source
MUST only be used to decode NAL units conveyed in RTP packets MUST only be used to decode NAL units conveyed in RTP packets
from the same source. When this mechanism is in use, SSRC from the same source. When this mechanism is in use, SSRC
collision detection and resolution MUST be performed as collision detection and resolution MUST be performed as
specified in [9]. specified in [9].
skipping to change at page 98, line 9 skipping to change at page 99, line 6
[6] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [6] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[7] Josefsson, S., "The Base16, Base32, and Base64 Data [7] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003. Encodings", RFC 3548, July 2003.
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[9] Lennox, J., Ott, J., and Schierl, T., "Source-Specific Media [9] Lennox, J., Ott, J., and Schierl, T., "Source-Specific Media
Attributes in the Session Description Protocol", draft-ietf- Attributes in the Session Description Protocol (SDP)", RFC
mmusic-sdp-source-attributes-02 (work in progress), October 5576, June 2009.
2008.
15.2. Informative References 15.2. Informative References
[10] Luthra, A., Sullivan, G.J., and T. Wiegand (eds.), Special [10] Luthra, A., Sullivan, G.J., and T. Wiegand (eds.), Special
Issue on H.264/AVC. IEEE Transactions on Circuits and Systems Issue on H.264/AVC. IEEE Transactions on Circuits and Systems
on Video Technology, July 2003. on Video Technology, July 2003.
[11] Ott, J., Bormann, C., Sullivan, G., Wenger, S., and R. Even [11] Ott, J., Bormann, C., Sullivan, G., Wenger, S., and R. Even
(Ed.), "RTP Payload Format for ITU-T Rec. H.263 Video", RFC (Ed.), "RTP Payload Format for ITU-T Rec. H.263 Video", RFC
4629, January 2007. 4629, January 2007.
 End of changes. 28 change blocks. 
66 lines changed or deleted 65 lines changed or added

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