Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: "Ogg objections" (Read 4845 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

"Ogg objections"

This is a bit of a repost. A new user, unfamiliar with the terms of service, posted this earlier. He included some inflammatory remarks quite unsuitable for the Tech forum where he posted it. Furthermore, this pertains to the Ogg container, not the Vorbis codec, so it was also in the wrong location.

Quote
The Ogg container format is being promoted by the Xiph Foundation for use with its Vorbis and Theora codecs. Unfortunately, a number of technical shortcomings in the format render it ill-suited to most, if not all, use cases. This article examines the most severe of these flaws.


Read more here: http://hardwarebug.org/2010/03/03/ogg-objections/

If you wish to discuss the technical details, feel free to comment here. If you wish to be inflammatory and troll, try this Slashdot thread: http://news.slashdot.org/story/10/03/03/19...ontainer-Format

"Ogg objections"

Reply #1
Ok, again.

According to the article Ogg has worse properties regarding overhead, latency and random access features than both matroska and mp4, for which also free implementations exist.

An additional criticism is that Ogg is much too complex without benefit (as higher flexibility) for real world scenarios compared to the other two. Albeit its complexity it isn't even that flexible, for example, checksumming is mandatory, which is wasted space for numerous scenarios. Also many constraints exist for streaming.

It is, for example, somewhat strange that it was specifically designed to be streamable, but you can't even setup self contained streams, that can be tuned into at any point (as webradio) without necessary quirks by a streaming server, which has to fake the beginning of a new stream as soon as you tune in.

"Ogg objections"

Reply #2
I'm not familiar with the details of other container formats but I do have experience with Ogg since I implemented my own Ogg Vorbis decoder from scratch a couple of years ago. I like to stress that I'm not really an Ogg fan boy. I use Matroska as well, mainly because I can cram AC3 and H264 streams into it. :-) But let me comment on a couple of issues here...

Quote
According to the article Ogg has worse properties regarding overhead, latency and random access features than both matroska and mp4, for which also free implementations exist.

Regarding overhead: You have a fixed per page overhead of 26 bytes (the header) which -- for typical page sizes of presumably 4--16 KiB -- represents an overhead of around 0.16--0.63%. Then, you have the lacing values which tell you how big stream packets are, where they start and end which adds 1+floor(s/255) additional bytes for a packet of size s. At average this comes down to about 0.5% of overhead per packet. This is about 0.6--1.1% of total overhead. I'm sure the overhead for small packets is comparable with Matroska's overhead. But for larger packets you could have saved a couple of bytes here and there. Still, the overhead is within the limits of the design goals.

Regarding latency: The argument here is that to reduce overhead we need large pages. But large pages imply high latency. How is this different from other container formats? Also, who cares about latency? For low latency applications you would typically use special low latency protocols which have their own framing. I don't think anybody at Xiph intends to use Ogg for real-time communication. I also don't think that anybody wants to use Matroska for that. Correct my if I'm wrong. Matroska also looks more like a storage/streaming format to me than something that is tailered for low latency real-time applications.

Regarding random access: Yes, Ogg "doesn't use index tables" -- at least Ogg doesn't know about these things. Ogg is a rather "naked" container format which doesn't know much about what it contains. This obviously has advantages as well as disadvantages. Last time I checked Xiph was developing "Ogg Skeleton" which is something that can be embedded into an Ogg stream (as its own logical stream). Ogg Skeleton is supposed to describe the other streams and may very well include seek index tables. If I recall correctly, Xiph planned to use Ogg Skeleton for most multiplexed A/V and non-Vorbis-only streams. I'm probably not up to date on this one. Last time I checked (couple of years ago) I only found a simple .TXT file that described Ogg Skeleton. So, with an .OGV file that contains a skeleton stream you can (in theory) simply parse the ogg file and enumerate various properties (kind, language, resolution, channels, time stamp format, etc) about the contained streams without having to know all the codecs.

Quote
An additional criticism is that Ogg is much too complex without benefit (as higher flexibility) for real world scenarios compared to the other two.

By complexity you probably don't mean the complexity of the Ogg stream format (because it is fairly simple) but its implications on handling random access and such, right? There's little complexity in the Ogg stream format itself.

Quote
Albeit its complexity it isn't even that flexible, for example, checksumming is mandatory, which is wasted space for numerous scenarios.

The checksums are part of the page headers which are accounted for in the overhead computation of mine. What flexibility do you miss?

Quote
It is, for example, somewhat strange that it was specifically designed to be streamable, but you can't even setup self contained streams, that can be tuned into at any point (as webradio) without necessary quirks by a streaming server, which has to fake the beginning of a new stream as soon as you tune in.

I would say that this is more a "limitation" of Vorbis because it requires special setup headers. To my knowledge no other codec works that way and if I recall correctly Vorbis represented a difficulty for other container formats as well due to this. To easily support codecs like Vorbis the container format should be able to distinguish between "codec setup packets" and "audio/video packets", so that a dumb streaming server can simply send you all "setup packets" before "a/v packets" without having to know anything about the codecs that are in use. Matroska may have this kind of signalling (I don't really know). Ogg does not, if I recall correctly. But again, this could be handled via Ogg Skeleton. Then, a streaming server only needs to understand Ogg and Skeleton, nothing else.

edit: Click Ogg Skeleton for more infos. I'm gonna read this now ...

Cheers,
SG

 

"Ogg objections"

Reply #3
Ogg Skeleton is supposed to describe the other streams and may very well include seek index tables.

It seems Ogg Skeleton has no way of signalling seek tables.

But everything else I mentioned about Skeleton seems to be true. It describes properties of other streams including the "granule pos"/"time stamp" format. It also has a way of signalling how many "codec setup packets" a codec needs so it can decode arbitrary packets. All this makes it possible to write rather simple ogg tools (stream servers, muxers, demuxers, cutters, general info tools) which don't need to know anything about the codecs -- which is a good thing ?.

Cheers,
SG