Talk:OggStream: Difference between revisions

From XiphWiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
Line 3: Line 3:
---
---


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 some "confusion" about the goals of OggStream: http://www.advogato.org/person/rbultje/diary.html?start=57 - maikmerten at gmx.net


---
---
Line 18: Line 18:


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.
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.
---
Thank you for very much for your explanation, Arc. Taking complexity out of apps and putting it into one well engineered library indeed sounds like a good idea. maikmerten at gmx.net

Latest revision as of 16:20, 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 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.

---

Thank you for very much for your explanation, Arc. Taking complexity out of apps and putting it into one well engineered library indeed sounds like a good idea. maikmerten at gmx.net