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]