rfc2035.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 900 行 · 第 1/3 页

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   These sampling factors indicate that the chromanince components of
   type 0/2/4 video is downsampled horizontally by 2 (often called
   4:2:2) while the chrominance components of type 1/3/5 video are
   downsampled both horizontally and vertically by 2 (often called
   4:2:0).

   The three pairs of types (0/1), (2/3) and (4/5) differ from each
   other as follows:

   0/1 : No restart markers are present in the entropy data.
         No restriction is placed on the fragmentation of the stream
         into RTP packets.
         The type specific field is unused and must be zero.

   2/3 : Restart markers are present in the entropy data.
         The entropy data is preceded by a DRI marker segment, defining
         the restart interval.
         No restriction is placed on the fragmentation of the stream
         into RTP packets.
         The type specific field is unused and must be zero.















Berc, et. al.               Standards Track                     [Page 6]

RFC 2035           RTP Payload Format for JPEG Video        October 1996


   4/5 : Restart markers are present in the entropy data.
         The entropy data is preceded by a DRI marker segment, defining
         the restart interval.
         Restart intervals are be sent as separate (possibly multiple)
         RTP packets.
         The type specific field (TSPEC) is used as follows:
             A restart interval count (RCOUNT) is defined, which
             starts at zero, and is incremented for each restart
             interval in the frame.

             The first packet of a restart interval gets TSPEC = RCOUNT.
             Subsequent packets of the restart interval get TSPEC = 254,
             except the final packet, which gets TSPEC = 255.

   Additional types in the range 128-255 may be defined by external
   means, such as a session protocol.

   Appendix B contains C source code for transforming the RTP/JPEG
   header parameters into the JPEG frame and scan headers that are
   absent from the data payload.

4.2.  The Q Field

   The quantization tables used in the decoding process are
   algorithmically derived from the Q field.  The algorithm used depends
   on the type field but only one algorithm is currently defined for the
   two types.

   Both type 0 and type 1 JPEG assume two quantizations tables.  These
   tables are chosen as follows.  For 1 <= Q <= 99, the Independent JPEG
   Group's formula [5] is used to produce a scale factor S as:

        S = 5000 / Q          for  1 <= Q <= 50
          = 200 - 2 * Q       for 51 <= Q <= 99

   This value is then used to scale Tables K.1 and K.2 from [1]
   (saturating each value to 8-bits) to give quantization table numbers
   0 and 1, respectively.  C source code is provided in Appendix A to
   compute these tables.

   For Q >= 100, a dynamically defined quantization table is used, which
   might be specified by a session setup protocol.  (This session
   protocol is beyond the scope of this document).  It is expected that
   the standard quantization tables will handle most cases in practice,
   and dynamic tables will be used rarely.  Q = 0 is reserved.






Berc, et. al.               Standards Track                     [Page 7]

RFC 2035           RTP Payload Format for JPEG Video        October 1996


4.3.  Fragmentation and Reassembly

   Since JPEG frames are large, they must often be fragmented.  Frames
   should be fragmented into packets in a manner avoiding fragmentation
   at a lower level.  When using restart markers, frames should be
   fragmented such that each packet starts with a restart interval (see
   below).

   Each packet that makes up a single frame has the same timestamp.  The
   fragment offset field is set to the byte offset of this packet within
   the original frame.  The RTP marker bit is set on the last packet in
   a frame.

   An entire frame can be identified as a sequence of packets beginning
   with a packet having a zero fragment offset and ending with a packet
   having the RTP marker bit set.  Missing packets can be detected
   either with RTP sequence numbers or with the fragment offset and
   lengths of each packet.  Reassembly could be carried out without the
   offset field (i.e., using only the RTP marker bit and sequence
   numbers), but an efficient single-copy implementation would not
   otherwise be possible in the presence of misordered packets.
   Moreover, if the last packet of the previous frame (containing the
   marker bit) were dropped, then a receiver could not detect that the
   current frame is entirely intact.

