OggStream: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
Line 1: | Line 1: | ||
== Goals == | == Goals == | ||
Revision as of 22:54, 19 November 2004
Goals
- Abstract:
- application (app) can be nothing more than a gui frontend to liboggstream
- allows very simple media players, editors, and stream systems to be developed
- minimizes duplicated effort (and thus faster deployment)
- ensures consistant Ogg support for all media players (ie, chaining, seeking, etc)
- can also be used to just decode codecs, choosing to handle file/stream receiving
- application (app) can be nothing more than a gui frontend to liboggstream
- Technical:
- apps need to know information about a stream;
- what codecs it contains
- what it's total length is (or non-seekable)
- apps need to be able to exchange uncompressed data with the library for encoding/decoding
- for non-transcoding operations (ie, streaming), apps also need to be able to exchange raw codec packets
- when meta/effects codecs are available, apps need to be able to access "processed" and "unprocessed" data
- support multiple "protocol" plugins (ie, file, http, etc)
- must provide buffered/cached info for app. (ie, for seek bar to show buffer status)
- makes it easy to show holes in stream
- allow app to provide data through "pipe" or "memory" protocol plugin
- must provide buffered/cached info for app. (ie, for seek bar to show buffer status)
- "Auto Update" system for automatic plugin search/installation from central site
- list licenses and restrictions
- it should prefer Xiph, then Free, then Proprietary, and finally Commercial
- this can either be based on their country or simply run with US IP law
- Linux-based systems can use distro-specific installation method (Gentoo can use Portage, Redhat use RPM, etc)
- list licenses and restrictions
- apps need to know information about a stream;
API
coming soon