Talk:OggStream: Difference between revisions
Maikmerten (talk | contribs) (Gstreamer <-> OggStream) |
No edit summary |
||
| Line 4: | Line 4: | ||
Some words to explain why OggStream is necessary although there are other frameworks (not only Gstreamer) would perhaps clear the "why?"-issue. It seems there´s is some "confusion" about the goals of OggStream: http://www.advogato.org/person/rbultje/diary.html?start=57 - maikmerten at gmx.net | Some words to explain why OggStream is necessary although there are other frameworks (not only Gstreamer) would perhaps clear the "why?"-issue. It seems there´s is some "confusion" about the goals of OggStream: http://www.advogato.org/person/rbultje/diary.html?start=57 - maikmerten at gmx.net | ||
--- | |||
Because putting all our eggs in one basket is '''not''' a good idea. | |||
GStreamer is a good tool, and we already support it, but there are alternatives for political and technical-choice reasons. Diversity is strength, not a weakness, and should be embraced. | |||
That said, we should also look at duplication of work. GStreamer, ffmpeg, Real/Helix, Quicktime, Annodex (liboggz/libfishsound), SDL, VideoLan... the list goes on, all have independent multi-codec Ogg implementations. This makes releasing a new codec difficult and slow, as each codec needs to be added to each seperate implementation and then properly debugged. We don't want to continue working around the limitations this gives us, such as not being able to chain Ogg streams or chain audio/video streams to audio-only streams. | |||
Many players, also, have their own internal frameworks. Xine, XMMS, and MPlayer come to mind. Their Ogg support is also inconsistant, incomplete, and often buggy. We've spent alot of time getting this debugged in our own tools, even, and even ices2 still produces illegal (not to spec) Ogg streams. | |||
To compete with proprietary media codecs, we need to be efficient with our time. OggStream is not intended as a general purpose media framework, but rather a set of compatable plugins which operate through a standard interface. It will be trivial for any existing media framework to connect to OggStream and use it to encode / decode / transcode / stream / losslessly edit / etc Ogg files. | |||
Also, [[OggStream]] will be usable to access non-standard streaming systems, such as [[IceShare]] and the various codecs over RTP (see [[SpeexRTP]], [[VorbisRTP]], or [[TheoraRTP]]). Most existing media players and frameworks don't support this currently and doing so would mean independent implementations across the board. Using a single library w/ universal (automatically downloaded) plugins is the way to go. | |||
Revision as of 09:17, 27 November 2004
I'd rather see Xiph help porting the Gstreamer framework to Windows. It's a great starting point on Linux and MacOS X already.
---
Some words to explain why OggStream is necessary although there are other frameworks (not only Gstreamer) would perhaps clear the "why?"-issue. It seems there´s is some "confusion" about the goals of OggStream: http://www.advogato.org/person/rbultje/diary.html?start=57 - maikmerten at gmx.net
---
Because putting all our eggs in one basket is not a good idea.
GStreamer is a good tool, and we already support it, but there are alternatives for political and technical-choice reasons. Diversity is strength, not a weakness, and should be embraced.
That said, we should also look at duplication of work. GStreamer, ffmpeg, Real/Helix, Quicktime, Annodex (liboggz/libfishsound), SDL, VideoLan... the list goes on, all have independent multi-codec Ogg implementations. This makes releasing a new codec difficult and slow, as each codec needs to be added to each seperate implementation and then properly debugged. We don't want to continue working around the limitations this gives us, such as not being able to chain Ogg streams or chain audio/video streams to audio-only streams.
Many players, also, have their own internal frameworks. Xine, XMMS, and MPlayer come to mind. Their Ogg support is also inconsistant, incomplete, and often buggy. We've spent alot of time getting this debugged in our own tools, even, and even ices2 still produces illegal (not to spec) Ogg streams.
To compete with proprietary media codecs, we need to be efficient with our time. OggStream is not intended as a general purpose media framework, but rather a set of compatable plugins which operate through a standard interface. It will be trivial for any existing media framework to connect to OggStream and use it to encode / decode / transcode / stream / losslessly edit / etc Ogg files.
Also, OggStream will be usable to access non-standard streaming systems, such as IceShare and the various codecs over RTP (see SpeexRTP, VorbisRTP, or TheoraRTP). Most existing media players and frameworks don't support this currently and doing so would mean independent implementations across the board. Using a single library w/ universal (automatically downloaded) plugins is the way to go.