[譯]Ogg bitstream overview

Ogg bitstream overview原文

Ogg bitstream overview

This document serves as starting point for understanding the design and implementation of the Ogg container format. If you're new to Ogg or merely want a high-level technical overview, start reading here. Other documents linked from the index page give distilled technical descriptions and references of the container mechanisms. This document is intended to aid understanding. 本文檔是瞭解Ogg容器格式的設計和實現的起點。若是您是Ogg的新手，或者只是想要高級技術概述，請在這裏開始閱讀。從索引頁面連接的其餘文檔提供了精煉的技術說明和容器機構的參考。本文檔旨在幫助理解。

Container format design points

Ogg is intended to be a simplest-possible container, concerned only with framing, ordering, and interleave. It can be used as a stream delivery mechanism, for media file storage, or as a building block toward implementing a more complex, non-linear container (for example, see the Skeleton or Annodex/CMML). Ogg旨在成爲最簡單的容器，僅關注成幀，排序和交錯。它能夠用做流傳輸機制，用於媒體文件存儲，也能夠用做實現更復雜的非線性容器的構建塊（例如，參見Skeleton或Annodex / CMML）。 The Ogg container is not intended to be a monolithic 'kitchen-sink'. It exists only to frame and deliver in-order stream data and as such is vastly simpler than most other containers. Elementary and multiplexed streams are both constructed entirely from a single building block (an Ogg page) comprised of eight fields totalling twenty-eight bytes (the page header) a list of packet lengths (up to 255 bytes) and payload data (up to 65025 bytes). The structure of every page is the same. There are no optional fields or alternate encodings. Ogg容器不能用做總體式「廚房水槽」。它僅用於幀和按順序傳輸流數據，所以比大多數其餘容器要簡單得多。基本流和多路複用流都徹底由單個構建塊（一個Ogg頁）構成，該構建塊由八個字段組成，這些字段總計28個字節（頁面標頭），數據包長度列表（最多255個字節）和有效負載數據（最多65025個）個字節）。每一個頁面的結構都相同。沒有可選字段或替代編碼。 Stream and media metadata is contained in Ogg and not built into the Ogg container itself. Metadata is thus compartmentalized and layered rather than part of a monolithic design, an especially good idea as no two groups seem able to agree on what a complete or complete-enough metadata set should be. In this way, the container and container implementation are isolated from unnecessary metadata design flux. 流和媒體元數據包含在Ogg中，而不是內置在Ogg容器中。所以，元數據是分隔的和分層的，而不是總體設計的一部分，這是一個特別好的主意，由於彷佛沒有兩個小組可以就完整的或足夠足夠的元數據集達成共識。這樣，容器和容器實現與沒必要要的元數據設計流隔離開來。

Streaming

The Ogg container is primarily a streaming format, encapsulating chronological, time-linear mixed media into a single delivery stream or file. The design is such that an application can always encode and/or decode all features of a bitstream in one pass with no seeking and minimal buffering. Seeking to provide optimized encoding (such as two-pass encoding) or interactive decoding (such as scrubbing or instant replay) is not disallowed or discouraged, however no container feature requires nonlinear access of the bitstream. Ogg容器主要是一種流格式，將按時間順序，時間線性的混合媒體封裝到單個傳遞流或文件中。這種設計使得應用程序始終能夠在一次遍歷中對比特流的全部特徵進行編碼和/或解碼，而無需尋找和最小化緩衝。尋求或建議不要提供優化的編碼（例如兩次經過編碼）或交互式解碼（例如清理或即時重放），可是沒有容器功能須要對位流進行非線性訪問。

Variable Bit Rate, Variable Payload Size

Ogg is designed to contain any size data payload with bounded, predictable efficiency. Ogg packets have no maximum size and a zero-byte minimum size. There is no restriction on size changes from packet to packet. Variable size packets do not require the use of any optional or additional container features. There is no optimal suggested packet size, though special consideration was paid to make sure 50-200 byte packets were no less efficient than larger packet sizes. The original design criteria was a 2% overhead at 50 byte packets, dropping to a maximum working overhead of 1% with larger packets, and a typical working overhead of .5-.7% for most practical uses. Ogg被設計爲包含任何大小的數據有效載荷，而且效率是有限的。 Ogg數據包沒有最大大小，最小字節數爲零。對每一個數據包的大小變化沒有限制。可變大小的數據包不須要使用任何可選的或附加的容器功能。儘管要特別注意確保50-200字節的數據包不比較大的數據包有效，但沒有建議的最佳數據包大小。最初的設計標準是50字節數據包的開銷爲2％，對於較大的數據包，最大開銷爲1％，對於大多數實際用途，典型的工做開銷爲0.5-0.7％。

