RFC2035 日本語訳

Network Working Group                                            L. Berc
Request for Comments: 2035                 Digital Equipment Corporation
Category: Standards Track                                      W. Fenner
                                                              Xerox PARC
                                                            R. Frederick
                                                              Xerox PARC
                                                              S. McCanne
                                            Lawrence Berkeley Laboratory
                                                            October 1996

Bercがコメントのために要求するワーキンググループL.をネットワークでつないでください: 2035年のDECカテゴリ: 標準化過程W.フェナーゼロックスPARC R.フレディリックゼロックスPARC S.McCanneローレンスバークレイ研究所1996年10月

              RTP Payload Format for JPEG-compressed Video

JPEGによって圧縮されたビデオのためのRTP有効搭載量形式

Status of this Memo

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

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   This memo describes the RTP payload format for JPEG video streams.
   The packet format is optimized for real-time video streams where
   codec parameters change rarely from frame to frame.

このメモはJPEGビデオストリームのためにRTPペイロード形式について説明します。フレームによってコーデックパラメタがめったに変化しないところでパケット・フォーマットはリアルタイムのビデオストリームのために最適化されます。

   This document is a product of the Audio-Video Transport working group
   within the Internet Engineering Task Force.  Comments are solicited
   and should be addressed to the working group's mailing list at rem-
   conf@es.net and/or the author(s).

このドキュメントはインターネット・エンジニアリング・タスク・フォースの中のAudio-ビデオTransportワーキンググループの製品です。 コメントは、請求されて、レム conf@es.net 、そして/または、作者にワーキンググループのメーリングリストに記述されるべきです。

1.  Introduction

1. 序論

   The Joint Photographic Experts Group (JPEG) standard [1,2,3] defines
   a family of compression algorithms for continuous-tone, still images.
   This still image compression standard can be applied to video by
   compressing each frame of video as an independent still image and
   transmitting them in series.  Video coded in this fashion is often
   called Motion-JPEG.

ジェイペグ(JPEG)規格[1、2、3]はそれでも、連続したトーン、イメージのために圧縮アルゴリズムの家族を定義します。 独立している静止画像としてビデオの各フレームを圧縮して、連続的にそれらを伝えることによって、この静止画像圧縮規格をビデオに適用できます。 こんなやり方でコード化されたビデオはしばしばMotionJPEGと呼ばれます。

   We first give an overview of JPEG and then describe the specific
   subset of JPEG that is supported in RTP and the mechanism by which
   JPEG frames are carried as RTP payloads.

私たちは、最初に、JPEGの概観を与えて、次に、RTPでサポートされるJPEGの特定の部分集合とJPEGフレームがRTPペイロードとして運ばれるメカニズムについて説明します。

   The JPEG standard defines four modes of operation: the sequential DCT
   mode, the progressive DCT mode, the lossless mode, and the
   hierarchical mode.  Depending on the mode, the image is represented

JPEG規格は4つの運転モードを定義します: 連続したDCTモード、進歩的なDCTモード、losslessモード、および階層的なモード。 モードによって、イメージは表されます。

Berc, et. al.               Standards Track                     [Page 1]

RFC 2035           RTP Payload Format for JPEG Video        October 1996

et Berc、アル。 規格はビデオ1996年10月にJPEGのためにRFC2035RTP有効搭載量形式を追跡します[1ページ]。

   in one or more passes.  Each pass (called a frame in the JPEG
   standard) is further broken down into one or more scans.  Within each
   scan, there are one to four components,which represent the three
   components of a color signal (e.g., "red, green, and blue", or a
   luminance signal and two chromanince signals).  These components can
   be encoded as separate scans or interleaved into a single scan.

1個以上のパスで。 それぞれのパス(JPEGのフレームが標準であると言う)は1つ以上のスキャンへさらに砕けています。 各スキャンの中に、1〜4つのコンポーネントがあります。(コンポーネントはカラー信号(例えば、「緑色の、そして、青い赤」か、輝度信号と2つのchromanince信号)の3つの部品を表します)。 これらのコンポーネントを別々のスキャンとしてコード化するか、またはただ一つのスキャンにはさみ込むことができます。

   Each frame and scan is preceded with a header containing optional
   definitions for compression parameters like quantization tables and
   Huffman coding tables.  The headers and optional parameters are
   identified with "markers" and comprise a marker segment; each scan
   appears as an entropy-coded bit stream within two marker segments.
   Markers are aligned to byte boundaries and (in general) cannot appear
   in the entropy-coded segment, allowing scan boundaries to be
   determined without parsing the bit stream.

ヘッダーが量子化テーブルとハフマンコード化テーブルのような圧縮パラメタのための任意の定義を含んでいて、各フレームとスキャンは先行されています。 ヘッダーと任意のパラメタは、「マーカー」と同一視されていて、マーカーセグメントを含みます。 各スキャンはエントロピーでコード化されたビットストリームとして2つのマーカーセグメントの中に現れます。 マーカーは、バイト境界に並べられて、(一般に、)エントロピーでコード化されたセグメントに現れることができません、ビットストリームを分析しないでスキャン境界が決定しているのを許容して。

   Compressed data is represented in one of three formats: the
   interchange format, the abbreviated format, or the table-
   specification format.  The interchange format contains definitions
   for all the table used in the by the entropy-coded segments, while
   the abbreviated format might omit some assuming they were defined
   out-of-band or by a "previous" image.

圧縮されたデータは3つの形式の1つで表されます: 置き換え形式、簡略化された形式、またはテーブル仕様形式。 置き換え形式が中で使用されたすべてのテーブルのための定義を含んでいる、簡略化された形式は省略するかもしれませんが、エントロピーでコード化されたセグメントで、それらがバンドの外か「前」のイメージによって定義されたと仮定しながら、いくつかを省略してください。

   The JPEG standard does not define the meaning or format of the
   components that comprise the image.  Attributes like the color space
   and pixel aspect ratio must be specified out-of-band with respect to
   the JPEG bit stream.  The JPEG File Interchange Format (JFIF) [4] is
   a defacto standard that provides this extra information using an
   application marker segment (APP0).  Note that a JFIF file is simply a
   JPEG interchange format image along with the APP0 segment.  In the
   case of video, additional parameters must be defined out-of-band
   (e.g., frame rate, interlaced vs. non-interlaced, etc.).

