home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 2000s / rfc2035.txt < prev    next >
Text File  |  1996-10-29  |  30KB  |  900 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            L. Berc
  8. Request for Comments: 2035                 Digital Equipment Corporation
  9. Category: Standards Track                                      W. Fenner
  10.                                                               Xerox PARC
  11.                                                             R. Frederick
  12.                                                               Xerox PARC
  13.                                                               S. McCanne
  14.                                             Lawrence Berkeley Laboratory
  15.                                                             October 1996
  16.  
  17.  
  18.               RTP Payload Format for JPEG-compressed Video
  19.  
  20. Status of this Memo
  21.  
  22.    This document specifies an Internet standards track protocol for the
  23.    Internet community, and requests discussion and suggestions for
  24.    improvements.  Please refer to the current edition of the "Internet
  25.    Official Protocol Standards" (STD 1) for the standardization state
  26.    and status of this protocol.  Distribution of this memo is unlimited.
  27.  
  28. Abstract
  29.  
  30.    This memo describes the RTP payload format for JPEG video streams.
  31.    The packet format is optimized for real-time video streams where
  32.    codec parameters change rarely from frame to frame.
  33.  
  34.    This document is a product of the Audio-Video Transport working group
  35.    within the Internet Engineering Task Force.  Comments are solicited
  36.    and should be addressed to the working group's mailing list at rem-
  37.    conf@es.net and/or the author(s).
  38.  
  39. 1.  Introduction
  40.  
  41.    The Joint Photographic Experts Group (JPEG) standard [1,2,3] defines
  42.    a family of compression algorithms for continuous-tone, still images.
  43.    This still image compression standard can be applied to video by
  44.    compressing each frame of video as an independent still image and
  45.    transmitting them in series.  Video coded in this fashion is often
  46.    called Motion-JPEG.
  47.  
  48.    We first give an overview of JPEG and then describe the specific
  49.    subset of JPEG that is supported in RTP and the mechanism by which
  50.    JPEG frames are carried as RTP payloads.
  51.  
  52.    The JPEG standard defines four modes of operation: the sequential DCT
  53.    mode, the progressive DCT mode, the lossless mode, and the
  54.    hierarchical mode.  Depending on the mode, the image is represented
  55.  
  56.  
  57.  
  58. Berc, et. al.               Standards Track                     [Page 1]
  59.  
  60. RFC 2035           RTP Payload Format for JPEG Video        October 1996
  61.  
  62.  
  63.    in one or more passes.  Each pass (called a frame in the JPEG
  64.    standard) is further broken down into one or more scans.  Within each
  65.    scan, there are one to four components,which represent the three
  66.    components of a color signal (e.g., "red, green, and blue", or a
  67.    luminance signal and two chromanince signals).  These components can
  68.    be encoded as separate scans or interleaved into a single scan.
  69.  
  70.    Each frame and scan is preceded with a header containing optional
  71.    definitions for compression parameters like quantization tables and
  72.    Huffman coding tables.  The headers and optional parameters are
  73.    identified with "markers" and comprise a marker segment; each scan
  74.    appears as an entropy-coded bit stream within two marker segments.
  75.    Markers are aligned to byte boundaries and (in general) cannot appear
  76.    in the entropy-coded segment, allowing scan boundaries to be
  77.    determined without parsing the bit stream.
  78.  
  79.    Compressed data is represented in one of three formats: the
  80.    interchange format, the abbreviated format, or the table-
  81.    specification format.  The interchange format contains definitions
  82.    for all the table used in the by the entropy-coded segments, while
  83.    the abbreviated format might omit some assuming they were defined
  84.    out-of-band or by a "previous" image.
  85.  
  86.    The JPEG standard does not define the meaning or format of the
  87.    components that comprise the image.  Attributes like the color space
  88.    and pixel aspect ratio must be specified out-of-band with respect to
  89.    the JPEG bit stream.  The JPEG File Interchange Format (JFIF) [4] is
  90.    a defacto standard that provides this extra information using an
  91.    application marker segment (APP0).  Note that a JFIF file is simply a
  92.    JPEG interchange format image along with the APP0 segment.  In the
  93.    case of video, additional parameters must be defined out-of-band
  94.    (e.g., frame rate, interlaced vs. non-interlaced, etc.).
  95.  
  96.    While the JPEG standard provides a rich set of algorithms for
  97.    flexible compression, cost-effective hardware implementations of the
  98.    full standard have not appeared.  Instead, most hardware JPEG video
  99.    codecs implement only a subset of the sequential DCT mode of
  100.    operation.  Typically, marker segments are interpreted in software
  101.    (which "re-programs" the hardware) and the hardware is presented with
  102.    a single, interleaved entropy-coded scan represented in the YUV color
  103.    space.
  104.  
  105. 2.  JPEG Over RTP
  106.  
  107.    To maximize interoperability among hardware-based codecs, we assume
  108.    the sequential DCT operating mode [1,Annex F] and restrict the set of
  109.    predefined RTP/JPEG "type codes" (defined below) to single-scan,
  110.    interleaved images.  While this is more restrictive than even
  111.  
  112.  
  113.  
  114. Berc, et. al.               Standards Track                     [Page 2]
  115.  
  116. RFC 2035           RTP Payload Format for JPEG Video        October 1996
  117.  
  118.  
  119.    baseline JPEG, many hardware implementation fall short of the
  120.    baseline specification (e.g., most hardware cannot decode non-
  121.    interleaved scans).
  122.  
  123.    In practice, most of the table-specification data rarely changes from
  124.    frame to frame within a single video stream.  Therefore, RTP/JPEG
  125.    data is represented in abbreviated format, with all of the tables
  126.    omitted from the bit stream.  Each image begins immediately with the
  127.    (single) entropy-coded scan.  The information that would otherwise be
  128.    in both the frame and scan headers is represented entirely within a
  129.    64-bit RTP/JPEG header (defined below) that lies between the RTP
  130.    header and the JPEG scan and is present in every packet.
  131.  
  132.    While parameters like Huffman tables and color space are likely to
  133.    remain fixed for the lifetime of the video stream, other parameters
  134.    should be allowed to vary, notably the quantization tables and image
  135.    size (e.g., to implement rate-adaptive transmission or allow a user
  136.    to adjust the "quality level" or resolution manually).  Thus explicit
  137.    fields in the RTP/JPEG header are allocated to represent this
  138.    information.  Since only a small set of quantization tables are
  139.    typically used, we encode the entire set of quantization tables in a
  140.    small integer field.  The image width and height are encoded
  141.    explicitly.
  142.  
  143.    Because JPEG frames are typically larger than the underlying
  144.    network's maximum packet size, frames must often be fragmented into
  145.    several packets.  One approach is to allow the network layer below
  146.    RTP (e.g., IP) to perform the fragmentation.  However, this precludes
  147.    rate-controlling the resulting packet stream or partial delivery in
  148.    the presence of loss.  For example, IP will not deliver a fragmented
  149.    datagram to the application if one or more fragments is lost, or IP
  150.    might fragment an 8000 byte frame into a burst of 8 back-to-back
  151.    packets.  Instead, RTP/JPEG defines a simple fragmentation and
  152.    reassembly scheme at the RTP level.
  153.  
  154. 3.  RTP/JPEG Packet Format
  155.  
  156.    The RTP timestamp is in units of 90000Hz.  The same timestamp must
  157.    appear across all fragments of a single frame.  The RTP marker bit is
  158.    set in the last packet of a frame.
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Berc, et. al.               Standards Track                     [Page 3]
  171.  
  172. RFC 2035           RTP Payload Format for JPEG Video        October 1996
  173.  
  174.  
  175. 3.1.  JPEG header
  176.  
  177.    A special header is added to each packet that immediately follows the
  178.    RTP header:
  179.  
  180.     0                   1                   2                   3
  181.     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
  182.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  183.    | Type specific |              Fragment Offset                  |
  184.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  185.    |      Type     |       Q       |     Width     |     Height    |
  186.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  187.  
  188. 3.1.1.  Type specific: 8 bits
  189.  
  190.    Interpretation depends on the value of the type field.
  191.  
  192. 3.1.2.  Fragment Offset: 24 bits
  193.  
  194.    The Fragment Offset is the data offset in bytes of the current packet
  195.    in the JPEG scan.
  196.  
  197. 3.1.3.  Type: 8 bits
  198.  
  199.    The type field specifies the information that would otherwise be
  200.    present in a JPEG abbreviated table-specification as well as the
  201.    additional JFIF-style parameters not defined by JPEG.  Types 0-127
  202.    are reserved as fixed, well-known mappings to be defined by this
  203.    document and future revisions of this document.  Types 128-255 are
  204.    free to be dynamically defined by a session setup protocol (which is
  205.    beyond the scope of this document).
  206.  
  207. 3.1.4.  Q: 8 bits
  208.  
  209.    The Q field defines the quantization tables for this frame using an
  210.    algorithm that determined by the Type field (see below).
  211.  
  212. 3.1.5.  Width: 8 bits
  213.  
  214.    This field encodes the width of the image in 8-pixel multiples (e.g.,
  215.    a width of 40 denotes an image 320 pixels wide).
  216.  
  217. 3.1.6.  Height: 8 bits
  218.  
  219.    This field encodes the height of the image in 8-pixel multiples
  220.    (e.g., a height of 30 denotes an image 240 pixels tall).
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Berc, et. al.               Standards Track                     [Page 4]
  227.  
  228. RFC 2035           RTP Payload Format for JPEG Video        October 1996
  229.  
  230.  
  231. 3.1.7.  Data
  232.  
  233.    The data following the RTP/JPEG header is an entropy-coded segment
  234.    consisting of a single scan.  The scan header is not present and is
  235.    inferred from the RTP/JPEG header.  The scan is terminated either
  236.    implicitly (i.e., the point at which the image is fully parsed), or
  237.    explicitly with an EOI marker.  The scan may be padded to arbitrary
  238.    length with undefined bytes.  (Existing hardware codecs generate
  239.    extra lines at the bottom of a video frame and removal of these lines
  240.    would require a Huffman-decoding pass over the data.)
  241.  
  242.    As defined by JPEG, restart markers are the only type of marker that
  243.    may appear embedded in the entropy-coded segment.  The "type code"
  244.    determines whether a restart interval is defined, and therefore
  245.    whether restart markers may be present. It also determines if the
  246.    restart intervals will be aligned with RTP packets, allowing for
  247.    partial decode of frames, thus increasing resiliance to packet drop.
  248.    If restart markers are present, the 6-byte DRI segment (define
  249.    restart interval marker [1, Sec. B.2.4.4] precedes the scan).
  250.  
  251.    JPEG markers appear explicitly on byte aligned boundaries beginning
  252.    with an 0xFF.  A "stuffed" 0x00 byte follows any 0xFF byte generated
  253.    by the entropy coder [1, Sec. B.1.1.5].
  254.  
  255. 4.  Discussion
  256.  
  257. 4.1.  The Type Field
  258.  
  259.    The Type field defines the abbreviated table-specification and
  260.    additional JFIF-style parameters not defined by JPEG, since they are
  261.    not present in the body of the transmitted JPEG data.  The Type field
  262.    must remain constant for the duration of a session.
  263.  
  264.    Six type codes are currently defined.  They correspond to an
  265.    abbreviated table-specification indicating the "Baseline DCT
  266.    sequential" mode, 8-bit samples, square pixels, three components in
  267.    the YUV color space, standard Huffman tables as defined in [1, Annex
  268.    K.3], and a single interleaved scan with a scan component selector
  269.    indicating components 0, 1, and 2 in that order.  The Y, U, and V
  270.    color planes correspond to component numbers 0, 1, and 2,
  271.    respectively.  Component 0 (i.e., the luminance plane) uses Huffman
  272.    table number 0 and quantization table number 0 (defined below) and
  273.    components 1 and 2 (i.e., the chrominance planes) use Huffman table
  274.    number 1 and quantization table number 1 (defined below).
  275.  
  276.    Additionally, video is non-interlaced and unscaled (i.e., the aspect
  277.    ratio is determined by the image width and height).  The frame rate
  278.    is variable and explicit via the RTP timestamp.
  279.  
  280.  
  281.  
  282. Berc, et. al.               Standards Track                     [Page 5]
  283.  
  284. RFC 2035           RTP Payload Format for JPEG Video        October 1996
  285.  
  286.  
  287.    Six RTP/JPEG types are currently defined that assume all of the
  288.    above.  The odd types have different JPEG sampling factors from the
  289.    even ones:
  290.  
  291.                         horizontal   vertical
  292.            types   comp  samp. fact. samp. fact.
  293.           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  294.           |  0/2/4  |  0  |     2     |   1   |
  295.           |  0/2/4  |  1  |     1     |   1   |
  296.           |  0/2/4  |  2  |     1     |   1   |
  297.           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  298.           |  1/3/5  |  0  |     2     |   2   |
  299.           |  1/3/5  |  1  |     1     |   1   |
  300.           |  1/3/5  |  2  |     1     |   1   |
  301.           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  302.  
  303.    These sampling factors indicate that the chromanince components of
  304.    type 0/2/4 video is downsampled horizontally by 2 (often called
  305.    4:2:2) while the chrominance components of type 1/3/5 video are
  306.    downsampled both horizontally and vertically by 2 (often called
  307.    4:2:0).
  308.  
  309.    The three pairs of types (0/1), (2/3) and (4/5) differ from each
  310.    other as follows:
  311.  
  312.    0/1 : No restart markers are present in the entropy data.
  313.          No restriction is placed on the fragmentation of the stream
  314.          into RTP packets.
  315.          The type specific field is unused and must be zero.
  316.  
  317.    2/3 : Restart markers are present in the entropy data.
  318.          The entropy data is preceded by a DRI marker segment, defining
  319.          the restart interval.
  320.          No restriction is placed on the fragmentation of the stream
  321.          into RTP packets.
  322.          The type specific field is unused and must be zero.
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Berc, et. al.               Standards Track                     [Page 6]
  339.  
  340. RFC 2035           RTP Payload Format for JPEG Video        October 1996
  341.  
  342.  
  343.    4/5 : Restart markers are present in the entropy data.
  344.          The entropy data is preceded by a DRI marker segment, defining
  345.          the restart interval.
  346.          Restart intervals are be sent as separate (possibly multiple)
  347.          RTP packets.
  348.          The type specific field (TSPEC) is used as follows:
  349.              A restart interval count (RCOUNT) is defined, which
  350.              starts at zero, and is incremented for each restart
  351.              interval in the frame.
  352.  
  353.              The first packet of a restart interval gets TSPEC = RCOUNT.
  354.              Subsequent packets of the restart interval get TSPEC = 254,
  355.              except the final packet, which gets TSPEC = 255.
  356.  
  357.    Additional types in the range 128-255 may be defined by external
  358.    means, such as a session protocol.
  359.  
  360.    Appendix B contains C source code for transforming the RTP/JPEG
  361.    header parameters into the JPEG frame and scan headers that are
  362.    absent from the data payload.
  363.  
  364. 4.2.  The Q Field
  365.  
  366.    The quantization tables used in the decoding process are
  367.    algorithmically derived from the Q field.  The algorithm used depends
  368.    on the type field but only one algorithm is currently defined for the
  369.    two types.
  370.  
  371.    Both type 0 and type 1 JPEG assume two quantizations tables.  These
  372.    tables are chosen as follows.  For 1 <= Q <= 99, the Independent JPEG
  373.    Group's formula [5] is used to produce a scale factor S as:
  374.  
  375.         S = 5000 / Q          for  1 <= Q <= 50
  376.           = 200 - 2 * Q       for 51 <= Q <= 99
  377.  
  378.    This value is then used to scale Tables K.1 and K.2 from [1]
  379.    (saturating each value to 8-bits) to give quantization table numbers
  380.    0 and 1, respectively.  C source code is provided in Appendix A to
  381.    compute these tables.
  382.  
  383.    For Q >= 100, a dynamically defined quantization table is used, which
  384.    might be specified by a session setup protocol.  (This session
  385.    protocol is beyond the scope of this document).  It is expected that
  386.    the standard quantization tables will handle most cases in practice,
  387.    and dynamic tables will be used rarely.  Q = 0 is reserved.
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Berc, et. al.               Standards Track                     [Page 7]
  395.  
  396. RFC 2035           RTP Payload Format for JPEG Video        October 1996
  397.  
  398.  
  399. 4.3.  Fragmentation and Reassembly
  400.  
  401.    Since JPEG frames are large, they must often be fragmented.  Frames
  402.    should be fragmented into packets in a manner avoiding fragmentation
  403.    at a lower level.  When using restart markers, frames should be
  404.    fragmented such that each packet starts with a restart interval (see
  405.    below).
  406.  
  407.    Each packet that makes up a single frame has the same timestamp.  The
  408.    fragment offset field is set to the byte offset of this packet within
  409.    the original frame.  The RTP marker bit is set on the last packet in
  410.    a frame.
  411.  
  412.    An entire frame can be identified as a sequence of packets beginning
  413.    with a packet having a zero fragment offset and ending with a packet
  414.    having the RTP marker bit set.  Missing packets can be detected
  415.    either with RTP sequence numbers or with the fragment offset and
  416.    lengths of each packet.  Reassembly could be carried out without the
  417.    offset field (i.e., using only the RTP marker bit and sequence
  418.    numbers), but an efficient single-copy implementation would not
  419.    otherwise be possible in the presence of misordered packets.
  420.    Moreover, if the last packet of the previous frame (containing the
  421.    marker bit) were dropped, then a receiver could not detect that the
  422.    current frame is entirely intact.
  423.  
  424. 4.4.  Restart Markers
  425.  
  426.    Restart markers indicate a point in the JPEG stream at which the
  427.    Huffman codec and DC predictors  are reset, allowing partial decoding
  428.    starting at that point.  The use of restart markers allows for
  429.    robustness in the face of packet loss.
  430.  
  431.    RTP/JPEG Types 4/5 allow for partial decode of frames, due to the
  432.    alignment of restart intervals with RTP packets. The decoder knows it
  433.    has a whole restart interval when it gets sequence of packets with
  434.    contiguous RTP sequence numbers, starting with TSPEC<254 (RCOUNT) and
  435.    either ending with TSPEC==255, or TSPEC<255 and next packet's
  436.    TSPEC<254 (or end of frame).
  437.  
  438.    It can then decompress the RST interval, and paint it. The X and Y
  439.    tile offsets of the first MCU in the interval are given by:
  440.  
  441.    tile_offset = RCOUNT * restart_interval * 2
  442.    x_offset    = tile_offset % frame_width_in_tiles
  443.    y_offset    = tile_offset / frame_width_in_tiles
  444.  
  445.    The MCUs in a restart interval may span multiple tile rows.
  446.  
  447.  
  448.  
  449.  
  450. Berc, et. al.               Standards Track                     [Page 8]
  451.  
  452. RFC 2035           RTP Payload Format for JPEG Video        October 1996
  453.  
  454.  
  455.    Decoders can, however, treat types 4/5 as types 2/3, simply
  456.    reassembling the entire frame and then decoding.
  457.  
  458. 5.  Security Considerations
  459.  
  460.    Security issues are not discussed in this memo.
  461.  
  462. 6.  Authors' Addresses
  463.  
  464.    Lance M. Berc
  465.    Systems Research Center
  466.    Digital Equipment Corporation
  467.    130 Lytton Ave
  468.    Palo Alto CA 94301
  469.  
  470.    Phone: +1 415 853 2100
  471.    EMail: berc@pa.dec.com
  472.  
  473.  
  474.    William C. Fenner
  475.    Xerox PARC
  476.    3333 Coyote Hill Road
  477.    Palo Alto, CA 94304
  478.  
  479.    Phone: +1 415 812 4816
  480.    EMail: fenner@cmf.nrl.navy.mil
  481.  
  482.  
  483.    Ron Frederick
  484.    Xerox PARC
  485.    3333 Coyote Hill Road
  486.    Palo Alto, CA 94304
  487.  
  488.    Phone: +1 415 812 4459
  489.    EMail: frederick@parc.xerox.com
  490.  
  491.  
  492.    Steven McCanne
  493.    Lawrence Berkeley Laboratory
  494.    M/S 46A-1123
  495.    One Cyclotron Road
  496.    Berkeley, CA 94720
  497.  
  498.    Phone: +1 510 486 7520
  499.    EMail: mccanne@ee.lbl.gov
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Berc, et. al.               Standards Track                     [Page 9]
  507.  
  508. RFC 2035           RTP Payload Format for JPEG Video        October 1996
  509.  
  510.  
  511. 7.  References
  512.  
  513. [1]  ISO DIS 10918-1. Digital Compression and Coding of Continuous-tone
  514.      Still Images (JPEG), CCITT Recommendation T.81.
  515.  
  516. [2]  William B. Pennebaker, Joan L. Mitchell, JPEG: Still Image Data
  517.      Compression Standard, Van Nostrand Reinhold, 1993.
  518.  
  519. [3]  Gregory K. Wallace, The JPEG Sill Picture Compression Standard,
  520.      Communications of the ACM, April 1991, Vol 34, No. 1, pp. 31-44.
  521.  
  522. [4]  The JPEG File Interchange Format.  Maintained by C-Cube Microsys-
  523.      tems, Inc., and available in
  524.      ftp://ftp.uu.net/graphics/jpeg/jfif.ps.gz.
  525.  
  526. [5]  Tom Lane et. al., The Independent JPEG Group software JPEG codec.
  527.      Source code available in
  528.      ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v5.tar.gz.
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Berc, et. al.               Standards Track                    [Page 10]
  563.  
  564. RFC 2035           RTP Payload Format for JPEG Video        October 1996
  565.  
  566.  
  567. Appendix A
  568.  
  569.    The following code can be used to create a quantization table from a
  570.    Q factor:
  571.  
  572. /*
  573.  * Table K.1 from JPEG spec.
  574.  */
  575. static const int jpeg_luma_quantizer[64] = {
  576.         16, 11, 10, 16, 24, 40, 51, 61,
  577.         12, 12, 14, 19, 26, 58, 60, 55,
  578.         14, 13, 16, 24, 40, 57, 69, 56,
  579.         14, 17, 22, 29, 51, 87, 80, 62,
  580.         18, 22, 37, 56, 68, 109, 103, 77,
  581.         24, 35, 55, 64, 81, 104, 113, 92,
  582.         49, 64, 78, 87, 103, 121, 120, 101,
  583.         72, 92, 95, 98, 112, 100, 103, 99
  584. };
  585.  
  586. /*
  587.  * Table K.2 from JPEG spec.
  588.  */
  589. static const int jpeg_chroma_quantizer[64] = {
  590.         17, 18, 24, 47, 99, 99, 99, 99,
  591.         18, 21, 26, 66, 99, 99, 99, 99,
  592.         24, 26, 56, 99, 99, 99, 99, 99,
  593.         47, 66, 99, 99, 99, 99, 99, 99,
  594.         99, 99, 99, 99, 99, 99, 99, 99,
  595.         99, 99, 99, 99, 99, 99, 99, 99,
  596.         99, 99, 99, 99, 99, 99, 99, 99,
  597.         99, 99, 99, 99, 99, 99, 99, 99
  598. };
  599.  
  600. /*
  601.  * Call MakeTables with the Q factor and two int[64] return arrays
  602.  */
  603. void
  604. MakeTables(int q, u_char *lum_q, u_char *chr_q)
  605. {
  606.   int i;
  607.   int factor = q;
  608.  
  609.   if (q < 1) factor = 1;
  610.   if (q > 99) factor = 99;
  611.   if (q < 50)
  612.     q = 5000 / factor;
  613.   else
  614.     q = 200 - factor*2;
  615.  
  616.  
  617.  
  618. Berc, et. al.               Standards Track                    [Page 11]
  619.  
  620. RFC 2035           RTP Payload Format for JPEG Video        October 1996
  621.  
  622.  
  623.   for (i=0; i < 64; i++) {
  624.     int lq = ( jpeg_luma_quantizer[i] * q + 50) / 100;
  625.     int cq = ( jpeg_chroma_quantizer[i] * q + 50) / 100;
  626.  
  627.     /* Limit the quantizers to 1 <= q <= 255 */
  628.     if ( lq < 1) lq = 1;
  629.     else if ( lq > 255) lq = 255;
  630.     lum_q[i] = lq;
  631.  
  632.     if ( cq < 1) cq = 1;
  633.     else if ( cq > 255) cq = 255;
  634.     chr_q[i] = cq;
  635.   }
  636. }
  637.  
  638. Appendix B
  639.  
  640.    The following routines can be used to create the JPEG marker segments
  641.    corresponding to the table-specification data that is absent from the
  642.    RTP/JPEG body.
  643.  
  644. u_char lum_dc_codelens[] = {
  645.         0, 1, 5, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0,
  646. };
  647.  
  648. u_char lum_dc_symbols[] = {
  649.         0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11,
  650. };
  651.  
  652. u_char lum_ac_codelens[] = {
  653.         0, 2, 1, 3, 3, 2, 4, 3, 5, 5, 4, 4, 0, 0, 1, 0x7d,
  654. };
  655.  
  656. u_char lum_ac_symbols[] = {
  657.         0x01, 0x02, 0x03, 0x00, 0x04, 0x11, 0x05, 0x12,
  658.         0x21, 0x31, 0x41, 0x06, 0x13, 0x51, 0x61, 0x07,
  659.         0x22, 0x71, 0x14, 0x32, 0x81, 0x91, 0xa1, 0x08,
  660.         0x23, 0x42, 0xb1, 0xc1, 0x15, 0x52, 0xd1, 0xf0,
  661.         0x24, 0x33, 0x62, 0x72, 0x82, 0x09, 0x0a, 0x16,
  662.         0x17, 0x18, 0x19, 0x1a, 0x25, 0x26, 0x27, 0x28,
  663.         0x29, 0x2a, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39,
  664.         0x3a, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49,
  665.         0x4a, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59,
  666.         0x5a, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69,
  667.         0x6a, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79,
  668.         0x7a, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89,
  669.         0x8a, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97, 0x98,
  670.         0x99, 0x9a, 0xa2, 0xa3, 0xa4, 0xa5, 0xa6, 0xa7,
  671.  
  672.  
  673.  
  674. Berc, et. al.               Standards Track                    [Page 12]
  675.  
  676. RFC 2035           RTP Payload Format for JPEG Video        October 1996
  677.  
  678.  
  679.         0xa8, 0xa9, 0xaa, 0xb2, 0xb3, 0xb4, 0xb5, 0xb6,
  680.         0xb7, 0xb8, 0xb9, 0xba, 0xc2, 0xc3, 0xc4, 0xc5,
  681.         0xc6, 0xc7, 0xc8, 0xc9, 0xca, 0xd2, 0xd3, 0xd4,
  682.         0xd5, 0xd6, 0xd7, 0xd8, 0xd9, 0xda, 0xe1, 0xe2,
  683.         0xe3, 0xe4, 0xe5, 0xe6, 0xe7, 0xe8, 0xe9, 0xea,
  684.         0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7, 0xf8,
  685.         0xf9, 0xfa,
  686. };
  687.  
  688. u_char chm_dc_codelens[] = {
  689.         0, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
  690. };
  691.  
  692. u_char chm_dc_symbols[] = {
  693.         0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11,
  694. };
  695.  
  696. u_char chm_ac_codelens[] = {
  697.         0, 2, 1, 2, 4, 4, 3, 4, 7, 5, 4, 4, 0, 1, 2, 0x77,
  698. };
  699.  
  700. u_char chm_ac_symbols[] = {
  701.         0x00, 0x01, 0x02, 0x03, 0x11, 0x04, 0x05, 0x21,
  702.         0x31, 0x06, 0x12, 0x41, 0x51, 0x07, 0x61, 0x71,
  703.         0x13, 0x22, 0x32, 0x81, 0x08, 0x14, 0x42, 0x91,
  704.         0xa1, 0xb1, 0xc1, 0x09, 0x23, 0x33, 0x52, 0xf0,
  705.         0x15, 0x62, 0x72, 0xd1, 0x0a, 0x16, 0x24, 0x34,
  706.         0xe1, 0x25, 0xf1, 0x17, 0x18, 0x19, 0x1a, 0x26,
  707.         0x27, 0x28, 0x29, 0x2a, 0x35, 0x36, 0x37, 0x38,
  708.         0x39, 0x3a, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48,
  709.         0x49, 0x4a, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58,
  710.         0x59, 0x5a, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68,
  711.         0x69, 0x6a, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78,
  712.         0x79, 0x7a, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87,
  713.         0x88, 0x89, 0x8a, 0x92, 0x93, 0x94, 0x95, 0x96,
  714.         0x97, 0x98, 0x99, 0x9a, 0xa2, 0xa3, 0xa4, 0xa5,
  715.         0xa6, 0xa7, 0xa8, 0xa9, 0xaa, 0xb2, 0xb3, 0xb4,
  716.         0xb5, 0xb6, 0xb7, 0xb8, 0xb9, 0xba, 0xc2, 0xc3,
  717.         0xc4, 0xc5, 0xc6, 0xc7, 0xc8, 0xc9, 0xca, 0xd2,
  718.         0xd3, 0xd4, 0xd5, 0xd6, 0xd7, 0xd8, 0xd9, 0xda,
  719.         0xe2, 0xe3, 0xe4, 0xe5, 0xe6, 0xe7, 0xe8, 0xe9,
  720.         0xea, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7, 0xf8,
  721.         0xf9, 0xfa,
  722. };
  723.  
  724. u_char *
  725. MakeQuantHeader(u_char *p, u_char *qt, int tableNo)
  726. {
  727.  
  728.  
  729.  
  730. Berc, et. al.               Standards Track                    [Page 13]
  731.  
  732. RFC 2035           RTP Payload Format for JPEG Video        October 1996
  733.  
  734.  
  735.         *p++ = 0xff;
  736.         *p++ = 0xdb;            /* DQT */
  737.         *p++ = 0;               /* length msb */
  738.         *p++ = 67;              /* length lsb */
  739.         *p++ = tableNo;
  740.         memcpy(p, qt, 64);
  741.         return (p + 64);
  742. }
  743.  
  744. u_char *
  745. MakeHuffmanHeader(u_char *p, u_char *codelens, int ncodes, u_char *symbols,
  746.                   int nsymbols, int tableNo, int tableClass)
  747. {
  748.         *p++ = 0xff;
  749.         *p++ = 0xc4;            /* DHT */
  750.         *p++ = 0;               /* length msb */
  751.         *p++ = 3 + ncodes + nsymbols; /* length lsb */
  752.         *p++ = tableClass << 4 | tableNo;
  753.         memcpy(p, codelens, ncodes);
  754.         p += ncodes;
  755.         memcpy(p, symbols, nsymbols);
  756.         p += nsymbols;
  757.         return (p);
  758. }
  759.  
  760. /*
  761.  * Given an RTP/JPEG type code, q factor, width, and height,
  762.  * generate a frame and scan headers that can be prepended
  763.  * to the RTP/JPEG data payload to produce a JPEG compressed
  764.  * image in interchange format (except for possible trailing
  765.  * garbage and absence of an EOI marker to terminate the scan).
  766.  */
  767. int MakeHeaders(u_char *p, int type, int q, int w, int h)
  768. {
  769.         u_char *start = p;
  770.         u_char lqt[64];
  771.         u_char cqt[64];
  772.  
  773.         /* convert from blocks to pixels */
  774.         w <<= 3;
  775.         h <<= 3;
  776.  
  777.         MakeTables(q, lqt, cqt);
  778.  
  779.         *p++ = 0xff;
  780.         *p++ = 0xd8;            /* SOI */
  781.  
  782.         p = MakeQuantHeader(p, lqt, 0);
  783.  
  784.  
  785.  
  786. Berc, et. al.               Standards Track                    [Page 14]
  787.  
  788. RFC 2035           RTP Payload Format for JPEG Video        October 1996
  789.  
  790.  
  791.         p = MakeQuantHeader(p, cqt, 1);
  792.  
  793.         p = MakeHuffmanHeader(p, lum_dc_codelens,
  794.                               sizeof(lum_dc_codelens),
  795.                               lum_dc_symbols,
  796.                               sizeof(lum_dc_symbols), 0, 0);
  797.         p = MakeHuffmanHeader(p, lum_ac_codelens,
  798.                               sizeof(lum_ac_codelens),
  799.                               lum_ac_symbols,
  800.                               sizeof(lum_ac_symbols), 0, 1);
  801.         p = MakeHuffmanHeader(p, chm_dc_codelens,
  802.                               sizeof(chm_dc_codelens),
  803.                               chm_dc_symbols,
  804.                               sizeof(chm_dc_symbols), 1, 0);
  805.         p = MakeHuffmanHeader(p, chm_ac_codelens,
  806.                               sizeof(chm_ac_codelens),
  807.                               chm_ac_symbols,
  808.                               sizeof(chm_ac_symbols), 1, 1);
  809.  
  810.         *p++ = 0xff;
  811.         *p++ = 0xc0;            /* SOF */
  812.         *p++ = 0;               /* length msb */
  813.         *p++ = 17;              /* length lsb */
  814.         *p++ = 8;               /* 8-bit precision */
  815.         *p++ = h >> 8;          /* height msb */
  816.         *p++ = h;               /* height lsb */
  817.         *p++ = w >> 8;          /* width msb */
  818.         *p++ = w;               /* wudth lsb */
  819.         *p++ = 3;               /* number of components */
  820.         *p++ = 0;               /* comp 0 */
  821.         if (type == 0)
  822.                 *p++ = 0x21;    /* hsamp = 2, vsamp = 1 */
  823.         else
  824.                 *p++ = 0x22;    /* hsamp = 2, vsamp = 2 */
  825.         *p++ = 0;               /* quant table 0 */
  826.         *p++ = 1;               /* comp 1 */
  827.         *p++ = 0x11;            /* hsamp = 1, vsamp = 1 */
  828.         *p++ = 1;               /* quant table 1 */
  829.         *p++ = 2;               /* comp 2 */
  830.         *p++ = 0x11;            /* hsamp = 1, vsamp = 1 */
  831.         *p++ = 1;               /* quant table 1 */
  832.  
  833.         *p++ = 0xff;
  834.         *p++ = 0xda;            /* SOS */
  835.         *p++ = 0;               /* length msb */
  836.         *p++ = 12;              /* length lsb */
  837.         *p++ = 3;               /* 3 components */
  838.         *p++ = 0;               /* comp 0 */
  839.  
  840.  
  841.  
  842. Berc, et. al.               Standards Track                    [Page 15]
  843.  
  844. RFC 2035           RTP Payload Format for JPEG Video        October 1996
  845.  
  846.  
  847.         *p++ = 0;               /* huffman table 0 */
  848.         *p++ = 1;               /* comp 1 */
  849.         *p++ = 0x11;            /* huffman table 1 */
  850.         *p++ = 2;               /* comp 2 */
  851.         *p++ = 0x11;            /* huffman table 1 */
  852.         *p++ = 0;               /* first DCT coeff */
  853.         *p++ = 63;              /* last DCT coeff */
  854.         *p++ = 0;               /* sucessive approx. */
  855.  
  856.         return (p - start);
  857. };
  858.  
  859.  
  860.  
  861.  
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Berc, et. al.               Standards Track                    [Page 16]
  899.  
  900.