rfc2431.txt

<VC++网络游戏建摸与实现>源代码


RFC 2431             RTP Payload Format for BT.656          October 1998


   Further encodings can only be defined through the Internet Assigned
   Numbers Authority (IANA).  For more information refer to Section 8,
   "IANA Considerations".

   P: 1 bit
   Indicates the required sample quantization size.  When 0, the payload
   is comprised of 8-bit samples.  Otherwise, it carries 10-bit samples.
   This bit MUST remain unchanged for all scan lines within the same
   frame.

   Z: 2 bits
   Reserved for future use.  Must be set to zero by the transmitter and
   ignored by the receiver.

   Scan Line (SL): 12 bits
   Indicates the scan line encapsulated in the payload.  Valid values
   range from 1 through 625 inclusive. If no frame blanking data is
   being transmitted, only scan lines 23 through 310 inclusive, and
   lines 336 through 623 inclusive SHOULD be sent in the case of Type=1
   or 3.  For 525/60 encoding (Type=0 or 2), scan lines 10 through 263
   inclusive and lines 273 through 525 SHOULD be transmitted.

   If a receiver is generating a BT.656-3 data stream directly from this
   packet, the F and V bits MUST be copied from the header rather than
   being generated implicitly from the scan line number.  In the event
   of a conflict, the F and V bits have precedence.

   Scan Offset (SO): 11 bits
   Indicates the offset within the scan line for application-level
   fragmentation.  After doing PMTU discovery, if the path MTU is less
   than the required size for one complete scan line, the data SHOULD be
   fragmented such that a given RTP packet does not exceed the allowable
   MTU.  The offset for the first packet of a scan line MUST be set to
   zero.  The scan offset refers to the sample-pair offset within the
   scan such that for a scan line width of 720, the maximum scan offset
   is 359.

6. Payload Format

   In keeping with the 4:2:2 color subsampling of BT.656 and BT.601,
   each pair of color-difference samples will be intermixed with two
   luminance samples.  As per BT.656, the format for transmission SHALL
   be Cb, Y, Cr, Y.  The following is a representation of a 720 sample
   packet with 8-bit quantization:







Tynan                       Standards Track                     [Page 6]

RFC 2431             RTP Payload Format for BT.656          October 1998


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Cb0      |      Y0       |      Cr0      |      Y1       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Cb1      |      Y2       |      Cr1      |      Y3       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      .
                                      .
                                      .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Cb359     |     Y718      |     Cr359     |     Y719      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   1144 and 1152 sample packets SHOULD increase the packet size
   accordingly while maintaining the sample order.

   For 10-bit quantization, each group of four samples MUST be encoded
   into a 40-bit word (five octets) prior to transmission.  The sample
   order is identical to that for 8-bit quantization.  The following is
   a representation of a 720 sample packet with 10-bit quantization:

               0         1         2         3
               0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8
              +---------+---------+---------+---------+
              |   Cb0   |   Y0    |   Cr0   |   Y1    |
              +---------+---------+---------+---------+
              |   Cb1   |   Y2    |   Cr1   |   Y3    |
              +---------+---------+---------+---------+
                                  .
                                  .
                                  .
              +---------+---------+---------+---------+
              |  Cb359  |  Y718   |  Cr359  |  Y719   |
              +---------+---------+---------+---------+
                (Note that the word width is 40 bits)
              +-------+-------+-------+-------+-------+
      Octets: |   0   |   1   |   2   |   3   |   4   |
              +-------+-------+-------+-------+-------+

   The octets shown in these diagrams are transmitted in network byte
   order, that is, left-to-right as shown.









Tynan                       Standards Track                     [Page 7]

RFC 2431             RTP Payload Format for BT.656          October 1998


7. Security Considerations

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [1].  This implies that confidentiality of the media
   streams is achieved by encryption.  Because the payload format is
   arranged end-to-end, encryption MAY be performed after encapsulation
   so there is no conflict between the two operations.

   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.

8. IANA Considerations

   The four encoding types defined by this document relate to specific
   schema defined by ITU-R Recommendation BT.656-3.  Future revisions of
   the recommendation may create further encoding types which need to be
   supported over RTP. The "Type" field is four bits wide allowing for a
   total of up to sixteen possible encodings, with twelve currently
   reserved for future use.  Due to the small number of possible
   encodings and given that it is very unlikely that future revisions of
   BT.656 will introduce any new schema, requests to extend the Type
   field MUST be vetted by the Internet Assigned Numbers Authority.
   Furthermore, implementors SHOULD check the IANA repository for new
   definitions of the Type field in order to comply with this document.

   Applications for a new Type value MUST be submitted to the IANA and
   include the requestors name and contact information, the reason for
   requesting a new Type and references to appropriate standards, such
   as an updated version of ITU-R Recommendation BT.656.  Furthermore,
   in the unlikely event that the new Type will lessen the security of a
   compliant implementation, such security risk MUST be detailed in the
   application.  The application will be reviewed by a Designated Expert
   and if appropriate, a new Type will be assigned.  This type will be
   listed in the IANA repository for future implementations.















Tynan                       Standards Track                     [Page 8]

RFC 2431             RTP Payload Format for BT.656          October 1998


9. References

   [1]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
         "RTP: A Transport Protocol for Real-Time Applications", RFC
         1889, January 1996.

   [2]   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), ITU-R Recommendation
         BT.656-3, 1995.

   [3]   Studio Encoding Parameters of Digital Television for Standard
         4:3 and Wide-Screen 16:9 Aspect Ratios, ITU-R Recommendation
         BT.601-5, 1995.

   [4]   Schulzrinne, H., "RTP Profile for Audio and Video Conference
         with Minimal Control", RFC 1890, January 1996.

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

   [6]   Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
         November 1990.

10. Author's Address

   Dermot Tynan
   Claddagh Films Limited
   3 White Oaks
   Clybaun Road
   Galway
   Ireland

   EMail: [e-mail]
   Phone: [phone]
















Tynan                       Standards Track                     [Page 9]

RFC 2431             RTP Payload Format for BT.656          October 1998


11.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.
























Tynan                       Standards Track                    [Page 10]