rfc3533oggWord文件下载.docx

1、 The key words MUST, MUST NOTREQUIREDSHALLSHALL NOT, SHOULDSHOULD NOTRECOMMENDEDMAY, and OPTIONAL in this document are to be interpreted as described in BCP 14, RFC 2119 2.Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions . . . . . . . . . . . . . .

2、 . . . . . . . . . . . 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. Sec

3、urity Considerations . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 A. Glossary of terms and abbreviations . . . . . . . . . . . . . 13 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 Authors Address . . . . . . . .

4、. . . . . . . . . . . . . . . 14 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15Pfeiffer Informational Page 1RFC 3533 OGG May 20031. Introduction 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 decod

5、ing 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 intell

6、ectual property concerns. 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 st

7、reams 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 provid

8、es 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. Please note that the MIME type application/ogg has been registered with the IANA 1.2. Definitions For describing the Og

9、g 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 th

10、e concrete format of the Ogg bitstream. See the Appendix for a more complete glossary. 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 e

11、ncapsulation process, has a structure, i.e., it is split up into a sequence of so-calledPackets. 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 contai

12、n boundary information - strung together they appear to be streams of random bytes with no landmarks.Pfeiffer Informational Page 2RFC 3533 OGG May 2003 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 encapsu

13、lation format 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 pro

14、vide: o framing for logical bitstreams. o interleaving of different logical bitstreams. o detection of corruption. o recapture after a parsing error. o position landmarks for direct random access of arbitrary positions in the bitstream. o streaming capability （i.e., no seeking is needed to build a 1

15、00% complete 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 simplicity to enable fast parsing. o simple concatenation mechanism of several physical bitstreams. All of these design co

16、nsiderations 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 enc

17、apsulation 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.4. The Ogg bitstream format A physical Ogg bitstream consists of multiple logical bitstreams interleaved in so-called Pages. Whole pages are t

18、aken in order from multiple logical bitstreams multiplexed at the page level. The logical bitstreams are identified by a unique serial number in thePfeiffer Informational Page 3 header of each page of the physical bitstream. This unique serial number is created randomly and does not have any connect

19、ion 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 bi

20、tstreams from the physical bitstream by taking the pages in order from the physical bitstream and redirecting them into the appropriate logical decoding entity. 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

21、 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）. The bos page contains information to uniquely identify the codec type and MAY cont

22、ain 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 requ

23、ired 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 there

24、fore 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 fra

25、med 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 packe

26、ts. 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）.

27、 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）.Pf

28、eiffer Informational Page 4 Ogg knows two types of multiplexing: concurrent multiplexing （so- called Grouping） and sequential multiplexing （so-calledChaining）. Grouping defines how to interleave several logical bitstreams page-wise in the same physical bitstream. Grouping is for example needed for i

29、nterleaving 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. In grouping, all bos pages of all logical bitstreams MUST appear together at the beginning of the Ogg bitstream. The media mapping specifi