Movatterモバイル変換

Network Working Group                                         C. PerkinsRequest for Comments: 4421                         University of GlasgowUpdates:4175                                              February 2006Category: Standards TrackRTP Payload Format for Uncompressed Video:Additional Colour Sampling ModesStatus of This Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2006).Abstract   The RFC Payload Format for Uncompressed Video,RFC 4175, defines a   scheme to packetise uncompressed, studio-quality, video streams for   transport using RTP.  This memo extends the format to support   additional colour sampling modes.1.  Introduction   The RTP Payload Format for Uncompressed Video [1] defines a scheme to   packetise uncompressed, studio-quality, video streams for transport   using RTP [2].  A range of standard and high-definition video formats   is supported, and parameters are defined so sender and receiver can   negotiate the image size, colour space, pixel depth, and colour   sampling mode.   A limitation of the signalling is that the number of bits per sample   is assumed to be the same for each colour component.  For example, it   is possible to signal video using RGB colour sampling with 8 bits for   each of the Red, Green, and Blue components (24 bits per pixel), but   not video using RGB colour sampling with 5 bits each for the Red and   Blue components, but 6 bits for the Green component (16 bits per   pixel).  Such video formats can easily be transported by the payload   format, but cannot be signalled using the parameters defined.  This   memo extends [1] with additional colour sampling modes, to signal   such video formats.Perkins                     Standards Track                     [Page 1]

RFC 4421           RTP Payload for Uncompressed Video      February 20062.  Conventions Used in this Document   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this   document are to be interpreted as described inRFC 2119 [3].3.  Payload Format Parameters   This memo defines six new colour sampling modes that MAY be signalled   for use with [1].  The new modes are "RGB+", "RG+B", "R+GB", "BGR+",   "BG+R", and "B+GR".  These sampling modes use the same packing order   of samples as do the RGB and BGR colour sampling modes, respectively   (Section 4.3 of [1]), except that an additional bit per sample of   colour depth MUST be used for the component marked by the + symbol.   The mandatory parameter "depth=N" indicates that N bits per sample   are used by the unmarked components, but N+1 bits are used by the   marked component.  All other features of the payload format are as   defined in [1].   The primary use of these colour sampling modes is to enable efficient   packing of data into small pixel groups ("pgroups").  The most common   use case is expected to be video with "depth=5", where the additional   bit of colour depth for the marked component enables a single pixel   to fit into two octets without padding.  The new colour sampling   modes MAY be used for other depths, however, should that prove   useful.4.  Example   A common uncompressed video format is RGB with 5 bits for the Red and   Blue components and 6 bits for the Green component, for a total of 16   bits per pixel.  Using the sampling modes defined in this memo, this   can be signalled in Session Description Protocol (SDP) according to   the following example:       v=0       o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5       s=-       c=IN IP4 192.0.2.6       t=2873397496 2873404696       m=video 51372 RTP/AVP 99       a=rtpmap:99 raw/90000       a=fmtp:99 sampling=RG+B; width=1024; height=768; depth=5;         colorimetry=SMPTE240M   The last line has been wrapped due to formatting constraints of this   memo, and forms one complete line in the SDP file.Perkins                     Standards Track                     [Page 2]

RFC 4421           RTP Payload for Uncompressed Video      February 20065.  Security Considerations   The security considerations of [1] apply.  No additional security   considerations are introduced by support for new colour sampling   modes.6.  IANA Considerations   The video/raw media type is extended with six new values for the   "sampling" parameter according to the rules defined in Section 6.2 of   [1].  The new values are "RGB+", "RG+B", "R+GB", "BGR+", "BG+R", and   "B+GR" as described in this memo.7.  Acknowledgements   Thanks to Jeremy Searle and Andrew Lee at Westland Helicopters.8.  Normative References   [1]  Gharai, L. and C. Perkins, "RTP Payload Format for Uncompressed        Video",RFC 4175, September 2005.   [2]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,        "RTP: A Transport Protocol for Real-Time Applications", STD 64,RFC 3550, July 2003.   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement        Levels",BCP 14,RFC 2119, March 1997.Author's Address   Colin Perkins   University of Glasgow   Department of Computing Science   17 Lilybank Gardens   Glasgow  G12 8QQ   UK   EMail: csp@csperkins.orgPerkins                     Standards Track                     [Page 3]

RFC 4421           RTP Payload for Uncompressed Video      February 2006Full Copyright Statement   Copyright (C) The Internet Society (2006).   This document is subject to the rights, licenses and restrictions   contained inBCP 78, and except as set forth therein, the authors   retain all their rights.   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 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.Intellectual Property   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 inBCP 78 andBCP 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   specification can be obtained from the IETF on-line IPR repository athttp://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.Acknowledgement   Funding for the RFC Editor function is provided by the IETF   Administrative Support Activity (IASA).Perkins                     Standards Track                     [Page 4]