Simple pagination

Ogg is a byte-aligned container with no context-dependent, optional or variable-length fields. Ogg requires no repacking of codec data. The page structure is written out in-line as packet data is submitted to the streaming abstraction. In addition, it is possible to implement both Ogg mux and demux as MT-hot zero-copy abstractions (as is done in the Tremor sourcebase). Ogg是一個字節對齊的容器，沒有上下文相關的，可選的或可變長度的字段。 Ogg不須要從新包裝編解碼器數據。當分組數據被提交給流抽象時，頁面結構被內聯地寫出。此外，還能夠將Ogg多路複用器和demux都實現爲MT熱零拷貝抽象（在Tremor源庫中完成）。

Capture

Ogg is designed for efficient and immediate stream capture with high confidence. Although packets have no size limit in Ogg, pages are a maximum of just under 64kB meaning that any Ogg stream can be captured with confidence after seeing 128kB of data or less [worst case; typical figure is 6kB] from any random starting point in the stream. Ogg旨在高置信度地進行高效，即時的流捕獲。儘管數據包在Ogg中沒有大小限制，可是頁面的最大值最大不到64kB，這意味着在看到128kB或更小的數據後，能夠放心地捕獲任何Ogg流。從流中任意隨機起點算起的典型數字是6kB]。

Seeking

Ogg implements simple coarse- and fine-grained seeking by design. Ogg經過設計實現了簡單的粗粒度和細粒度搜索。 Coarse seeking may be performed by simply 'moving the tone arm' to a new position and 'dropping the needle'. Rapid capture with accompanying timecode from any location in an Ogg file is guaranteed by the stream design. From the acquisition of the first timecode, all data needed to play back from that time code forward is ahead of the stream cursor. 粗略搜索能夠經過簡單地「將音調臂移至新位置並放下針」來執行。流設計可確保從Ogg文件中的任何位置快速捕獲附帶的時間碼。從獲取第一個時間碼開始，從該時間碼開始播放所需的全部數據都在流遊標以前。 Ogg implements full sample-granularity seeking using an interpolated bisection search built on the capture and timecode mechanisms used by coarse seeking. As above, once a search finds the desired timecode, all data needed to play back from that time code forward is ahead of the stream cursor. Ogg使用插值二分搜索來實現完整的樣本粒度搜索，該插值二分搜索基於粗搜索使用的捕獲和時間碼機制。如上所述，一旦搜索找到所需的時間碼，則從該時間碼開始播放所需的全部數據都在流遊標以前。 Both coarse and fine seeking use the page structure and sequencing inherent to the Ogg format. All Ogg streams are fully seekable from creation; seekability is unaffected by truncation or missing data, and is tolerant of gross corruption. Seek operations are neither 'fuzzy' nor heuristic. 粗略查找和精細查找都使用Ogg格式固有的頁面結構和排序。全部Ogg流均可以從建立中徹底查找；可搜索性不受截斷或丟失數據的影響，而且能夠容忍嚴重腐敗。搜尋操做既不「模糊」也不啓發式。 Seeking without use of an index is a major point of the Ogg design. There two primary reasons why Ogg transport forgoes an index: 不使用索引進行查找是Ogg設計的重點。 Ogg傳輸放棄索引的主要緣由有兩個：

