doc: Add RFC documents

1 files changed, 227 insertions, 0 deletions

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]
+