From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4421.txt | 227 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 doc/rfc/rfc4421.txt (limited to 'doc/rfc/rfc4421.txt') diff --git a/doc/rfc/rfc4421.txt b/doc/rfc/rfc4421.txt new file mode 100644 index 0000000..305bff6 --- /dev/null +++ b/doc/rfc/rfc4421.txt @@ -0,0 +1,227 @@ + + + + + + +Network Working Group C. Perkins +Request for Comments: 4421 University of Glasgow +Updates: 4175 February 2006 +Category: Standards Track + + + RTP Payload Format for Uncompressed Video: + Additional Colour Sampling Modes + +Status 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 2006 + + +2. 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 in RFC 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 2006 + + +5. 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.org + + + + + + + + + + + + +Perkins Standards Track [Page 3] + +RFC 4421 RTP Payload for Uncompressed Video February 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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. + + 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 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 + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Perkins Standards Track [Page 4] + -- cgit v1.2.3