1. An index is only marginally useful in Ogg for the complexity added; it adds no new functionality and seldom improves performance noticeably. Empirical testing shows that indexless interpolation search does not require many more seeks in practice than using an index would.對於增長的複雜度，索引在Ogg中僅是微不足道的。它沒有添加任何新功能，不多會顯着提升性能。經驗測試代表，與使用索引相比，無索引內插搜索實際上不須要更多的搜索。
2. 'Optional' indexes encourage lazy implementations that can seek only when indexes are present, or that implement indexless seeking only by building an internal index after reading the entire file beginning to end. This has been the fate of other containers that specify optional indexing.「可選」索引鼓勵懶惰的實現，這些實現只能在存在索引的狀況下才進行查找，或者僅經過在讀取整個文件後從頭開始構建內部索引來實現無索引的查找。這是其餘指定可選索引的容器的命運。 In addition, it must be possible to create an Ogg stream in a single pass. Although an optional index can simply be tacked on the end of the created stream, some software groups object to end-positioned indexes and claim to be unwilling to support indexes not located at the stream beginning. 此外，必須有可能在一次經過中建立Ogg流。儘管能夠將可選索引簡單地添加到建立的流的末尾，可是某些軟件組反對放置在末尾的索引，並聲稱不肯意支持不在流開頭的索引。 All this said, it's become clear that an optional index is a demanded feature. For this reason, the OggSkeleton now defines a proposed index. 綜上所述，很明顯，可選索引是必需的功能。所以，OggSkeleton如今定義了建議的索引。

Simple multiplexing

Ogg multiplexes streams by interleaving pages from multiple elementary streams into a multiplexed stream in time order. The multiplexed pages are not altered. Muxing an Ogg AV stream out of separate audio, video and data streams is akin to shuffling several decks of cards together into a single deck; the cards themselves remain unchanged. Demultiplexing is similarly simple (as the cards are marked). Ogg經過按時間順序未來自多個基本流的頁面交錯到一個多路複用的流中來多路複用流。多路複用的頁面不會更改。將Ogg AV流從單獨的音頻，視頻和數據流中混合出來，相似於將幾副紙牌一塊兒洗牌成一個紙牌。卡自己保持不變。解複用一樣簡單（如已標記卡）。 The goal of this design is to make the mux/demux operation as trivial as possible to allow live streaming systems to build and rebuild streams on the fly with minimal CPU usage and no additional storage or latency requirements. 該設計的目的是使複用/解複用操做盡量地簡單，以容許實時流系統在不佔用額外存儲空間或等待時間的狀況下，以最少的CPU使用率即時構建和重建流。

Continuous and Discontinuous Media

Ogg streams belong to one of two categories, "Continuous" streams and "Discontinuous" streams. Ogg流屬於「連續」流和「不連續」流兩類之一。 A stream that provides a gapless, time-continuous media type with a fine-grained timebase is considered to be 'Continuous'. A continuous stream should never be starved of data. Examples of continuous data types include broadcast audio and video. 提供具備細粒度時基的無間隙，時間連續的媒體類型的流被認爲是「連續的」。連續的數據流永遠不會餓死數據。連續數據類型的示例包括廣播音頻和視頻。 A stream that delivers data in a potentially irregular pattern or with widely spaced timing gaps is considered to be 'Discontinuous'. A discontinuous stream may be best thought of as data representing scattered events; although they happen in order, they are typically unconnected data often located far apart. One example of a discontinuous stream types would be captioning such as Ogg Kate. Although it's possible to design captions as a continuous stream type, it's most natural to think of captions as widely spaced pieces of text with little happening between. 以潛在的不規則模式或間隔較大的時間間隔傳送數據的流被認爲是「不連續的」。最好將不連續流視爲表明分散事件的數據。儘管它們是按順序發生的，但它們一般是一般彼此相距很遠的未鏈接數據。不連續流類型的一個示例是字幕，例如Ogg Kate。儘管能夠將字幕設計爲連續流類型，但將字幕視爲間隔很遠的文本片斷卻不多發生是很天然的。 The fundamental reason for distinction between continuous and discontinuous streams concerns buffering. 區分連​​續流和不連續流的根本緣由與緩衝有關。

Buffering

