Network Working Group S. Pfeiffer
Request for Comments: 3533 CSIRO
Category: Informational May 2003
The Ogg Encapsulation Format Version 0
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document describes the Ogg bitstream format version 0, which is a general, freely-available encapsulation format for media streams. It is able to encapsulate any kind and number of video and audio encoding formats as well as other data streams in a single bitstream.
この文書では、メディアストリームのための一般的な、自由に利用可能なカプセル化形式でのOggビットストリームフォーマットバージョン0を記述する。単一のビットストリームに任意の種類のビデオおよびオーディオ符号化フォーマットの数だけでなく、他のデータストリームをカプセル化することができます。
Terminology
用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[2]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements for a generic encapsulation format . . . . . . . 3
4. The Ogg bitstream format . . . . . . . . . . . . . . . . . . . 3
5. The encapsulation process . . . . . . . . . . . . . . . . . . 6
6. The Ogg page format . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A. Glossary of terms and abbreviations . . . . . . . . . . . . . 13
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
The Ogg bitstream format has been developed as a part of a larger project aimed at creating a set of components for the coding and decoding of multimedia content (codecs) which are to be freely available and freely re-implementable, both in software and in hardware for the computing community at large, including the Internet community. It is the intention of the Ogg developers represented by Xiph.Org that it be usable without intellectual property concerns.
オッグビットストリームのフォーマットは、ソフトウェアおよびハードウェアの両方で、再実装可能な自由に自由に利用可能となるようにされているマルチメディアコンテンツの符号化及び復号化するためのコンポーネントのセットを作成することを目的と大きなプロジェクト（コーデック）の一部として開発されましたインターネットコミュニティなどの大型のコンピューティング・コミュニティのため。それは、知的財産の懸念なしに使用可能であるXiph.Orgによって表されるのOgg開発者の意図です。
This document describes the Ogg bitstream format and how to use it to encapsulate one or several media bitstreams created by one or several encoders. The Ogg transport bitstream is designed to provide framing, error protection and seeking structure for higher-level codec streams that consist of raw, unencapsulated data packets, such as the Vorbis audio codec or the upcoming Tarkin and Theora video codecs. It is capable of interleaving different binary media and other time-continuous data streams that are prepared by an encoder as a sequence of data packets. Ogg provides enough information to properly separate data back into such encoder created data packets at the original packet boundaries without relying on decoding to find packet boundaries.
この文書では、オッグビットストリーム形式とどのように一つまたは複数のエンコーダによって作成された1つのまたは複数のメディアビットストリームをカプセル化するためにそれを使用する方法について説明します。オッグ輸送ビットストリームは、Vorbisのオーディオコーデックや今後のTarkinとTheoraのビデオコーデックとして生、カプセル化されていないデータ・パケット、から構成され、より高いレベルのコーデックストリームのフレーミング、エラー保護と求めている構造を提供するように設計されています。これは、異なるバイナリメディアとデータ・パケットのシーケンスとして符号化することにより製造される他の時間的に連続データストリームをインターリーブすることが可能です。 OGGバックパケット境界を見つけるために、復号化に頼ることなく、元のパケット境界でデータ・パケットを作成し、そのようなエンコーダに適切に別個のデータに十分な情報を提供します。
Please note that the MIME type application/ogg has been registered with the IANA [1].
MIMEタイプapplication / oggのは、IANA [1]に登録されていることに注意してください。
For describing the Ogg encapsulation process, a set of terms will be used whose meaning needs to be well understood. Therefore, some of the most fundamental terms are defined now before we start with the description of the requirements for a generic media stream encapsulation format, the process of encapsulation, and the concrete format of the Ogg bitstream. See the Appendix for a more complete glossary.
オッグカプセル化プロセスを説明するために、用語のセットは、その意味を十分に理解する必要が使用されます。私たちは、一般的なメディアストリームのカプセル化フォーマット、カプセル化のプロセス、およびOggビットストリームの具体的なフォーマットの要件の説明を始める前に、したがって、最も基本的な用語のいくつかは、現在定義されています。より完全な用語集は付録を参照してください。
The result of an Ogg encapsulation is called the "Physical (Ogg) Bitstream". It encapsulates one or several encoder-created bitstreams, which are called "Logical Bitstreams". A logical bitstream, provided to the Ogg encapsulation process, has a structure, i.e., it is split up into a sequence of so-called "Packets". The packets are created by the encoder of that logical bitstream and represent meaningful entities for that encoder only (e.g., an uncompressed stream may use video frames as packets). They do not contain boundary information - strung together they appear to be streams of random bytes with no landmarks.
Oggのカプセル化の結果は、「物理（オッグ）ビットストリーム」と呼ばれています。これは、「論理ビットストリーム」と呼ばれる1つまたは複数のエンコーダで作成したビットストリームを、カプセル化します。オッグカプセル化プロセスに提供される論理ビットストリームは、構造は、即ち、それがいわゆる「パケット」のシーケンスに分割されています。パケットは、その論理ビットストリームのエンコーダによって作成され、そのエンコーダのみ（例えば、非圧縮ストリームをパケットとしてビデオフレームを使用することができる）のために意味のあるエンティティを表しています。彼らは、境界情報が含まれていない - 彼らは無いのランドマークとランダムバイトのストリームのように見えるつなぎ合わせ。
Please note that the term "packet" is not used in this document to signify entities for transport over a network.
用語「パケット」は、ネットワーク上での輸送のためのエンティティを表すために、このドキュメントで使用されていないことに注意してください。
The design idea behind Ogg was to provide a generic, linear media transport format to enable both file-based storage and stream-based transmission of one or several interleaved media streams independent of the encoding format of the media data. Such an encapsulation format needs to provide:
オッグ後ろ設計思想は、ファイルベースのストレージおよび1つまたはいくつかのインターリーブされたメディアのストリームベースの伝送の両方は、メディアデータの符号化形式の独立したストリーム可能にする一般的な、リニアメディアトランスポート・フォーマットを提供することでした。このようなカプセル化フォーマットは、提供する必要があります：
o framing for logical bitstreams.
論理ビットストリームのためのOフレーミング。
o interleaving of different logical bitstreams.
異なる論理ビットストリームの入出力インターリーブ。
o detection of corruption.
汚職のOの検出。
o recapture after a parsing error.
O解析エラーの後に奪還。
o position landmarks for direct random access of arbitrary positions in the bitstream.
ビットストリーム中の任意の位置のダイレクトランダムアクセスのためのO位置目印。
o streaming capability (i.e., no seeking is needed to build a 100% complete bitstream).
Oのストリーミング機能（すなわち、何のシークが100％完全なビットストリームを構築するために必要ありません）。
o small overhead (i.e., use no more than approximately 1-2% of bitstream bandwidth for packet boundary marking, high-level framing, sync and seeking).
O小さなオーバーヘッド（すなわち、パケット境界マーキング、ハイレベルのフレーミング、同期及びシークのためのビットストリームの帯域幅の約1~2％以下で使用しません）。
o simplicity to enable fast parsing.
高速な解析を可能にするためにOのシンプルさ。
o simple concatenation mechanism of several physical bitstreams.
複数の物理ビットストリームのO、単純な連結メカニズム。
All of these design considerations have been taken into consideration for Ogg. Ogg supports framing and interleaving of logical bitstreams, seeking landmarks, detection of corruption, and stream resynchronisation after a parsing error with no more than approximately 1-2% overhead. It is a generic framework to perform encapsulation of time-continuous bitstreams. It does not know any specifics about the codec data that it encapsulates and is thus independent of any media codec.
これらの設計上の考慮事項のすべてがオッグのために考慮されています。 oggのは、これ以上の1〜2程度以下％のオーバーヘッドで解析エラーの後にフレーミングし、論理ビットストリームのインターリーブ、求めているのランドマーク、破損の検出、およびストリームの再同期をサポートしています。時間的に連続したビットストリームのカプセル化を実行するための汎用的なフレームワークです。それはカプセル化し、任意のメディアコーデックのように独立しているコーデックのデータについての詳細を知りません。
A physical Ogg bitstream consists of multiple logical bitstreams interleaved in so-called "Pages". Whole pages are taken in order from multiple logical bitstreams multiplexed at the page level. The logical bitstreams are identified by a unique serial number in the header of each page of the physical bitstream. This unique serial number is created randomly and does not have any connection to the content or encoder of the logical bitstream it represents. Pages of all logical bitstreams are concurrently interleaved, but they need not be in a regular order - they are only required to be consecutive within the logical bitstream. Ogg demultiplexing reconstructs the original logical bitstreams from the physical bitstream by taking the pages in order from the physical bitstream and redirecting them into the appropriate logical decoding entity.
物理のOggビットストリームは、いわゆる「ページ」でインターリーブ複数の論理ビットストリームで構成されています。全体のページは、ページ・レベルで多重化し、複数の論理ビットストリームから順番に取得されます。論理ビットストリームは、物理ビットストリームの各ページのヘッダに固有のシリアル番号によって識別されます。このユニークなシリアル番号はランダムに作成され、それが表す論理ビットストリームのコンテンツやエンコーダへの接続を持っていません。すべての論理ビットストリームのページは同時に、インターリーブされているが、それらは通常の順序である必要はない - 彼らは唯一の論理的ビットストリーム内の連続であることが要求されています。 Oggの分離は、物理的なビットストリームから順番にページを取り、適切な論理デコードエンティティにそれらをリダイレクトすることによって、物理的なビットストリームから元の論理ビットストリームを再構築します。
Each Ogg page contains only one type of data as it belongs to one logical bitstream only. Pages are of variable size and have a page header containing encapsulation and error recovery information. Each logical bitstream in a physical Ogg bitstream starts with a special start page (bos=beginning of stream) and ends with a special page (eos=end of stream).
それだけで一つの論理ビットストリームに属しているように、各Oggページは、データの一種類のみが含まれています。ページには、可変サイズのものであり、カプセル化とエラー回復情報を含むページヘッダを持っています。物理のOggビットストリーム内の各論理ビットストリームは、特殊なスタートページ（ストリームのBOS =初め）で始まり、特別なページ（EOS =ストリームの終わり）で終わります。
The bos page contains information to uniquely identify the codec type and MAY contain information to set up the decoding process. The bos page SHOULD also contain information about the encoded media - for example, for audio, it should contain the sample rate and number of channels. By convention, the first bytes of the bos page contain magic data that uniquely identifies the required codec. It is the responsibility of anyone fielding a new codec to make sure it is possible to reliably distinguish his/her codec from all other codecs in use. There is no fixed way to detect the end of the codec-identifying marker. The format of the bos page is dependent on the codec and therefore MUST be given in the encapsulation specification of that logical bitstream type. Ogg also allows but does not require secondary header packets after the bos page for logical bitstreams and these must also precede any data packets in any logical bitstream. These subsequent header packets are framed into an integral number of pages, which will not contain any data packets. So, a physical bitstream begins with the bos pages of all logical bitstreams containing one initial header packet per page, followed by the subsidiary header packets of all streams, followed by pages containing data packets.
BOSページが一意コーデックタイプを識別し、復号処理を設定するための情報を含むことができる情報を含みます。 BOSのページには、エンコードされたメディアに関する情報が含まれている必要があります - 例えば、オーディオのために、それはチャンネルのサンプルレートと番号が含まれている必要があります。慣例により、BOSページの最初のバイトは一意に必要なコーデックを識別し、魔法のデータが含まれています。確実に使用中のすべての他のコーデックからの彼/彼女のコーデックを区別することが可能であることを確認するために、新しいコーデックを守備誰の責任です。コーデック識別マーカーの終了を検出するための決まった方法はありません。 BOSページの形式は、コーデックに依存し、従ってその論理ビットストリーム型のカプセル化仕様で与えられなければなりません。オッグもできますが、論理ビットストリームのためのBOSのページ後の二次ヘッダーパケットを必要とせず、これらはまた、任意の論理ビットストリーム内のデータパケットの前に置く必要があります。これらの後続ヘッダパケットはあらゆるデータ・パケットを含まないページの整数、に囲まれています。だから、物理的なビットストリームは、データパケットを含むページに続くすべてのストリームの子会社ヘッダーパケット、続く1ページに1つの最初のヘッダパケットを含むすべての論理ビットストリームのBOSページから始まります。
The encapsulation specification for one or more logical bitstreams is called a "media mapping". An example for a media mapping is "Ogg Vorbis", which uses the Ogg framework to encapsulate Vorbis-encoded audio data for stream-based storage (such as files) and transport (such as TCP streams or pipes). Ogg Vorbis provides the name and revision of the Vorbis codec, the audio rate and the audio quality on the Ogg Vorbis bos page. It also uses two additional header pages per logical bitstream. The Ogg Vorbis bos page starts with the byte 0x01, followed by "vorbis" (a total of 7 bytes of identifier).
一つ以上の論理ビットストリームのためのカプセル化仕様は、「メディア・マッピング」と呼ばれています。メディアマッピングの例は、ストリームベース（ファイルなど）の貯蔵および輸送のためにVorbisの符号化音声データをカプセル化するためのOggフレームワークを使用して「のOgg Vorbisの」、（TCPストリームやパイプなど）です。オッグVorbisのはVorbisのコーデック、オーディオレートおよびOgg Vorbisのbosのページ上のオーディオ品質の名前とリビジョンを提供します。また、論理ビットストリームごとに2つの追加のヘッダページを使用しています。 Ogg VorbisのBOSページ「がVorbisの」（識別子の7バイトの合計）が続くバイトが0x01で始まります。
Ogg knows two types of multiplexing: concurrent multiplexing (so-called "Grouping") and sequential multiplexing (so-called "Chaining"). Grouping defines how to interleave several logical bitstreams page-wise in the same physical bitstream. Grouping is for example needed for interleaving a video stream with several synchronised audio tracks using different codecs in different logical bitstreams. Chaining on the other hand, is defined to provide a simple mechanism to concatenate physical Ogg bitstreams, as is often needed for streaming applications.
同時多重化（「グループ化」と呼ばれる）と、順次多重化（いわゆる「チェーン」）：オッグは、多重化の二つのタイプを知っています。グループは、同じ物理ビットストリームに複数の論理ビットストリームのページ単位をインターリーブする方法を定義します。グループ化は、異なる論理ビットストリームに異なるコーデックを使用して複数の同期オーディオトラックとビデオストリームをインタリーブするために必要な、たとえばです。一方チェイン、多くの場合、ストリーミングアプリケーションのために必要とされるように、物理のOggビットストリームを連結するための簡単なメカニズムを提供するために定義されています。
In grouping, all bos pages of all logical bitstreams MUST appear together at the beginning of the Ogg bitstream. The media mapping specifies the order of the initial pages. For example, the grouping of a specific Ogg video and Ogg audio bitstream may specify that the physical bitstream MUST begin with the bos page of the logical video bitstream, followed by the bos page of the audio bitstream. Unlike bos pages, eos pages for the logical bitstreams need not all occur contiguously. Eos pages may be 'nil' pages, that is, pages containing no content but simply a page header with position information and the eos flag set in the page header. Each grouped logical bitstream MUST have a unique serial number within the scope of the physical bitstream.
グループでは、すべての論理ビットストリームのすべてのbosページがオッグビットストリームの先頭に一緒に表示される必要があります。メディアマッピングは、最初のページの順序を指定します。例えば、特定のOggビデオおよびOggオーディオビットストリームのグループ化は、物理的なビットストリームがオーディオビットストリームのBOSページに続く論理ビデオビットストリームのBOSページで開始しなければならないことを指定することができます。 BOSページとは異なり、論理ビットストリームのためのEOSページが連続発生したすべての必要はありません。 EOSページが「ゼロ」ページであってもよい、すなわち、位置情報およびページヘッダーのEOSフラグが設定されないコンテンツが、単にページヘッダを含まないページです。各グループ化された論理ビットストリームは、物理ビットストリームの範囲内で一意のシリアル番号を持っていなければなりません。
In chaining, complete logical bitstreams are concatenated. The bitstreams do not overlap, i.e., the eos page of a given logical bitstream is immediately followed by the bos page of the next. Each chained logical bitstream MUST have a unique serial number within the scope of the physical bitstream.
チェーンでは、完全な論理ビットストリームが連結されます。ビットストリーム、すなわち、所与の論理ビットストリームのEOSページが直ちに次のBOSページ続いて、重なりません。各チェーン論理ビットストリームは、物理ビットストリームの範囲内で一意のシリアル番号が必要です。
It is possible to consecutively chain groups of concurrently multiplexed bitstreams. The groups, when unchained, MUST stand on their own as a valid concurrently multiplexed bitstream. The following diagram shows a schematic example of such a physical bitstream that obeys all the rules of both grouped and chained multiplexed bitstreams.
それは同時に、多重化ビットストリームの連続鎖基に可能です。グループは、非連鎖とき、有効に同時に多重化ビットストリームとして自分で立たなければなりません。次の図は、両方のグループ化と連鎖多重化されたビットストリームのすべてのルールに従うような物理ビットストリームの概略的な例を示しています。
physical bitstream with pages of
different logical bitstreams grouped and chained
-------------------------------------------------------------
|*A*|*B*|*C*|A|A|C|B|A|B|#A#|C|...|B|C|#B#|#C#|*D*|D|...|#D#|
-------------------------------------------------------------
bos bos bos eos eos eos bos eos
In this example, there are two chained physical bitstreams, the first of which is a grouped stream of three logical bitstreams A, B, and C. The second physical bitstream is chained after the end of the grouped bitstream, which ends after the last eos page of all its grouped logical bitstreams. As can be seen, grouped bitstreams begin together - all of the bos pages MUST appear before any data pages. It can also be seen that pages of concurrently multiplexed bitstreams need not conform to a regular order. And it can be seen that a grouped bitstream can end long before the other bitstreams in the group end.
この例では、第2の物理ビットストリームが最後EOS後に終了グループ化されたビットストリームの終了後に連鎖されている3つの論理ビットストリームのA、B、およびCのグループ化されたストリームである第一その2つの連鎖の物理ビットストリームは、ありますそのすべてのグループ化された論理ビットストリームのページ。図から分かるように、グループ化されたビットストリームは、一緒に始める - BOSのすべてのページには、任意のデータページの前に現れなければなりません。また、同時に、多重化ビットストリームのページは、通常の順序に準拠する必要はないことがわかります。そしてグループ化されたビットストリームは、グループ内の他のエンドビットストリームの前に長い終わることができていることがわかります。
Ogg does not know any specifics about the codec data except that each logical bitstream belongs to a different codec, the data from the codec comes in order and has position markers (so-called "Granule positions"). Ogg does not have a concept of 'time': it only knows about sequentially increasing, unitless position markers. An application can only get temporal information through higher layers which have access to the codec APIs to assign and convert granule positions or time.
オッグは、各論理ビットストリームは別のコーデックに属していることを除いてコーデックデータについての詳細を知らない、コーデックからのデータが順番に来て、位置マーカー（いわゆる「グラニュール位置」）を有します。 oggのは「時間」の概念がありません：それはたったの約順次増加し、単位のない位置マーカーを知っています。アプリケーションは、顆粒位置や時間を割り当てて、変換するコーデックのAPIへのアクセス権を持っている上位層を貫通して、時間的な情報を得ることができます。
A specific definition of a media mapping using Ogg may put further constraints on its specific use of the Ogg bitstream format. For example, a specific media mapping may require that all the eos pages for all grouped bitstreams need to appear in direct sequence. An example for a media mapping is the specification of "Ogg Vorbis". Another example is the upcoming "Ogg Theora" specification which encapsulates Theora-encoded video data and usually comes multiplexed with a Vorbis stream for an Ogg containing synchronised audio and video. As Ogg does not specify temporal relationships between the encapsulated concurrently multiplexed bitstreams, the temporal synchronisation between the audio and video stream will be specified in this media mapping. To enable streaming, pages from various logical bitstreams will typically be interleaved in chronological order.
オッグを使用してメディアマッピングの具体的な定義はオッグビットストリーム形式のその具体的な使用に更なる制約を置いてもよいです。例えば、特定のメディアマッピングは、すべてのグループ化されたビットストリームのためのすべてのEOSページが直接シーケンスで表示する必要があることを要求することができます。メディアマッピングの例は「オッグVorbisの」の仕様です。別の例では、同期オーディオとビデオを含むのOgg Vorbisのためのストリームに多重化Theoraのエンコードされたビデオデータをカプセル化し、通常くる今後の「オッグTheoraの」仕様です。オッグは、カプセル化され、同時に多重化されたビットストリーム間の時間的関係を指定していないとして、オーディオとビデオストリームの間の時間的同期がこのメディアマッピングで指定されます。ストリーミングを有効にするには、様々な論理ビットストリームからのページは、一般的に年代順にインターリーブされます。
The process of multiplexing different logical bitstreams happens at the level of pages as described above. The bitstreams provided by encoders are however handed over to Ogg as so-called "Packets" with packet boundaries dependent on the encoding format. The process of encapsulating packets into pages will be described now.
上記のように多重異なる論理ビットストリームの処理は、ページのレベルで起こります。エンコーダによって提供されたビットストリームは、しかし、エンコード形式に依存してパケット境界を持つ、いわゆる「パケット」とオッグに引き渡されています。ページにパケットをカプセル化する過程を説明します。
From Ogg's perspective, packets can be of any arbitrary size. A specific media mapping will define how to group or break up packets from a specific media encoder. As Ogg pages have a maximum size of about 64 kBytes, sometimes a packet has to be distributed over several pages. To simplify that process, Ogg divides each packet into 255 byte long chunks plus a final shorter chunk. These chunks are called "Ogg Segments". They are only a logical construct and do not have a header for themselves.
オッグの観点から、パケットは、任意のサイズにすることができます。特定のメディアのマッピングがどのようにグループに定義したり、特定のメディアエンコーダからのパケットを分割します。 Oggページは約64キロバイトの最大サイズを持っているとして、時にはパケットは複数のページに分散する必要があります。そのプロセスを簡素化するために、オッグは、255のバイト長のチャンクを加え、最終的な短いチャンクに各パケットを分割します。これらのチャンクは「オッグ・セグメント」と呼ばれています。彼らは唯一の論理的な構造であり、自分自身のためのヘッダを持っていません。
A group of contiguous segments is wrapped into a variable length page preceded by a header. A segment table in the page header tells about the "Lacing values" (sizes) of the segments included in the page. A flag in the page header tells whether a page contains a packet continued from a previous page. Note that a lacing value of 255 implies that a second lacing value follows in the packet, and a value of less than 255 marks the end of the packet after that many additional bytes. A packet of 255 bytes (or a multiple of 255 bytes) is terminated by a lacing value of 0. Note also that a 'nil' (zero length) packet is not an error; it consists of nothing more than a lacing value of zero in the header.
連続したセグメントのグループは、ヘッダが先行可変長ページに包まれています。ページヘッダ内のセグメント・テーブルは、ページに含まれるセグメントの「レーシング値」（サイズ）について伝えます。ページのヘッダ内のフラグは、ページが前ページからパケットを含むかどうかを伝えます。 255のレーシング値が第2レーシング値はパケットに続くことを意味し、255未満の値は、多くの追加バイト後のパケットの終了を示すことに留意されたいです。 255バイトのパケット（または255バイトの倍数）は「ゼロ」（ゼロ長さ）は、パケットがエラーではないことにも注意0のレーシング値によって終了されます。それはヘッダ内のゼロのレーシング値よりも何で構成されています。
The encoding is optimized for speed and the expected case of the majority of packets being between 50 and 200 bytes large. This is a design justification rather than a recommendation. This encoding both avoids imposing a maximum packet size as well as imposing minimum overhead on small packets. In contrast, e.g., simply using two bytes at the head of every packet and having a max packet size of 32 kBytes would always penalize small packets (< 255 bytes, the typical case) with twice the segmentation overhead. Using the lacing values as suggested, small packets see the minimum possible byte-aligned overhead (1 byte) and large packets (>512 bytes) see a fairly constant ~0.5% overhead on encoding space.
符号化は、速度と大きな50と200バイトの間でパケットの大多数の期待場合のために最適化されます。これは、設計上の正当な理由なく、勧告です。この符号化は、最大パケットサイズを課すだけでなく、小さなパケットに最小のオーバーヘッドを課す回避両方。対照的に、例えば、単に各パケットの先頭に2つのバイトを使用し、32Kバイトの最大パケットサイズを有する常に倍セグメンテーションオーバーヘッドで小さなパケット（<255バイト、一般的なケース）を不利になります。示唆されるようにレーシング値を使用して、小さなパケットは、最小可能バイト整列オーバーヘッド（1バイト）と大きなパケットが（> 512バイト）の符号化空間に〜ほぼ一定0.5％のオーバーヘッドを見ます。
The following diagram shows a schematic example of a media mapping using Ogg and grouped logical bitstreams:
次の図は、メディアのOggを使用してマッピングし、グループ化された論理ビットストリームの概略的な例を示しています。
logical bitstream with packet boundaries
-----------------------------------------------------------------
> | packet_1 | packet_2 | packet_3 | <
-----------------------------------------------------------------
|segmentation (logically only)
v
packet_1 (5 segments) packet_2 (4 segs) p_3 (2 segs)
------------------------------ -------------------- ------------
.. |seg_1|seg_2|seg_3|seg_4|s_5 | |seg_1|seg_2|seg_3|| |seg_1|s_2 | ..
------------------------------ -------------------- ------------
| page encapsulation
v
page_1 (packet_1 data) page_2 (pket_1 data) page_3 (packet_2 data)
------------------------ ---------------- ------------------------
|H|------------------- | |H|----------- | |H|------------------- |
|D||seg_1|seg_2|seg_3| | |D|seg_4|s_5 | | |D||seg_1|seg_2|seg_3| | ...
|R|------------------- | |R|----------- | |R|------------------- |
------------------------ ---------------- ------------------------
|
pages of |
other --------| |
logical -------
bitstreams | MUX |
-------
|
v
page_1 page_2 page_3
------ ------ ------- ----- -------
... || | || | || | || | || | ...
------ ------ ------- ----- -------
physical Ogg bitstream
In this example we take a snapshot of the encapsulation process of one logical bitstream. We can see part of that bitstream's subdivision into packets as provided by the codec. The Ogg encapsulation process chops up the packets into segments. The packets in this example are rather large such that packet_1 is split into 5 segments - 4 segments with 255 bytes and a final smaller one. Packet_2 is split into 4 segments - 3 segments with 255 bytes and a final very small one - and packet_3 is split into two segments. The encapsulation process then creates pages, which are quite small in this example. Page_1 consists of the first three segments of packet_1, page_2 contains the remaining 2 segments from packet_1, and page_3 contains the first three pages of packet_2. Finally, this logical bitstream is multiplexed into a physical Ogg bitstream with pages of other logical bitstreams.
この例では、一つの論理ビットストリームのカプセル化プロセスのスナップショットを取ります。コーデックによって提供されるように私たちは、パケットにそのビットストリームの細分化の一部を見ることができます。オッグカプセル化プロセスは、セグメントにパケットをチョップ。 4つの255バイトのセグメントと最後の小さい方 - この例ではパケットがpacket_1 5つのセグメントに分割されるように、かなり大きいです。 3つの255バイトのセグメントと最後の非常に小さなもの - - Packet_2は、4つのセグメントに分割され、packet_3は、2つのセグメントに分割されます。カプセル化プロセスは、この例では非常に小さいページを作成します。 PAGE_1はpacket_1の最初の三つのセグメントから構成され、page_2はpacket_1からの残りの2つのセグメントを含み、page_3はpacket_2の最初の3ページを含みます。最後に、この論理ビットストリームは、他の論理ビットストリームのページを持つ物理のOggビットストリームに多重化されます。
A physical Ogg bitstream consists of a sequence of concatenated pages. Pages are of variable size, usually 4-8 kB, maximum 65307 bytes. A page header contains all the information needed to demultiplex the logical bitstreams out of the physical bitstream and to perform basic error recovery and landmarks for seeking. Each page is a self-contained entity such that the page decode mechanism can recognize, verify, and handle single pages at a time without requiring the overall bitstream.
物理のOggビットストリームは、連結一連のページで構成されています。ページは、可変サイズ、通常4-8キロバイト、最大65307バイトです。ページヘッダは、物理ビットストリームのうち、論理ビットストリームを分離し、追求のための基本的なエラー回復やランドマークを実行するために必要なすべての情報が含まれています。各ページには、ページデコードメカニズムは、認識を確認し、全体的なビットストリームを必要とせずに一度に単一のページを扱うことができるような自己完結型のエンティティです。
The Ogg page header has the following format:
Oggページヘッダーの形式は次のとおりです。
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| Byte +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | capture_pattern: Magic number for page start "OggS" | 0-3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | version | header_type | granule_position | 4-7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 8-11 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | bitstream_serial_number | 12-15 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | page_sequence_number | 16-19 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | CRC_checksum | 20-23 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |page_segments | segment_table | 24-27 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 28- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |バイト+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | capture_pattern：ページ開始「OggS」のためのマジックナンバー| 0-3 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |バージョン| header_type | granule_position | 4-7 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | 8-11 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | bitstream_serial_number | 12-15 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | page_sequence_number | 16-19 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | CRC_checksum | 20-23 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | page_segments | segment_table | 24-27 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | ... | 28- + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
The LSb (least significant bit) comes first in the Bytes. Fields with more than one byte length are encoded LSB (least significant byte) first.
LSB（最下位ビット）バイトで最初に来ます。複数のバイト長のフィールドはLSB（最下位バイト）最初に符号化されます。
The fields in the page header have the following meaning:
ページヘッダー内のフィールドの意味は以下のとおりです。
1. capture_pattern: a 4 Byte field that signifies the beginning of a page. It contains the magic numbers:
1. capture_pattern：ページの始まりを意味し4バイトのフィールド。それは魔法の数字が含まれています。
0x4f 'O'
0x4f 'O'
0x67 'g'
0x67 'G'
0x67 'g'
0x67 'G'
0x53 'S'
$ 53「S」
It helps a decoder to find the page boundaries and regain synchronisation after parsing a corrupted stream. Once the capture pattern is found, the decoder verifies page sync and integrity by computing and comparing the checksum.
これは、ページ境界を見つけて、破損したストリームを解析した後に同期を回復するデコーダに役立ちます。キャプチャパターンが検出されると、デコーダは、チェックサムを計算し、比較することにより、ページ同期及び整合性を検証します。
2. stream_structure_version: 1 Byte signifying the version number of the Ogg file format used in this stream (this document specifies version 0).
2. stream_structure_version：このストリームで使用されるのOggファイル形式のバージョン番号（この文書はバージョン0を指定する）を意味1バイト。
3. header_type_flag: the bits in this 1 Byte field identify the specific type of this page.
3. header_type_flag：この1バイトフィールド内のビットは、このページの特定のタイプを識別する。
* bit 0x01
*ビットが0x01
set: page contains data of a packet continued from the previous page
セット：ページが前ページから続くパケットのデータが含まれています
unset: page contains a fresh packet
未設定：ページには、新鮮なパケットが含まれています
* bit 0x02
*ビット0×02
set: this is the first page of a logical bitstream (bos)
設定：これは論理ビットストリームの最初のページです（BOS）
unset: this page is not a first page
設定を解除：このページは、最初のページではありません
* bit 0x04
*ビット0x04を
set: this is the last page of a logical bitstream (eos)
設定：これは論理ビットストリームの最後のページである（EOS）
unset: this page is not a last page
設定を解除：このページは、最後のページではありません
4. granule_position: an 8 Byte field containing position information. For example, for an audio stream, it MAY contain the total number of PCM samples encoded after including all frames finished on this page. For a video stream it MAY contain the total number of video frames encoded after this page. This is a hint for the decoder and gives it some timing and position information. Its meaning is dependent on the codec for that logical bitstream and specified in a specific media mapping. A special value of -1 (in two's complement) indicates that no packets finish on this page.
4. granule_position：位置情報を含む8バイトのフィールド。例えば、オーディオストリームのために、それは、このページに仕上がっすべてのフレームを含めた後、エンコードされたPCMサンプルの合計数を含むかもしれません。ビデオストリームの場合には、このページの後にエンコードされたビデオフレームの総数を含むかもしれません。これは、デコーダのためのヒントであり、それはいくつかのタイミングと位置情報を与えます。その意味では、その論理ビットストリームのためのコーデックに依存し、特定のメディアマッピングで指定されています。 （2の補数で）-1の特別な値は、パケットがこのページに仕上げるないことを示しています。
5. bitstream_serial_number: a 4 Byte field containing the unique serial number by which the logical bitstream is identified.
5. bitstream_serial_number：論理ビットストリームを識別するための固有のシリアル番号を含む4バイトのフィールド。
6. page_sequence_number: a 4 Byte field containing the sequence number of the page so the decoder can identify page loss. This sequence number is increasing on each logical bitstream separately.
6. page_sequence_number：デコーダはページの損失を識別できるように、ページのシーケンス番号を含む4バイトのフィールド。このシーケンス番号は、個別に各論理ビットストリームに増加しています。
7. CRC_checksum: a 4 Byte field containing a 32 bit CRC checksum of the page (including header with zero CRC field and page content). The generator polynomial is 0x04c11db7.
7. CRC_checksum：（ゼロCRCフィールドを有するヘッダとページコンテンツを含む）ページの32ビットCRCチェックサムを含む4バイトのフィールド。生成多項式は0x04c11db7です。
8. number_page_segments: 1 Byte giving the number of segment entries encoded in the segment table.
8. number_page_segments：セグメント・テーブルで符号化されたセグメントのエントリの数を与える1バイト。
9. segment_table: number_page_segments Bytes containing the lacing values of all segments in this page. Each Byte contains one lacing value.
9. segment_table：このページのすべてのセグメントのレーシング値を含むnumber_page_segmentsバイト数。各バイトは1つのレーシング値が含まれています。
The total header size in bytes is given by: header_size = number_page_segments + 27 [Byte]
ヘッダサイズ= number_page_segments + 27 [バイト]：バイト単位の総ヘッダサイズは次式で与えられます。
The total page size in Bytes is given by: page_size = header_size + sum(lacing_values: 1..number_page_segments) [Byte]
PAGE_SIZE =ヘッダサイズ+ SUM（lacing_values：1..number_page_segments）[バイト]バイトの総ページサイズは、次式で与えられます。
The Ogg encapsulation format is a container format and only encapsulates content (such as Vorbis-encoded audio). It does not provide for any generic encryption or signing of itself or its contained content bitstreams. However, it encapsulates any kind of content bitstream as long as there is a codec for it, and is thus able to contain encrypted and signed content data. It is also possible to add an external security mechanism that encrypts or signs an Ogg physical bitstream and thus provides content confidentiality and authenticity.
オッグカプセル化形式はコンテナ形式であり、唯一の（例えば、Vorbisのエンコードされたオーディオのような）コンテンツをカプセル化します。それは、それ自体またはそれに含まれるコンテンツのビットストリームのいずれかの一般的な暗号化や署名のために提供されていません。しかし、それは限り、それのためのコーデックがあるとして、コンテンツのビットストリームの任意の種類をカプセル化し、これにより暗号化し、署名したコンテンツデータを含むことが可能です。暗号化や署名のOgg物理ビットストリームを、したがって、コンテンツ機密性と信頼性を提供する外部のセキュリティメカニズムを追加することも可能です。
As Ogg encapsulates binary data, it is possible to include executable content in an Ogg bitstream. This can be an issue with applications that are implemented using the Ogg format, especially when Ogg is used for streaming or file transfer in a networking scenario. As such, Ogg does not pose a threat there. However, an application decoding Ogg and its encapsulated content bitstreams has to ensure correct handling of manipulated bitstreams, of buffer overflows and the like.
オッグは、バイナリデータをカプセル化するように、オッグビットストリーム内の実行可能なコンテンツを含むことが可能です。これはオッグは、ネットワーキングのシナリオでのストリーミングやファイル転送のために使用され、特にOggのフォーマットを使用して実装されているアプリケーションで問題となることがあります。そのため、オッグが脅威をもたらすことはありません。しかし、OGG、そのカプセル化されたコンテンツのビットストリームを復号化アプリケーションは、バッファオーバーフローなどの操作されたビットストリームの正しい取り扱いを保証しなければなりません。
[1] Walleij, L., "The application/ogg Media Type", RFC 3534, May 2003.
[1] Walleij、L.、 "アプリケーション/ oggのメディアタイプ"、RFC 3534、2003年5月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
Appendix A. Glossary of terms and abbreviations
用語や略語の付録A.用語集
bos page: The initial page (beginning of stream) of a logical bitstream which contains information to identify the codec type and other decoding-relevant information.
BOSのページ：コーデックの種類や他のデコード関連情報を識別するための情報が含まれている論理ビットストリームの最初のページ（ストリームの始まり）。
chaining (or sequential multiplexing): Concatenation of two or more complete physical Ogg bitstreams.
チェーン（またはシーケンシャル多重化）：2つの以上の完全な物理のOggビットストリームの連結。
eos page: The final page (end of stream) of a logical bitstream.
EOSページ：論理ビットストリームの最終ページ（ストリームの終わり）。
granule position: An increasing position number for a specific logical bitstream stored in the page header. Its meaning is dependent on the codec for that logical bitstream and specified in a specific media mapping.
顆粒位置：ページのヘッダーに格納された特定の論理ビットストリームのための増加位置番号。その意味では、その論理ビットストリームのためのコーデックに依存し、特定のメディアマッピングで指定されています。
grouping (or concurrent multiplexing): Interleaving of pages of several logical bitstreams into one complete physical Ogg bitstream under the restriction that all bos pages of all grouped logical bitstreams MUST appear before any data pages.
グループ化（または同時多重）：すべてのグループ化された論理ビットストリームのすべてのbosページが任意のデータページの前に現れなければならないという制約の下で一つの完全な物理のOggビットストリームに複数の論理ビットストリームのページのインターリーブ。
lacing value: An entry in the segment table of a page header representing the size of the related segment.
レーシング値：関連するセグメントのサイズを示すページヘッダのセグメント・テーブル内のエントリ。
logical bitstream: A sequence of bits being the result of an encoded media stream.
論理ビットストリーム：エンコードされたメディアストリームの結果であるビットのシーケンス。
media mapping: A specific use of the Ogg encapsulation format together with a specific (set of) codec(s).
メディアマッピング：特定と共にオッグカプセル化フォーマットの特定の使用（のセット）コーデック（S）。
(Ogg) packet: A subpart of a logical bitstream that is created by the encoder for that bitstream and represents a meaningful entity for the encoder, but only a sequence of bits to the Ogg encapsulation.
（オッグ）パケット：そのビットストリームのための符号化器によって作成され、エンコーダの意味のエンティティが、オッグカプセル化ビットの配列のみを表している論理ビットストリームのサブパート。
(Ogg) page: A physical bitstream consists of a sequence of Ogg pages containing data of one logical bitstream only. It usually contains a group of contiguous segments of one packet only, but sometimes packets are too large and need to be split over several pages.
（オッグ）ページ：物理ビットストリームは、唯一の論理ビットストリームのデータを含むOggのページの配列からなります。これは、通常は1つのパケットの連続したセグメントのグループが含まれていますが、時々、パケットがあまりにも大きく、複数のページに分割する必要があります。
physical (Ogg) bitstream: The sequence of bits resulting from an Ogg encapsulation of one or several logical bitstreams. It consists of a sequence of pages from the logical bitstreams with the restriction that the pages of one logical bitstream MUST come in their correct temporal order.
物理的（オッグ）ビットストリーム：一つまたは複数の論理ビットストリームのオッグカプセル化に起因するビットのシーケンス。これは、一つの論理ビットストリームのページが正しい時間的順序に来なければならないという制限を持つ論理ビットストリームから一連のページで構成されています。
(Ogg) segment: The Ogg encapsulation process splits each packet into chunks of 255 bytes plus a last fractional chunk of less than 255 bytes. These chunks are called segments.
（オッグ）セグメント：オッグカプセル化プロセスが255バイトを加えた255バイト未満の最後の端数のチャンクのチャンクに各パケットを分割します。これらのチャンクはセグメントと呼ばれています。
Appendix B. Acknowledgements
付録B.謝辞
The author gratefully acknowledges the work that Christopher Montgomery and the Xiph.Org foundation have done in defining the Ogg multimedia project and as part of it the open file format described in this document. The author hopes that providing this document to the Internet community will help in promoting the Ogg multimedia project at http://www.xiph.org/. Many thanks also for the many technical and typo corrections that C. Montgomery and the Ogg community provided as feedback to this RFC.
作者は感謝クリストファー・モンゴメリーとXiph.Org財団は、この文書で説明するオープンファイル形式のOggマルチメディアプロジェクトを定義する際に、それの一環として行われてきた仕事を認めています。著者は、インターネットコミュニティにこの文書を提供することがhttp://www.xiph.org/でのOggマルチメディアプロジェクトの促進に役立つことを期待しています。またC.モンゴメリーおよびOggコミュニティがこのRFCへのフィードバックとして提供される多くの技術やタイプミスの修正のために感謝します。
Author's Address
著者のアドレス
Silvia Pfeiffer CSIRO, Australia Locked Bag 17 North Ryde, NSW 2113 Australia
シルビア・ファイファーCSIRO、オーストラリアはバッグ17ノースライド、NSW 2113オーストラリアのロック
Phone: +61 2 9325 3141 EMail: Silvia.Pfeiffer@csiro.au URI: http://www.cmis.csiro.au/Silvia.Pfeiffer/
電話：+61 2 9325 3141 Eメール：Silvia.Pfeiffer@csiro.au URI：http://www.cmis.csiro.au/Silvia.Pfeiffer/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。