JPEG規格はイメージを包括するコンポーネントの意味か書式を定義しません。 バンドの外でJPEGビットストリームに関して色のスペースとピクセルアスペクトのような属性を指定しなければなりません。 JPEG File Interchange Format(JFIF)[4]はアプリケーションマーカーセグメント(APP0)を使用することでこのその他の情報を提供する事実上の規格です。 JFIFファイルがAPP0セグメントと共に単にJPEG置き換え形式イメージであることに注意してください。 ビデオの場合では、バンドの外(例えば非交錯に対して交錯するフレームレートなど)で追加パラメタを定義しなければなりません。

   While the JPEG standard provides a rich set of algorithms for
   flexible compression, cost-effective hardware implementations of the
   full standard have not appeared.  Instead, most hardware JPEG video
   codecs implement only a subset of the sequential DCT mode of
   operation.  Typically, marker segments are interpreted in software
   (which "re-programs" the hardware) and the hardware is presented with
   a single, interleaved entropy-coded scan represented in the YUV color
   space.

JPEG規格がフレキシブルな圧縮のための豊かなセットのアルゴリズムを提供している間、完全な規格の費用対効果に優れたハードウェア実装は現れていません。 代わりに、ほとんどのハードウェアJPEGビデオコーデックが連続したDCT運転モードの部分集合だけを実行します。 通常、ソフトウェア(ハードウェアの「プログラムを変える」)でマーカーセグメントを解釈します、そして、YUV色のスペースに表された単一の、そして、はさみ込まれたエントロピーでコード化されたスキャンをハードウェアに与えます。

2.  JPEG Over RTP

2. RTPの上のJPEG

   To maximize interoperability among hardware-based codecs, we assume
   the sequential DCT operating mode [1,Annex F] and restrict the set of
   predefined RTP/JPEG "type codes" (defined below) to single-scan,
   interleaved images.  While this is more restrictive than even

私たちは、ハードウェアベースのコーデックの中で相互運用性を最大にするために、連続したDCTがオペレーティング・モード[1、Annex F]であると思って、事前に定義されたRTP/JPEG「タイプコード」(以下では、定義される)のセットをただ一つのスキャンであって、はさみ込まれたイメージに制限します。 これは同等であるというよりも制限していますが

Berc, et. al.               Standards Track                     [Page 2]

RFC 2035           RTP Payload Format for JPEG Video        October 1996

et Berc、アル。 規格はビデオ1996年10月にJPEGのためにRFC2035RTP有効搭載量形式を追跡します[2ページ]。

   baseline JPEG, many hardware implementation fall short of the
   baseline specification (e.g., most hardware cannot decode non-
   interleaved scans).

基線JPEG、多くのハードウェア実装がベースライン仕様書より下回っています(例えば、ほとんどのハードウェアは非はさみ込まれたスキャンを解読できません)。

   In practice, most of the table-specification data rarely changes from
   frame to frame within a single video stream.  Therefore, RTP/JPEG
   data is represented in abbreviated format, with all of the tables
   omitted from the bit stream.  Each image begins immediately with the
   (single) entropy-coded scan.  The information that would otherwise be
   in both the frame and scan headers is represented entirely within a
   64-bit RTP/JPEG header (defined below) that lies between the RTP
   header and the JPEG scan and is present in every packet.

実際には、フレームによって仕様を見送っているデータの大部分はただ一つのビデオストリームの中でめったに変化しません。 したがって、テーブルのすべてがビットストリームから省略されている状態で、RTP/JPEGデータは簡略化された形式で表されます。 各イメージはすぐ(単一)のエントロピーでコード化されたスキャンで始まります。 そうでなければフレームとスキャンヘッダーの両方にある情報は、完全にRTPヘッダーとJPEGの間の偽りがスキャンする64ビットのRTP/JPEGヘッダー(以下では、定義される)の中に表されて、あらゆるパケットに存在しています。

   While parameters like Huffman tables and color space are likely to
   remain fixed for the lifetime of the video stream, other parameters
   should be allowed to vary, notably the quantization tables and image
   size (e.g., to implement rate-adaptive transmission or allow a user
   to adjust the "quality level" or resolution manually).  Thus explicit
   fields in the RTP/JPEG header are allocated to represent this
   information.  Since only a small set of quantization tables are
   typically used, we encode the entire set of quantization tables in a
   small integer field.  The image width and height are encoded
   explicitly.

ハフマンテーブルと色のスペースのようなパラメタがビデオストリームの生涯に修理されたままで残っていそうな間、他のパラメタが異なることができるべきであって、著しく量子化は、テーブルと画像寸法(例えば、レート適応型のトランスミッションを実行するか、またはユーザが手動で「品質水準」か解決を調整するのを許容する)です。 したがって、この情報を表すためにRTP/JPEGヘッダーの明白な野原を割り当てます。 小さいセットの量子化テーブルだけが通常使用されるので、私たちは小さい整数分野で全体のセットの量子化テーブルをコード化します。 イメージ幅と高さは明らかにコード化されます。

   Because JPEG frames are typically larger than the underlying
   network's maximum packet size, frames must often be fragmented into
   several packets.  One approach is to allow the network layer below
   RTP (e.g., IP) to perform the fragmentation.  However, this precludes
   rate-controlling the resulting packet stream or partial delivery in
   the presence of loss.  For example, IP will not deliver a fragmented
   datagram to the application if one or more fragments is lost, or IP
   might fragment an 8000 byte frame into a burst of 8 back-to-back
   packets.  Instead, RTP/JPEG defines a simple fragmentation and
   reassembly scheme at the RTP level.

JPEGフレームが基本的なネットワークの最大のパケット規模より通常大きいので、しばしばいくつかのパケットにフレームを断片化しなければなりません。 1つのアプローチはRTP(例えば、IP)の下のネットワーク層が断片化を実行するのを許容することです。 しかしながら、これは、損失の面前で結果として起こるパケットの流れか一部受け渡しをレートで制御するのを排除します。 例えば、1個以上の断片が無くなるなら、IPが断片化しているデータグラムをアプリケーションに届けないだろうか、またはIPは8000年のバイトのフレームを8つの背中合わせのパケットの炸裂に断片化するかもしれません。 代わりに、RTP/JPEGはRTPレベルで簡単な断片化と再アセンブリ計画を定義します。

3.  RTP/JPEG Packet Format

3. RTP/JPEGパケット・フォーマット

   The RTP timestamp is in units of 90000Hz.  The same timestamp must
   appear across all fragments of a single frame.  The RTP marker bit is
   set in the last packet of a frame.