A continuous stream is, by definition, gapless. Ogg buffering is based on the simple premise of never allowing an active continuous stream to starve for data during decode; buffering works ahead until all continuous streams in a physical stream have data ready and no further. 根據定義，連續流是無間隙的。 Ogg緩衝基於這樣一個簡單的前提：在解碼過程當中，永遠不容許活動的連續流餓數據。緩衝將繼續工做，直到物理流中的全部連續流都準備好數據爲止。 Discontinuous stream data is not assumed to be predictable. The buffering design takes discontinuous data 'as it comes' rather than working ahead to look for future discontinuous data for a potentially unbounded period. Thus, the buffering process makes no attempt to fill discontinuous stream buffers; their pages simply 'fall out' of the stream when continuous streams are handled properly. 不連續的流數據不被認爲是可預測的。緩衝設計「按需」獲取不連續數據，而不是提早進行工做以尋找可能不受限制的未來的不連續數據。所以，緩衝過程不會嘗試填充不連續的流緩衝區。若是正確地處理了連續流，它們的頁面只會從流中「掉出來」。 Buffering requirements in this design need not be explicitly declared or managed in the encoded stream. The decoder simply reads as much data as is necessary to keep all continuous stream types gapless and no more, with discontinuous data processed as it arrives in the continuous data. Buffering is implicitly optimal for the given stream. Because all pages of all data types are stamped with absolute timing information within the stream, inter-stream synchronization timing is always maintained without the need for explicitly declared buffer-ahead hinting. 此設計中的緩衝要求不須要在編碼流中明確聲明或管理。解碼器簡單地讀取所需的數據，以使全部連續流類型保持無間隙且再也不中斷，並在到達連續數據時處理不連續的數據。對於給定的流，緩衝是隱式最佳的。因爲全部數據類型的全部頁面都在流中標記有絕對定時信息，所以始終保持流間同步定時，而無需顯式聲明的提早緩衝提示。

Codec metadata

Ogg does not replicate codec-specific metadata into the mux layer in an attempt to make the mux and codec layer implementations 'fully separable'. Things like specific timebase, keyframing strategy, frame duration, etc, do not appear in the Ogg container. The mux layer is, instead, expected to query a codec through a centralized interface, left to the implementation, for this data when it is needed. Ogg不會將特定於編解碼器的元數據複製到mux層中，以嘗試使mux和codec層實現「徹底可分離」。諸如特定時基，關鍵幀策略，幀持續時間等之類的內容不會出如今Ogg容器中。相反，指望複用器層經過集中式接口查詢編解碼器，該接口留給實現，以在須要時對此數據進行查詢。 Though modern design wisdom usually prefers to predict all possible needs of current and future codecs then embed these dependencies and the required metadata into the container itself, this strategy increases container specification complexity, fragility, and rigidity. The mux and codec code becomes more independent, but the specifications become logically less independent. A codec can't do what a container hasn't already provided for. Novel codecs are harder to support, and you can do fewer useful things with the ones you've already got (eg, try to make a good splitter without using any codecs. Such a splitter is limited to splitting at keyframes only, or building yet another new mechanism into the container layer to mark what frames to skip displaying). 儘管現代設計智慧一般傾向於預測當前和未來編解碼器的全部可能需求，而後將這些依賴關係和所需的元數據嵌入容器自己，可是這種策略會增長容器規範的複雜性，脆弱性和剛性。多路複用器和編解碼器代碼變得更加獨立，可是規範在邏輯上變得不那麼獨立。編解碼器沒法執行容器還沒有提供的操做。新型編解碼器更難支持，而且您能夠用已有的編解碼器作更少的有用的事情（例如，嘗試不使用任何編解碼器而製做一個好的拆分器。此類拆分器僅限於僅在關鍵幀處拆分或構建容器層中的另外一種新機制能夠標記要跳過的幀。 Ogg's design goes the opposite direction, where the specification is to be as simple, easy to understand, and 'proofed' against novel codecs as possible. When an Ogg mux layer requires codec-specific information, it queries the codec (or a codec stub). This trades a more complex implementation for a simpler, more flexible specification. Ogg的設計朝着相反的方向發展，即規範要儘量簡單，易於理解，並儘量抵制新型編解碼器。當Ogg Mux層須要特定於編解碼器的信息時，它將查詢編解碼器（或編解碼器存根）。這將更復雜的實現換成更簡單，更靈活的規範。

Stream structure metadata

