summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4421.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4421.txt')
-rw-r--r--doc/rfc/rfc4421.txt227
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]
+