RFC4175 日本語訳

Network Working Group                                          L. Gharai
Request for Comments: 4175                                       USC/ISI
Category: Standards Track                                     C. Perkins
                                                   University of Glasgow
                                                          September 2005

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

RTP Payload Format for Uncompressed Video

Status of This Memo

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.

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 Notice

   Copyright (C) The Internet Society (2005).

Copyright (C) The Internet Society (2005).

Abstract

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.

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

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

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.

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

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).

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.

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

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

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

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.

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.

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

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

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.

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.

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.

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

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").

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

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.

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.

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

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.

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.

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

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

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

Figure 1: RTP Payload Format showing two (partial) lines of video

4.1.  The RTP Header

4.1. The RTP Header

   The fields of the fixed RTP header have their usual meaning, with the
   following additional notes:

The fields of the fixed RTP header have their usual meaning, with the following additional notes:

   Payload Type (PT): 7 bits

Payload Type (PT): 7 bits

     A dynamically allocated payload type field that designates the
     payload as uncompressed video.

A dynamically allocated payload type field that designates the payload as uncompressed video.

   Timestamp: 32 bits

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 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.

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

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.

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

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.

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

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.

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

4.2. Payload Header

   Extended Sequence Number: 16 bits

Extended Sequence Number: 16 bits

     The high order bits of the extended 32-bit sequence number, in
     network byte order.

The high order bits of the extended 32-bit sequence number, in network byte order.

   Length: 16 bits

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.

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

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.

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: 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

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

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.

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

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.

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

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.

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

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.

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.)

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.

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

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.

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.

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: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: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: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.

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

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

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

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:

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

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

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).

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

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

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.

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:

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 0: Y00-C Y01 Y02-C Y03 Y04-C Y05

       line 1:  Y10     Y11   Y12     Y13   Y14     Y15

line 1: Y10 Y11 Y12 Y13 Y14 Y15

       line 2:  Y20-C   Y21   Y22-C   Y23   Y24-C   Y25

line 2: Y20-C Y21 Y22-C Y23 Y24-C Y25

       line 3:  Y30     Y31   Y32     Y33   Y34     Y35

line 3: Y30 Y31 Y32 Y33 Y34 Y35

       line 4:  Y40-C   Y41   Y42-C   Y43   Y44-C   Y45

line 4: Y40-C Y41 Y42-C Y43 Y44-C Y45

       line 5:  Y50     Y51   Y52     Y53   Y54     Y55

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

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:

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]

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

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

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]

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

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]

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

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.

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

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.

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

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.

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

6.1. MIME type registration

   MIME media type name: video

MIME media type name: video

   MIME subtype name: raw

MIME subtype name: raw

   Required parameters:

Required parameters:

     rate: The RTP timestamp clock rate.  Applications using this
     payload format SHOULD use a value of 90000.

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.

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

GharaiとパーキンスStandardsは解凍されたビデオ2005年9月にRFC4175RTP有効搭載量形式を追跡します[11ページ]。

     width: Determines the number of pixels per line.  This is an
     integer between 1 and 32767.

幅: 1線あたりのピクセル数を測定します。 これは1〜32767の整数です。

     height: Determines the number of lines per frame.  This is an
     integer between 1 and 32767.

高さ: 1フレームあたりの線の数を測定します。 これは1〜32767の整数です。

     depth: Determines the number of bits per sample.  This is an
     integer with typical values including 8, 10, 12, and 16.

深さ: 1サンプルあたりのビットの数を測定します。 これは8、10、12、および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:

測色: このパラメタはcolorimetric仕様と他の転送の特性のセットをビデオソースと定義します、外部仕様の参照で。 有効値とそれらの仕様は以下の通りです。

          BT601-5      ITU Recommendation BT.601-5 [601]
          BT709-2      ITU Recommendation BT.709-2 [709]
          SMPTE240M    SMPTE standard 240M [240]

BT601-5 ITU Recommendation BT.601-5[601]BT709-2 ITU Recommendation BT.709-2[709]SMPTE240M SMPTE標準の240M[240]

     New values may be registered as described in section 6.2 of RFC
     4175.

新しい値はRFC4175のセクション6.2で説明されるように示されるかもしれません。

   Optional parameters:

任意のパラメタ:

     Interlace: If this OPTIONAL parameter is present, it indicates that
     the video stream is interlaced.  If absent, progressive scan is
     implied.

インターレース: このOPTIONALパラメタが存在しているなら、それは、ビデオストリームが交錯するのを示します。 休んでいて、進歩的なスキャンが含意されるなら。

     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.

先端は1番目をさばきます: このOPTIONALパラメタが存在しているなら、それは、分野0の最初の線から始まって、色差のサンプルがpacketizedされるのを示します。 不在は、分野1の最初の線から始まって、色差のサンプルがpacketizedされるのを含意します。

     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).

