idnits 2.17.1 draft-ietf-avt-uncomp-video-ext-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 184. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 161. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 168. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 174. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC4175, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC4175, updated by this document, for RFC5378 checks: 2002-10-18) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 25, 2005) is 6782 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Perkins 3 Internet-Draft University of Glasgow 4 Updates: 4175 (if approved) September 25, 2005 5 Expires: March 29, 2006 7 RTP Payload Format for Uncompressed Video: Additional Colour Sampling 8 Modes 9 draft-ietf-avt-uncomp-video-ext-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 29, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This memo extends the RTP Payload Format for Uncompressed Video to 43 support additional colour sampling modes. 45 1. Introduction 47 The RTP Payload Format for Uncompressed Video [1] defines a scheme to 48 packetise uncompressed, studio-quality, video streams for transport 49 using RTP [2]. A range of standard and high definition video formats 50 are supported, and parameters are defined so sender and receiver can 51 negotiate the image size, colour space, pixel depth, and colour 52 sampling mode. 54 A limitation of the signalling is that the number of bits per sample 55 is assumed to be the same for each colour component. For example, it 56 is possible to signal video using RGB colour sampling with 8-bits for 57 each of the Red, Green and Blue components (24 bits per pixel), but 58 not video using RGB colour sampling with 5-bits each for the Red and 59 Blue components, but 6-bits for the Green component (16 bits per 60 pixel). Such video formats can easily be transported by the payload 61 format, but cannot be signalled using the parameters defined. This 62 memo extends [1] with additional colour sampling modes, to signal 63 such video formats. 65 2. Conventions Used in this Document 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 [3]. 71 3. Payload Format Parameters 73 This memo defines six new colour sampling modes that MAY be signalled 74 for use with [1]. The new modes are "RGB+", "RG+B", "R+GB", "BGR+", 75 "BG+R" and "B+GR". These sampling modes use the same packing order 76 of samples as do the RGB and BGR colour sampling modes respectively 77 ([1] Section 4.3), except that an additional bit per sample of colour 78 depth MUST be used for the component marked by the + symbol. The 79 mandatory parameter "depth=N" indicates that N bits per sample are 80 used by the unmarked components, but N+1 bits are used by the marked 81 component. All other features of the payload format are as defined 82 in [1]. 84 The primary use of these colour sampling modes is to enable efficient 85 packing of data into small pixel groups ("pgroups"). The most common 86 use case is expected to be video with "depth=5", where the additional 87 bit of colour depth for the marked component enables a single pixel 88 to fit into two octets without padding. The new colour sampling 89 modes MAY be used for other depths, however, should that prove 90 useful. 92 4. Example 94 A common uncompressed video format is RGB with 5 bits for the Red and 95 Blue components and six bits for the Green component, for a total of 96 16 bits per pixel. Using the sampling modes defined in this memo, 97 this can be signalled in SDP according to the following example: 99 v=0 100 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 101 s=- 102 c=IN IP4 10.47.16.6 103 t=2873397496 2873404696 104 m=video 51372 RTP/AVP 99 105 a=rtpmap:99 raw/90000 106 a=fmtp:99 sampling=RG+B; width=1024; height=768; depth=5; 107 colorimetry=SMPTE240M 109 The last line has been wrapped due to formatting constraints of this 110 memo, and forms one complete line in the SDP file. 112 5. Security Considerations 114 The security considerations of [1] apply. No additional security 115 considerations are introduced by support for new colour sampling 116 modes. 118 6. IANA Considerations 120 The video/raw media type is extended with six new values for the 121 "sampling" parameter according to the rules defined in section 6.2 of 122 [1]. The new values are "RGB+", "RG+B", "R+GB", "BGR+", "BG+R" and 123 "B+GR" as described in this memo. 125 7. Acknowledgements 127 Thanks to Jeremy Searle and Andrew Lee at Westland Helicopters. 129 8. Normative References 131 [1] Perkins, C. and L. Gharai, "RTP Payload Format for Uncompressed 132 Video", RFC 4175, September 2005. 134 [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 135 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 136 RFC 3550, July 2003. 138 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 139 Levels", BCP 14, RFC 2119, March 1997. 141 Author's Address 143 Colin Perkins 144 University of Glasgow 145 Department of Computing Science 146 17 Lilybank Gardens 147 Glasgow G12 8QQ 148 UK 150 Email: csp@csperkins.org 152 Intellectual Property Statement 154 The IETF takes no position regarding the validity or scope of any 155 Intellectual Property Rights or other rights that might be claimed to 156 pertain to the implementation or use of the technology described in 157 this document or the extent to which any license under such rights 158 might or might not be available; nor does it represent that it has 159 made any independent effort to identify any such rights. Information 160 on the procedures with respect to rights in RFC documents can be 161 found in BCP 78 and BCP 79. 163 Copies of IPR disclosures made to the IETF Secretariat and any 164 assurances of licenses to be made available, or the result of an 165 attempt made to obtain a general license or permission for the use of 166 such proprietary rights by implementers or users of this 167 specification can be obtained from the IETF on-line IPR repository at 168 http://www.ietf.org/ipr. 170 The IETF invites any interested party to bring to its attention any 171 copyrights, patents or patent applications, or other proprietary 172 rights that may cover technology that may be required to implement 173 this standard. Please address the information to the IETF at 174 ietf-ipr@ietf.org. 176 Disclaimer of Validity 178 This document and the information contained herein are provided on an 179 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 180 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 181 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 182 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 183 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 184 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 186 Copyright Statement 188 Copyright (C) The Internet Society (2005). This document is subject 189 to the rights, licenses and restrictions contained in BCP 78, and 190 except as set forth therein, the authors retain all their rights. 192 Acknowledgment 194 Funding for the RFC Editor function is currently provided by the 195 Internet Society.