The Ogg container itself does not define a metadata system for declaring the structure and interrelations between multiple media types in a muxed stream. That is, the Ogg container itself does not specify data like 'which steam is the subtitle stream?' or 'which video stream is the primary angle?'. This metadata still exists, but is stored by the Ogg container rather than being built into the Ogg container itself. Xiph specifies the 'Skeleton' metadata format for Ogg streams, but this decoupling of container and stream structure metadata means it is possible to use Ogg with any metadata specification without altering the container itself, or without stream structure metadata at all. Ogg容器自己並未定義用於聲明覆用流中多種媒體類型之間的結構和相互關係的元數據系統。也就是說，Ogg容器自己不指定諸如「字幕流是哪一股蒸汽？」之類的數據。或「哪一個視頻流是主要角度？」。該元數據仍然存在，可是由Ogg容器存儲，而不是內置在Ogg容器自己中。 Xiph爲Ogg流指定了「骨架」元數據格式，可是容器和流結構元數據的這種解耦意味着能夠將Ogg與任何元數據規範一塊兒使用，而無需更改容器自己，或者根本不須要流結構元數據。

Frame accurate absolute position

Every Ogg page is stamped with a 64 bit 'granule position' that serves as an absolute timestamp for mux and seeking. A few nifty little tricks are usually also embedded in the granpos state, but we'll leave those aside for the moment (strictly speaking, they're part of each codec's mapping, not Ogg). 每一個Ogg頁面上都印有一個64位的「顆粒位置」，做爲多路複用和查找的絕對時間戳。一般，granpos狀態中還嵌入了一些漂亮的小技巧，但咱們暫時將其忽略（嚴格地說，它們是每一個編解碼器映射的一部分，而不是Ogg）。 As previously mentioned above, granule positions are mapped into absolute timestamps by the codec, rather than being a hard timestamp. This allows maximally efficient use of the available 64 bits to address every sample/frame position without approximation while supporting new and previously unknown timebase encodings without needing to extend or update the mux layer. When a codec needs a novel timebase, it simply brings the code for that mapping along with it. This is not a theoretical curiosity; new, wholly novel timebases were deployed with the adoption of both Theora and Dirac. "Rolling INTRA" (keyframeless video) also benefits from novel use of the granule position. 如上所述，顆粒位置由編解碼器映射到絕對時間戳，而不是硬時間戳。這樣就能夠最大程度地有效利用可用的64位來近似估計每一個採樣/幀的位置，同時支持新的和之前未知的時基編碼，而無需擴展或更新多路複用器層。當編解碼器須要新穎的時基時，它只需將用於該映射的代碼與之一塊兒帶來便可。這不是理論上的好奇心；經過Theora和Dirac部署了全新的全新時基。 「滾動INTRA」（無關鍵幀視頻）還得益於對顆粒位置的新穎使用。

Ogg stream arrangement

Packets, pages, and bitstreams

Ogg codecs place raw compressed data into packets. Packets are octet payloads containing the data needed for a single decompressed unit, eg, one video frame. Packets have no maximum size and may be zero length. They do not generally have any framing information; strung together, the unframed packets form a logical bitstream of codec data with no internal landmarks. Ogg編解碼器將原始壓縮數據放入數據包中。數據包是八位字節有效載荷，其中包含單個解壓縮單元（例如一個視頻幀）所需的數據。數據包沒有最大大小，長度可能爲零。它們一般沒有任何框架信息。串在一塊兒的未成幀的數據包造成沒有內部界標的編解碼器數據的邏輯比特流。

Packets of raw codec data are not typically internally framed. When they are strung together into a stream without any container to provide framing, they lose their individual boundaries. Seek and capture are not possible within an unframed stream, and for many codecs with variable length payloads and/or early-packet termination (such as Vorbis), it may become impossible to recover the original frame boundaries even if the stream is scanned linearly from beginning to end. Logical bitstream packets are grouped and framed into Ogg pages along with a unique stream serial number to produce a physical bitstream. An elementary stream is a physical bitstream containing only a single logical bitstream. Each page is a self contained entity, although a packet may be split and encoded across one or more pages. The page decode mechanism is designed to recognize, verify and handle single pages at a time from the overall bitstream. 原始編解碼器數據包一般不會在內部進行幀化。當它們在沒有任何容器提供框架的狀況下串在一塊兒成爲流時，它們會失去各自的邊界。在未成幀的流中沒法進行查找和捕獲，而且對於許多具備可變長度有效載荷和/或早期數據包終止的編解碼器（例如Vorbis），即便從如下位置對流進行線性掃描，也可能沒法恢復原始幀邊界開始到結束。 邏輯比特流包被分組並與惟一的流序列號一塊兒分紅Ogg頁面，以生成物理比特流。基本流是僅包含單個邏輯位流的物理位流。儘管能夠在一個或多個頁面上拆分和編碼數據包，但每一個頁面都是一個獨立的實體。頁面解碼機制旨在一次識別，驗證和處理整個比特流中的單個頁面。