彩度位置: このOPTIONALパラメタは輝度のサンプルに比例して色差のサンプルの立場を定義します。 それは、整数のただ一つの整数かコンマ切り離された組のどちらかです。 整数値はRFC4175の図6-8で指定されるように0〜8まで及びます。 ただ一つの整数は、CbとCrが共同位置しているのを含意します。 整数のコンマ切り離された組はそれぞれCbとCrのサンプルの位置を指定します。 不在では、ゼロのただ一つの値は色によって「副-標本抽出」のビデオ(彩度位置=0)のために想定されます。

     gamma: An OPTIONAL floating point gamma correction value.

ガンマ: OPTIONAL浮動小数点ガンマ補正。

Gharai & Perkins            Standards Track                    [Page 12]

RFC 4175       RTP Payload Format for Uncompressed Video  September 2005

GharaiとパーキンスStandardsは解凍されたビデオ2005年9月にRFC4175RTP有効搭載量形式を追跡します[12ページ]。

   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.

解凍されたビデオはRFC4175の指定されるとしてのRTPの上に送られるだけです。 ファイル形式メディアタイプは、全くこのときこのトランスミッションメディアタイプを伴うために定義されていません。

   Security considerations: See section 9 of RFC 4175.

セキュリティ問題: RFC4175のセクション9を見てください。

   Interoperability considerations: NONE.

相互運用性問題: なし。

   Published specification: RFC 4175.

広められた仕様: RFC4175。

   Applications which use this media type: Video communication.

このメディアタイプを使用するアプリケーション: ビデオコミュニケーション。

   Additional information: None

追加情報: なし

   Person & email address to contact for further information:

詳細のために連絡する人とEメールアドレス:

     Ladan Gharai <ladan@isi.edu>
     IETF Audio/Video Transport working group.

Ladan Gharai <ladan@isi.edu 、gt;、IETF Audio/ビデオTransportワーキンググループ。

   Intended usage: COMMON

意図している用法: 一般的

   Author: Ladan Gharai <ladan@isi.edu>
   Change controller: IETF AVT Working Group
         delegated from the IESG

以下を書いてください。 Ladan Gharai <ladan@isi.edu 、gt;、コントローラを変えてください: IESGから代表として派遣されたIETF AVT作業部会

6.2.  Parameter Registration

6.2. パラメタ登録

   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.

RFCか他の永久的で容易に利用可能な仕様(RFC2434[2434]のSpecification Required方針)に参照をつけるなら、「標本抽出」パラメタの新しい値はIANAに示されるかもしれません。 新規登録はサンプルに関する梱包指図書と色とサブ標本抽出モードの有効な組み合わせを定義しなければなりません。

   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]).

colorimetricパラメタと適切なもう一方が特性(RFC2434[2434]のSpecification Required方針)を移すならRFCか他の永久的で容易に利用可能な仕様に参照をつけるなら、「測色」パラメタの新しい値はIANAに示されるかもしれません。

7.  Mapping MIME Parameters into SDP

7. MIMEパラメタを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:

タイプ仕様が特定のマッピングを持っているMIMEメディアで運ばれた情報はSessionで記述プロトコル(SDP)[SDP]をさばきます。(それは、RTPセッションについて説明するのに一般的に使用されます)。 SDPがいつ解凍されたビデオを輸送するセッション、マッピングを指定するのにおいて使用されているかは、以下の通りです:

Gharai & Perkins            Standards Track                    [Page 13]

RFC 4175       RTP Payload Format for Uncompressed Video  September 2005

GharaiとパーキンスStandardsは解凍されたビデオ2005年9月にRFC4175RTP有効搭載量形式を追跡します[13ページ]。

   -  The MIME type ("video") goes in SDP "m=" as the media name.

- MIMEの種類(「ビデオ」)はメディア名としてSDP「m=」に行きます。

   -  The MIME subtype (payload format name) goes in SDP "a=rtpmap" as
      the encoding name.

- MIME「副-タイプ」(ペイロード形式名)はコード化名としてSDP"a=rtpmap"に入ります。

   -  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.

- パラメタ=価値のセミコロンの切り離されたリストが対にされるので直接メディアタイプが結ぶMIMEからそれらをコピーすることによって、残っているパラメタはSDP"a=fmtp"属性に入ります。

   A sample SDP mapping for uncompressed video is as follows:

解凍されたビデオのためのサンプルSDPマッピングは以下の通りです:

     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

ビデオ30000RTP/AVP112m=a=rtpmap: 112 生の/90000a=fmtp: 112 標本抽出はYCbCr-4と等しいです: 2:2 幅=1280。 高さ=720。 深さ=10。 測色はBT.709-2と等しいです。 彩度位置=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.