RTPタイムスタンプが90000Hzのユニットにあります。 同じタイムスタンプはシングルフレームのすべての断片の向こう側に現れなければなりません。 RTPマーカービットはフレームの最後のパケットに設定されます。

Berc, et. al.               Standards Track                     [Page 3]

RFC 2035           RTP Payload Format for JPEG Video        October 1996

et Berc、アル。 規格はビデオ1996年10月にJPEGのためにRFC2035RTP有効搭載量形式を追跡します[3ページ]。

3.1.  JPEG header

3.1. JPEGヘッダー

   A special header is added to each packet that immediately follows the
   RTP header:

特別なヘッダーはすぐにRTPヘッダーに続く各パケットに加えられます:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type specific |              Fragment Offset                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |       Q       |     Width     |     Height    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ特有です。| 断片オフセット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| Q| 幅| 高さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1.1.  Type specific: 8 bits

3.1.1. タイプ特有: 8ビット

   Interpretation depends on the value of the type field.

解釈はタイプ分野の値に依存します。

3.1.2.  Fragment Offset: 24 bits

3.1.2. 断片は相殺されました: 24ビット

   The Fragment Offset is the data offset in bytes of the current packet
   in the JPEG scan.

Fragment OffsetはJPEGスキャンにおける、現在のパケットのバイトで相殺されたデータです。

3.1.3.  Type: 8 bits

3.1.3. 以下をタイプしてください。 8ビット

   The type field specifies the information that would otherwise be
   present in a JPEG abbreviated table-specification as well as the
   additional JFIF-style parameters not defined by JPEG.  Types 0-127
   are reserved as fixed, well-known mappings to be defined by this
   document and future revisions of this document.  Types 128-255 are
   free to be dynamically defined by a session setup protocol (which is
   beyond the scope of this document).

タイプ分野はJPEGによって定義されなかった追加JFIF-スタイルパラメタと同様にそうでなければ、JPEGでのプレゼントがテーブル仕様を簡略化したということである情報を指定します。 タイプ0-127は、このドキュメントのこのドキュメントと今後の改正で定義されるために修理されて、周知のマッピングとして予約されます。 セッションセットアッププロトコル(このドキュメントの範囲にある)でタイプ128-255は無料でダイナミックに定義できます。

3.1.4.  Q: 8 bits

3.1.4. Q: 8ビット

   The Q field defines the quantization tables for this frame using an
   algorithm that determined by the Type field (see below).

Q分野は、Type分野のそばでそんなに決定しているアルゴリズムを使用することで量子化テーブルをこのフレームと定義します(以下を見てください)。

3.1.5.  Width: 8 bits

3.1.5. 幅: 8ビット

   This field encodes the width of the image in 8-pixel multiples (e.g.,
   a width of 40 denotes an image 320 pixels wide).

この分野は8画素の倍数における、イメージの幅をコード化します(例えば、40の幅は320幅画素のイメージを指示します)。

3.1.6.  Height: 8 bits

3.1.6. 高さ: 8ビット

   This field encodes the height of the image in 8-pixel multiples
   (e.g., a height of 30 denotes an image 240 pixels tall).

この分野は8画素の倍数における、イメージの高さをコード化します(例えば、30の高さは240高さ画素のイメージを指示します)。

Berc, et. al.               Standards Track                     [Page 4]

RFC 2035           RTP Payload Format for JPEG Video        October 1996

et Berc、アル。 規格はビデオ1996年10月にJPEGのためにRFC2035RTP有効搭載量形式を追跡します[4ページ]。

3.1.7.  Data

3.1.7. データ

   The data following the RTP/JPEG header is an entropy-coded segment
   consisting of a single scan.  The scan header is not present and is
   inferred from the RTP/JPEG header.  The scan is terminated either
   implicitly (i.e., the point at which the image is fully parsed), or
   explicitly with an EOI marker.  The scan may be padded to arbitrary
   length with undefined bytes.  (Existing hardware codecs generate
   extra lines at the bottom of a video frame and removal of these lines
   would require a Huffman-decoding pass over the data.)

RTP/JPEGヘッダーに続くデータはただ一つのスキャンから成るエントロピーでコード化されたセグメントです。 スキャンヘッダーは、存在していなくて、RTP/JPEGヘッダーから推論されます。 スキャンはEOIマーカーでそれとなく(すなわち、イメージが完全に分析されるポイント)明らかに終えられます。 スキャンは未定義のバイトがある任意の長さに水増しされるかもしれません。 (既存のハードウェアコーデックはビデオフレームの下部で余分な線を発生させて、これらの線の取り外しはデータに関してハフマン-解読パスを必要とするでしょう。)

   As defined by JPEG, restart markers are the only type of marker that
   may appear embedded in the entropy-coded segment.  The "type code"
   determines whether a restart interval is defined, and therefore
   whether restart markers may be present. It also determines if the
   restart intervals will be aligned with RTP packets, allowing for
   partial decode of frames, thus increasing resiliance to packet drop.
   If restart markers are present, the 6-byte DRI segment (define
   restart interval marker [1, Sec. B.2.4.4] precedes the scan).

JPEGによって定義されるように、再開マーカーはエントロピーでコード化されたセグメントに埋め込まれているように見えるかもしれない唯一のタイプの採点者です。 「タイプコード」は再開間隔が定義されるかどうかと、したがって、再開マーカーに出席しているかもしれないかどうか決定します。 また、それは、再開間隔がRTPパケットに並べられるかどうか決定します、パケット滴への部分的なフレームを解読している、その結果、増加するresilianceを考慮して。 再開マーカーがプレゼント、6バイトのDRIセグメントであるなら(再開間隔マーカーを定義してください。[1、秒 B.2.4.4] 先行、スキャン)

   JPEG markers appear explicitly on byte aligned boundaries beginning
   with an 0xFF.  A "stuffed" 0x00 byte follows any 0xFF byte generated
   by the entropy coder [1, Sec. B.1.1.5].

JPEGマーカーは、0xFFと共に始まりながら、バイトの並べられた境界に明らかに現れます。 「詰められた」0×00バイトはエントロピー符号化器で発生するどんな0xFFバイトにも続きます。[1、秒 B.1.1.5].

4.  Discussion

4. 議論

4.1.  The Type Field

4.1. タイプ分野

   The Type field defines the abbreviated table-specification and
   additional JFIF-style parameters not defined by JPEG, since they are
   not present in the body of the transmitted JPEG data.  The Type field
   must remain constant for the duration of a session.

