doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc4175.txt b/doc/rfc/rfc4175.txt
new file mode 100644
index 0000000..dfce28c
--- /dev/null
+++ b/doc/rfc/rfc4175.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                          L. Gharai
+Request for Comments: 4175                                       USC/ISI
+Category: Standards Track                                     C. Perkins
+                                                   University of Glasgow
+                                                          September 2005
+
+
+               RTP Payload Format for Uncompressed Video
+
+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 (2005).
+
+Abstract
+
+   This memo specifies a packetization scheme for encapsulating
+   uncompressed video into a payload format for the Real-time Transport
+   Protocol, RTP.  It supports a range of standard- and high-definition
+   video formats, including common television formats such as ITU
+   BT.601, and standards from the Society of Motion Picture and
+   Television Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M.  The
+   format is designed to be applicable and extensible to new video
+   formats as they are developed.
+
+1.  Introduction
+
+   This memo defines a scheme to packetize uncompressed, studio-quality
+   video streams for transport using RTP [RTP].  It supports a range of
+   standard and high-definition video formats, including ITU-R BT.601
+   [601], SMPTE 274M [274] and SMPTE 296M [296].
+
+   Formats for uncompressed standard definition television are defined
+   by ITU Recommendation BT.601 [601] along with bit-serial and parallel
+   interfaces in Recommendation BT.656 [656].  These formats allow both
+   625-line and 525-line operation, with 720 samples per digital active
+   line, 4:2:2 color sub-sampling, and 8- or 10-bit digital
+   representation.
+
+
+
+
+
+
+Gharai & Perkins            Standards Track                     [Page 1]
+
+RFC 4175       RTP Payload Format for Uncompressed Video  September 2005
+
+
+   The representation of uncompressed high-definition television is
+   specified in SMPTE standards 274M [274] and 296M [296].  SMPTE 274M
+   defines a family of scanning systems with an image format of
+   1920x1080 pixels with progressive and interlaced scanning, while
+   SMPTE 296M defines systems with an image size of 1280x720 pixels and
+   progressive scanning.  In progressive scanning, scan lines are
+   displayed in sequence from top to bottom of a full frame.  In
+   interlaced scanning, a frame is divided into its odd and even scan
+   lines (called fields) and the two fields are displayed in succession.
+   SMPTE 274M and 296M define images with aspect ratios of 16:9, and
+   define the digital representation for RGB and YCbCr components.  In
+   the case of YCbCr components, the Cb and Cr components are
+   horizontally sub-sampled by a factor of two (4:2:2 color encoding).
+
+   Although these formats differ in their details, they are structurally
+   very similar.  This memo specifies a payload format to encapsulate
+   these and other similar video formats for transport within RTP.
+
+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 [2119].
+
+3.  Payload Design
+
+   Each scan line of digital video is packetized into one or more RTP
+   packets.  If the data for a complete scan line exceeds the network
+   MTU, the scan line SHOULD be fragmented into multiple RTP packets,
+   each smaller than the MTU.  A single RTP packet MAY contain data for
+   more than one scan line.  Only the active samples are included in the
+   RTP payload: inactive samples and the contents of horizontal and
+   vertical blanking SHOULD NOT be transported.  In instances where
+   ancillary data is being transmitted, the sender and receiver can
+   disambiguate between ancillary and video data via scan line numbers.
+   That is, the ancillary data will use scan line numbers that are not
+   within the scope of the video frame.
+
+   Scan line numbers are included in the RTP payload header, along with
+   a field identifier for interlaced video.
+
+      For SMPTE 296M format video, valid scan line numbers are from 26
+      through 745, inclusive.  For progressive scan SMPTE 274M format
+      video, valid scan lines are from scan line 42 through 1121,
+      inclusive.  For interlaced scan SMPTE 274M format video, valid
+      scan line numbers for field one (F=0) are from 21 to 560 and valid
+      scan line numbers for the second field (F=1) are from 584 to 1123.
+      For ITU-R BT.601 format video, the blanking intervals defined in
+
+
+
+Gharai & Perkins            Standards Track                     [Page 2]
+
+RFC 4175       RTP Payload Format for Uncompressed Video  September 2005
+
+
+      BT.656 are used: for 625 line video, lines 24 to 310 of field one
+      (F=0) and 337 to 623 of the second field (F=1) are valid; for 525
+      line video, lines 21 to 263 of the first field, and 284 to 525 of
+      the second field are valid.  Other formats (e.g., [372]) may
+      define different ranges of active lines.
+
+   The payload header contains a 16-bit extension to the standard 16-bit
+   RTP sequence number, thereby extending the sequence number to 32 bits
+   and enabling the payload format to accommodate high data rates
+   without ambiguity.  This is necessary as the 16-bit RTP sequence
+   number will roll over very quickly for high data rates.  For example,
+   for a 1-Gbps video stream with packet sizes of at least 1000 octets,
+   the standard RTP packet will roll over in 0.5 seconds, which can be a
+   problem for detecting loss and out-of-order packets particularly in
+   instances where the round-trip time is greater than half a second.
+   The extended 32-bit number allows for a longer wrap-around time of
+   approximately nine hours.
+
+   Each scan line comprises an integer number of pixels.  Each pixel is
+   represented by a number of samples.  Samples may be coded as 8-, 10-,
+   12-, or 16-bit values.  A sample may represent a color component or a
+   luminance component of the video.  Color samples may be shared
+   between adjacent pixels.  The sharing of color samples between
+   adjacent pixels is known as color sub-sampling.  This is typically
+   done in the YCbCr color space for the purpose of reducing the size of
+   the image data.
+
+   Pixels that share sample values MUST be transported together as a
+   "pixel group".  If 10-bit or 12-bit samples are used, each pixel may
+   also comprise a non-integer number of octets.  In this case, several
+   pixels MUST be combined into an octet-aligned pixel group for
+   transmission.  These restrictions simplify the operation of receivers
+   by ensuring that the complete payload is octet aligned, and that
+   samples relating to a single pixel are not fragmented across multiple
+   packets [ALF].
+
+   For example, in YCbCr video with 4:1:1 color sub-sampling, each group
+   of 4 adjacent pixels comprises 6 samples, Y1 Y2 Y3 Y4 Cr Cb, with the
+   Cr and Cb values being shared between all 4 pixels.  If samples are
+   8-bit values, the result is a group of 4 pixels comprising 6 octets.
+   If, however, samples are 10-bit values, the resulting 60-bit group is
+   not octet aligned.  To be both octet aligned and appropriately
+   framed, two groups of 4 adjacent pixels must be collected, thereby
+   becoming octet aligned on a 15-octet boundary.  This length is
+   referred to as the pixel group size ("pgroup").
+
+
+
+
+
+
+Gharai & Perkins            Standards Track                     [Page 3]
+
+RFC 4175       RTP Payload Format for Uncompressed Video  September 2005
+
+
+   Formally, the "pgroup" parameter is the size in octets of the
+   smallest grouping of pixels such that 1) the grouping comprises an
+   integer number of octets; and 2) if color sub-sampling is used,
+   samples are only shared within the grouping.  When packetizing
+   digital active line content, video data MUST NOT be fragmented within
+   a pgroup.
+
+   Video content is almost always associated with additional information
+   such as audio tracks, time code, etc.  In professional digital video
+   applications, this data is commonly embedded in non-active portions
+   of the video stream (horizontal and vertical blanking periods) so
+   that precise and robust synchronization is maintained.  This payload
+   format requires that applications using such synchronized ancillary
+   data SHOULD deliver it in separate RTP sessions that operate
+   concurrently with the video session.  The normal RTP mechanisms
+   SHOULD be used to synchronize the media.
+
+4.  RTP Packetization
+
+   The standard RTP header is followed by a 2-octet payload header that
+   extends the RTP Sequence Number, and by a 6-octet payload header for
+   each line (or partial line) of video included.  One or more lines, or
+   partial lines, of video data follow.  This format makes the payload
+   header 32-bit aligned in the common case, where one scan line (or
+   fragment) of video is included in each RTP packet.
+
+   For example, if two lines of video are encapsulated, the payload
+   format will be as shown in Figure 1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gharai & Perkins            Standards Track                     [Page 4]
+
+RFC 4175       RTP Payload Format for Uncompressed Video  September 2005
+
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | V |P|X|   CC  |M|    PT       |       Sequence Number         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                           Time Stamp                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             SSRC                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Extended Sequence Number    |            Length             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |F|          Line No            |C|           Offset            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |            Length             |F|          Line No            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |C|           Offset            |                               .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               .
+      .                                                               .
+      .                 Two (partial) lines of video data             .
+      .                                                               .
+      +---------------------------------------------------------------+
+
+     Figure 1: RTP Payload Format showing two (partial) lines of video
+
+4.1.  The RTP Header
+
+   The fields of the fixed RTP header have their usual meaning, with the
+   following additional notes:
+
+   Payload Type (PT): 7 bits
+
+     A dynamically allocated payload type field that designates the
+     payload as uncompressed video.
+
+   Timestamp: 32 bits
+
+     For progressive scan video, the timestamp denotes the sampling
+     instant of the frame to which the RTP packet belongs.  Packets MUST
+     NOT include data from multiple frames, and all packets belonging to
+     the same frame MUST have the same timestamp.
+
+     For interlaced video, the timestamp denotes the sampling instant of
+     the field to which the RTP packet belongs.  Packets MUST NOT
+     include data from multiple fields, and all packets belonging to the
+     same field MUST have the same timestamp.  Use of field timestamps,
+     rather than a frame timestamp and field indicator bit, is needed to
+     support reverse 3-2 pulldown.
+
+
+
+
+Gharai & Perkins            Standards Track                     [Page 5]
+
+RFC 4175       RTP Payload Format for Uncompressed Video  September 2005
+
+
+     A 90-kHz timestamp SHOULD be used in both cases.  If the sampling
+     instant does not correspond to an integer value of the clock (as
+     may be the case when interleaving), the value SHALL be truncated to
+     the next lowest integer, with no ambiguity.
+
+   Marker bit (M): 1 bit
+
+     If progressive scan video is being transmitted, the marker bit
+     denotes the end of a video frame.  If interlaced video is being
+     transmitted, it denotes the end of the field.  The marker bit MUST
+     be set to 1 for the last packet of the video frame/field.  It MUST
+     be set to 0 for other packets.
+
+   Sequence Number: 16 bits
+
+     The low-order bits for RTP sequence number.  The standard 16-bit
+     sequence number is augmented with another 16 bits in the payload
+     header in order avoid problems due to wrap-around when operating at
+     high rate rates.
+
+4.2.  Payload Header
+
+   Extended Sequence Number: 16 bits
+
+     The high order bits of the extended 32-bit sequence number, in
+     network byte order.
+
+   Length: 16 bits
+
+     Number of octets of data included from this scan line, in network
+     byte order.  This MUST be a multiple of the pgroup value.
+
+   Line No.: 15 bits
+
+     Scan line number of encapsulated data, in network byte order.
+     Successive RTP packets MAY contains parts of the same scan line
+     (with an incremented RTP sequence number, but the same timestamp),
+     if it is necessary to fragment a line.
+
+   Offset: 15 bits
+
+     Offset of the first pixel of the payload data within the scan line.
+     If YCbCr format data is being transported, this is the pixel offset
+     of the luminance sample; if RGB format data is being transported,
+     it is the pixel offset of the red sample; if BGR format data is
+     being transported, it is the pixel offset of the blue sample.  The
+
+
+
+
+
+Gharai & Perkins            Standards Track                     [Page 6]
+
+RFC 4175       RTP Payload Format for Uncompressed Video  September 2005
+
+
+     value is in network byte order.  The offset has a value of zero if
+     the first sample in the payload corresponds to the start of the
+     line, and increments by one for each pixel.
+
+   Field Identification (F): 1 bit
+
+     Identifies which field the scan line belongs to, for interlaced
+     data.  F=0 identifies the first field and F=1 the second field.
+     For progressive scan data (e.g., SMPTE 296M format video), F MUST
+     always be set to zero.
+
+   Continuation (C): 1 bit
+
+     Determines if an additional scan line header follows the current
+     scan line header in the RTP packet.  Set to 1 if an additional
+     header follows, implying that the RTP packet is carrying data for
+     more than one scan line.  Set to 0 otherwise.  Several scan lines
+     MAY be included in a single packet, up to the path MTU limit.  The
+     only way to determine the number of scan lines included per packet
+     is to parse the payload headers.
+
+4.3.  Payload Data
+
+   Depending on the video format, each RTP packet can include either a
+   single complete scan line, a single fragment of a scan line, or one
+   (or more) complete scan lines and scan line fragments.  The length of
+   each scan line or scan line fragment MUST be an integer multiple of
+   the pgroup size in octets.  Scan lines SHOULD be fragmented so that
+   the resulting RTP packet is smaller than the path MTU.
+
+   It is possible that the scan line length is not evenly divisible by
+   the number of pixels in a pgroup, so the final pixel data of a scan
+   line does not align to either an octet or a pgroup boundary.
+   Nonetheless, the payload MUST contain a whole number of pgroups; the
+   sender MUST fill the remaining bits of the final pgroup with zero and
+   the receiver MUST ignore the fill data. (In effect, the trailing edge
+   of the image is black-filled to a pgroup boundary.)
+
+   For RGB format video, samples are packed in order Red-Green-Blue.
+   For BGR format video, samples are packed in order Blue-Green-Red.
+   For both formats, if 8-bit samples are used, the pgroup is 3 octets.
+   If 10-bit samples are used, samples from 4 adjacent pixels form 15-
+   octet pgroups.  If 12-bit samples are used, samples from 2 adjacent
+   pixels form 9-octet pgroups.  If 16-bit samples are used, each pixel
+   forms a separate 6-octet pgroup.
+
+
+
+
+
+
+Gharai & Perkins            Standards Track                     [Page 7]
+
+RFC 4175       RTP Payload Format for Uncompressed Video  September 2005
+
+
+   For RGBA format video, samples are packed in order Red-Green-Blue-
+   Alpha.  For BGRA format video, samples are packed in order Blue-
+   Green-Red-Alpha.  For 8-, 10-, 12-, or 16-bit samples, each pixel
+   forms its own pgroup, with octet sizes of 4, 5, 6, and 8,
+   respectively.
+
+   If the video is in YCbCr format, the packing of samples into the
+   payload depends on the color sub-sampling used.
+
+   For YCbCr 4:4:4 format video, samples are packed in order Cb-Y-Cr for
+   both interlaced and progressive frames.  If 8-bit samples are used,
+   the pgroup is 3 octets.  If 10-bit samples are used, samples from 4
+   adjacent pixels form 15-octet pgroups.  If 12-bit samples are used,
+   samples from 2 adjacent pixels form 9-octet pgroups.  If 16-bit
+   samples are used, each pixel forms a separate 6-octet pgroup.
+
+   For YCbCr 4:2:2 format video, the Cb and Cr components are
+   horizontally sub-sampled by a factor of two (each Cb and Cr sample
+   corresponds to two Y components).  Samples are packed in order Cb0-
+   Y0-Cr0-Y1 for both interlaced and progressive scan lines.  For 8-,
+   10-, 12-, or 16-bit samples, the pgroup is formed from two adjacent
+   pixels (4, 5, 6, or 8 octets, respectively).
+
+   For YCbCr 4:1:1 format video, the Cb and Cr components are
+   horizontally sub-sampled by a factor of four (each Cb and Cr sample
+   corresponds to four Y components).  Samples are packed in order Cb0-
+   Y0-Y1-Cr0-Y2-Y3 for both interlaced and progressive scan lines.  For
+   8-, 10-, 12-, or 16-bit samples, the pgroup is formed from four
+   adjacent pixels (6, 15, 9, or 12 octets, respectively).
+
+   For YCbCr 4:2:0 video, the Cb and Cr components are sub-sampled by a
+   factor of two both horizontally and vertically.  Therefore,
+   chrominance samples are shared between certain adjacent lines.
+   Figure 2 shows the composition of luminance and chrominance samples
+   for a 6x6 pixel grid of 4:2:0 YCbCr video.  The pixel group is a
+   group of four pixels arranged in a 2x2 matrix.  The octet size of the
+   pgroup for progressive scan 4:2:0 video with samples sizes of 8, 10,
+   12, and 16 bits is 6, 15, 9, and 12 octets, respectively.  For
+   interlaced 4:2:0 video, the corresponding pgroups are 4, 5, 6, and 8
+   octets.
+
+
+
+
+
+
+
+
+
+
+
+Gharai & Perkins            Standards Track                     [Page 8]
+
+RFC 4175       RTP Payload Format for Uncompressed Video  September 2005
+
+
+       line 0:  Y00   Y01   Y02   Y03   Y04   Y05
+                Cb00 Cr00   Cb01 Cr01   Cb02 Cr02
+       line 1:  Y10   Y11   Y12   Y13   Y14   Y15
+
+       line 2:  Y20   Y21   Y22   Y23   Y24   Y25
+                Cb10 Cr10   Cb11 Cr11   Cb12 Cr12
+       line 3:  Y30   Y31   Y32   Y33   Y34   Y35
+
+       line 4:  Y40   Y41   Y42   Y43   Y44   Y45
+                Cb20 Cr20   Cb21 Cr21   Cb22 Cr22
+       line 5:  Y50   Y51   Y52   Y53   Y54   Y55
+
+     Figure 2: Chrominance/luminance composition in 4:2:0 YCbCr video
+
+   When packetizing progressive scan 4:2:0 YCbCr video, samples from two
+   consecutive scan lines are included in each packet.  The scan line
+   number in the payload header is set to that of the first scan line of
+   the pair:
+
+     line 0/1:
+     Y00-Y01-Y10-Y11-Cb00-Cr00 Y02-Y03-Y12-Y13-Cb01-Cr01
+                                           Y04-Y05-Y14-Y15-Cb02-Cr02
+
+     line 2/3:
+     Y20-Y21-Y30-Y31-Cb10-Cr10 Y22-Y23-Y32-Y33-Cb11-Cr11
+                                           Y24-Y25-Y34-Y35-Cb12-Cr12
+
+     line 4/5:
+     Y40-Y41-Y50-Y51-Cb20-Cr20 Y42-Y43-Y52-Y53-Cb21-Cr21
+                                           Y44-Y45-Y54-Y55-Cb22-Cr22
+
+     Figure 3: Packetization of progressive 4:2:0 YCbCr video
+
+   For interlaced transport, chrominance samples are transported with
+   every other line.  The first set of chrominance samples may be
+   transported with either the first line of field 0, or the first line
+   of field 1.  Figure 4 illustrates the transport of chrominance
+   samples starting with the first line of field 0 (signaled by the
+   "top-field-first" MIME parameter).
+
+
+
+
+
+
+
+
+
+
+
+
+Gharai & Perkins            Standards Track                     [Page 9]
+
+RFC 4175       RTP Payload Format for Uncompressed Video  September 2005
+
+
+     field 0:
+        line 0: Y00-Y01-Cb00-Cr00 Y02-Y03-Cb01-Cr01 Y04-Y05-Cb02-Cr02
+        line 2: Y20-Y21 Y22-Y23 Y24-Y25
+        line 4: Y40-Y41-Cb20-Cr20 Y42-Y43-Cb21-Cr21 Y44-Y45-Cb22-Cr22
+
+     field 1:
+        line 1: Y10-Y11 Y12-Y13 Y14-Y15
+        line 3: Y30-Y31-Cb10-Cr10 Y32-Y33-Cb11 Cr11 Y34-Y35-Cb12-Cr12
+        line 5: Y50-Y51 Y52-Y53 Y54-Y55
+
+     Figure 4: Packetization of interlaced 4:2:0 YCbCr video with
+               top-field-first.
+
+   Chrominance values may be sampled with different offsets relative to
+   luminance values.  For instance, in Figure 2, chrominance values are
+   sampled at the same distance from neighboring luminance samples.  It
+   is also possible for a chrominance sample to be co-sited with a
+   luminance sample, as in Figure 5:
+
+       line 0:  Y00-C   Y01   Y02-C   Y03   Y04-C   Y05
+
+       line 1:  Y10     Y11   Y12     Y13   Y14     Y15
+
+       line 2:  Y20-C   Y21   Y22-C   Y23   Y24-C   Y25
+
+       line 3:  Y30     Y31   Y32     Y33   Y34     Y35
+
+       line 4:  Y40-C   Y41   Y42-C   Y43   Y44-C   Y45
+
+       line 5:  Y50     Y51   Y52     Y53   Y54     Y55
+
+     Figure 5: Co-sited video sampling in 4:2:0 YCbCr video where C
+               designates a CbCr pair
+
+   In general, chrominance values may be placed between luminance
+   samples or co-sited.  Positions can be designated by an integer
+   numbering system starting from left to right and top to bottom.  The
+   position matrices shown in Figures 6, 7, and 8 apply for 4:2:0,
+   4:2:2, and 4:1:1 video, respectively:
+
+       line N:    Y[0] [1] Y[2]   Y[0] [1] Y[2]
+                   [3] [4] Y[5]    [3] [4]  [5]
+       line N+1:  Y[6] [7] Y[8]   Y[6] [7] Y[8]
+
+     Figure 6: Chrominance position matrix for 4:2:0 YCbCr video
+
+
+
+
+
+
+Gharai & Perkins            Standards Track                    [Page 10]
+
+RFC 4175       RTP Payload Format for Uncompressed Video  September 2005
+
+
+       line N:    Y[0] [1] Y[2] [3]  Y[0] [1] Y[2] [3]
+       line N+1:  Y[0] [1] Y[2] [3]  Y[0] [1] Y[2] [3]
+
+     Figure 7: Chrominance position matrix for 4:2:2 YCbCr video
+
+
+       line N:    Y[0] [1] Y[2] [3] Y[4] [5] Y[6]
+       line N+1:  Y[0] [1] Y[2] [3] Y[4] [5] Y[6]
+
+     Figure 8: Chrominance position matrix for 4:1:1 YCbCr video
+
+   Although these positions do not affect the packetization order of
+   chrominance and luminance samples, the information is needed for
+   interpolation prior to display and therefore should be signaled to
+   the receiver.
+
+5.  RTCP Considerations
+
+   RTCP SHOULD be used as specified in RFC 3550 [RTP].  It is to be
+   noted that the sender's octet count in SR packets and the cumulative
+   number of packets lost will wrap around quickly for high data rate
+   streams.  This means that these two fields may not accurately
+   represent octet count and number of packets lost since the beginning
+   of transmission, as defined in RFC 3550.  Therefore, for network
+   monitoring purposes, other means of keeping track of these variables
+   SHOULD be used.
+
+6.  IANA Considerations
+
+   The IANA has registered one new MIME subtype along with an associated
+   RTP Payload Format, and has created two sub-parameter registries, as
+   described in the following.
+
+6.1.  MIME type registration
+
+   MIME media type name: video
+
+   MIME subtype name: raw
+
+   Required parameters:
+
+     rate: The RTP timestamp clock rate.  Applications using this
+     payload format SHOULD use a value of 90000.
+
+     sampling: Determines the color (sub-)sampling mode of the video
+     stream.  Currently defined values are RGB, RGBA, BGR, BGRA,
+     YCbCr-4:4:4, YCbCr-4:2:2, YCbCr-4:2:0, and YCbCr-4:1:1.  New values
+     may be registered as described in section 6.2 of RFC 4175.
+
+
+
+Gharai & Perkins            Standards Track                    [Page 11]
+
+RFC 4175       RTP Payload Format for Uncompressed Video  September 2005
+
+
+     width: Determines the number of pixels per line.  This is an
+     integer between 1 and 32767.
+
+     height: Determines the number of lines per frame.  This is an
+     integer between 1 and 32767.
+
+     depth: Determines the number of bits per sample.  This is an
+     integer with typical values including 8, 10, 12, and 16.
+
+     colorimetry: This parameter defines the set of colorimetric
+     specifications and other transfer characteristics for the video
+     source, by reference to an external specification.  Valid values
+     and their specification are:
+
+          BT601-5      ITU Recommendation BT.601-5 [601]
+          BT709-2      ITU Recommendation BT.709-2 [709]
+          SMPTE240M    SMPTE standard 240M [240]
+
+     New values may be registered as described in section 6.2 of RFC
+     4175.
+
+
+   Optional parameters:
+
+     Interlace: If this OPTIONAL parameter is present, it indicates that
+     the video stream is interlaced.  If absent, progressive scan is
+     implied.
+
+     Top-field-first: If this OPTIONAL parameter is present, it
+     indicates that chrominance samples are packetized starting with the
+     first line of field 0.  Its absence implies that chrominance
+     samples are packetized starting with the first line of field 1.
+
+     chroma-position: This OPTIONAL parameter defines the position of
+     chrominance samples relative to luminance samples.  It is either a
+     single integer or a comma separated pair of integers.  Integer
+     values range from 0 to 8, as specified in Figures 6-8 of RFC 4175.
+     A single integer implies that Cb and Cr are co-sited.  A comma
+     separated pair of integers designates the locations of Cb and Cr
+     samples, respectively.  In its absence, a single value of zero is
+     assumed for color-subsampled video (chroma-position=0).
+
+     gamma: An OPTIONAL floating point gamma correction value.
+
+
+
+
+
+
+
+
+Gharai & Perkins            Standards Track                    [Page 12]
+
+RFC 4175       RTP Payload Format for Uncompressed Video  September 2005
+
+
+   Encoding considerations:
+
+     Uncompressed video is only transmitted over RTP as specified in RFC
+     4175.  No file format media type has been defined to go with this
+     transmission media type at this time.
+
+   Security considerations: See section 9 of RFC 4175.
+
+   Interoperability considerations: NONE.
+
+   Published specification: RFC 4175.
+
+   Applications which use this media type: Video communication.
+
+   Additional information: None
+
+   Person & email address to contact for further information:
+
+     Ladan Gharai <ladan@isi.edu>
+     IETF Audio/Video Transport working group.
+
+   Intended usage: COMMON
+
+   Author: Ladan Gharai <ladan@isi.edu>
+   Change controller: IETF AVT Working Group
+         delegated from the IESG
+
+6.2.  Parameter Registration
+
+   New values of the "sampling" parameter MAY be registered with the
+   IANA provided they reference an RFC or other permanent and readily
+   available specification (the Specification Required policy of RFC
+   2434 [2434]).  A new registration MUST define the packing order of
+   samples and a valid combinations of color and sub-sampling modes.
+
+   New values of the "colorimetry" parameter MAY be registered with the
+   IANA provided they reference an RFC or other permanent and readily
+   available specification if colorimetric parameters and other
+   applicable transfer characteristics (the Specification Required
+   policy of RFC 2434 [2434]).
+
+7.  Mapping MIME Parameters into SDP
+
+   The information carried in the MIME media type specification has a
+   specific mapping to fields in the Session Description Protocol (SDP)
+   [SDP], which is commonly used to describe RTP sessions.  When SDP is
+   used to specify sessions transporting uncompressed video, the mapping
+   is as follows:
+
+
+
+Gharai & Perkins            Standards Track                    [Page 13]
+
+RFC 4175       RTP Payload Format for Uncompressed Video  September 2005
+
+
+   -  The MIME type ("video") goes in SDP "m=" as the media name.
+
+   -  The MIME subtype (payload format name) goes in SDP "a=rtpmap" as
+      the encoding name.
+
+   -  Remaining parameters go in the SDP "a=fmtp" attribute by copying
+      them directly from the MIME media type string as a semicolon-
+      separated list of parameter=value pairs.
+
+   A sample SDP mapping for uncompressed video is as follows:
+
+     m=video 30000 RTP/AVP 112
+     a=rtpmap:112 raw/90000
+     a=fmtp:112 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10;
+                              colorimetry=BT.709-2; chroma-position=1
+
+   In this example, a dynamic payload type 112 is used for uncompressed
+   video.  The RTP sampling clock is 90 kHz.  Note that the "a=fmtp:"
+   line has been wrapped to fit this page, and will be a single long
+   line in the SDP file.
+
+8.  Security Considerations
+
+   RTP packets using the payload format defined in this specification
+   are subject to the security considerations discussed in the RTP
+   specification [RTP] and any appropriate RTP profile.  This implies
+   that confidentiality of the media streams is achieved by encryption.
+
+   This payload type does not exhibit any significant non-uniformity in
+   the receiver side computational complexity for packet processing to
+   cause a potential denial-of-service threat.
+
+   It is important to note that uncompressed video can have immense
+   bandwidth requirements (up to 270 Mbps for standard-definition video,
+   and approximately 1 Gbps for high-definition video).  This is
+   sufficient to cause potential for denial-of-service if transmitted
+   onto most currently available Internet paths.
+
+   Accordingly, if best-effort service is being used, users of this
+   payload format MUST monitor packet loss to ensure that the packet
+   loss rate is within acceptable parameters.  Packet loss is considered
+   acceptable if a TCP flow across the same network path, and
+   experiencing the same network conditions, would achieve an average
+   throughput, measured on a reasonable timescale, that is not less than
+   the RTP flow is achieving.  This condition can be satisfied by
+   implementing congestion control mechanisms to adapt the transmission
+
+
+
+
+
+Gharai & Perkins            Standards Track                    [Page 14]
+
+RFC 4175       RTP Payload Format for Uncompressed Video  September 2005
+
+
+   rate (or the number of layers subscribed for a layered multicast
+   session), or by arranging for a receiver to leave the session if the
+   loss rate is unacceptably high.
+
+   This payload format may also be used in networks that provide
+   quality-of-service guarantees.  If enhanced service is being used,
+   receivers SHOULD monitor packet loss to ensure that the service that
+   was requested is actually being delivered.  If it is not, then they
+   SHOULD assume that they are receiving best-effort service and behave
+   accordingly.
+
+9.  Relation to RFC 2431
+
+   In comparison with RFC 2431, this memo specifies support for a wider
+   variety of uncompressed video, in terms of frame size, color sub-
+   sampling and sample sizes.  Although [BT656] can transport up to 4096
+   scan lines and 2048 pixels per line, our payload type can support up
+   to 32768 scan lines and pixels per line.  Also, RFC 2431 only address
+   4:2:2 YCbCr data, while this memo covers YCbCr, RGB, RGBA, BGR, BGRA,
+   and most common color sub-sampling schemes.  Given the variety of
+   video types that we cover, this memo also assumes out-of-band
+   signaling for sample size and data types (RFC 2431 uses in band
+   signaling).
+
+10.  Relation to RFC 3497
+
+   RFC 3497 [292RTP] specifies a RTP payload format for encapsulating
+   SMPTE 292M video.  The SMPTE 292M standard defines a bit-serial
+   digital interface for local area High-Definition Television (HDTV)
+   transport.  As a transport medium, SMPTE 292M utilizes 10-bit words
+   and a fixed 1.485 Gbps (and 1.485/1.001 Gbps) data rate.  SMPTE 292M
+   is typically used in the broadcast industry for the transport of
+   other video formats such as SMPTE 260M, SMPTE 295M, SMPTE 274M, and
+   SMPTE 296M.
+
+   RFC 3497 defines a circuit emulation for the transport of SMPTE 292M
+   over RTP.  It is very specific to SMPTE 292 and has been designed to
+   be interoperable with existing broadcast equipment with a constant
+   rate of 1.485 Gbps.
+
+   This memo defines a flexible native packetization scheme that can
+   packetize any uncompressed video, at varying data rates.  In
+   addition, unlike RFC 3497, this memo only transports active video
+   pixels (i.e., horizontal and vertical blanking are not transported).
+
+
+
+
+
+
+
+Gharai & Perkins            Standards Track                    [Page 15]
+
+RFC 4175       RTP Payload Format for Uncompressed Video  September 2005
+
+
+11.  Acknowledgements
+
+   The authors are grateful to Philippe Gentric, Chuck Harrison, Stephan
+   Wenger, and Dave Singer for their feedback.
+
+   This memo is based upon work supported by the U.S. National Science
+   Foundation (NSF) under Grant No. 0230738.  Any opinions, findings,
+   and conclusions or recommendations expressed in this material are
+   those of the authors and do not necessarily reflect the views of NSF.
+
+Normative References
+
+   [RTP]    Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+            "RTP: A Transport Protocol for Real-Time Applications", STD
+            64, RFC 3550, July 2003.
+
+   [2119]   Bradner, S., "Key words for use in RFCs to Indicate
+            Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [2434]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
+            IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+            October 1998.
+
+   [601]    International Telecommunication Union, "Studio encoding
+            parameters of digital television for standard 4:3 and wide
+            screen 16:9 aspect ratios", Recommendation BT.601, October
+            1995.
+
+   [709]    International Telecommunication Union, "Parameter Values for
+            HDTV Standards for Production and International Programme
+            Exchange", Recommendation BT.709-2
+
+   [240]    Society of Motion Picture and Television Engineers,
+            "Television - Signal Parameters - 1125-Line High-Definition
+            Production", SMPTE 240M-1999.
+
+Informative References
+
+   [274]    Society of Motion Picture and Television Engineers,
+            "1920x1080 Scanning and Analog and Parallel Digital
+            Interfaces for Multiple Picture Rates", SMPTE 274M-1998.
+
+   [296]    Society of Motion Picture and Television Engineers,
+            "1280x720 Scanning, Analog and Digital Representation and
+            Analog Interfaces", SMPTE 296M-1998.
+
+
+
+
+
+
+Gharai & Perkins            Standards Track                    [Page 16]
+
+RFC 4175       RTP Payload Format for Uncompressed Video  September 2005
+
+
+   [372]    Society of Motion Picture and Television Engineers, "Dual
+            Link 292M Interface for 1920 x 1080 Picture Raster", SMPTE
+            372M-2002.
+
+   [ALF]    Clark, D. D., and Tennenhouse, D. L., "Architectural
+            Considerations for a New Generation of Protocols", In
+            Proceedings of SIGCOMM '90 (Philadelphia, PA, Sept. 1990),
+            ACM.
+
+   [SDP]    Handley, M. and V. Jacobson, "SDP: Session Description
+            Protocol", RFC 2327, April 1998.
+
+   [BT656]  Tynan, D., "RTP Payload Format for BT.656 Video Encoding",
+            RFC 2431, October 1998.
+
+   [292RTP] Gharai, L., Perkins, C., Goncher, G., and A. Mankin, "RTP
+            Payload Format for Society of Motion Picture and Television
+            Engineers (SMPTE) 292M Video", RFC 3497, March 2003.
+
+   [656]    International Telecommunication Union, "Interfaces for
+            Digital Component Video Signals in 525-line and 625-line
+            Television Systems Operating at the 4:2:2 Level of
+            Recommendation ITU-R BT.601 (Part A)", Recommendation
+            BT.656, April 1998.
+
+Authors' Addresses
+
+   Ladan Gharai
+   USC Information Sciences Institute
+   3811 N. Fairfax Drive, #200
+   Arlington, VA 22203
+   USA
+
+   EMail: ladan@isi.edu
+
+
+   Colin Perkins
+   University of Glasgow
+   Department of Computing Science
+   17 Lilybank Gardens
+   Glasgow G12 8QQ
+   United Kingdom
+
+   EMail: csp@csperkins.org
+
+
+
+
+
+
+
+Gharai & Perkins            Standards Track                    [Page 17]
+
+RFC 4175       RTP Payload Format for Uncompressed Video  September 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   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 currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Gharai & Perkins            Standards Track                    [Page 18]
+