On Sun, Nov 05, 2006 at 12:46:10AM -0800, Charles Iliya Krempeaux wrote:
I understand that the Ogg team and Matroska team had different design goals. (The Ogg team seems to hold "streaming" as their design goal. Where
The Ogg team's claim of streaming is purely proaganda. The Ogg format is not "streamable" in the sense that you have to buffer large chunks before you can write them, or else have HUGE overhead.
This probably shows my ignorance in the area but... if you have the inclination to put up with what probably seem like a "basic" questions.... What are Ogg's problems with streaming? And how does NUT fix this problem?
Ogg's problem with streaming is that the only way it avoids massive overhead is by packing large numbers of frames into a single Ogg "page". The page cannot be transmitted until it's complete, adding an extra senseless stage of latency to the stream. In practice it's something like half a second with common low-quality-stream bitrates and settings, making it rather useless for something like videoconference or voip. Even if perfect on-time delivery isn't essential to your application, there are already enough things causing latency in live media streaming that adding another layer of latency is utterly stupid. NUT simply has no level of buffering beyond ensuring that frames are written in the correct order by time. There is no concept of "page" or other higher level of packetization; every frame is written as an individual unit in the file stream. Due to extremely efficient header coding designed mostly by Michael, we're able to achieve this without any overhead penalty at low bitrates (where it matters most) and extremely minimal overhead penalty at higher bitrates. Rich