この例では、ダイナミックなペイロードタイプ112は解凍されたビデオに使用されます。 RTP標本抽出時計は90kHzです。 それに注意してください、「a=fmtp:」 このページに合うように線を包装してあります、そして、SDPファイルのただ一つの長い線でしょう。

8.  Security Considerations

8. セキュリティ問題

   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.

この仕様に基づき定義されたペイロード書式を使用するRTPパケットはRTP仕様[RTP]とどんな適切なRTPプロフィールでも議論したセキュリティ問題を受けることがあります。 これは、メディアの流れの秘密性が暗号化で達成されるのを含意します。

   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.

解凍されたビデオが莫大な帯域幅要件(標準定義ビデオのための最大270Mbps、およびハイデフィニッションビデオのためのおよそ1Gbps)を持つことができることに注意するのは重要です。 最も現在の利用可能なインターネット経路に送られるなら、これは、サービスの否定の可能性を引き起こすために十分です。

   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

それに従って、ベストエフォート型サービスが利用されているなら、このペイロード形式のユーザは、許容できるパラメタの中にパケット損失率があるのを保証するためにパケット損失をモニターしなければなりません。 同じネットワーク経路、および同じネットワークが条件とさせる経験の向こう側のTCP流動が妥当なスケールで測定された少なくとも流れが実現しているRTPである平均したスループットを実現するなら、パケット損失は許容できると考えられます。 トランスミッションを適合させるために混雑制御機構を実行することによって、この状態を満たすことができます。

Gharai & Perkins            Standards Track                    [Page 14]

RFC 4175       RTP Payload Format for Uncompressed Video  September 2005

GharaiとパーキンスStandardsは解凍されたビデオ2005年9月にRFC4175RTP有効搭載量形式を追跡します[14ページ]。

   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.

また、このペイロード形式はサービスの質保証を提供するネットワークに使用されるかもしれません。 高度サービスが使用されているなら、受信機SHOULDは、要求されたサービスが実際に提供されているのを保証するためにパケット損失をモニターします。 それはそうでなく、次に、それらはSHOULDです。彼らが受信のベストエフォート型サービスであり、それに従って、振る舞うと仮定してください。

9.  Relation to RFC 2431

9. RFC2431との関係

   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).

RFC2431との比較では、このメモは、より広いバラエティーの解凍されたビデオのサポートを指定します、フレーム・サイズ、色のサブ標本抽出、およびサンプルサイズに関して。 [BT656]は1線あたり線と2048画素を4096年のスキャンまで輸送できますが、私たちのペイロードタイプは1線あたり最大32768スキャン線と画素を支えることができます。 また、RFC2431は4:2:2つのYCbCrデータしか記述しません、このメモがYCbCrを覆っていますが、RGB、RGBA、BGR、BGRA、および最も一般的な色のサブ標本抽出計画。 私たちがカバーするビデオタイプの品種を考えて、また、このメモはサンプルサイズとデータ型(バンドシグナリングにおけるRFC2431用途)のためにバンドの外でシグナリングを仮定します。

10.  Relation to RFC 3497

10. RFC3497との関係

   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.

RFC3497[292RTP]はSMPTEの292Mのビデオを要約するのにRTPペイロード形式を指定します。 SMPTEの292Mの規格は局部High-定義Television(HDTV)輸送のために少し連続のデジタルインタフェースを定義します。 輸送培地として、SMPTE292Mは10ビットの単語と固定1.485Gbps(そして、1.485/1.001Gbps)のデータ信号速度を利用します。 通常、SMPTE292MはSMPTE260Mや、SMPTE295Mや、SMPTE274Mや、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.

RFC3497はRTPの上でSMPTEの輸送のためのサーキットエミュレーションを292M定義します。 それは、SMPTE292に非常に特定であり、1.485Gbpsの一定のレートがある既存の放送設備で共同利用できるように設計されています。

   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).

このメモは異なったデータ信号速度でどんな解凍されたビデオもpacketizeすることができるフレキシブルなネイティブのpacketization計画を定義します。 さらに、RFC3497と異なって、このメモはアクティブなビデオ画素を輸送するだけです(すなわち、水平で垂直な空白は輸送されません)。

Gharai & Perkins            Standards Track                    [Page 15]

RFC 4175       RTP Payload Format for Uncompressed Video  September 2005

GharaiとパーキンスStandardsは解凍されたビデオ2005年9月にRFC4175RTP有効搭載量形式を追跡します[15ページ]。

11.  Acknowledgements

11. 承認

   The authors are grateful to Philippe Gentric, Chuck Harrison, Stephan
   Wenger, and Dave Singer for their feedback.