Type分野はJPEGによって定義されなかった簡略化されたテーブル仕様と追加JFIF-スタイルパラメタを定義します、それらが伝えられたJPEGデータのボディーに存在していないので。 Type分野はセッションの持続時間に一定のままで残らなければなりません。

   Six type codes are currently defined.  They correspond to an
   abbreviated table-specification indicating the "Baseline DCT
   sequential" mode, 8-bit samples, square pixels, three components in
   the YUV color space, standard Huffman tables as defined in [1, Annex
   K.3], and a single interleaved scan with a scan component selector
   indicating components 0, 1, and 2 in that order.  The Y, U, and V
   color planes correspond to component numbers 0, 1, and 2,
   respectively.  Component 0 (i.e., the luminance plane) uses Huffman
   table number 0 and quantization table number 0 (defined below) and
   components 1 and 2 (i.e., the chrominance planes) use Huffman table
   number 1 and quantization table number 1 (defined below).

6つのタイプコードが現在、定義されます。 彼らは、「基線DCT連続した」モード、8ビットのサンプル、正方形の画素、YUV色のスペースの3つのコンポーネント、[1、Annex K.3]で定義される、標準のハフマンテーブル、およびスキャンコンポーネントセレクタがそのオーダーでコンポーネント0、1、および2を示しているただ一つのはさみ込まれたスキャンを示しながら、簡略化されたテーブル仕様に対応します。 Y、U、およびVカラー飛行機はそれぞれコンポーネントNo.0、1、および2に対応しています。 コンポーネント0(すなわち、輝度飛行機)はハフマン表番号0と量子化表番号0(以下では、定義されます)を使用します、そして、コンポーネント1と2(すなわち、色差飛行機)はハフマン表番号1と量子化表番号1(以下では、定義されます)を使用します。

   Additionally, video is non-interlaced and unscaled (i.e., the aspect
   ratio is determined by the image width and height).  The frame rate
   is variable and explicit via the RTP timestamp.

さらに、ビデオは、非交錯して非スケーリングされています(イメージ幅と高さに従って、すなわち、アスペクトレシオは決定しています)。 フレームレートは、RTPタイムスタンプで可変であって、明白です。

Berc, et. al.               Standards Track                     [Page 5]

RFC 2035           RTP Payload Format for JPEG Video        October 1996

et Berc、アル。 規格はビデオ1996年10月にJPEGのためにRFC2035RTP有効搭載量形式を追跡します[5ページ]。

   Six RTP/JPEG types are currently defined that assume all of the
   above.  The odd types have different JPEG sampling factors from the
   even ones:

上記のすべてを仮定する6つのRTP/JPEGタイプが現在、定義されます。 変なタイプは異なったJPEGに同等のものからの要素を抽出させます:

                        horizontal   vertical
           types   comp  samp. fact. samp. fact.
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |  0/2/4  |  0  |     2     |   1   |
          |  0/2/4  |  1  |     1     |   1   |
          |  0/2/4  |  2  |     1     |   1   |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |  1/3/5  |  0  |     2     |   2   |
          |  1/3/5  |  1  |     1     |   1   |
          |  1/3/5  |  2  |     1     |   1   |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

水平な立形コンピュータ挽き割りトウモロコシ事実挽き割りトウモロコシ事実。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0/2/4 | 0 | 2 | 1 | | 0/2/4 | 1 | 1 | 1 | | 0/2/4 | 2 | 1 | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1/3/5 | 0 | 2 | 2 | | 1/3/5 | 1 | 1 | 1 | | 1/3/5 | 2 | 1 | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

これらの標本抽出要素は、タイプ1/3/5のビデオの色差成分が2(しばしば4:2:0と呼ぶ)時までに水平に垂直にdownsampledされますが、2(しばしば4:2:2と呼ぶ)時までにタイプ0/2/4のビデオのchromaninceの部品が水平にdownsampledされるのを示します。

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

3組のタイプ(0/1)、(2/3)、および(4/5)は以下の通り互いに異なっています:

   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.

0/1 : どんな再開マーカーもエントロピーデータに出席していません。 制限は全くRTPパケットへの流れの断片化に関して課されません。 タイプの特定の分野は、未使用であり、ゼロであるに違いありません。

   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.

2/3 : 再開マーカーはエントロピーデータに出席しています。 再開間隔を定義して、DRIマーカーセグメントはエントロピーデータに先行します。 制限は全くRTPパケットへの流れの断片化に関して課されません。 タイプの特定の分野は、未使用であり、ゼロであるに違いありません。

Berc, et. al.               Standards Track                     [Page 6]

RFC 2035           RTP Payload Format for JPEG Video        October 1996

et Berc、アル。 規格はビデオ1996年10月にJPEGのためにRFC2035RTP有効搭載量形式を追跡します[6ページ]。

   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.

4/5 : 再開マーカーはエントロピーデータに出席しています。 再開間隔を定義して、DRIマーカーセグメントはエントロピーデータに先行します。 再開間隔はそうです。別々(ことによると複数の)のRTPパケットとして、送ってください。 タイプの特定の分野(TSPEC)は以下の通り使用されます: 再開間隔カウント(RCOUNT)は、定義されます。(それは、ゼロから出発して、それぞれの再開間隔の間、フレームで増加されます)。

             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.

再開間隔の最初のパケットはTSPEC=RCOUNTを手に入れます。 最終的なパケットを除いて、再開間隔のその後のパケットはTSPEC=254を得ます。(それは、TSPEC=255を得ます)。

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

範囲128-255の追加タイプはセッションプロトコルなどの外部の手段で定義されるかもしれません。

   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.

付録BはRTP/JPEGヘッダーパラメタをデータペイロードから欠けているJPEGフレームとスキャンヘッダーに変えるためのCソースコードを含んでいます。

4.2.  The Q Field

4.2. Q分野

   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.

Q分野から解読過程で使用される量子化テーブルをalgorithmicallyに得ます。 使用されるアルゴリズムはタイプフィールドによりますが、1つのアルゴリズムだけが現在、2つのタイプのために定義されます。

   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:

両方が0をタイプします、そして、タイプ1JPEGが2つの量子化がテーブルであると仮定します。 これらのテーブルは以下の通り選ばれています。 Q<1<==99に関しては、無党派JPEG Groupの公式[5]は、以下として位取り因数Sを生産するのに使用されます。

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

SはQ<1<==50 = 200のための5000/Qと等しいです--51<のための2*Qは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.

