Ogg: Difference between revisions
Jump to navigation
Jump to search
Maikmerten (talk | contribs) (Initial content) |
Maikmerten (talk | contribs) (→Design constraints for Ogg bitstreams: projects using Ogg) |
||
Line 9: | Line 9: | ||
* Specification of absolute position within the original sample stream. | * Specification of absolute position within the original sample stream. | ||
* Simple mechanism to ease limited editing, such as a simplified concatenation mechanism. | * Simple mechanism to ease limited editing, such as a simplified concatenation mechanism. | ||
* Detection of corruption, recapture after error and direct, random access to data at arbitrary positions in the bitstream. | * Detection of corruption, recapture after error and direct, random access to data at arbitrary positions in the bitstream. | ||
== Projects using Ogg == | |||
* [[Vorbis]] | |||
* [[Theora]] | |||
* [[FLAC]] | |||
* [[Speex]] | |||
* [[Icecast]] | |||
== External links == | == External links == | ||
* [http://www.xiph.org/ogg/doc/ Ogg documentation] | * [http://www.xiph.org/ogg/doc/ Ogg documentation] |
Revision as of 07:32, 1 September 2004
About
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 Theora video codec.
Design constraints for Ogg bitstreams
- True streaming; we must not need to seek to build a 100% complete bitstream.
- Use no more than approximately 1-2% of bitstream bandwidth for packet boundary marking, high-level framing, sync and seeking.
- Specification of absolute position within the original sample stream.
- Simple mechanism to ease limited editing, such as a simplified concatenation mechanism.
- Detection of corruption, recapture after error and direct, random access to data at arbitrary positions in the bitstream.