The primary purpose of a container is to provide framing for raw packets, marking the packet boundaries so the exact packets can be retrieved for decode later. The container also provides secondary functions such as capture, timestamping, sequencing, stream identification and so on. Not all of these functions are represented in the diagram. 容器的主要目的是爲原始數據包提供幀，標記數據包的邊界，以即可以檢索確切的數據包以供之後解碼。容器還提供輔助功能，例如捕獲，時間戳記，排序，流識別等。並不是全部這些功能都在圖中表示。 In the Ogg container, pages do not necessarily contain integer numbers of packets. Packets may span across page boundaries or even multiple pages. This is necessary as pages have a maximum possible size in order to provide capture guarantees, but packet size is unbounded. 在Ogg容器中，頁面不必定包含整數個數據包。數據包可能跨越頁面邊界，甚至跨越多個頁面。這是必要的，由於頁面具備最大可能的大小以便提供捕獲保證，可是數據包大小是不受限制的。 Ogg Bitstream Framing specifies the page format of an Ogg bitstream, the packet coding process and elementary bitstreams in detail. Ogg比特流成幀詳細指定了Ogg比特流的頁面格式，數據包編碼過程和基本比特流。

Multiplexed bitstreams

Multiple logical/elementary bitstreams can be combined into a single multiplexed bitstream by interleaving whole pages from each contributing elementary stream in time order. The result is a single physical stream that multiplexes and frames multiple logical streams. Each logical stream is identified by the unique stream serial number stamped in its pages. A physical stream may include a 'meta-header' (such as the Ogg Skeleton) comprising its own Ogg page at the beginning of the physical stream. A decoder recovers the original logical/elementary bitstreams out of the physical bitstream by taking the pages in order from the physical bitstream and redirecting them into the appropriate logical decoding entity. 經過按時間順序交織來自每一個貢獻基本流的整個頁面，能夠將多個邏輯/基本位流組合爲單個多路複用位流。結果是單個物理流，該物理流對多個邏輯流進行了多路複用和幀化。每一個邏輯流由在其頁面上標記的惟一流序列號標識。物理流能夠包括在物理流的開始處包括其本身的Ogg頁面的「元頭」（例如，Ogg骨架）。解碼器經過從物理比特流中按順序提取頁面並將其重定向到適當的邏輯解碼實體中，從而從物理比特流中恢復出原始邏輯/基本比特流。

Multiple media types are mutliplexed into a single Ogg stream by interleaving the pages from each elementary physical stream. 經過交錯來自每一個基本物理流的頁面，能夠將多種媒體類型多路複用爲單個Ogg流。 Ogg Bitstream Multiplexing specifies proper multiplexing of an Ogg bitstream in detail. Ogg比特流複用詳細指定了Ogg比特流的正確複用。

Chaining

Multiple Ogg physical bitstreams may be concatenated into a single new stream; this is chaining. The bitstreams do not overlap; the final page of a given logical bitstream is immediately followed by the initial page of the next. 多個Ogg物理比特流能夠串聯成一個新的流；這是連鎖。比特流不重疊；給定邏輯比特流的最後一頁緊隨其後。 Each logical bitstream in a chain must have a unique serial number within the scope of the full physical bitstream, not only within a particular link or segment of the chain. 一條鏈中的每一個邏輯比特流必須在完整物理比特流的範圍內具備惟一的序列號，而不只僅是在特定的鏈路或鏈段內。

Continuous and discontinuous streams

