IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
"Ogg objections", A technical discussion of problems inherent in the Ogg container
Canar
post Mar 4 2010, 16:43
Post #1





Group: Super Moderator
Posts: 3373
Joined: 26-July 02
From: To:
Member No.: 2796



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 (Ogg objections introduction)
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


--------------------
You cannot ABX the rustling of jimmies.
No mouse? No problem.
Go to the top of the page
+Quote Post
diacon
post Mar 4 2010, 17:26
Post #2





Group: Members
Posts: 17
Joined: 1-March 10
Member No.: 78631



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.

This post has been edited by diacon: Mar 4 2010, 17:28
Go to the top of the page
+Quote Post
SebastianG
post Mar 5 2010, 18:11
Post #3





Group: Developer
Posts: 1318
Joined: 20-March 04
From: Göttingen (DE)
Member No.: 12875



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

This post has been edited by SebastianG: Mar 5 2010, 18:20
Go to the top of the page
+Quote Post
SebastianG
post Mar 6 2010, 07:42
Post #4





Group: Developer
Posts: 1318
Joined: 20-March 04
From: Göttingen (DE)
Member No.: 12875



QUOTE (SebastianG @ Mar 5 2010, 18:11) *
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
Go to the top of the page
+Quote Post
SebastianG
post Mar 11 2010, 18:46
Post #5





Group: Developer
Posts: 1318
Joined: 20-March 04
From: Göttingen (DE)
Member No.: 12875



QUOTE (SebastianG @ Mar 6 2010, 07:42) *
It seems Ogg Skeleton has no way of signalling seek tables.

They're actually working on it.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 18th December 2014 - 23:10