そして、この値は、量子化表番号0と1を与えるために[1](各値を8ビットに飽和状態にする)からTables K.1とK.2をそれぞれスケーリングするのに使用されます。 これらのテーブルを計算するためにCソースコードをAppendix Aに提供します。

   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.

Q>=100に関しては、ダイナミックに定義された量子化テーブルは使用されています(セッションセットアッププロトコルによって指定されるかもしれません)。 (このセッションプロトコルはこのドキュメントの範囲を超えています。) 標準の量子化テーブルが実際にはほとんどのケースを扱うと予想されて、ダイナミックなテーブルはめったに使用されないでしょう。 Q=0は予約されています。

Berc, et. al.               Standards Track                     [Page 7]

RFC 2035           RTP Payload Format for JPEG Video        October 1996

et Berc、アル。 規格はビデオ1996年10月にJPEGのためにRFC2035RTP有効搭載量形式を追跡します[7ページ]。

4.3.  Fragmentation and Reassembly

4.3. 断片化と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).

JPEGフレームが大きいので、しばしばそれらを断片化しなければなりません。 フレームは下のレベルで断片化を避ける方法でパケットに断片化されるべきです。 再開マーカーを使用するとき、フレームが断片化されるべきであるので、各パケットは再開間隔から始めます(以下を見てください)。

   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.

シングルフレームを作る各パケットが同じタイムスタンプを持っています。 断片オフセット分野はオリジナルのフレームの中にこのパケットのバイトオフセットに設定されます。 RTPマーカービットはフレームにおける最後のパケットの上に設定されます。

   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.

ゼロがRTPマーカービットを持っているパケットと共に相殺されて、終わりながら断片化するパケットと共に始まるパケットの系列がセットしたので、全体のフレームを特定できます。 RTP一連番号か断片オフセットとそれぞれのパケットの長さでなくなったパケットを検出できます。 オフセット分野(すなわち、RTPマーカービットだけを使用して、一連番号)なしでReassemblyを行うことができましたが、効率的なただ一つのコピー実現はそうでなければ、misorderedパケットがあるとき可能でないでしょう。 そのうえ、受信機が検出できなかった電流が縁どるその時は前のフレーム(マーカービットを含んでいる)の最後のパケットが低下したなら完全に完全です。

4.4.  Restart Markers

4.4. 再開マーカー

   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.

再開マーカーはハフマンコーデックとDC予言者がリセットされるJPEGの流れでポイントを示します、その時から部分的な解読を許して。 再開マーカーの使用はパケット損失に直面して丈夫さを考慮します。

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

RTP/JPEG Types4/5が考慮する、部分的である、RTPパケットがある再開間隔の整列のためフレームを解読してください。 デコーダは、隣接のRTP一連番号と共にパケットの系列を得る全体の再開間隔を過すのを知っています、TSPEC<254(RCOUNT)から始まって、TSPEC==255か、TSPEC<255と次のパケットのTSPEC<254(または、フレームの端)で終わって。

   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:

それは、次に、RST間隔を減圧して、それを塗装できます。 以下は間隔での最初のMCUのXとYタイルオフセットを与えます。

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

_のタイル_オフセット=RCOUNT*再開_間隔*2x_オフセット=タイル_オフセット%フレーム_幅の_は_タイルでy_オフセット=タイル_オフセット/フレーム_幅の_にタイルを張ります。

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

再開間隔のMCUsは集合タイル列にかかるかもしれません。

Berc, et. al.               Standards Track                     [Page 8]

RFC 2035           RTP Payload Format for JPEG Video        October 1996

et Berc、アル。 規格はビデオ1996年10月にJPEGのためにRFC2035RTP有効搭載量形式を追跡します[8ページ]。

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

しかしながら、単に全体のフレームを組み立て直して、次に、解読を組み立て直して、デコーダはタイプ2/3としてタイプ4/5を扱うことができます。

5.  Security Considerations

5. セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

6.  Authors' Addresses

6. 作者のアドレス

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

槍のM.Berc SystemsリサーチセンターDEC130リットンAveパロアルトカリフォルニア 94301

   Phone: +1 415 853 2100
   EMail: berc@pa.dec.com

以下に電話をしてください。 +1 2100年の415 853メール: berc@pa.dec.com

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

ウィリアムC.フェナーゼロックスPARC3333コヨーテヒル・Roadパロアルト、カリフォルニア 94304

   Phone: +1 415 812 4816
   EMail: fenner@cmf.nrl.navy.mil

以下に電話をしてください。 +1 4816年の415 812メール: fenner@cmf.nrl.navy.mil

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

ロンフレディリックゼロックスPARC3333コヨーテヒル・Roadパロアルト、カリフォルニア 94304

   Phone: +1 415 812 4459
   EMail: frederick@parc.xerox.com

以下に電話をしてください。 +1 4459年の415 812メール: frederick@parc.xerox.com

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

Roadバークレー、スティーブンMcCanneローレンスバークレイ研究所M/S46A-1123 1Cyclotronカリフォルニア 94720

   Phone: +1 510 486 7520
   EMail: mccanne@ee.lbl.gov

以下に電話をしてください。 +1 7520年の510 486メール: mccanne@ee.lbl.gov

Berc, et. al.               Standards Track                     [Page 9]

RFC 2035           RTP Payload Format for JPEG Video        October 1996

et Berc、アル。 規格はビデオ1996年10月にJPEGのためにRFC2035RTP有効搭載量形式を追跡します[9ページ]。

7.  References

7. 参照

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

[1] ISOは10918-1をけなします。 指圧と連続したトーン静止画像(JPEG)のコード化、CCITT推薦T.81。

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

[2] ウィリアム・B.ペネベーカー、ジョーン・L.ミッチェル、JPEG: 標準の静止画像データ圧縮バンNostrandラインホルト、1993。

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

[3] グレゴリー・K.ウォレス、JPEG Sill Picture Compression Standard、ACMのCommunications、1991年4月、Vol34、No.1、ページ 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.

[4] JPEGは置き換え形式をファイルします。 シーキューブMicrosys- tems Inc.によって維持されていて、 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.

[5]トムレインetアル、無党派JPEG GroupソフトウェアJPEGコーデック 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

et Berc、アル。 規格はビデオ1996年10月にJPEGのためにRFC2035RTP有効搭載量形式を追跡します[10ページ]。

Appendix A

付録A

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

Q要素から量子化テーブルを作成するのに以下のコードを使用できます:

/*
 * 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
};

JPEG仕様からの/**テーブルK.1。 *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、/静的なconst int jpeg_luma_量子化器[64]=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
};

JPEG仕様からの/**テーブルK.2。 *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、/静的なconst int jpeg_彩度_量子化器[64]=99。

/*
 * Call MakeTables with the Q factor and two int[64] return arrays
 */
void
MakeTables(int q, u_char *lum_q, u_char *chr_q)
{
  int i;
  int factor = q;

Q要素がある/**呼び出しMakeTablesと2int[64]がアレイ*/空間MakeTablesを返す、(int q、u_炭の*ラム_q、u_炭の*は_qをchrします)int i(int要素=q)

  if (q < 1) factor = 1;
  if (q > 99) factor = 99;
  if (q < 50)
    q = 5000 / factor;
  else
    q = 200 - factor*2;

(q<1)が=1を因数分解するなら。 (q>99)が=99を因数分解するなら。 (q<50)qが5000/要素と等しいなら。 ほかのq=200--*2を因数分解してください。

Berc, et. al.               Standards Track                    [Page 11]

RFC 2035           RTP Payload Format for JPEG Video        October 1996

et Berc、アル。 規格はビデオ1996年10月にJPEGのためにRFC2035RTP有効搭載量形式を追跡します[11ページ]。

  for (i=0; i < 64; i++) {
    int lq = ( jpeg_luma_quantizer[i] * q + 50) / 100;
    int cq = ( jpeg_chroma_quantizer[i] * q + 50) / 100;

(i=0; i<64; i++)、int lq=(jpeg_luma_量子化器[i]*q+50)/100(int cq=(_彩度_量子化器[i]*q+50をjpegします)/100)

    /* Limit the quantizers to 1 <= q <= 255 */
    if ( lq < 1) lq = 1;
    else if ( lq > 255) lq = 255;
    lum_q[i] = lq;

/*限界q1<への量子化器=<は(lq<1)lq=1であるなら255*/と等しいです。 ほかに、(lq>255)であるなら、lqは255と等しいです。 ラム_q[i]はlqと等しいです。

    if ( cq < 1) cq = 1;
    else if ( cq > 255) cq = 255;
    chr_q[i] = cq;
  }
}

(cq<1)cq=1であるなら。 ほかに、(cq>255)であるなら、cqは255と等しいです。 chr_q[i]はcqと等しいです。 } }

Appendix B

付録B

   The following routines can be used to create the JPEG marker segments
   corresponding to the table-specification data that is absent from the
   RTP/JPEG body.

RTP/JPEGボディーから欠けているテーブル仕様データに対応するJPEGマーカーセグメントを作成するのに以下のルーチンを使用できます。

u_char lum_dc_codelens[] = {
        0, 1, 5, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0,
};

0、1、5、1、1、1、1、1、1、0、0、0、0、0、0、u_炭のラム_dc_codelens[]=0。

u_char lum_dc_symbols[] = {
        0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11,
};

0、1、2、3、4、5、6、7、8、9、10、u_炭のラム_dc_シンボル[]=11。

u_char lum_ac_codelens[] = {
        0, 2, 1, 3, 3, 2, 4, 3, 5, 5, 4, 4, 0, 0, 1, 0x7d,
};

u_炭のラム_ac_codelens[]は0、2、1、3、3、2、4、3、5、5、4、4、0、0、1、0x7dと等しいです。

u_char lum_ac_symbols[] = {
        0x01, 0x02, 0x03, 0x00, 0x04, 0x11, 0x05, 0x12,
        0x21, 0x31, 0x41, 0x06, 0x13, 0x51, 0x61, 0x07,
        0x22, 0x71, 0x14, 0x32, 0x81, 0x91, 0xa1, 0x08,
        0x23, 0x42, 0xb1, 0xc1, 0x15, 0x52, 0xd1, 0xf0,
        0x24, 0x33, 0x62, 0x72, 0x82, 0x09, 0x0a, 0x16,
        0x17, 0x18, 0x19, 0x1a, 0x25, 0x26, 0x27, 0x28,
        0x29, 0x2a, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39,
        0x3a, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49,
        0x4a, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59,
        0x5a, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69,
        0x6a, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79,
        0x7a, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89,
        0x8a, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97, 0x98,
        0x99, 0x9a, 0xa2, 0xa3, 0xa4, 0xa5, 0xa6, 0xa7,

u_炭のラム_ac_シンボルが等しい、0×01 0×02 0×03 0×00 0×04 0×11 0×05 0×12 0×21 0×31 0×41 0×06 0×13 0×51 0×61 0×07 0×22 0×71 0×14 0×32 0×81 0×91 0xa1、0×08、0×23、0×42、0xb1、0xc1、0×15、0×52、0xd1、0xf0、0×24、0×33、0×62、0×72、0×82、0×09、0x0a、0×16、0×17、0×18、0×19、0x1a、0×25、0×26、0×27、0×28、0×29、0x2a、0×34、0×35、0×36、0×37; 0×38 0×39 0x3a、0×43、0×44、0×45、0×46、0×47、0×48、0×49、0x4a、0×53、0×54、0×55、0×56、0×57、0×58、0×59、0x5a、0×63、0×64、0×65、0×66、0×67、0×68、0×69、0x6a、0×73、0×74、0×75、0×76、0×77、0×78、0×79、0x7a、0×83、0×84、0×85、0×86、0×87、0×88、0×89、0x8a、0×92、0×93、0×94、0×95、0×96、0×97、0×98、0×99、0x9a、0xa2、0xa3、0xa4、0xa5、0xa6、0xa7

Berc, et. al.               Standards Track                    [Page 12]

RFC 2035           RTP Payload Format for JPEG Video        October 1996

et Berc、アル。 規格はビデオ1996年10月にJPEGのためにRFC2035RTP有効搭載量形式を追跡します[12ページ]。

        0xa8, 0xa9, 0xaa, 0xb2, 0xb3, 0xb4, 0xb5, 0xb6,
        0xb7, 0xb8, 0xb9, 0xba, 0xc2, 0xc3, 0xc4, 0xc5,
        0xc6, 0xc7, 0xc8, 0xc9, 0xca, 0xd2, 0xd3, 0xd4,
        0xd5, 0xd6, 0xd7, 0xd8, 0xd9, 0xda, 0xe1, 0xe2,
        0xe3, 0xe4, 0xe5, 0xe6, 0xe7, 0xe8, 0xe9, 0xea,
        0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7, 0xf8,
        0xf9, 0xfa,
};

