RFC3533 日本語訳
3533 The Ogg Encapsulation Format Version 0. S. Pfeiffer. May 2003. (Format: TXT=32045 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Pfeiffer Request for Comments: 3533 CSIRO Category: Informational May 2003
コメントを求めるワーキンググループS.ファイファー要求をネットワークでつないでください: 3533年のCSIROカテゴリ: 情報の2003年5月
The Ogg Encapsulation Format Version 0
オッグカプセル化形式バージョン0
Status of this Memo
この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)インターネット協会(2003)。 All rights reserved。
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.
このドキュメントはオッグbitstream形式バージョン0について説明します。(バージョンはメディアの流れのための一般的で、自由に利用可能なカプセル化形式です)。それは単一のbitstreamの他のデータ・ストリームと同様にどんな種類と数のビデオとオーディオのコード化形式も要約できます。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 定義. . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 一般的なカプセル化のための要件は.3 4をフォーマットします。 オッグbitstream形式. . . . . . . . . . . . . . . . . . . 3 5。 カプセル化過程. . . . . . . . . . . . . . . . . . 6 6。 オッグページ形式. . . . . . . . . . . . . . . . . . . . . 9 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 11 8。 用語と略語. . . . . . . . . . . . . 13B.Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 14AuthorのAddress. . . . . . . . . . . . . . . . . . . . . . . 14Full Copyright Statement. . . . . . . . . . . . . . . . . . . 15の参照. . . . . . . . . . . . . . . . . . . . . . . . . . 12A.Glossary
Pfeiffer Informational [Page 1] RFC 3533 OGG May 2003
[1ページ]RFC3533OGG2003年5月の情報のファイファー
1. Introduction
1. 序論
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.
より大きいプロジェクトの一部がマルチメディアコンテント(コーデック)のコード化と自由に利用可能であって、自由に再実行可能なことである解読のための1セットの部品を作成するのを目的としたので、オッグbitstream形式は発生しました、全体のコンピューティング共同体へのソフトウェアとハードウェアの両方、インターネットコミュニティを含んでいて。 それは知的所有権関心なしで使用可能であるというXiph.Orgによって表されたオッグ開発者の意志です。
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、1時までに作成された数個のメディアbitstreamsまたは数個のエンコーダを要約するためにオッグbitstream形式とどうそれを使用するかを説明します。 オッグ輸送bitstreamは生の、そして、非要約のデータ・パケットから成るよりハイレベルのコーデックの流れに縁どり、誤り保護、および探知構造を提供するように設計されています、Vorbisのオーディオのコーデックや今度のTarkinやTheoraビデオコーデックのように。 それは異なった2進のメディアとデータ・パケットの系列としてエンコーダによって準備される他の時間連続したデータ・ストリームをはさみ込むことができます。 オッグは適切にパケット境界を見つけるために解読を当てにしないで元のパケット境界のそのようなエンコーダの作成されたデータ・パケットにデータを切り離して戻すことができるくらいの情報を提供します。
Please note that the MIME type application/ogg has been registered with the IANA [1].
MIMEの種類アプリケーション/oggはIANA[1]に登録されました。
2. Definitions
2. 定義
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.
オッグカプセル化の過程について説明するために、意味がよく理解される必要がある用語一式は使用されるでしょう。 したがって、私たちが一般的なメディア流れのカプセル化形式、カプセル化の過程、およびオッグbitstreamの具体的な形式のための要件の記述から始まる前に最も基本的な用語のいくつかが現在、定義されます。 より完全な用語集に関してAppendixを見てください。
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.
オッグカプセル化の結果は「(オッグ)物理的なBitstream」と呼ばれます。 それは1か数個のエンコーダで作成されたbitstreamsを要約します。(bitstreamsは「論理的なBitstreams」と呼ばれます)。 オッグカプセル化の過程に提供された論理的なbitstreamは構造を持っています、すなわち、それがいわゆる「パケット」の系列に分けられます。 パケットは、その論理的なbitstreamのエンコーダによって作成されて、そのエンコーダだけのために重要な実体を表します(例えば、解凍された流れはパケットとしてビデオフレームを使用するかもしれません)。 それらは境界情報を含んでいません--糸でとめ合わせられて、彼らは、目印のない無作為のバイトの流れであるように見えます。
Pfeiffer Informational [Page 2] RFC 3533 OGG May 2003
[2ページ]RFC3533OGG2003年5月の情報のファイファー
Please note that the term "packet" is not used in this document to signify entities for transport over a network.
「パケット」という用語は、ネットワークの上の輸送のための実体を意味するのに本書では使用されません。
3. Requirements for a generic encapsulation format
3. 一般的なカプセル化形式のための要件
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 論理的なbitstreamsのために、縁どっています。
o interleaving of different logical bitstreams.
o 異なった論理的な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 bitstreamの任意の位置のダイレクトランダムアクセスのために目印を置いてください。
o streaming capability (i.e., no seeking is needed to build a 100%
complete bitstream).
o 能力(すなわち、探すことは100%の完全なbitstreamを造るのに必要でない)を流します。
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 %のbitstreamおよそ帯域幅を使用します)。
o simplicity to enable fast parsing.
o 速く分析しながら可能にする簡単さ。
o simple concatenation mechanism of several physical bitstreams.
o 数個の物理的なbitstreamsの簡単な連結メカニズム。
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.
これらのデザイン問題のすべてがオッグのために考慮に入れられました。 オッグは論理的なbitstreamsの縁どりとインターリービングを支持します、およそ1-2%のオーバーヘッドだけで目印、不正の検出、および構文解析誤りの後の流れの再連動を求めて。 時間連続したbitstreamsのカプセル化を実行するのは、一般的な枠組みです。それが要約して、その結果、どんなメディアコーデックからも独立しているのがコーデックデータに関してどんな詳細も知りません。
4. The Ogg bitstream format
4. オッグbitstream形式
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
物理的なオッグbitstreamはいわゆる「ページ」ではさみ込まれた複数の論理的なbitstreamsから成ります。 ページレベルで多重送信された複数の論理的なbitstreamsから整然とした状態で全体のページを取ります。 論理的なbitstreamsは中でユニークな通し番号によって特定されます。
Pfeiffer Informational [Page 3] RFC 3533 OGG May 2003
[3ページ]RFC3533OGG2003年5月の情報のファイファー
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.
物理的なbitstreamのそれぞれのページのヘッダー。 このユニークな通し番号には、手当たりしだいに創造されて、それが表す論理的なbitstreamの内容かエンコーダには少しの接続もありません。 それらは定時注文にある必要はありません--すべての論理的なbitstreamsのページは同時にはさみ込まれますが、論理的なbitstreamの中に連続するのが必要であるだけです。 オッグ逆多重化は、物理的なbitstreamから物理的なbitstreamから整然としているページ取って、適切な論理的な解読実体にそれらを向け直すことによって、オリジナルの論理的なbitstreamsを再建します。
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).
1論理的なbitstreamだけに属すとき、それぞれのオッグページは1つのタイプに関するデータだけを含んでいます。 ページには、可変サイズがあって、カプセル化とエラー回復情報を含むページヘッダーがあります。 物理的なオッグbitstreamのそれぞれの論理的なbitstreamは特別なスタートページ(流れの棒=始まり)から始まって、特別なページ(流れの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.
棒ページは、唯一コーデックタイプを特定する情報を含んでいて、解読過程に設定する情報を含むかもしれません。 また、棒ページSHOULDはコード化されたメディアの情報を含んでいます--例えば、オーディオのために、それはチャンネルの見本郵送料率と数を含むべきです。 コンベンションで、棒ページの最初のバイトは唯一必要なコーデックを特定する魔法のデータを含みます。使用中の他のすべてのコーデックとその人のコーデックを確かに区別するのが可能であることを確実にするのは、だれでも新しいコーデックをさばく責任です。 コーデックの終わりがマーカーを特定するのを検出する固定方法が全くありません。 形式、棒では、ページにコーデックに依存していて、したがって、その論理的なbitstreamタイプのカプセル化仕様で与えなければなりません。 許容しますが、論理的なbitstreamsとこれらのための棒ページがどんな論理的なbitstreamのどんなデータ・パケットにも先行しなければならなかった後にもオッグも二次ヘッダーパケットを必要としません。 これらのその後のヘッダーパケットは整数のページに縁どられます。(ページは少しのデータ・パケットも含まないでしょう)。 それで、すべての論理的なbitstreamsの棒ページが1データ・パケットを含むページがあとに続いたすべての流れの補助のヘッダーパケットがあとに続いたページあたり1つの初期のヘッダーパケットを含んでいて、物理的なbitstreamは始まります。
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論理的なbitstreamsのためのカプセル化仕様は「メディアマッピング」と呼ばれます。 メディアマッピングのための例は流れのベースの格納(ファイルなどの)と輸送(TCPの流れかパイプなどの)のためのVorbisによってコード化されたオーディオデータを要約するのにオッグ枠組みを使用する「オッグ・ボルビス」です。 オッグVorbisはオッグ・ボルビス棒ページのVorbisコーデックの名前と改正、オーディオレート、およびオーディオ音質を提供します。 また、それは論理的なbitstreamあたり追加2ヘッダーページを使用します。 "vorbis"(合計7バイトの識別子)によって続かれて、オッグ・ボルビス棒ページはバイト0x01から始まります。
Pfeiffer Informational [Page 4] RFC 3533 OGG May 2003
[4ページ]RFC3533OGG2003年5月の情報のファイファー
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.
オッグは2つのタイプのマルチプレクシングを知っています: 同時発生のマルチプレクシング(そのように「分類している」と呼ばれる)と連続したマルチプレクシング(いわゆる「推論」)。 組分けは数個の論理的なbitstreamsページ同じくらいで的な物理的なbitstreamをはさみ込む方法を定義します。 組分けは、例えば、他方では、数台の連動したオーディオトラックが異なった論理的なbitstreams推論に異なったコーデックを使用している状態でビデオストリームをはさみ込むのに必要であり、物理的なオッグbitstreamsを連結するように簡単なメカニズムを提供するために定義されます、しばしばストリーミング・アプリケーションに必要であるように。
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.
組分けでは、すべての論理的なbitstreamsのすべての棒ページがオッグbitstreamの始めに一緒に現れなければなりません。 メディアマッピングはイニシャルページの注文を指定します。 例えば物理的なbitstreamが論理的なビデオbitstreamの棒ページで始めなければならないbitstreamが指定するかもしれない特定のオッグビデオとオッグオーディオの組分けはオーディオのbitstreamの棒ページで続きました。 棒ページと異なって、論理的なbitstreamsのためのeosページは近接してすべて起こる必要はありません。 エオスページは'無い'ページであるかもしれません(すなわち、単に情報とeos旗がページヘッダーに設定する位置があるページヘッダー以外の内容を全く含まないページ)。 それぞれの分類された論理的なbitstreamは物理的なbitstreamの範囲の中にユニークな通し番号を持たなければなりません。
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.
推論では、完全な論理的なbitstreamsは連結されます。 bitstreamsは重なりません、すなわち、次の棒ページがすぐに、与えられた論理的なbitstreamのeosページのあとに続きます。 それぞれのチェーニングされた論理的なbitstreamは物理的なbitstreamの範囲の中にユニークな通し番号を持たなければなりません。
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.
連続して同時に多重送信されたbitstreamsのグループをチェーニングするのは可能です。鎖を解かれると、グループは有効な同時に多重送信されたbitstreamとして一人で立たなければなりません。 以下のダイヤグラムは、両方のすべての規則に従うそのような物理的なbitstreamの概要の例が多重送信された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
異なった論理的なbitstreamsのページが分類されて、チェーニングされている物理的なbitstream------------------------------------------------------------- |**|*B*|*C*|A|A|C|B|A|B|##|C|...|B|C|#B#|#C#|*D*|D|...|#D#| ------------------------------------------------------------- 棒棒棒eos eos eos棒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
この例には、それの1番目が3の論理的なbitstreams Aの分類された流れである2チェーニングされた物理的なbitstreamsがあります、B、C. 2番目の物理的なbitstreamは分類されたbitstreamの端の後にチェーニングされます。bitstreamはすべての分類された論理的なbitstreamsの最後のeosページの後に終わります。分類されたbitstreamsは見ることができるように始まります。
Pfeiffer Informational [Page 5] RFC 3533 OGG May 2003
[5ページ]RFC3533OGG2003年5月の情報のファイファー
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.
優に棒ページは以前、どんなデータページ一緒に、現れなければなりません。 また、同時に多重送信されたbitstreamsのページが定時注文に従う必要はないのを見ることができます。 そして、分類されたbitstreamが他のbitstreamsのずっと前にグループ終わりで終わることができるのを見ることができます。
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.
それぞれの論理的なbitstreamが異なったコーデックに属す以外に、オッグがコーデックデータに関してどんな詳細も知らないで、コーデックからのデータには、整然とするようになって、位置のマーカー(いわゆる「小さな粒位置」)があります。 オッグには、'時間'の概念がありません: それは、およそ連続して増加して、unitlessがマーカーを置くのを知っているだけです。 アプリケーションは小さな粒位置を割り当てて、変換するためにコーデック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.
オッグを使用するメディアマッピングの特定の定義はオッグbitstream形式の特定的用法に更なる規制を置くかもしれません。 例えば、特定のメディアマッピングは、すべてのためのすべてのeosページがダイレクト系列に現れるbitstreamsの必要性を分類したのを必要とするかもしれません。 メディアマッピングのための例は「オッグ・ボルビス」の仕様です。 別の例はTheoraによってコード化されたビデオ・データを要約して、通常、オッグのためのVorbisの流れが連動したオーディオとビデオを含んでいて多重送信していた状態で来る今度の「オッグ・セオラ」仕様です。 オッグが要約の同時に多重送信されたbitstreamsの間の時の関係を指定しないとき、オーディオとビデオストリームの間の時の連動はこのメディアマッピングで指定されるでしょう。 ストリーミングを可能にするために、様々な論理的なbitstreamsからのページは年代順に通常はさみ込まれるでしょう。
5. The encapsulation process
5. カプセル化の過程
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.
異なった論理的なbitstreamsを多重送信する過程は上で説明されるようにページのレベルで起こります。 しかしながら、エンコーダによって提供されたbitstreamsはいわゆる「パケット」としてコード化形式に依存するパケット境界でオッグに引き渡されます。 パケットをページにカプセルに入れる過程は現在、説明されるでしょう。
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.
オッグの見解から、パケットはどんな任意のサイズのものであることができます。 特定のメディアマッピングは特定のメディアエンコーダからパケットを分類するか、または壊れさせる方法を定義するでしょう。 オッグページにおよそ64kBytesの最大サイズがあるとき、時々、パケットは数ページの上に分配されなければなりません。 その過程を簡素化するために、オッグは各パケットを長さ255バイトの塊と最終的なより短い塊に分割します。 これらの塊は「オッグSegments」と呼ばれます。 彼らには、論理的な構造物だけであり、自分たちのためのヘッダーがありません。
Pfeiffer Informational [Page 6] RFC 3533 OGG May 2003
[6ページ]RFC3533OGG2003年5月の情報のファイファー
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.
隣接のセグメントのグループはヘッダーによって先行された可変長ページに包装されます。 ページにセグメントの(サイズ)を含んでいて、ページヘッダーのセグメントテーブルは「ひもで締まる値」に関して話します。 ページヘッダーの旗は、1ページが前のページから続けられていたパケットを含むかどうか言います。 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バイトを使用して、32kBytesの最大パケットサイズを持っていると、小型小包(<255バイト、典型的なケース)は分割オーバーヘッドの2倍でいつも罰せられるでしょう。 示されて、小さいパケットが見るようにひもで締まる値を使用して、最小の可能なバイトはスペースをコード化するとき(>512バイト)が頭上をかなり一定の~0.5%見る頭上(1バイト)の、そして、大きいパケットを並べました。
Pfeiffer Informational [Page 7] RFC 3533 OGG May 2003
[7ページ]RFC3533OGG2003年5月の情報のファイファー
The following diagram shows a schematic example of a media mapping using Ogg and grouped logical bitstreams:
以下のダイヤグラムはオッグと分類された論理的なbitstreamsを使用することでメディアマッピングの概要の例を示しています:
logical bitstream with packet boundaries
-----------------------------------------------------------------
> | packet_1 | packet_2 | packet_3 | <
-----------------------------------------------------------------
パケット境界がある論理的なbitstream----------------------------------------------------------------- >| パケット_1| パケット_2| パケット_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 | ..
------------------------------ -------------------- ------------
パケット_1(5つのセグメント)パケット_2(4segs)p_3(2segs)------------------------------ -------------------- ------------ .. |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|------------------- | ------------------------ ---------------- ------------------------
_2(pket_1データ)ページのページ_1(パケット_1データ)ページの_3(パケット_2データ)------------------------ ---------------- ------------------------ |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
| ページ| 他--------| | 当然------- bitstreams| 多重化装置| ------- | v
page_1 page_2 page_3
------ ------ ------- ----- -------
... || | || | || | || | || | ...
------ ------ ------- ----- -------
physical Ogg bitstream
_2ページのページ_1ページの_3------ ------ ------- ----- ------- ... || | || | || | || | || | ... ------ ------ ------- ----- ------- 物理的なオッグ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
この例では、私たちは1論理的なbitstreamのカプセル化の過程のスナップを取ります。 私たちはコーデックで提供するようにそのbitstreamの下位区分の一部をパケットに見ることができます。オッグカプセル化の過程はパケットをセグメントに細かく切ります。 この例のパケットがかなり大きいので、パケット_1は5つのセグメントに分けられます--255バイトがある4つのセグメントと最終的なより小さいもの。 パケット_2は4つのセグメントに分けられます--3は255でバイトとaを区分します。
Pfeiffer Informational [Page 8] RFC 3533 OGG May 2003
[8ページ]RFC3533OGG2003年5月の情報のファイファー
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.
最終的な非常に小さいもの、およびパケット_3は2つのセグメントに分けられます。 そして、カプセル化の過程はページを作成します。(ページはこの例でかなり小さいです)。 ページ_1はパケット_1の最初の3つのセグメントから成ります、そして、ページ_2はパケット_1からの残っている2つのセグメントを含んでいます、そして、ページ_3は最初の3ページのパケット_2を含んでいます。 最終的に、他の論理的なbitstreamsのページがある物理的なオッグbitstreamにこの論理的なbitstreamを多重送信します。
6. The Ogg page format
6. オッグページ形式
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.
物理的なオッグbitstreamは連結されたページの系列から成ります。 ページは可変サイズ、通常4-8kB、最大の65307バイトのものです。 ページヘッダーは物理的なbitstreamから論理的なbitstreamsを反多重送信して、探知のために基本的なエラー回復と目印を実行するのに必要であるすべての情報を含んでいます。 各ページ単位で、総合的なbitstreamを必要としないで、ページは、自己完結的な存在がそのようなものであるので、一度に、1ページを缶が認識するメカニズムを解読して、確かめて、扱います。
The Ogg page header has the following format:
オッグページヘッダーには、以下の形式があります:
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| バイト+++++++++++++++++++++++++++++++++| _パターンを得てください: スタート「OggS」というページマジックナンバー| 0-3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| ヘッダー_タイプ| 小さな粒_位置| 4-7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 8-11 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | bitstream_シリーズ_番号| 12-15 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ページ_系列_番号| 16-19 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | CRC_チェックサム| 20-23 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |ページ_セグメント| セグメント_テーブル| 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(最下位ビット)はBytesで一番になります。 最初に、1バイト以上の長さがある分野はコード化されたLSB(最も重要でないバイト)です。
Pfeiffer Informational [Page 9] RFC 3533 OGG May 2003
[9ページ]RFC3533OGG2003年5月の情報のファイファー
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. _パターンを得てください: 1ページの始まりを意味する4Byte分野。 それはマジックナンバーを含んでいます:
0x4f 'O'
0x4f'O'
0x67 'g'
'0×67g'
0x67 'g'
'0×67g'
0x53 'S'
0×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. _構造_バージョンを流してください: この流れ(このドキュメントはバージョン0を指定する)に使用されるオッグファイル形式のバージョン番号を意味する1バイト。
3. header_type_flag: the bits in this 1 Byte field identify the
specific type of this page.
3. ヘッダー_タイプ_は弛みます: この1つのByte分野のビットはこのページの特定のタイプを特定します。
* 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)
以下を設定してください。 これは論理的なbitstreamの最初のページです。(棒)
unset: this page is not a first page
unset: このページは最初のページではありません。
* bit 0x04
* ビット0x04
set: this is the last page of a logical bitstream (eos)
以下を設定してください。 これは論理的なbitstreamの終面です。(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
4. 小さな粒_位置: 位置の情報を含む8Byte分野。 例えば、オーディオストリームのために、それはこのページで終わっているすべてのフレームを含んだ後にコード化されたPCMのサンプルの総数を含むかもしれません。 ビデオストリームのために、それはビデオの総数を含むかもしれません。
Pfeiffer Informational [Page 10] RFC 3533 OGG May 2003
[10ページ]RFC3533OGG2003年5月の情報のファイファー
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.
フレームはこの後、ページをコード化しました。 これは、デコーダのためのヒントであり、何らかのタイミングと位置の情報をそれに教えます。 意味は、その論理的なbitstreamにおいてコーデックに依存して特定のメディアマッピングで指定されています。 -1(2の補数における)の特別な値は、パケットが全くこのページで終わらないのを示します。
5. bitstream_serial_number: a 4 Byte field containing the unique
serial number by which the logical bitstream is identified.
5. bitstream_シリーズ_番号: 論理的なbitstreamが特定されるユニークな通し番号を含む4Byte分野。
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. ページ_系列_番号: デコーダがページの損失を特定できるようにページの一連番号を含む4Byte分野。 この一連番号は別々にそれぞれの論理的なbitstreamで増加しています。
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_チェックサム: ページ(CRCがさばくゼロとページ内容でヘッダーを含んでいる)の32ビットのCRCチェックサムを含む4Byte分野。 ジェネレータ多項式は0x04c11db7です。
8. number_page_segments: 1 Byte giving the number of segment entries
encoded in the segment table.
8. 数の_ページ_セグメント: セグメントテーブルでコード化されたセグメントエントリーの数を与える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. セグメント_テーブル: このページのすべてのセグメントのひもで締まる値を含む数の_ページ_セグメントBytes。 各Byteは1つのひもで締まる値を含んでいます。
The total header size in bytes is given by: header_size = number_page_segments + 27 [Byte]
以下はバイトで表現される総ヘッダーサイズを与えます。 ヘッダー_サイズは数の_ページ_セグメント+27と等しいです。[バイト]
The total page size in Bytes is given by: page_size = header_size + sum(lacing_values: 1..number_page_segments) [Byte]
以下はBytesの総ページ・サイズを与えます。 ページ_サイズ=ヘッダー_サイズ+合計(ひもで締まる_値: 1..number_ページ_セグメント)[バイト]
7. Security Considerations
7. セキュリティ問題
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によってコード化されたオーディオなどの)を要約するだけです。 それはどんな一般的な暗号化、それ自体の調印または含まれた内容bitstreamsにも備えません。しかしながら、それは、それのためのコーデックがある限り、どんな種類の内容bitstreamも要約して、その結果、コード化されてサインされた満足しているデータを含むことができます。 それは、また、オッグのために物理的なbitstreamにコード化するか、またはサインする対外安全保障メカニズムを加えるのにおいて可能であり、その結果、満足している秘密性と信憑性を提供します。
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
オッグが2進のデータを要約するとき、オッグbitstreamの実行可能な内容を含んでいるのは可能です。 これはオッグがストリーミングかファイル転送に特に使用されるときネットワークシナリオでオッグ形式を使用することで実行されるアプリケーションの問題であるかもしれません。 as
Pfeiffer Informational [Page 11] RFC 3533 OGG May 2003
[11ページ]RFC3533OGG2003年5月の情報のファイファー
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.
そのようなもの、オッグはそこで脅威を引き起こしません。 しかしながら、オッグを解読するアプリケーションと要約の内容bitstreamsは操られたbitstreams、バッファオーバーフローと同様のものの正しい取り扱いを確実にしなければなりません。
8. References
8. 参照
[1] Walleij, L., "The application/ogg Media Type", RFC 3534, May
2003.
L.、「アプリケーション/oggメディアType」、RFC3534 2003年5月の[1]Walleij。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Pfeiffer Informational [Page 12] RFC 3533 OGG May 2003
[12ページ]RFC3533OGG2003年5月の情報のファイファー
Appendix A. Glossary of terms and abbreviations
用語と略語の付録A.Glossary
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.
棒ページ: コーデックタイプを特定する情報と他の解読関連している情報を含む論理的なbitstreamのイニシャルページ(流れの始まり)。
chaining (or sequential multiplexing): Concatenation of two or more
complete physical Ogg bitstreams.
推論(または、連続したマルチプレクシング): 2以上精密検査オッグbitstreamsの連結。
eos page: The final page (end of stream) of a logical bitstream.
eosページ: 論理的なbitstreamの最終的なページ(流れの終わり)。
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.
小さな粒位置: ページヘッダーに格納された特定の論理的なbitstreamの増加する位置の番号。 意味は、その論理的なbitstreamにおいてコーデックに依存して特定のメディアマッピングで指定されています。
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.
組分け(または、同時発生のマルチプレクシング): すべての棒ページのすべてが論理的なbitstreamsを分類したという制限での1つの精密検査のオッグbitstreamへの数個の論理的なbitstreamsのページのインターリービングは以前、どんなデータページ現れなければなりません。
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.
論理的なbitstream: コード化されたメディアの流れの結果であるビットの系列。
media mapping: A specific use of the Ogg encapsulation format
together with a specific (set of) codec(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.
(オッグ)パケット: しかし、そのbitstreamのためにエンコーダによって作成されて、エンコーダのために重要な実体を表す論理的なbitstreamの下位区分、オッグカプセル化へのビットの系列だけ。
(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.
(オッグ)ページ: 物理的なbitstreamは1論理的なbitstreamだけに関するデータを含むオッグページの系列から成ります。 通常、それが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.
物理的な(オッグ)bitstream: 数個の論理的なbitstreams1のオッグカプセル化から生じるビットかそれの系列は1論理的なbitstreamのページが彼らの正しい時のオーダーに入らなければならないという制限で論理的なbitstreamsからのページの系列から成ります。
Pfeiffer Informational [Page 13] RFC 3533 OGG May 2003
[13ページ]RFC3533OGG2003年5月の情報のファイファー
(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基礎がオッグマルチメディアプロジェクトを定義して、それの一部として本書では説明されたオープン・ファイル形式をした仕事を承諾します。 作者は、このドキュメントをインターネットコミュニティに提供するのが、 http://www.xiph.org/ でオッグマルチメディアプロジェクトを助成するのを手伝うことを望んでいます。また、C.モンゴメリとオッグ社会がフィードバックとしてこのRFCに供給した多くの技術的、そして、誤植修正ありがとうございます。
Author's Address
作者のアドレス
Silvia Pfeiffer CSIRO, Australia Locked Bag 17 North Ryde, NSW 2113 Australia
シルビアファイファーCSIRO、オーストラリア鍵をかけた袋17の北のNSW2113ライド(オーストラリア)
Phone: +61 2 9325 3141 EMail: Silvia.Pfeiffer@csiro.au URI: http://www.cmis.csiro.au/Silvia.Pfeiffer/
以下に電話をしてください。 +61 2 9325 3141はメールされます: Silvia.Pfeiffer@csiro.au ユリ: http://www.cmis.csiro.au/Silvia.Pfeiffer/
Pfeiffer Informational [Page 14] RFC 3533 OGG May 2003
[14ページ]RFC3533OGG2003年5月の情報のファイファー
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Pfeiffer Informational [Page 15]
ファイファーInformationalです。[15ページ]
一覧
スポンサーリンク
