Audio/Video Transport WG M.M. Hannuksela
Internet Draft Y.-K. Wang
Intended status: Standards track Nokia
Expires: December 2008 June 4, 2008
Session Multiplexing for SVC Video
draft-hannuksela-avt-rtp-svc-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 4, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Hannuksela, Wang Expires December 4, 2008 [Page 1]
Internet-Draft Session Multiplexing for SVC Video June 2008
Abstract
This memo describes a method for decoding order recovery of the
Network Abstraction Layer (NAL) units carried in multiple session-
multiplexed RTP sessions for Scalable Video Coding (SVC), which is
defined in Annex G of the ITU-T Recommendation H.264 video codec that
is technically identical to Amendment 3 of ISO/IEC International
Standard 14496-10. The method applies when non-interleaved
transmission of NAL units using the Single NAL Unit packetization
mode or the Non-Interleaved packetization mode defined in RFC 3984 is
in use.
Table of Contents
Status of this Memo...............................................1
Copyright Notice..................................................1
Abstract..........................................................2
Table of Contents.................................................2
1. Introduction...................................................3
2. Conventions....................................................3
3. The SVC Codec..................................................3
4. Scope..........................................................3
5. Definitions and Abbreviations..................................4
5.1. Definitions...............................................4
5.1.1. Definitions Per SVC Specification....................4
5.1.2. Definitions Local to This Memo.......................4
5.2. Abbreviations.............................................4
6. RTP Payload Format.............................................4
6.1. Design Principles.........................................4
6.2. RTP Header Usage..........................................4
6.3. Common Structure of the RTP Payload Format................4
6.4. NAL Unit Header Usage.....................................4
6.5. Packetization Modes.......................................5
6.5.1. Packetization Modes for Session Multiplexing.........5
6.6. Decoding Order Number (DON)...............................8
6.6.1. Access Unit DON (AU-DON) for Session Multiplexing....8
6.6.2. Cross-Session DON (CS-DON) for Session Multiplexing..8
6.7. Aggregation Packets.......................................8
6.8. Fragmentation Units (FUs).................................8
6.9. Payload Content Scalability Information (PACSI) NAL Unit..8
7. Packetization Rules............................................9
7.1. Packetization Rules for Session Multiplexing..............9
7.1.1. NI-A Session-Multiplexing Packetization Rules........9
7.1.2. I-C Session-Multiplexing Packetization Rules........10
Hannuksela, Wang Expires December 4, 2008 [Page 2]
Internet-Draft Session Multiplexing for SVC Video June 2008
7.1.3. Packetization rules for non-VCL NAL units...........10
7.1.4. Packetization rules for Prefix NAL units............10
8. De-Packetization Process......................................10
8.1. De-Packetization Process for Session Multiplexing........10
8.1.1. Decoding Order Recovery for the NI-A Mode...........10
8.1.1.1. Informative Algorithm for NI-A Decoding Order
Recovery within an Access Unit..........................13
8.1.2. Decoding Order Recovery for the I-C Mode............13
9. Payload Format Parameters.....................................13
9.1. Media Type Registration..................................13
9.2. SDP Parameters...........................................15
9.3. Examples.................................................15
9.4. Parameter Set Considerations.............................15
10. Security Considerations......................................15
11. Congestion Control...........................................15
12. IANA Consideration...........................................15
13. Informative Appendix: Application Examples...................15
14. References...................................................15
14.1. Normative References....................................15
14.2. Informative References..................................16
15. Authors' Addresses...........................................16
Intellectual Property Statement..................................16
Disclaimer of Validity...........................................17
Copyright Statement..............................................17
Acknowledgement..................................................17
1. Introduction
Section 1 of draft-ietf-avt-rtp-svc-10 applies.
In addition, this memo specifies an alternative method for decoder
order recovery of NAL units carried in multiple session-multiplexed
RTP sessions.
2. Conventions
Section 2 of draft-ietf-avt-rtp-svc-10 applies.
3. The SVC Codec
Section 3 of draft-ietf-avt-rtp-svc-10 applies.
4. Scope
Section 4 of draft-ietf-avt-rtp-svc-10 applies.
Hannuksela, Wang Expires December 4, 2008 [Page 3]
Internet-Draft Session Multiplexing for SVC Video June 2008
5. Definitions and Abbreviations
5.1. Definitions
5.1.1. Definitions Per SVC Specification
Section 5.1.1 of draft-ietf-avt-rtp-svc-10 applies.
5.1.2. Definitions Local to This Memo
Section 5.1.2 of draft-ietf-avt-rtp-svc-10 applies with the following
addition.
access unit decoding order number (AU-DON): A variable that is
derived for each access unit when the single NAL unit
packetization mode or the non-interleaved packetization mode is
in use. AU-DON indicates the decoding order of an access unit.
5.2. Abbreviations
Section 5.2 of draft-ietf-avt-rtp-svc-10 applies with the following
addition.
AU-DON: Access Unit Decoding Order Number
6. RTP Payload Format
6.1. Design Principles
Section 6.1 of draft-ietf-avt-rtp-svc-10 applies.
6.2. RTP Header Usage
Section 6.2 of draft-ietf-avt-rtp-svc-10 applies.
6.3. Common Structure of the RTP Payload Format
Section 6.3 of draft-ietf-avt-rtp-svc-10 applies.
6.4. NAL Unit Header Usage
Section 6.4 of draft-ietf-avt-rtp-svc-10 applies.
Hannuksela, Wang Expires December 4, 2008 [Page 4]
Internet-Draft Session Multiplexing for SVC Video June 2008
6.5. Packetization Modes
Section 5.4 of RFC 3984 applies when session multiplexing is not in
use. The packetization modes specified in Section 5.4 of RFC 3984
are also referred to as session-specific packetization modes.
When session multiplexing is in use, the following applies in
addition.
6.5.1. Packetization Modes for Session Multiplexing
This memo specifies two cases of session-multiplexing packetization
modes when session multiplexing is in use:
o Non-interleaved AU-DON (NI-A) mode
o Interleaved CS-DON (I-C) mode
The NI-A mode is targeted for systems that require relatively low
end-to-end latency, e.g. conversational systems. In the NI-A mode,
NAL units in each RTP session are transmitted in NAL unit decoding
order. The I-C mode is targeted for systems that do not require very
low end-to-end latency. The I-C mode allows transmission of NAL
units out of NAL unit decoding order in each RTP session.
The session-multiplexing packetization mode in use MAY be signaled by
the value of the OPTIONAL session-multiplexing-packetization-mode
media type parameter or by external means. When the value of
session-multiplexing-packetization-mode is equal to 0, the NI-A mode
MUST be used. When the value of session-multiplexing-packetization-
mode is equal to 1, the I-C mode MUST be used. [Ed.Note(YkW): There
MAY be at most one global session-multiplexing-packetization-mode
present in the SDP common for all the multiplexed RTP sessions. It
is also possible to have session-multiplexing-packetization-mode
session-specific in the SDP, but then all the multiplexed sessions
MUST have the same value of this parameter. When session-
multiplexing-packetization-mode is not present, the NI-A mode is
implied.]
The used session-multiplexing packetization mode governs which
session-specific packetization modes are allowed in the multiplexed
RTP sessions, which in turn govern which NAL unit types are allowed
as RTP payloads.
Table 3.1 summarizes the allowed session-specific packetization modes
for the NI-A session-multiplexing packetizatio modes. Table 3.2
Hannuksela, Wang Expires December 4, 2008 [Page 5]
Internet-Draft Session Multiplexing for SVC Video June 2008
summarizes the allowed session-specific packetization modes for the
I-C session-multiplexing packetization mode.
Table 3.1 Summary of allowed session-specific packetization modes
for the NI-A session-multiplexing packetization modes (yes = allowed,
no = disallowed)
Session-Specific Mode Base Session Enhancement Session
----------------------------------------------------------
Single NAL Unit Mode yes no
Non-Interleaved Mode yes yes
Interleaved Mode no no
Table 3.2 Summary of allowed session-specific packetization modes
for the I-C session-multiplexing packetization mode (yes = allowed,
no = disallowed)
Session-Specific Mode Base Session Enhancement Session
----------------------------------------------------------
Single NAL Unit Mode no no
Non-Interleaved Mode no no
Interleaved Mode yes yes
Table 3.3 summarizes the allowed NAL unit types for each allowed
session-specific packetization mode of the NI-A session-multiplexing
packetization mode. Table 3.4 summarizes the allowed NAL unit types
for the only allowed session-specific packetization mode (i.e. the
interleaved mode) of the I-C session-multiplexing packetization mode.
Hannuksela, Wang Expires December 4, 2008 [Page 6]
Internet-Draft Session Multiplexing for SVC Video June 2008
Table 3.3 Summary of allowed NAL unit types for each session-
specific packetization mode of the NI-A session-multiplexing
packetization mode (yes = allowed, no = disallowed, ig = ignore)
Type Packet Single NAL Non-Interleaved
Unit Mode Mode
------------------------------------------------
0 undefined ig ig
1-23 NAL unit yes yes
24 STAP-A no yes
25 STAP-B no no
26 MTAP16 no no
27 MTAP24 no no
28 FU-A no yes
29 FU-B no no
30 PACSI yes yes
31 undefined ig ig
Table 3.4 Summary of allowed NAL unit types for the session-specific
packetization mode of the I-C session-multiplexing packetization mode
(yes = allowed, no = disallowed, ig = ignore)
Type Packet Interleaved
Mode
------------------------------
0 undefined ig
1-23 NAL unit no
24 STAP-A no
25 STAP-B yes
26 MTAP16 yes
27 MTAP24 yes
28 FU-A yes
29 FU-B yes
30 PACSI no (see the informative note below)
31 undefined no
Informative note: PACSI NAL units are allowed to be included
in an aggregation packet but disallowed as single NAL unit
packets.
The NAL unit type values indicated as undefined in Tables 3.3 and 3.4
are reserved for future extensions. NAL units of those types SHOULD
NOT be sent by a sender and MUST be ignored by a receiver. Note that
NAL unit type 30 and 31 are indicated as undefined in RFC 3984,
therefore RFC 3984 receivers MUST ignore NAL units of this type, if
present.
Hannuksela, Wang Expires December 4, 2008 [Page 7]
Internet-Draft Session Multiplexing for SVC Video June 2008
6.6. Decoding Order Number (DON)
Section 5.5 of [RFC3984] applies when session multiplexing is not in
use.
When session multiplexing is in use, the following applies in
addition.
6.6.1. Access Unit DON (AU-DON) for Session Multiplexing
When the NI-A session-multiplexing packetization mode is in use, the
packetization of each session MUST be as specified in Section 7.1.,
and the following applies for the derivation of the AU-DON value for
each non-PACSI NAL unit.
The AU-DON value for all NAL units having the same NALU time is
identical and MUST be conveyed in at least one PACSI NAL unit.
6.6.2. Cross-Session DON (CS-DON) for Session Multiplexing
When the I-C session-multiplexing packetization mode is in use, the
DON values derived according to RFC 3984 of all the NAL units in each
of the multiplexed RTP sessions MUST indicate CS-DON values.
6.7. Aggregation Packets
Section 6.7 of draft-ietf-avt-rtp-svc-10 applies.
6.8. Fragmentation Units (FUs)
Section 6.8 of draft-ietf-avt-rtp-svc-10 applies.
6.9. Payload Content Scalability Information (PACSI) NAL Unit
Section 6.9 of draft-ietf-avt-rtp-svc-10 applies with the following
modifications.
The name of the DONC field is changed to AU-DON.
The semantics of DONC are removed.
The occurrences of "DONC" are replaced with "AU-DON".
The semantics of AU-DON are specified as follows.
Hannuksela, Wang Expires December 4, 2008 [Page 8]
Internet-Draft Session Multiplexing for SVC Video June 2008
o When present, the field AU-DON indicates the access unit decoding
order number for all the NAL units in the aggregation packet (when
the PACSI NAL unit is included in an aggregation packet) or the
AU-DON of the next non-PACSI NAL unit in transmission order (when
the PACSI NAL unit is included in a single NAL unit packet).
7. Packetization Rules
Section 7 of draft-ietf-avt-rtp-svc-10 applies.
7.1. Packetization Rules for Session Multiplexing
When session multiplexing is used, decoding order recovery for NAL
units carried in all the multiplexed RTP sessions is needed. The
following packetization rules ensure that decoding order of NAL units
carried in the multiplexed sessions can be correctly recovered for
each of the session-multiplexing packetization modes according to the
de-packetization process specified in Section 8.1. .
7.1.1. NI-A Session-Multiplexing Packetization Rules
When the NI-A session-multiplexing packetization mode is in use, the
following applies.
o For each single NAL unit packet containing a non-PACSI NAL unit,
if present, the previous packet MUST have the same RTP timestamp
as the single NAL unit packet, and the following applies.
If the NALU time of the non-PACSI NAL unit is not equal to the
NALU time of the previous non-PACSI NAL unit in decoding
order, the previous packet MUST contain a PACSI NAL unit
containing the AU-DON field;
Otherwise (the NALU time of the non-PACSI NAL unit is equal to
the NALU time of the previous non-PACSI NAL unit in decoding
order), the previous packet MAY contain a PACSI NAL unit
containing the AU-DON field.
o For each STAP-A packet, if present, if the RTP timestamp is
different from the RTP timestamp of the previous STAP-A packet,
the first NAL unit in the STAP-A packet MUST be a PACSI NAL unit
containing the AU-DON field.
o For each FU-A packet, if present, the previous packet MUST have
the same RTP timestamp as the FU-A packet, and the following
applies.
Hannuksela, Wang Expires December 4, 2008 [Page 9]
Internet-Draft Session Multiplexing for SVC Video June 2008
If the FU-A packet is the start of the fragmented NAL unit, the
following applies;
If the NALU time of the fragmented NAL unit is not equal
to the NALU time of the previous non-PACSI NAL unit in
decoding order, the previous packet MUST contain a PACSI
NAL unit containing the AU-DON field;
Otherwise (the NALU time of the fragmented NAL unit is
equal to the NALU time of the previous non-PACSI NAL unit
in decoding order), the previous packet MAY contain a
PACSI NAL unit containing the AU-DON field.
o For each single NAL unit packet containing a PACSI NAL unit, if
present, the PACSI NAL unit MUST contain the AU-DON field.
7.1.2. I-C Session-Multiplexing Packetization Rules
Section 7.1.2 of draft-ietf-avt-rtp-svc-10 applies.
7.1.3. Packetization rules for non-VCL NAL units
Section 7.1.3 of draft-ietf-avt-rtp-svc-10 applies.
7.1.4. Packetization rules for Prefix NAL units
Section 7.1.4 of draft-ietf-avt-rtp-svc-10 applies.
8. De-Packetization Process
Section 8 of draft-ietf-avt-rtp-svc-10 applies.
8.1. De-Packetization Process for Session Multiplexing
Section 8.1 of draft-ietf-avt-rtp-svc-10 applies.
8.1.1. Decoding Order Recovery for the NI-A Mode
The following process SHALL be applied when the NI-A session-
multiplexing packetization mode is in use.
The RTP packets output from the RTP-level reception processing for
each session are placed into the de-session-multiplexing buffer.
It is RECOMMENDED to set the size of the de-session-multiplexing
buffer, in terms of number of bytes, equal to or greater than the
Hannuksela, Wang Expires December 4, 2008 [Page 10]
Internet-Draft Session Multiplexing for SVC Video June 2008
value of the sprop-desemul-buf-req media type parameter of the
highest RTP session the receiver receives.
The AU-DON value is inferred and stored for each NAL unit.
The receiver operation is described below with the help of the
following functions and constants:
o Function AbsDON is specified in Section 8.1 of RFC 3984.
o Function don_diff is specified in Section 5.5 of RFC 3984.
o Constant N is the value of the OPTIONAL sprop-session-
multiplexing-depth media type parameter of the highest RTP session
incremented by 1.
Initial buffering lasts until one of the following conditions is
fulfilled:
o There are N or more VCL NAL units in the de-session-multiplexing
buffer.
o If sprop-semul-max-don-diff of the highest SVC RTP session is
present, don_diff(m,n) is greater than the value of sprop-semul-
max-don-diff of the highest RTP session, in which n corresponds to
the NAL unit having the greatest value of AbsDON among the
received NAL units and m corresponds to the NAL unit having the
smallest value of AbsDON among the received NAL units.
o Initial buffering has lasted for the duration equal to or greater
than the value of the OPTIONAL sprop-desemul-init-buf-time media
type parameter of the highest SVC RTP session.
The NAL units to be removed from the de-session-multiplexing buffer
are determined as follows:
o If the de-session-multiplexing buffer contains at least N VCL NAL
units, NAL units are removed from the de-session-multiplexing
buffer and passed to the decoder in the order specified below
until the buffer contains N-1 or fewer VCL NAL units.
Hannuksela, Wang Expires December 4, 2008 [Page 11]
Internet-Draft Session Multiplexing for SVC Video June 2008
o If sprop-semul-max-don-diff of the highest SVC RTP session is
present, all NAL units m for which don_diff(m,n) is greater than
sprop-max-don-diff of the highest RTP session are removed from the
de-session-multiplexing buffer and passed to the decoder in the
order specified below. Herein, n corresponds to the NAL unit
having the greatest value of AbsDON among the NAL units in the de-
session-multiplexing buffer.
The order in which NAL units are passed to the decoder is specified
as follows:
o Let PDON be a variable that is initialized to 0 at the beginning
of the RTP sessions.
o For each NAL unit associated with a value of AU-DON, an AU-DON
distance is calculated as follows. If the value of AU-DON of the
NAL unit is greater than the value of PDON, the AU-DON distance is
equal to AU-DON - PDON. Otherwise, the AU-DON distance is equal
to 65535 - PDON + AU-DON + 1.
o NAL units are delivered to the decoder in ascending order of AU-
DON distance. If several NAL units share the same value of AU-DON
distance, the following applies.
An initial NAL unit order for an access unit is formed
starting from the base session and proceeding to the highest
session in the session dependency order specified according to
[I-D.ietf-mmusic-decoding-dependency]. Within a session, NAL
units sharing the same value of AU-DON are ordered into the
initial NAL unit order for the access unit in their
transmission order.
A NAL unit decoding order for the access unit is derived from
the initial NAL unit order for the access unit by reordering
SEI NAL units conveyed in a non-base session and not included
PACSI NAL units as specified for the NAL unit decoding order
in [SVC].
NAL units are passed to the decoder in the NAL unit decoding
order for the access unit.
o When a desired number of NAL units have been passed to the
decoder, the value of PDON is set to the value of AU-DON for the
last NAL unit passed to the decoder.
Hannuksela, Wang Expires December 4, 2008 [Page 12]
Internet-Draft Session Multiplexing for SVC Video June 2008
8.1.1.1. Informative Algorithm for NI-A Decoding Order Recovery within
an Access Unit
Section 8.1.1.1 of draft-ietf-avt-rtp-svc-10 applies.
8.1.2. Decoding Order Recovery for the I-C Mode
Section 8.1.2 of draft-ietf-avt-rtp-svc-10 applies.
9. Payload Format Parameters
Section 9 of draft-ietf-avt-rtp-svc-10 applies.
9.1. Media Type Registration
Section 9.1 of draft-ietf-avt-rtp-svc-10 applies with the following
modifications.
session-multiplexing-packetization-mode:
This parameter MUST be present when the current RTP depends
one or more other RTP sessions.
This parameter signals the properties of a NAL unit stream
carried in more than one RTP session using session
multiplexing or the capabilities of a receiver implementation.
When the value of session-multiplexing-packetization-mode is
equal to 0, the NI-A mode MUST be used. When the value of
session-multiplexing-packetization-mode is equal to 1, the I-C
mode MUST be used. The value of session-multiplexing-
packetization-mode MUST be an integer in the range of 0 to 1,
inclusive.
sprop-session-multiplexing-depth:
This parameter MUST be present when the current RTP depends
one or more other RTP sessions.
This parameter signals the properties of a NAL unit stream
carried in the current RTP session and the RTP sessions the
current RTP session depends on. It is guaranteed that
receivers can reconstruct NAL unit decoding order as specified
in section 8.1. of this memo when the de-session-multiplexing
buffer size is at least the value of sprop-session-
multiplexing-depth + 1 in terms of VCL NAL units.
The value of sprop-session-multiplexing-depth MUST be an
integer in the range of 0 to 32767, inclusive.
Hannuksela, Wang Expires December 4, 2008 [Page 13]
Internet-Draft Session Multiplexing for SVC Video June 2008
sprop-desemul-buf-req:
This parameter MUST be present when the current RTP depends
one or more other RTP sessions.
sprop-desemul-buf-req signals the required size of the de-
session-multiplexing buffer for the NAL unit stream carried in
the current RTP session and the RTP sessions the current RTP
session depends on. It is guaranteed that receivers can
recover the decoding order of the received NAL units from the
current RTP session and the RTP sessions the current RTP
session depends on as specified in section 8.1. , when the de-
session-multiplexing buffer size is at least the value of
sprop-desemul-buf-req in terms of bytes.
The value of sprop-desemul-buf-req MUST be an integer in the
range of 0 to 4294967295, inclusive.
desemul-buf-cap:
This parameter signals the capabilities of a receiver
implementation and indicates the amount of de-session-
multiplexing buffer space in units of bytes that the receiver
has available for recovering the NAL unit decoding order as
specified in section 8.1. . A receiver is able to handle any
NAL unit stream for which the value of the sprop-desemul-buf-
req parameter is smaller than or equal to this parameter.
If the parameter is not present, then a value of 0 MUST be
used for desemul-buf-cap. The value of desemul-buf-cap MUST
be an integer in the range of 0 to 4294967295, inclusive.
sprop-desemul-init-buf-time:
This parameter MAY be used to signal the properties of a NAL
unit stream carried in the current RTP session and the RTP
sessions the current RTP session depends on.
The parameter signals the initial buffering time that a
receiver MUST wait before starting to recover the NAL unit
decoding order as specified in section 8.1. of this memo.
The parameter is coded as a non-negative base10 integer
representation in clock ticks of a 90-kHz clock. If the
parameter is not present, then no initial buffering time value
is defined. Otherwise the value of sprop-desemul-init-buf-
time MUST be an integer in the range of 0 to 4294967295,
inclusive.
Hannuksela, Wang Expires December 4, 2008 [Page 14]
Internet-Draft Session Multiplexing for SVC Video June 2008
sprop-semul-max-don-diff:
This parameter MAY be used to signal the properties of a NAL
unit stream carried in the current RTP session and the RTP
sessions the current RTP session depends on. It MUST NOT be
used to signal transmitter or receiver or codec capabilities.
sprop-semul-max-don-diff is an integer in the range of 0 to
32767, inclusive. If sprop-semul-max-don-diff is not present,
the value of the parameter is unspecified. sprop-semul-max-
don-diff is calculated same as sprop-max-don-diff as specified
in RFC 3984, with decoding order number being replaced by AU-
DON or CS-DON when the NI-A mode or the I-C mode is in use,
respectively.
9.2. SDP Parameters
Section 9.2 of draft-ietf-avt-rtp-svc-10 applies.
9.3. Examples
Section 9.3 of draft-ietf-avt-rtp-svc-10 applies.
9.4. Parameter Set Considerations
Section 9.4 of draft-ietf-avt-rtp-svc-10 applies.
10. Security Considerations
Section 10 of draft-ietf-avt-rtp-svc-10 applies.
11. Congestion Control
Section 11 of draft-ietf-avt-rtp-svc-10 applies.
12. IANA Consideration
Section 12 of draft-ietf-avt-rtp-svc-10 applies.
13. Informative Appendix: Application Examples
Section 13 of draft-ietf-avt-rtp-svc-10 applies.
14. References
14.1. Normative References
Section 14.1 of draft-ietf-avt-rtp-svc-10 applies with the following
addition.
Hannuksela, Wang Expires December 4, 2008 [Page 15]
Internet-Draft Session Multiplexing for SVC Video June 2008
[I-D.ietf-avt-rtp-svc] Wenger, S., Wang, Y.-K."RTP payload format
for SVC video", draft-ietf-avt-rtp-svc-10 (work in
progress), May 2008.
14.2. Informative References
Section 14.2 of draft-ietf-avt-rtp-svc-10 applies.
15. Authors' Addresses
Miska M. Hannuksela
Nokia Research Center
P.O. Box 1000
33721 Tampere
Finland
Phone: +358-7180-73151
EMail: miska.hannuksela@nokia.com
Ye-Kui Wang
Nokia Research Center
P.O. Box 1000
33721 Tampere
Finland
Phone: +358-50-466-7004
EMail: ye-kui.wang@nokia.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
Hannuksela, Wang Expires December 4, 2008 [Page 16]
Internet-Draft Session Multiplexing for SVC Video June 2008
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society. Further, the author Thomas Schierl of Fraunhofer
HHI is sponsored by the European Commission under the contract number
FP7-ICT-214063, project SEA. The authors want to thank Jonathan
Lennox for his valuable comments on and input to the draft.
Hannuksela, Wang Expires December 4, 2008 [Page 17]