Ogg Format Accusations Refuted

SergeyKurdakov sends in a followup to our discussion a couple of months ago on purported shortcomings to the Ogg format. The inventor of the format, Monty "xiphmont" Montgomery of the Xiph Foundation, now refutes those objections in detail, with the introduction: "Earnest falsehoods left unchallenged risk being accepted as fact." The refutation has another advantage besides authoritativeness: it's far better written than the attack.

Comments

Re:tl;dr

[Anonymous Coward]

Nearly every other container format+codec has exactly two bits that are codec dependent: an identifier (e.g. 'XVID' or "V_MPEG4/ISO/AVC" or a number) and binary private data/codec-specific init data/whatever you want to call it. Some codecs in some containers additionally define one bitstream, if the codec has multiple possible (h.264).

Timestamps, dimensions, aspect ratio, framerate, samplerate, etc. are stored in codec-independant ways in the container.

Ogg is not like that at all. The only thing it stores in a codec-independant manner is framing. Every other piece of information you might expect a container to have is stored in a codec-dependant manner. Even metadata!

I have no fucking clue why the creator does not see this as the problem that it is for everyone that tries to work with ogg.

It still doesn't address many real world problems

[pslam]

My rant with Ogg is not so much the minute details of the format itself but that it works badly in a few common real world cases:

• Resizing metadata. It's stored at the beginning, so resizing the metadata requires moving the majority of the file around (or rewriting it).
• Metadata growing across a page boundary (64KB). Not unlikely if you're storing anything substantial such as album art. I know, that's slightly abusing it, but it's convenient to go there and it's common practice. The trouble is this affects the page numbering, requiring every page in the stream to be renumbered, and then every page including its contents to have its CRC recalculated. Very expensive.
• No index. Seriously, why can't we have an index? It doesn't have to be at the beginning of stream - the end is fine too. Which leads me to...
• Random access video across a high latency link. Think that's uncommon? What about cell phones playing a web-hosted video, where 1000ms+ is the norm? Or even laptops with a 3G access dongle? An index (even a small one) mitigates the issue, even if placed at the end of stream.
• Mandatory per-page CRC forces low-latency streaming to use single packet per page. Demux cannot continue before an entire page is received, which increases latency by the number of packets in a page (minus 1). Per-packet or even no CRC would be more appropriate.

I know it's all been said before, but these are pretty common cases and Ogg isn't great when you have to deal with them. Everything else is nit-picking. I'm not a fan of the minute details of the format either, to be honest, but the above are real world examples of where it falls a little short. I should add that none of these issues make it unusable in any of those situations: just annoying.

RTFA.

[SanityInAnarchy]

From TFA:

An index is only marginally useful in Ogg for the complexity added; it adds no new functionality and seldom improves performance noticeably. Why add extra complexity if it gets you nothing?

You can do seeking without an index:

A binary search is discussed in the spec for ease of comprehension; implementation documents suggest an interpolated bisection search. So far, this is the same as Matroska and NUT.

The only difference being, Matroska implementers tend to be lazy about implementing the indexless seeking properly, and people tend to use indexes, thus propagating this myth even more.

The Vorbis source distribution includes an example program called 'seeking_example' that does a stress-test of 5000 seeks of different kinds within an Ogg file. Testing here with SVN r17178, 5000 seeks within a 10GB Ogg file constructed by concatenating 22 short Ogg videos of varying bitrates together results in 17459 actual seek system calls. This yields a result of just under 3.5 real seeks per Ogg seek request when doing exact positioning within an Ogg file. Most actual seeking within an Ogg file would be more appropriately implemented by scrubbing with a single physical seek.

And there you go. I don't know WTF is wrong with your players, but really, how can a total of four seeks bring your system to a crawl?