Within Ogg, each stream must be declared (by the codec) to be continuous- or discontinuous-time. Most codecs treat all streams they use as either inherently continuous- or discontinuous-time, although this is not a requirement. A codec may, as part of its mapping, choose according to data in the initial header. 在Ogg中，必須（經過編解碼器）將每一個流聲明爲連續時間或不連續時間。大多數編解碼器將其使用的全部流本質上視爲連續時間或不連續時間，儘管這不是必需的。編解碼器能夠做爲其映射的一部分，根據初始標頭中的數據進行選擇。 Continuous-time pages are stamped by end-time, discontinuous pages are stamped by begin-time. Pages in a multiplexed stream are interleaved in order of the time stamp regardless of stream type. Both continuous and discontinuous logical streams are used to seek within a physical stream, however only continuous streams are used to determine buffering depth; because discontinuous streams are stamped by start time, they will always 'fall out' at the proper time when buffering the continuous streams. See 'Examples' for an illustration of the buffering mechanism. 連續時間頁面由結束時間標記，不連續頁面由開始時間標記。無論流類型如何，複用流中的頁面都按時間戳順序交錯。連續邏輯流和不連續邏輯流都用於在物理流中查找，可是隻有連續流才用於肯定緩衝深度。由於不連續的流是由開始時間標記的，因此當緩衝連續的流時，它們老是在適當的時間「掉出」。有關緩衝機制的說明，請參見「示例」。

Multiplexing Requirements

Multiplexing requirements within Ogg are straightforward. When constructing a single-link (unchained) physical bitstream consisting of multiple elementary streams: Ogg中的多路複用要求很簡單。在構造由多個基本流組成的單連接（未連接）物理比特流時：

1. The initial header for each stream appears in sequence, each header on a single page. All initial headers must appear with no intervening data (no auxiliary header pages or packets, no data pages or packets). Order of the initial headers is unspecified. The 'beginning of stream' flag is set on each initial header.每一個流的初始標頭按順序出現，每一個標頭在單個頁面上。全部初始標頭必須沒有中間數據出現（沒有輔助標頭頁面或數據包，沒有數據頁面或數據包）。初始標題的順序未指定。在每一個初始標頭上設置「流的開始」標誌。
2. All auxiliary headers for all streams must follow. Order is unspecified. The final auxiliary header of each stream must flush its page.全部流的全部輔助標頭都必須跟隨。訂單未指定。每一個流的最終輔助標頭必須刷新其頁面。
3. Data pages for each stream follow, interleaved in time order.隨後是每一個流的數據頁，按時間順序交錯。
4. The final page of each stream sets the 'end of stream' flag. Unlike initial pages, terminal pages for the logical bitstreams need not occur contiguously; indeed it may not be possible for them to do so.每一個流的最後一頁設置「流結束」標誌。與初始頁面不一樣，邏輯位流的終端頁面沒必要連續出現；實際上，他們不可能這樣作 Each grouped bitstream must have a unique serial number within the scope of the physical bitstream. 每一個分組的位流在物理位流的範圍內必須具備惟一的序列號。

chaining and multiplexing

Multiplexed and/or unmultiplexed bitstreams may be chained consecutively. Such a physical bitstream obeys all the rules of both chained and multiplexed streams. Each link, when unchained, must stand on its own as a valid physical bitstream. Chained streams do not mix or interleave; a new segment may not begin until all streams in the preceding segment have terminated. 複用和/或未複用的比特流能夠被連續地連接。這樣的物理比特流遵照鏈式和多路複用流的全部規則。斷開連接時，每一個連接必須做爲有效的物理比特流獨立存在。連接的流不會混合或交錯。直到先前段中的全部流都已終止，新段纔可能開始。

Codec Mapping Requirements

Each codec is allowed some freedom in deciding how its logical bitstream is encapsulated into an Ogg bitstream (even if it is a trivial mapping, eg, 'plop the packets in and go'). This is the codec's mapping. Ogg imposes a few mapping requirements on any codec. 每一個編解碼器在決定如何將其邏輯比特流封裝到Ogg比特流中都具備必定的自由度（即便它是微不足道的映射，例如「將數據包複製進去」）。這是編解碼器的映射。 Ogg對任何編解碼器都提出了一些映射要求。