0xa8、0xa9、0xaa、0xb2、0xb3、0xb4、0xb5、0xb6、0xb7、0xb8、0xb9、0xba、0xc2、0xc3、0xc4、0xc5、0xc6、0xc7、0xc8、0xc9、0xca、0xd2、0xd3、0xd4、0xd5、0xd6、0xd7、0xd8、0xd9、0xda、0xe1、0xe2、0xe3、0xe4、0xe5、0xe6、0xe7、0xe8、0xe9、0xea、0xf1、0xf2、0xf3、0xf4、0xf5、0xf6、0xf7、0xf8、0xf9、0xfa、。

u_char chm_dc_codelens[] = {
        0, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
};

0、3、1、1、1、1、1、1、1、1、1、0、0、0、0、u_炭のchm_dc_codelens[]=0。

u_char chm_dc_symbols[] = {
        0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11,
};

0、1、2、3、4、5、6、7、8、9、10、u_炭のchm_dc_シンボル[]=11。

u_char chm_ac_codelens[] = {
        0, 2, 1, 2, 4, 4, 3, 4, 7, 5, 4, 4, 0, 1, 2, 0x77,
};

0、2、1、2、4、4、3、4、7、5、4、4、0、1、2、u_炭のchm_ac_codelens[]=0×77。

u_char chm_ac_symbols[] = {
        0x00, 0x01, 0x02, 0x03, 0x11, 0x04, 0x05, 0x21,
        0x31, 0x06, 0x12, 0x41, 0x51, 0x07, 0x61, 0x71,
        0x13, 0x22, 0x32, 0x81, 0x08, 0x14, 0x42, 0x91,
        0xa1, 0xb1, 0xc1, 0x09, 0x23, 0x33, 0x52, 0xf0,
        0x15, 0x62, 0x72, 0xd1, 0x0a, 0x16, 0x24, 0x34,
        0xe1, 0x25, 0xf1, 0x17, 0x18, 0x19, 0x1a, 0x26,
        0x27, 0x28, 0x29, 0x2a, 0x35, 0x36, 0x37, 0x38,
        0x39, 0x3a, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48,
        0x49, 0x4a, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58,
        0x59, 0x5a, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68,
        0x69, 0x6a, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78,
        0x79, 0x7a, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87,
        0x88, 0x89, 0x8a, 0x92, 0x93, 0x94, 0x95, 0x96,
        0x97, 0x98, 0x99, 0x9a, 0xa2, 0xa3, 0xa4, 0xa5,
        0xa6, 0xa7, 0xa8, 0xa9, 0xaa, 0xb2, 0xb3, 0xb4,
        0xb5, 0xb6, 0xb7, 0xb8, 0xb9, 0xba, 0xc2, 0xc3,
        0xc4, 0xc5, 0xc6, 0xc7, 0xc8, 0xc9, 0xca, 0xd2,
        0xd3, 0xd4, 0xd5, 0xd6, 0xd7, 0xd8, 0xd9, 0xda,
        0xe2, 0xe3, 0xe4, 0xe5, 0xe6, 0xe7, 0xe8, 0xe9,
        0xea, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7, 0xf8,
        0xf9, 0xfa,
};

u_炭のchm_ac_シンボル=; { } 。

u_char *
MakeQuantHeader(u_char *p, u_char *qt, int tableNo)
{

u_炭*のMakeQuantHeader(u_炭*p、u_炭*のqt、int tableNo)

Berc, et. al.               Standards Track                    [Page 13]

RFC 2035           RTP Payload Format for JPEG Video        October 1996

et Berc、アル。 規格はビデオ1996年10月にJPEGのためにRFC2035RTP有効搭載量形式を追跡します[13ページ]。

        *p++ = 0xff;
        *p++ = 0xdb;            /* DQT */
        *p++ = 0;               /* length msb */
        *p++ = 67;              /* length lsb */
        *p++ = tableNo;
        memcpy(p, qt, 64);
        return (p + 64);
}

*+ + p=0xff。 *+ + p=0xdb。 /*DQT*/*p++=0。 /*長さのmsb*/*p++=67。 + + /*長さのlsb*/*p=tableNo。 memcpy(p、qt、64)。 戻ってください(p+64)。 }

u_char *
MakeHuffmanHeader(u_char *p, u_char *codelens, int ncodes, u_char *symbols,
                  int nsymbols, int tableNo, int tableClass)
{
        *p++ = 0xff;
        *p++ = 0xc4;            /* DHT */
        *p++ = 0;               /* length msb */
        *p++ = 3 + ncodes + nsymbols; /* length lsb */
        *p++ = tableClass << 4 | tableNo;
        memcpy(p, codelens, ncodes);
        p += ncodes;
        memcpy(p, symbols, nsymbols);
        p += nsymbols;
        return (p);
}

u_炭*のMakeHuffmanHeader(u_炭*p、u_炭*のcodelens、int ncodes、u_は*シンボル、int nsymbols、int tableNo、int tableClassを炭にします){ *p++ = 0xff; *p++ = 0xc4; /* DHT */ *p++ = 0; /* length msb */ *p++ = 3 + ncodes + nsymbols; /* length lsb */ *p++ = tableClass << 4 | tableNo; memcpy(p, codelens, ncodes); p += ncodes; memcpy(p, symbols, nsymbols); p += nsymbols; return (p); }

/*
 * Given an RTP/JPEG type code, q factor, width, and height,
 * generate a frame and scan headers that can be prepended
 * to the RTP/JPEG data payload to produce a JPEG compressed
 * image in interchange format (except for possible trailing
 * garbage and absence of an EOI marker to terminate the scan).
 */