4.4.  Restart Markers

   Restart markers indicate a point in the JPEG stream at which the
   Huffman codec and DC predictors  are reset, allowing partial decoding
   starting at that point.  The use of restart markers allows for
   robustness in the face of packet loss.

   RTP/JPEG Types 4/5 allow for partial decode of frames, due to the
   alignment of restart intervals with RTP packets. The decoder knows it
   has a whole restart interval when it gets sequence of packets with
   contiguous RTP sequence numbers, starting with TSPEC<254 (RCOUNT) and
   either ending with TSPEC==255, or TSPEC<255 and next packet's
   TSPEC<254 (or end of frame).

   It can then decompress the RST interval, and paint it. The X and Y
   tile offsets of the first MCU in the interval are given by:

   tile_offset = RCOUNT * restart_interval * 2
   x_offset    = tile_offset % frame_width_in_tiles
   y_offset    = tile_offset / frame_width_in_tiles

   The MCUs in a restart interval may span multiple tile rows.




Berc, et. al.               Standards Track                     [Page 8]

RFC 2035           RTP Payload Format for JPEG Video        October 1996


   Decoders can, however, treat types 4/5 as types 2/3, simply
   reassembling the entire frame and then decoding.

5.  Security Considerations

   Security issues are not discussed in this memo.

6.  Authors' Addresses

   Lance M. Berc
   Systems Research Center
   Digital Equipment Corporation
   130 Lytton Ave
   Palo Alto CA 94301

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


   William C. Fenner
   Xerox PARC
   3333 Coyote Hill Road
   Palo Alto, CA 94304

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


   Ron Frederick
   Xerox PARC
   3333 Coyote Hill Road
   Palo Alto, CA 94304

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


   Steven McCanne
   Lawrence Berkeley Laboratory
   M/S 46A-1123
   One Cyclotron Road
   Berkeley, CA 94720

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






Berc, et. al.               Standards Track                     [Page 9]

RFC 2035           RTP Payload Format for JPEG Video        October 1996


7.  References

[1]  ISO DIS 10918-1. Digital Compression and Coding of Continuous-tone
     Still Images (JPEG), CCITT Recommendation T.81.

[2]  William B. Pennebaker, Joan L. Mitchell, JPEG: Still Image Data
     Compression Standard, Van Nostrand Reinhold, 1993.

[3]  Gregory K. Wallace, The JPEG Sill Picture Compression Standard,
     Communications of the ACM, April 1991, Vol 34, No. 1, pp. 31-44.

[4]  The JPEG File Interchange Format.  Maintained by C-Cube Microsys-
     tems, Inc., and available in
     ftp://ftp.uu.net/graphics/jpeg/jfif.ps.gz.

[5]  Tom Lane et. al., The Independent JPEG Group software JPEG codec.
     Source code available in
     ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v5.tar.gz.

































Berc, et. al.               Standards Track                    [Page 10]

RFC 2035           RTP Payload Format for JPEG Video        October 1996


Appendix A

   The following code can be used to create a quantization table from a
   Q factor:

/*
 * Table K.1 from JPEG spec.
 */
static const int jpeg_luma_quantizer[64] = {
        16, 11, 10, 16, 24, 40, 51, 61,
        12, 12, 14, 19, 26, 58, 60, 55,
        14, 13, 16, 24, 40, 57, 69, 56,
        14, 17, 22, 29, 51, 87, 80, 62,
        18, 22, 37, 56, 68, 109, 103, 77,
        24, 35, 55, 64, 81, 104, 113, 92,
        49, 64, 78, 87, 103, 121, 120, 101,
        72, 92, 95, 98, 112, 100, 103, 99
};

/*
 * Table K.2 from JPEG spec.
 */
static const int jpeg_chroma_quantizer[64] = {
        17, 18, 24, 47, 99, 99, 99, 99,
        18, 21, 26, 66, 99, 99, 99, 99,
        24, 26, 56, 99, 99, 99, 99, 99,
        47, 66, 99, 99, 99, 99, 99, 99,
        99, 99, 99, 99, 99, 99, 99, 99,
        99, 99, 99, 99, 99, 99, 99, 99,
        99, 99, 99, 99, 99, 99, 99, 99,
        99, 99, 99, 99, 99, 99, 99, 99
};

/*