draft-ietf-avt-rtp-mvc-00.txt   draft-ietf-avt-rtp-mvc-01.txt 
Audio/Video Transport WG Y.-K. Wang Audio/Video Transport WG Y.-K. Wang
Internet Draft Huawei Technologies Internet Draft Huawei Technologies
Intended status: Standards track T. Schierl Intended status: Standards track T. Schierl
Expires: October 2010 Fraunhofer HHI Expires: April 2011 Fraunhofer HHI
April 28, 2010 October 9, 2010
RTP Payload Format for MVC Video RTP Payload Format for MVC Video
draft-ietf-avt-rtp-mvc-00.txt draft-ietf-avt-rtp-mvc-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 28, 2010. This Internet-Draft will expire on April 9, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Abstract Abstract
This memo describes an RTP payload format for the multiview This memo describes an RTP payload format for the multiview
extension of the ITU-T Recommendation H.264 video codec that is extension of the ITU-T Recommendation H.264 video codec that is
technically identical to ISO/IEC International Standard 14496-10. technically identical to ISO/IEC International Standard 14496-10.
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 (NAL) units, produced by the video encoder, Network Abstraction Layer (NAL) units, produced by the video encoder,
in each RTP payload. The payload format has wide applicability, in each RTP payload. The payload format can be applied in RTP based
such as 3D video streaming, free-viewpoint video, and 3DTV. 3D video transmissions such as such as 3D video streaming, free-
viewpoint video, and 3DTV.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Conventions....................................................4 2. Conventions....................................................4
3. The MVC Codec..................................................4 3. The MVC Codec..................................................4
3.1. Overview..................................................4 3.1. Overview..................................................4
3.2. Parameter Set Concept.....................................5 3.2. Parameter Set Concept.....................................5
3.3. Network Abstraction Layer Unit Header.....................5 3.3. Network Abstraction Layer Unit Header.....................5
4. Scope..........................................................8 4. Scope..........................................................8
skipping to change at page 3, line 16 skipping to change at page 3, line 17
9.2.4. Usage in Declarative Session Descriptions...........20 9.2.4. Usage in Declarative Session Descriptions...........20
9.3. Examples.................................................20 9.3. Examples.................................................20
9.4. Parameter Set Considerations.............................20 9.4. Parameter Set Considerations.............................20
10. Security Considerations......................................20 10. Security Considerations......................................20
11. Congestion Control...........................................21 11. Congestion Control...........................................21
12. IANA Considerations..........................................21 12. IANA Considerations..........................................21
13. Acknowledgments..............................................21 13. Acknowledgments..............................................21
14. References...................................................21 14. References...................................................21
14.1. Normative References....................................21 14.1. Normative References....................................21
14.2. Informative References..................................22 14.2. Informative References..................................22
Author's Addresses...............................................23 Author's Addresses...............................................22
15. Open issues:.................................................23 15. Open issues:.................................................23
16. Changes Log..................................................23 16. Changes Log..................................................23
1. Introduction 1. Introduction
This memo specifies an RTP [RFC3550] payload format for a forthcoming This memo specifies an RTP [RFC3550] payload format for a forthcoming
new mode of the H.264/AVC video coding standard, known as Multiview new mode of the H.264/AVC video coding standard, known as Multiview
Video Coding (MVC). Formally, MVC will take the form of Amendment 4 Video Coding (MVC). Formally, MVC will take the form of Amendment 4
to ISO/IEC 14496 Part 10 [MPEG4-10], and Annex H of ITU-T Rec. H.264 to ISO/IEC 14496 Part 10 [MPEG4-10], and Annex H of ITU-T Rec. H.264
[H.264]. The latest draft specification of MVC is available in [MVC]. [H.264]. The latest draft specification of MVC is available in [MVC].
skipping to change at page 6, line 40 skipping to change at page 6, line 40
In H.264/AVC, NAL unit types 14 and 20 are reserved for future In H.264/AVC, NAL unit types 14 and 20 are reserved for future
extensions. MVC uses these two NAL unit types. NAL unit type 14 is extensions. MVC uses these two NAL unit types. NAL unit type 14 is
used for prefix NAL unit, and NAL unit type 20 is used for coded used for prefix NAL unit, and NAL unit type 20 is used for coded
slice of non-base view. NAL unit types 14 and 20 indicate the slice of non-base view. NAL unit types 14 and 20 indicate the
presence of three additional octets in the NAL unit header, as shown presence of three additional octets in the NAL unit header, as shown
below. below.
+---------------+---------------+---------------+ +---------------+---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|I| PRID | VID | TID |A|V|O| |S|I| PRID | VID | TID |A|V|O|
+---------------+---------------+---------------+ +---------------+---------------+---------------+
S: 1 bit
svc_extention_flag. MUST be equal to 0 in MVC context. In the
context of Scalable Video Coding (SVC), the flag must be equal to 1.
I: 1 bit
non_idr_flag. This component specifies whether the access unit the
NAL unit belongs to is an IDR access unit (when equal to 0) or not
(when equal to 1), as specified in [MVC].
PRID: 6 bits PRID: 6 bits
priority_id. This flag specifies a priority identifier for the NAL priority_id. This flag specifies a priority identifier for the NAL
unit. A lower value of PRID indicates a higher priority. unit. A lower value of PRID indicates a higher priority.
VID: 10 bits
view_id. This component specifies the view identifier of the view
the NAL unit belongs to.
TID: 3 bits TID: 3 bits
temporal_id. This component specifies the temporal layer (or frame temporal_id. This component specifies the temporal layer (or frame
rate) hierarchy. Informally put, a temporal layer consisting of view rate) hierarchy. Informally put, a temporal layer consisting of view
component with a less temporal_id corresponds to a lower frame rate. component with a less temporal_id corresponds to a lower frame rate.
A given temporal layer typically depends on the lower temporal layers A given temporal layer typically depends on the lower temporal layers
(i.e. the temporal layers with less temporal_id values) but never (i.e. the temporal layers with less temporal_id values) but never
depends on any higher temporal layer (i.e. a temporal layers with depends on any higher temporal layer (i.e. a temporal layers with
higher temporal_id value). higher temporal_id value).
A: 1 bit A: 1 bit
anchor_pic_flag. This component specifies whether the view component anchor_pic_flag. This component specifies whether the access unit
is an anchor picture (when equal to 1) or not (when equal to 0), as the NAL unit belongs to is an anchor access unit (when equal to 1) or
specified in [MVC]. not (when equal to 0), as specified in [MVC].
VID: 10 bits
view_id. This component specifies the view identifier of the view
the NAL unit belongs to.
I: 1 bit
idr_flag. This component specifies whether the view component is a
view instantaneous decoding refresh (V-IDR) picture for the view
(when equal to 1) or not (when equal to 0), as specified in [MVC].
V: 1 bit V: 1 bit
inter_view_flag. This component specifies whether the view component inter_view_flag. This component specifies whether the view component
is used for inter-view prediction (when equal to 1) or not (when is used for inter-view prediction (when equal to 1) or not (when
equal to 0). equal to 0).
R: 1 bit
reserved_zero_one_bit. Reserved bit for future extension. R MUST be
equal to 0. Receivers SHOULD ignore the value of
reserved_zero_one_bit.
O: 1 bit O: 1 bit
reserved_one_bit. Reserved bit for future extension. R shall be reserved_one_bit. Reserved bit for future extension. R shall be
equal to 1. Receivers SHOULD ignore the value of equal to 1. Receivers SHOULD ignore the value of
reserved_zero_one_bit. reserved_zero_one_bit.
This memo reuses the same additional NAL unit types introduced in RFC This memo reuses the same additional NAL unit types introduced in RFC
3984, which are presented in section 6.3. In addition, this memo 3984, which are presented in section 6.3. In addition, this memo
introduces one more NAL unit type, 30, as specified in section 6.8. introduces one more NAL unit type, 30, as specified in section 6.8.
These NAL unit types are marked as unspecified in [MVC] and These NAL unit types are marked as unspecified in [MVC] and
skipping to change at page 9, line 23 skipping to change at page 9, line 23
certain level of temporal and view scalability. An operation point certain level of temporal and view scalability. An operation point
contains only those NAL units required for a valid bitstream to contains only those NAL units required for a valid bitstream to
represent a certain subset of views at a certain temporal level. An represent a certain subset of views at a certain temporal level. An
operation point is described by the view_id values of the subset of operation point is described by the view_id values of the subset of
views, and the highest temporal_id. views, and the highest temporal_id.
multi-session transmission: The transmission mode in which the MVC multi-session transmission: The transmission mode in which the MVC
bitstream is transmitted over multiple RTP sessions, with each stream bitstream is transmitted over multiple RTP sessions, with each stream
having the same SSRC. These multiple RTP streams can be associated having the same SSRC. These multiple RTP streams can be associated
using the RTCP CNAME, or explicit signalling of the SSRC used. using the RTCP CNAME, or explicit signalling of the SSRC used.
Dependency between RTP sessions MUST be signaled according to [I- Dependency between RTP sessions MUST be signaled according to
D.ietf-mmusic-decoding-dependency] and this memo. [RFC5583] and this memo.
single-session transmission: The transmission mode in which the MVC single-session transmission: The transmission mode in which the MVC
bitstream is transmitted over a single RTP session, with a single bitstream is transmitted over a single RTP session, with a single
SSRC and separate timestamp and sequence number spaces. SSRC and separate timestamp and sequence number spaces.
[Ed.Note(TS):Need more definitions here.] [Ed.Note(TS):Need more definitions here.]
5.1. Abbreviations 5.1. Abbreviations
In addition to the abbreviations defined in [RFC3984], the following In addition to the abbreviations defined in [RFC3984], the following
skipping to change at page 20, line 32 skipping to change at page 20, line 32
pairs. pairs.
9.2.2. Usage with the SDP Offer/Answer Model 9.2.2. Usage with the SDP Offer/Answer Model
TBD. TBD.
9.2.3. Usage with multi-session transmission 9.2.3. Usage with multi-session transmission
If multi-session transmission is used, the rules on signaling media If multi-session transmission is used, the rules on signaling media
decoding dependency in SDP as defined in decoding dependency in SDP as defined in
[I-D.draft-ietf-mmusic-decoding-dependency] apply. [RFC5583] apply.
9.2.4. Usage in Declarative Session Descriptions 9.2.4. Usage in Declarative Session Descriptions
TBD. TBD.
9.3. Examples 9.3. Examples
TBD. TBD.
9.4. Parameter Set Considerations 9.4. Parameter Set Considerations
skipping to change at page 21, line 15 skipping to change at page 21, line 15
11. Congestion Control 11. Congestion Control
TBD. TBD.
12. IANA Considerations 12. IANA Considerations
Request for media type registration to be added. Request for media type registration to be added.
13. Acknowledgments 13. Acknowledgments
The author Thomas Schierl of Fraunhofer HHI is sponsored by the The work of Thomas Schierl has been supported by the European
European Commission under the contract number FP7-ICT-214063, project Commission under contract number FP7-ICT-248036, project COAST.
SEA.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
14. References 14. References
14.1. Normative References 14.1. Normative References
[H.264] ITU-T Recommendation H.264, "Advanced video coding for [H.264] ITU-T Recommendation H.264, "Advanced video coding for
generic audiovisual services", 3rd Edition, November 2007. generic audiovisual services", 3rd Edition, November 2007.
[I-D.draft-ietf-avt-rtp-svc] Wenger, S., Wang, Y. -K., Schierl, T. [I-D.draft-ietf-avt-rtp-svc] Wenger, S., Wang, Y. -K., Schierl, T.
and A. Eleftheriadis, "RTP payload format for SVC video", and A. Eleftheriadis, "RTP payload format for SVC video",
draft-ietf-avt-rtp-svc-13 (work in progress), July 2008. draft-ietf-avt-rtp-svc-23 (work in progress), October 2010.
[I-D.draft-ietf-mmusic-decoding-dependency] Schierl, T., and Wenger, [RFC5583] Schierl, T., and Wenger, S., "Signaling media decoding
S., "Signaling media decoding dependency in Session dependency in the Session Description Protocol (SDP)", RFC
Description Protocol (SDP)", draft-ietf-mmusic-decoding- 5583, July 2009.
dependency-02 (work in progress), May 2008.
[MPEG4-10] [MPEG4-10]
ISO/IEC International Standard 14496-10:2005. ISO/IEC International Standard 14496-10:2005.
[MVC] Joint Video Team, "Joint Draft 7 of MVC ", available from [MVC] Joint Video Team, "Joint Draft 7 of MVC ", available from
http://ftp3.itu.ch/av-arch/jvt-site/2008_04_Geneva/JVT- http://ftp3.itu.ch/av-arch/jvt-site/2008_04_Geneva/JVT-
AA209.zip, Geneva, Switzerland, April 2008. AA209.zip, Geneva, Switzerland, April 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
skipping to change at page 23, line 15 skipping to change at page 23, line 4
Author's Addresses Author's Addresses
Ye-Kui Wang Ye-Kui Wang
Huawei Technologies Huawei Technologies
400 Somerset Corporate Blvd, Suite 602 400 Somerset Corporate Blvd, Suite 602
Bridgewater, NJ 08807 Bridgewater, NJ 08807
USA USA
Phone: +1-908-541-3518 Phone: +1-908-541-3518
EMail: yekuiwang@huawei.com EMail: yekuiwang@huawei.com
Thomas Schierl Thomas Schierl
Fraunhofer HHI Fraunhofer HHI
Einsteinufer 37 Einsteinufer 37
D-10587 Berlin D-10587 Berlin
Germany Germany
Phone: +49-30-31002-227 Phone: +49-30-31002-227
EMail: schierl@hhi.fhg.de EMail: ts@thomas-schierl.de
15. Open issues: 15. Open issues:
- The use of CL-DON for session reordering allows also for - The use of CL-DON for session reordering allows also for
interleaved transmission with non-interleaved packetization mode. interleaved transmission with non-interleaved packetization mode.
There should be a clear separation between both tools. This issue There should be a clear separation between both tools. This issue
should be handled the same way as for the SVC payload draft. should be handled the same way as for the SVC payload draft.
- Since SVC session multiplexing (multi source transmission(MST)) is - Since SVC session multiplexing (multi source transmission(MST)) is
cleared, it would be great to just reference the MST sections in cleared, it would be great to just reference the MST sections in
skipping to change at line 1117 skipping to change at page 25, line 20
22 April 2010: YkW 22 April 2010: YkW
- To keep the draft alive, no change other than version number etc. - To keep the draft alive, no change other than version number etc.
From draft-wang-avt-rtp-mvc-05 to draft-ietf-avt-rtp-mvc-00 From draft-wang-avt-rtp-mvc-05 to draft-ietf-avt-rtp-mvc-00
28 April 2010: YkW 28 April 2010: YkW
- No change other than version number etc. - No change other than version number etc.
From draft-ietf-avt-rtp-mvc-00 to draft-ietf-avt-rtp-mvc-01
8/9 October 2010:
- YkW: Updated the NAL unit header syntax and semantics in section
3.3 per the latest MVC specification.
- TS: Minor edits
 End of changes. 19 change blocks. 
42 lines changed or deleted 38 lines changed or added

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