[要約] RFC 3533は、Oggカプセル化形式のバージョン0に関する仕様書であり、Oggメディアファイルの構造とデータのエンコード方法を定義しています。このRFCの目的は、Oggフォーマットの標準化と相互運用性の向上です。
Network Working Group S. Pfeiffer
Request for Comments: 3533 CSIRO
Category: Informational May 2003
The Ogg Encapsulation Format Version 0
OGGカプセル化形式バージョン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.
Copyright（c）The Internet Society（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 BitStream形式のバージョン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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
OGG BitStream形式は、ソフトウェアとハードウェアの両方で、自由に利用可能で自由に再実装可能なマルチメディアコンテンツ（コーデック）のコーディングとデコードのセットを作成することを目的とした、より大きなプロジェクトの一部として開発されました。インターネットコミュニティを含むコンピューティングコミュニティ全体。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.
このドキュメントでは、OGGビットストリーム形式と、1つまたは複数のエンコーダーによって作成された1つまたは複数のメディアビットストリームをカプセル化するために使用する方法について説明します。OGG Transport BitStreamは、Vorbis Audio Codecや今後のTarkinおよびTheora Video Codecsなどの生の非カプセル化データパケットで構成される、フレーミング、エラー保護、および高レベルのコーデックストリームの構造を提供するように設計されています。エンコーダーによって一連のデータパケットとして作成された、さまざまなバイナリメディアやその他の時間を連続したデータストリームをインターリーで締めることができます。OGGは、パケットの境界を見つけるためにデコードに依存することなく、元のパケット境界でそのようなエンコーダ作成されたデータパケットにデータを適切に分離するのに十分な情報を提供します。
Please note that the MIME type application/ogg has been registered with the IANA [1].
MIMEタイプアプリケーション/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カプセル化プロセスを説明するために、その意味をよく理解する必要がある用語のセットが使用されます。したがって、最も基本的な用語のいくつかは、一般的なメディアストリームカプセル化形式の要件、カプセル化のプロセス、および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カプセル化の結果は、「物理的（OGG）ビットストリーム」と呼ばれます。「論理ビットストリーム」と呼ばれる1つまたは複数のエンコーダーが作成したビットストリームをカプセル化します。OGGカプセル化プロセスに提供される論理的なビットストリームには、構造があります。つまり、いわゆる「パケット」のシーケンスに分割されます。パケットは、その論理的なビットストリームのエンコーダーによって作成され、そのエンコーダのみの意味のあるエンティティを表します（たとえば、非圧縮ストリームは、ビデオフレームをパケットとして使用する場合があります）。それらには境界情報が含まれていません - それらは、ランドマークのないランダムバイトのストリームのように見えます。
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:
OGGの背後にあるデザインのアイデアは、メディアデータのエンコード形式とは無関係に、1つまたは複数のインターリーブメディアストリームのファイルベースのストレージとストリームベースの送信の両方を有効にするための一般的な線形メディアトランスポートフォーマットを提供することでした。このようなカプセル化形式は、次のことを提供する必要があります。
o framing for logical bitstreams.
o 論理的なビットストリームのフレーミング。
o interleaving of different logical bitstreams.
o さまざまな論理的なビットストリームのインターリーブ。
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について考慮されています。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 Demultiplexingは、物理的なビットストリームからページを順番に取得し、適切な論理デコードエンティティにリダイレクトすることにより、物理的なビットストリームから元の論理ビットストリームを再構築します。
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ページには、1つの論理的なビットストリームのみに属しているため、1つのタイプのデータのみが含まれています。ページはさまざまなサイズで、カプセル化とエラー回復情報を含むページヘッダーがあります。物理的なOGGビットストリームの各論理的なビットストリームは、特別な開始ページ（bos = streamの開始）で始まり、特別なページ（eos = end of stream）で終わります。
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ページの形式はコーデックに依存しているため、その論理的なビットストリームタイプのカプセル化仕様に指定する必要があります。OGGはまた、論理的なビットストリーム用のBOSページの後にセカンダリヘッダーパケットを必要としませんが、これらは論理的なビットストリームのデータパケットの前にも必要です。これらの後続のヘッダーパケットは、データパケットを含まない積分数ページに囲まれています。したがって、物理的なビットストリームは、ページごとに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).
1つ以上の論理的なビットストリームのカプセル化仕様は、「メディアマッピング」と呼ばれます。メディアマッピングの例は「Ogg Vorbis」です。OGGフレームワークを使用して、ストリームベースのストレージ（ファイルなど）やトランスポート（TCPストリームやパイプなど）のVorbisエンコードオーディオデータをカプセル化します。Ogg Vorbisは、OGG Vorbis BOSページのVorbis Codec、オーディオレート、オーディオ品質の名前と改訂を提供します。また、論理的なビットストリームごとに2つの追加のヘッダーページを使用します。OGG Vorbis BOSページは、バイト0x01から始まり、「Vorbis」（合計7バイトの識別子）が続きます。
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は、2種類の多重化の2種類を知っています。グループ化は、同じ物理的なビットストリームでページごとにいくつかの論理的なビットストリームをインターリーする方法を定義します。たとえば、さまざまな論理的なビットストリームで異なるコーデックを使用して、いくつかの同期オーディオトラックを使用してビデオストリームをインテリアするためにグループ化が必要です。一方、チェーンは、アプリケーションのストリーミングによく必要であるように、物理的な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 BitStreamの冒頭に一緒に表示される必要があります。メディアマッピングは、初期ページの順序を指定します。たとえば、特定のOGGビデオとOGGオーディオビットストリームのグループ化は、物理的なビットストリームが論理ビデオビットストリームのBOSページから開始する必要があることを指定する場合があります。BOSページとは異なり、論理的なビットストリームのEOSページは、すべてが連続して発生する必要はありません。EOSページは、「nil」ページ、つまり、コンテンツが含まれていないが、ポジション情報を備えたページヘッダーとページヘッダーに設定されたページヘッダーです。グループ化された各論理ビットストリームには、物理的なビットストリームの範囲内に一意のシリアル番号が必要です。
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つの鎖の物理的なビットストリームがあります。最初は、3つの論理的なビットストリームA、B、およびCのグループ化されたストリームです。2番目の物理的なビットストリームは、最後のEOSの後に終了した後に終了するグループ化されたビットストリームの終了後にチェーンされます。グループ化されたすべての論理ビットストリームのページ。ご覧のとおり、グループ化されたビットストリームは一緒に始まります。すべての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は、各論理的なビットストリームが異なるコーデックに属していることを除いて、コーデックデータに関する詳細を知りません。コーデックのデータは順番で位置マーカー（いわゆる「顆粒位置」）を持っています。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.
OGGを使用したメディアマッピングの特定の定義により、OGG BitStream形式の特定の使用にさらに制約がある場合があります。たとえば、特定のメディアマッピングでは、グループ化されたすべてのビットストリームのすべてのEOSページが直接シーケンスで表示される必要がある場合があります。メディアマッピングの例は、「ogg vorbis」の仕様です。もう1つの例は、Theoraがエンコードされたビデオデータをカプセル化し、通常同期されたオーディオとビデオを含むOGG用のVorbisストリームで多重化される「Ogg Theora」仕様です。OGGは、カプセル化された同時に多重化されたビットストリーム間の一時的な関係を指定していないため、このメディアマッピングでは、オーディオストリームとビデオストリームの間の時間的同期が指定されます。ストリーミングを有効にするために、さまざまな論理的なビットストリームからのページは通常、時系列でインターリーブされます。
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.
さまざまな論理ビットストリームを多重化するプロセスは、上記のようにページのレベルで発生します。ただし、エンコーダーが提供するビットストリームは、エンコード形式に依存するパケット境界を持ついわゆる「パケット」としてOGGに引き渡されます。パケットをページにカプセル化するプロセスについて説明します。
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の観点から見ると、パケットは任意のサイズにすることができます。特定のメディアマッピングは、特定のメディアエンコーダーからパケットをグループ化または分割する方法を定義します。OGGページの最大サイズは約64 kバイトであるため、パケットを数ページで配布する必要がある場合があります。そのプロセスを簡素化するために、OGGは各パケットを255バイトの長いチャンクと最終的な短いチャンクに分割します。これらのチャンクは「OGGセグメント」と呼ばれます。それらは論理的な構成要素であり、自分自身のヘッダーを持っていません。
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バイトを使用し、32 kバイトの最大パケットサイズを持つだけで、常にセグメンテーションオーバーヘッドの2倍の小さなパケット（<255バイト、典型的なケース）をペナルティします。提案されているように、レーシング値を使用して、小さなパケットは、可能な最小バイトアライメントオーバーヘッド（1バイト）と大きなパケット（> 512バイト）を確認します。
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
|セグメンテーション（論理的にのみ）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
|ページカプセル化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.
この例では、1つの論理的なビットストリームのカプセル化プロセスのスナップショットを取ります。Codecが提供するように、そのBitStreamのサブディビジョンの一部をパケットに見ることができます。OGGカプセル化プロセスは、パケットをセグメントにチョップします。この例のパケットは、Packet_1が5つのセグメントに分割されるようにかなり大きいため、255バイトと最終的な小さなセグメントがあります。packet_2は4つのセグメントに分割されます - 255バイトと最後の非常に小さなものを持つ3つのセグメント - パケット_3は2つのセグメントに分割されます。カプセル化プロセスは、この例では非常に小さいページを作成します。page_1は、packet_1の最初の3つのセグメントで構成され、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 kb、最大65307バイトの可変サイズです。ページヘッダーには、物理的なビットストリームから論理的なビットストリームを非難するために必要なすべての情報が含まれています。各ページは、ページデコードメカニズムがビットストリーム全体を必要とせずに一度に1つのページを認識、検証、および処理できるように自己完結型のエンティティです。
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-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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'
0x53 '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：1バイトこのストリームで使用されているOGGファイル形式のバージョン番号を意味します（このドキュメントはバージョン0を指定します）。
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
UNSET：ページには新鮮なパケットが含まれています
* bit 0x02
* ビット0x02
set: this is the first page of a logical bitstream (bos)
セット：これは論理的なビットストリーム（BOS）の最初のページです
unset: this page is not a first page
Unset：このページは最初のページではありません
* bit 0x04
* ビット0x04
set: this is the last page of a logical bitstream (eos)
セット：これは論理的なビットストリーム（EOS）の最後のページです
unset: this page is not a last page
Unset：このページは最後のページではありません
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サンプルの総数が含まれる場合があります。ビデオストリームの場合、このページの後にエンコードされたビデオフレームの総数が含まれる場合があります。これはデコーダーのヒントであり、タイミングと位置情報を提供します。その意味は、その論理的なビットストリームのコーデックに依存し、特定のメディアマッピングで指定されています。-1の特別な値（2つの補数）は、このページでパケットが終了しないことを示します。
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：ページの32ビットCRCチェックサムを含む4バイトフィールド（ゼロCRCフィールドとページコンテンツを備えたヘッダーを含む）。発電機多項式は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]
バイトの合計ヘッダーサイズは、header_size = number_page_segments 27 [byte]によって与えられます。
The total page size in Bytes is given by:
page_size = header_size + sum(lacing_values: 1..number_page_segments)
[Byte]
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.
OGGカプセル化形式はコンテナ形式であり、コンテンツのみをカプセル化します（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ビットストリームに含めることができます。これは、特にOGGがネットワーキングシナリオでストリーミングまたはファイル転送に使用される場合、OGG形式を使用して実装されるアプリケーションの問題になる可能性があります。そのため、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
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ページが表示されなければならないという制限の下で、1つの完全な物理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).
メディアマッピング：OGGカプセル化形式の特定の（セットの）コーデック（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）パケット：そのビットストリームのエンコーダーによって作成され、エンコーダーの意味のあるエンティティを表す論理的なビットストリームのサブパート。
(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つの論理的なビットストリームのみのデータを含む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）ビットストリーム：1つまたは複数の論理的なビットストリームのOGGカプセル化から生じるビットのシーケンス。これは、1つの論理ビットストリームのページが正しい時間的順序で来なければならないという制限を伴う論理的なビットストリームからの一連のページで構成されています。
(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.
（OGG）セグメント：OGGカプセル化プロセスは、各パケットを255バイトのチャンクに加えて、255バイト未満の最後の分数チャンクに分割します。これらのチャンクはセグメントと呼ばれます。
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 Foundationが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 North Ryde、NSW 2113 Australia
Phone: +61 2 9325 3141
EMail: Silvia.Pfeiffer@csiro.au
URI: http://www.cmis.csiro.au/Silvia.Pfeiffer/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。