作者はフィリップGentric、チャック・ハリソン、シュテファンWenger、およびデーヴSingerに彼らのフィードバックに感謝しています。

   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.

このメモはグラントNo.0230738の下に全米科学財団によって支持された仕事(NSF)に基づいています。 この材料の中に述べられたどんな意見か、調査結果と、結論か推薦も、作者のものであり、必ず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.

[RTP] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。

   [2119]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

[2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [2434]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 2434,
            October 1998.

[2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

   [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.

[601] 国際電気通信連合、「標準の4:3とワイドスクリーン16:9アスペクトレシオのためにデジタル・テレビのパラメタをコード化するスタジオ」、Recommendation BT.601(1995年10月)。

   [709]    International Telecommunication Union, "Parameter Values for
            HDTV Standards for Production and International Programme
            Exchange", Recommendation BT.709-2

[709]国際電気通信連合、「生産と国際プログラム交換のHDTV規格のためのパラメタ値」、推薦BT.709-2

   [240]    Society of Motion Picture and Television Engineers,
            "Television - Signal Parameters - 1125-Line High-Definition
            Production", SMPTE 240M-1999.

[240]映画テレビ技術者協会、「テレビ--信号パラメタ--1125線のハイデフィニッション生産」、SMPTE240M1999。

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.

[274] 映画テレビ技術者協会、「1920×1080 スキャンしていてアナログの、そして、平行なDigitalは複数の絵のレートのために連結します」、SMPTE274M1998。

   [296]    Society of Motion Picture and Television Engineers,
            "1280x720 Scanning, Analog and Digital Representation and
            Analog Interfaces", SMPTE 296M-1998.

[296] 映画テレビ技術者協会、「1280×720スキャン、アナログ、ディジタル表現、およびアナログは連結する」、SMPTE296M1998。

Gharai & Perkins            Standards Track                    [Page 16]

RFC 4175       RTP Payload Format for Uncompressed Video  September 2005

GharaiとパーキンスStandardsは解凍されたビデオ2005年9月にRFC4175RTP有効搭載量形式を追跡します[16ページ]。

   [372]    Society of Motion Picture and Television Engineers, "Dual
            Link 292M Interface for 1920 x 1080 Picture Raster", SMPTE
            372M-2002.

[372]映画テレビ技術者協会、「1920x1080Picture RasterのためのLinkの292Mの二元的なInterface」SMPTE372M2002。

   [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.

[ALF] SIGCOMM90年(フィラデルフィア(PA)1990年9月)、ACMの議事におけるクラーク、D.D.とTennenhouse、D.L.、「プロトコルの新しい世代建築問題。」

   [SDP]    Handley, M. and V. Jacobson, "SDP: Session Description
            Protocol", RFC 2327, April 1998.

[SDP] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。

   [BT656]  Tynan, D., "RTP Payload Format for BT.656 Video Encoding",
            RFC 2431, October 1998.

[BT656] タイナン、D.、「BT.656ビデオのコード化のためのRTP有効搭載量形式」、RFC2431、1998年10月。

   [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.

[292RTP] Gharai、L.、パーキンス、C.、Goncher、G.、およびA.マンキン、「映画テレビ技術者協会(SMPTE)の292MのビデオのためのRTP有効搭載量形式」、RFC3497(2003年3月)。

   [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.

[656] 国際電気通信連合、「推薦ITU-R BT.601の4:2:2レベルで作動する525線の、そして、625線のテレビジョン方式のデジタルコンポーネントビデオ信号のためのインタフェース、(a)を分けてください、」、推薦BT.656(1998年4月)

Authors' Addresses

作者のアドレス

   Ladan Gharai
   USC Information Sciences Institute
   3811 N. Fairfax Drive, #200
   Arlington, VA 22203
   USA

Ladan Gharai USC情報科学は3811年のN.フェアファクスのドライブ、#200アーリントン、ヴァージニア22203米国を設けます。

   EMail: ladan@isi.edu

メール: ladan@isi.edu

   Colin Perkins
   University of Glasgow
   Department of Computing Science
   17 Lilybank Gardens
   Glasgow G12 8QQ
   United Kingdom

グラスゴー電子計算学17LilybankガーデンズグラスゴーG12 8QQイギリスの部のコリンパーキンス大学

   EMail: csp@csperkins.org

メール: csp@csperkins.org

Gharai & Perkins            Standards Track                    [Page 17]

RFC 4175       RTP Payload Format for Uncompressed Video  September 2005

GharaiとパーキンスStandardsは解凍されたビデオ2005年9月にRFC4175RTP有効搭載量形式を追跡します[17ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Gharai & Perkins            Standards Track                    [Page 18]

Gharaiとパーキンス標準化過程[18ページ]