1. The framing specification defines 'beginning of stream' and 'end of stream' page markers via a header flag (it is possible for a stream to consist of a single page). A correct stream always consists of an integer number of pages, an easy requirement given the variable size nature of pages.他的框架規範經過標頭標誌定義了「流的開始」和「流的結束」頁面標記（一個流可能由一個頁面組成）。正確的流始終由整數頁組成，考慮到頁面可變大小的性質，這是一個簡單的要求。
2. The first page of an elementary Ogg bitstream consists of a single, small 'initial header' packet that must include sufficient information to identify the exact CODEC type. From this initial header, the codec must also be able to determine its timebase and whether or not it is a continuous- or discontinuous-time stream. The initial header must fit on a single page. If a codec makes use of auxiliary headers (for example, Vorbis uses two auxiliary headers), these headers must follow the initial header immediately. The last header finishes its page; data begins on a fresh page.基本Ogg比特流的第一頁包含一個小的「初始標頭」數據包，該數據包必須包含足夠的信息以標識確切的CODEC類型。根據此初始報頭，編解碼器還必須可以肯定其時基以及它是連續時間流仍是不連續時間流。初始標頭必須適合單個頁面。若是編解碼器使用輔助標頭（例如，Vorbis使用兩個輔助標頭），則這些標頭必須緊隨初始標頭以後。最後一個標題完成其頁面；數據重新的一頁開始。 As an example, Ogg Vorbis places the name and revision of the Vorbis CODEC, the audio rate and the audio quality into this initial header. Vorbis comments and detailed codec setup appears in the larger auxiliary headers.例如，Ogg Vorbis將Vorbis CODEC的名稱和修訂版，音頻速率和音頻質量放入此初始標頭中。 Vorbis註釋和詳細的編解碼器設置出如今較大的輔助標題中。
3. Granule positions must be translatable to an exact absolute time value. As described above, the mux layer is permitted to query a codec or codec stub plugin to perform this mapping. It is not necessary for an absolute time to be mappable into a single unique granule position value.顆粒位置必須可轉換爲確切的絕對時間值。如上所述，容許多路複用器層查詢編解碼器或編解碼器存根插件以執行此映射。絕對時間沒必要映射到單個惟一的顆粒位置值。
4. Codecs are not required to use a fixed duration-per-packet (for example, Vorbis does not). the mux layer is permitted to query a codec or codec stub plugin for the time duration of a packet.編解碼器不須要使用固定的每包持續時間（例如，Vorbis不須要）。多路複用器層能夠查詢編解碼器或編解碼器存根插件以獲取數據包的持續時間。
5. Although an absolute time need not be translatable to a unique granule position, a codec must be able to determine the unique granule position of the current packet using the granule position of a preceding packet.儘管絕對時間沒必要轉換爲惟一的顆粒位置，可是編解碼器必須可以使用先前數據包的顆粒位置來肯定當前數據包的惟一顆粒位置。
6. Packets and pages must be arranged in ascending granule-position and time order.數據包和頁面必須按顆粒位置和時間順序升序排列。

Examples

[More to come shortly; this section is currently being revised and expanded]不久之後還會有更多；本節目前正在修訂和擴展 Below, we present an example of a multiplexed and chained bitstream: 下面，咱們提供一個多路複用和連接的比特流的示例：

In this example, we see pages from five total logical bitstreams multiplexed into a physical bitstream. Note the following characteristics: 在該示例中，咱們看到來自五個總邏輯位流的頁面被多路複用爲一個物理位流。請注意如下特徵：

1. Multiplexed bitstreams in a given link begin together; all of the initial pages must appear before any data pages. When concurrently multiplexed groups are chained, the new group does not begin until all the bitstreams in the previous group have terminated.給定鏈路中的多路複用比特流一塊兒開始；全部初始頁面必須出如今任何數據頁面以前。當併發多路複用的組連接在一塊兒時，新的組直到前一個組中的全部比特流都終止後纔開始。
2. The ordering of pages of concurrently multiplexed bitstreams is goverened by timestamp (not shown here); there is no regular interleaving order. Pages within a logical bitstream appear in sequence order.併發複用的比特流的頁面順序由時間戳（此處未顯示）控制。沒有常規的交織順序。邏輯位流中的頁面按順序出現。