int MakeHeaders(u_char *p, int type, int q, int w, int h)
{
        u_char *start = p;
        u_char lqt[64];
        u_char cqt[64];

RTP/JPEGタイプコードを/**に与えて、q要素、幅、および高さ、*はフレームを発生させて、それがスキャンヘッダーであることができることはJPEGが*イメージを圧縮した置き換えがフォーマットする(スキャンを終えるEOIマーカーの可能な引きずっている*ゴミと欠如を除いて)生産物にRTP/JPEGデータペイロードへの*をprependedしました。 */int MakeHeaders(u_炭*p、intタイプ、int q、int w、int h)、u_炭*始めはp; u_炭のlqt[64]; u_炭のcqt[64]と等しいです。

        /* convert from blocks to pixels */
        w <<= 3;
        h <<= 3;

ブロックから画素*/w<<=3までの/*転向者。 h<<=3。

        MakeTables(q, lqt, cqt);

MakeTables(q、lqt、cqt)。

        *p++ = 0xff;
        *p++ = 0xd8;            /* SOI */

*+ + p=0xff。 *+ + p=0xd8。 /*SOI*/

        p = MakeQuantHeader(p, lqt, 0);

pはMakeQuantHeader(p、lqt、0)と等しいです。

Berc, et. al.               Standards Track                    [Page 14]

RFC 2035           RTP Payload Format for JPEG Video        October 1996

et Berc、アル。 規格はビデオ1996年10月にJPEGのためにRFC2035RTP有効搭載量形式を追跡します[14ページ]。

        p = MakeQuantHeader(p, cqt, 1);

pはMakeQuantHeader(p、cqt、1)と等しいです。

        p = MakeHuffmanHeader(p, lum_dc_codelens,
                              sizeof(lum_dc_codelens),
                              lum_dc_symbols,
                              sizeof(lum_dc_symbols), 0, 0);
        p = MakeHuffmanHeader(p, lum_ac_codelens,
                              sizeof(lum_ac_codelens),
                              lum_ac_symbols,
                              sizeof(lum_ac_symbols), 0, 1);
        p = MakeHuffmanHeader(p, chm_dc_codelens,
                              sizeof(chm_dc_codelens),
                              chm_dc_symbols,
                              sizeof(chm_dc_symbols), 1, 0);
        p = MakeHuffmanHeader(p, chm_ac_codelens,
                              sizeof(chm_ac_codelens),
                              chm_ac_symbols,
                              sizeof(chm_ac_symbols), 1, 1);

pはMakeHuffmanHeaderと等しいです(p、ラム_dc_はsizeof(ラム_dc_はcodelensされる)に、ラム_dc_シンボル、sizeof0、0(ラム_dc_シンボル)をcodelensします)。 pはMakeHuffmanHeaderと等しいです(p、ラム_ac_はsizeof(ラム_ac_はcodelensされる)に、ラム_ac_シンボル、sizeof0、1(ラム_ac_シンボル)をcodelensします)。 pはMakeHuffmanHeader(p、chm_dcの_のcodelensのsizeof(_dc_codelensをchmする)にchmな_dc_シンボル、sizeof1、0(chm_dc_シンボル))と等しいです。 pはMakeHuffmanHeader(p、chm_acの_のcodelensのsizeof(_ac_codelensをchmする)にchmな_ac_シンボル、sizeof1、1(chm_ac_シンボル))と等しいです。

        *p++ = 0xff;
        *p++ = 0xc0;            /* SOF */
        *p++ = 0;               /* length msb */
        *p++ = 17;              /* length lsb */
        *p++ = 8;               /* 8-bit precision */
        *p++ = h >> 8;          /* height msb */
        *p++ = h;               /* height lsb */
        *p++ = w >> 8;          /* width msb */
        *p++ = w;               /* wudth lsb */
        *p++ = 3;               /* number of components */
        *p++ = 0;               /* comp 0 */
        if (type == 0)
                *p++ = 0x21;    /* hsamp = 2, vsamp = 1 */
        else
                *p++ = 0x22;    /* hsamp = 2, vsamp = 2 */
        *p++ = 0;               /* quant table 0 */
        *p++ = 1;               /* comp 1 */
        *p++ = 0x11;            /* hsamp = 1, vsamp = 1 */
        *p++ = 1;               /* quant table 1 */
        *p++ = 2;               /* comp 2 */
        *p++ = 0x11;            /* hsamp = 1, vsamp = 1 */
        *p++ = 1;               /* quant table 1 */

*+ + p=0xff。 *+ + p=0xc0。 /*SOF*/*p++=0。 /*長さのmsb*/*p++=17。 /*長さのlsb*/*p++=8。 /*8ビットの精度*/*p++はh>>8と等しいです。 /*高さのmsb*/*p++はhと等しいです。 /*高さのlsb*/*p++はw>>8と等しいです。 /*幅のmsb*/*p++はwと等しいです。 /*wudth lsb*/*p++=3。 コンポーネント*/*p++=0の/*数。 /*コンピュータ0*/は(=0をタイプします)*p++であるなら0×21と等しいです。 /*hsampは2、vsamp=1*/ほかの*p++=0x22と等しいです。 /*hsampは2、vsamp=2*/*p++=0と等しいです。 /*舟棹テーブル0*/*p++=1。 /*コンピュータ1*/*p++=0x11。 /*hsampは1、vsamp=1*/*p++=1と等しいです。 /*舟棹テーブル1*/*p++=2。 /*コンピュータ2*/*p++=0x11。 /*hsampは1、vsamp=1*/*p++=1と等しいです。 /*舟棹テーブル1 */

        *p++ = 0xff;
        *p++ = 0xda;            /* SOS */
        *p++ = 0;               /* length msb */
        *p++ = 12;              /* length lsb */
        *p++ = 3;               /* 3 components */
        *p++ = 0;               /* comp 0 */

*+ + p=0xff。 *+ + p=0xda。 /*SOS*/*p++=0。 /*長さのmsb*/*p++=12。 /*長さのlsb*/*p++=3。 /*3つのコンポーネント*/*p++は0と等しいです。 /*コンピュータ0*/

Berc, et. al.               Standards Track                    [Page 15]

RFC 2035           RTP Payload Format for JPEG Video        October 1996

et Berc、アル。 規格はビデオ1996年10月にJPEGのためにRFC2035RTP有効搭載量形式を追跡します[15ページ]。

        *p++ = 0;               /* huffman table 0 */
        *p++ = 1;               /* comp 1 */
        *p++ = 0x11;            /* huffman table 1 */
        *p++ = 2;               /* comp 2 */
        *p++ = 0x11;            /* huffman table 1 */
        *p++ = 0;               /* first DCT coeff */
        *p++ = 63;              /* last DCT coeff */
        *p++ = 0;               /* sucessive approx. */

*p++=0。 /*huffmanテーブル0*/*p++=1。 /*コンピュータ1*/*p++=0x11。 /*huffmanテーブル1*/*p++=2。 /*コンピュータ2*/*p++=0x11。 /*huffmanテーブル1*/*p++=0。 /*最初のDCT coeff*/*p++=63。 最後の/*DCT coeff*/*p++=0。 /*は周囲で*/をsucessiveします。

        return (p - start);
};

戻ってください(p--始め)。 };

Berc, et. al.               Standards Track                    [Page 16]

et Berc、アル。 標準化過程[16ページ]