Ogg Format Accusations Refuted 248
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.
Re:tl;dr (Score:4, Informative)
Summary so far:
Many of the complaints levied against Ogg were not about its technical merits, but about its inadequate documentation -- a feature Matroska shares. Other complaints were about features of Ogg (such as mappings) which nearly every other container format has as well. ... I've only gotten about a quarter of the way through, so far.
Well written, and informative, but... (Score:5, Informative)
Re:tl;dr (Score:3, Informative)
The article is itself basically a summary of the format. If you don't care enough to read the article, probably all you should be worried about is what your iPod will and won't play.
Re:tl;dr (Score:5, Informative)
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.
Re:Well written, and informative, but... (Score:1, Informative)
I'm not sure what crazy German fetish porn you are watching that does that, but I've never had that issue.
Re:Well written, and informative, but... (Score:5, Informative)
As the article notes, .ogm isn't actually a normal ogg container, so the author isn't disputing issues with ogm (he calls it an ugly windows specific hack). And in any case, if you use a codec set to use few keyframes, you'll get poor seek performance in *any* container format - it's quite likely the issues you saw had everything to do with the encoding choices made and little with the (deprecated) ogm container.
It still doesn't address many real world problems (Score:5, Informative)
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:
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.
Re:tl;dr (Score:4, Informative)
And you're ignoring the problem that with ogg you have to hunt down and read the spec of every single codec that you want to implement demuxing support for, and that it is impossible to have, say, a generic lightweight file analyzer that tells you duration, codecs used, metadata, samplerate, framerate, etc.
From the article:
"This is commonly asserted by detractors, but a combination of false and missing the point.
Ogg transport is based entirely on the page structure primitive, described accurately above. There are no other structures in the container transport itself. Higher level structures are built out of pages, not built into them. All Ogg streams conform to this page structure and all Ogg streams are parseable and demuxable without knowing anything about the codec. "Drop the needle" anywhere in an Ogg stream and start demuxing; you get the codec data out without knowing anything about the codec. You possibly won't know what exactly to do with that data without the codec mapping and the data is possibly useless without the codec anyway, but that's true of every container.
To avoid being accused of sidestepping the issue, I posit that the actual [if unstated] objection is that the Ogg container does not fully specify the granule position in the transport specification. Beyond a few requirements, a codec mapping defines the granule position spec for that codec's streams, not the Ogg spec. In theory, this would mean that without codec knowledge or some other place to find the granule position definition, a decoder missing the codec for a given stream would not be able to determine the timestamp on the stream that it is not capable of decoding anyway. In practice, the granule position mapping does in fact exist in the stream metadata within the Skeleton header[7] (as it would be in Matroska or NUT). Additionally, the Ogg design allows implementations to ignore the pretty design theory and just do things the way other containers do by building granule position calculation into the mux implementation.
There's specific considered reasons for the granulepos design which take some space to explain accurately. Because Mr. Rullgard also wrote a lengthy diatribe against Ogg timestamping[8], I'll leave the explanation for there and link to it here when my response to the other article is live."
Re:Well written, and informative, but... (Score:4, Informative)
Have you tried it with MPlayer? I just tried it with an OGV [archive.org] from archive.org. Seeking was instantaneous.
Re:Well written, and informative, but... (Score:1, Informative)
Since I'm on a bit of a soapbox, I'd also like to address this:
Detailed documentation (or the lack thereof) is vitally important, however it has little to do with the container design itself. Mr. Rullgard claims to establish that Ogg is badly flawed, not that it needs more documentation.
Not having adequate documentation *is a flaw*. I find it incredible that anybody working with file formats would argue otherwise.
Re:tl;dr (Score:1, Informative)
And you're ignoring the problem that with ogg you have to hunt down and read the spec of every single codec that you want to implement demuxing support for, and that it is impossible to have, say, a generic lightweight file analyzer that tells you duration, codecs used, metadata, samplerate, framerate, etc.
Ogginfo seems pretty lightweight. It tells me the duration, codecs used, metadata, samplerate, framerate, and more. I guess someone has already solved the problem for you. Here is a sample of its output run against Elephants Dream:
$ ogginfo Elephants_Dream.ogg
Processing file "Elephants_Dream.ogg"...
New logical stream (#1, serial: 1e05b679): type skeleton
New logical stream (#2, serial: 72ba3177): type theora
New logical stream (#3, serial: 30fa15ff): type vorbis
Theora headers parsed for stream 2, information follows...
Version: 3.2.1
Vendor: Xiph.Org libThusnelda I 20081201
Width: 426
Height: 240
Total image: 432 by 240, crop offset (0, 0)
Framerate 24/1 (24.00 fps)
Aspect ratio undefined
Colourspace: Rec. ITU-R BT.470-6 Systems B and G (PAL)
Pixel format 4:2:0
Target bitrate: 0 kbps
Nominal quality setting (0-63): 32
User comments section follows...
ENCODER=ffmpeg2theora-0.24
Vorbis headers parsed for stream 3, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20080501
Channels: 2
Rate: 48000
Nominal bitrate: 80.000000 kb/s
Upper bitrate not set
Lower bitrate not set
User comments section follows...
ENCODER=ffmpeg2theora-0.24
Logical stream 1 ended
Vorbis stream 3:
Total data length: 4986375 bytes
Playback length: 10m:53.696s
Average bitrate: 61.023779 kb/s
Logical stream 3 ended
Theora stream 2:
Total data length: 30621851 bytes
Playback length: 10m:53.791s
Average bitrate: 374.698578 kb/s
Logical stream 2 ended
Re:Well written, and informative, but... (Score:3, Informative)
Yes, I have. I can only conclude that I'm encoding it wrong.
But I seem capable of making streamable/seekable vids in other formats, so why is it so difficult with ffmpeg2theora?
Re:tl;dr (Score:3, Informative)
Too bad that in practice, I've seen a skeleton header maybe once. And anything optional is guaranteed to be missing in many cases. Thus to demux a new codec you still have to find the codec spec, find the ogg mapping, write the granule demangler, write a parser for the codec headers, etc. instead of adding a single entry to a table like you would for sane containers.
I think this speaks to your own inexperience more than anything else. Here's an ogg video with a Skeleton stream:
http://videos.videoonwikipedia.org/video/275/cell-phone-engineerguyogv [videoonwikipedia.org]
You can find many more with Skeleton streams at http://videos.videoonwikipedia.org [videoonwikipedia.org] or http://openvideo.dailymotion.com [dailymotion.com] or http://www.archive.org [archive.org] or many other sites. I can only conclude that you are not very knowledgeable about ogg usage in practice.
Re:Well written, and informative, but... (Score:3, Informative)
Re:tl;dr (Score:2, Informative)
Okay, I'll uninstall libtheora from my Fedora 12 desktop:
# rpm --nodeps -e libtheora-1.1.0-1.fc12.x86_64 libtheora-1.1.0-1.fc12.i686
Totem no longer plays Elephants_Dream.ogg because libtheora is not installed. It outputs a warning:
$ totem Elephants_Dream.ogg
(totem:8219): GStreamer-WARNING **: Failed to load plugin '/usr/lib64/gstreamer-0.10/libgsttheora.so': libtheoraenc.so.1: cannot open shared object file: No such file or directory
Let's try ogginfo now:
$ ogginfo Elephants_Dream.ogg
Processing file "Elephants_Dream.ogg"...
New logical stream (#1, serial: 1e05b679): type skeleton
New logical stream (#2, serial: 72ba3177): type theora
New logical stream (#3, serial: 30fa15ff): type vorbis
Theora headers parsed for stream 2, information follows...
Version: 3.2.1
Vendor: Xiph.Org libThusnelda I 20081201
Width: 426
Height: 240
Total image: 432 by 240, crop offset (0, 0)
Framerate 24/1 (24.00 fps)
Aspect ratio undefined
Colourspace: Rec. ITU-R BT.470-6 Systems B and G (PAL)
Pixel format 4:2:0
Target bitrate: 0 kbps
Nominal quality setting (0-63): 32
User comments section follows...
ENCODER=ffmpeg2theora-0.24
Vorbis headers parsed for stream 3, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20080501
Channels: 2
Rate: 48000
Nominal bitrate: 80.000000 kb/s
Upper bitrate not set
Lower bitrate not set
User comments section follows...
ENCODER=ffmpeg2theora-0.24
Logical stream 1 ended
Vorbis stream 3:
Total data length: 4986375 bytes
Playback length: 10m:53.696s
Average bitrate: 61.023779 kb/s
Logical stream 3 ended
Theora stream 2:
Total data length: 30621851 bytes
Playback length: 10m:53.791s
Average bitrate: 374.698578 kb/s
Logical stream 2 ended
Information output is the same. Reinstall libtheora:
# yum install libtheora.x86_64 libtheora.i686
And totem plays Elephants_Dream.ogg once again.
Re:Does MPEG-TS have indexes? (Score:5, Informative)
That's because MPEG Transport Streams have an easily-accessible Presentation Time Stamp (PTS) in each GOP header, and it's reasonably easy to calculate the increment between PTSs (which will vary with framerate). The simplistic explanation is that the GOP header has the bit rate* & framerate; you can calculate the PTS increment either from the framerate or examining adjacent blocks, you then check the current PTS, calculate the desired PTS from that, and can then jump to the appropriate part of the file to find the PTS you're after.
(That's assuming you're working with a TS file, where the player can examine the first & last block to determine file length. With streaming, you're restricted to working with what's in the buffer (& hopefully your app knows how long the buffer is, since it allocated it!))
Ogg, AFAIK, doesn't have that info in the block header - IIRC it relies on the bitstream having presentation timing stored in it (i.e. none, in the case of most audio formats), which means you have to decode the block to find it. It was done that way to allow for variable framerates to be stored without having to build a huge index. MKV is a bit better in this respect, but it's a remarkably fragile container.
* It falls down a bit sometimes, particularly where the bitrate in the block header is set to max (15Mbps), or where you're using VBR. With the latter the calculation will usually get you in the ballpark; with both cases, some splitters/decoders calculate the bitrate themselves while playing, store it, and use that for seeking.
Re:Ogg format considered not as good as MPEG (Score:3, Informative)
Doesn't count... in America. I've never seen a VCD for sale, except in obscure import shops. It was big in Asia.
Re:Ogg format considered not as good as MPEG (Score:3, Informative)
It may not have been popular in the US (it certainly wasn't obvious here in Australia) - but just about every Chinese home in Australia I went to (in the course of my job) from the mid-90's onwards had at least 1 VCD player (and often one for each TV), and discs were common in the local Asian shops and markets.
Even now, if you buy Asian movies from any of the on-line Asian retailers you'll see plenty of VCD versions.
Re:VP8 Codec (Score:1, Informative)
Ogg is a container, not a codec. If Google does end up releasing VP8 on a royalty free basis they may very well do so by packaging it in Ogg. It would be a convenient way to go as Firefox, Opera, and Chrome already support Ogg.
Re:VP8 Codec (Score:3, Informative)
That's great. What container are they going to put it in again?
(Less snarky version: VP8 is a codec. Ogg (& MKV, & AVI, & etc) are container formats that hold data encoded with various codecs. The situation is muddied somewhat with MPEG, as the various versions encompass both a codec and a container. DivX too, but the DivX container is nothing more than a bastardised .AVI container containing video encoded with the DivX codec.)
Re:tl;dr (Score:3, Informative)
No, that's not at all what I wrote. The fundamental purpose of a container is to consolidate multiple pieces of information into a single file. Without containers, you would need one file for your audio data and a separate one for your video data. You should not need to understand the video data to play the audio data; it is sufficient to know its length. And *that* is what I wrote.
Re:Well written, and informative, but... (Score:3, Informative)
No, Monty is simply lying about this point.
While the fields in Ogm are based on Window's VfW, they can be created and parsed on any platform quite easily. I've NEVER used Ogm one Windows, I've ALWAYS used it under Unix systems. Ogmtools can be used to generate such files, and MPlayer (which works on damn near every platform, from Linux, Windows, and OSX to VMS and OS/2) will play them out of the box, with no additional dependencies.
RTFA. (Score:5, Informative)
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?
Re:tl;dr (Score:5, Informative)
Ah, the gotcha is in the source:
http://svn.xiph.org/trunk/vorbis-tools/ogginfo/ogginfo2.c [xiph.org]
Ogginfo's source includes information on how to process the metadata for various codecs.
So, the grandparent's complaint is still valid. Ogginfo appears to require recompilation for every stream that they want to support inside an ogg container.
Re:Ogg format considered not as good as MPEG (Score:3, Informative)
Really? I don't think I ever saw a single VCD on a store shelf. I recall they existed, and I think I even watched one once, but basically they were a brief fad that completely failed to make a measurable dent in the VHS market and rapidly disappeared without a trace. That's not what I'd call "massively popular".
Just because *you* never saw them doesn't mean they weren't successful. Head to Asia - they still sell them by the truckload aside DVD and Blu-Ray, and displaced VHS over 15 years ago. I bought a few dozen a couple months back because they were cheap and easy to copy to the computer. Then I remembered just how awful MPEG-1 looked.
Re:The goal (Score:3, Informative)
Your points are good ones. However, you and other make reference to "low bitrate MP3s". Isn't that somewhat besides the point? If you're going to compare Ogg Vorbis q6 or q8 to MP3, you should compare to the best and most widely available codec and encoding options.
By far, the most popular MP3 encoder is LAME, and the preferred format is V0 or V2. V0 generally has the most downloads on the popular private bittorrent trackers, but V2 is the choice of "scene" release groups.
Neither is low quality. V2 averages around 192 kbit/sec and V0 around 245 kbit/sec. There is very little perceptible difference between LAME at V0 v. 320.
While Ogg Vorbis using the aoTuv encoder can achieve transparency at a slightly lower bitrate, from my ABX tests, and reading on Hydrogenaudio, you save, at most around 5%.
I grant that this may be valuable on a DAP. While there are DAPs with Ogg Vorbis support, lets be honest here. What's the most popular DAC on the market? Apples iPod or Touch/iPhone, most likely. The vast majority of people I see with DAPs use an Apple product. Unless you use the third party Rockbox firmware, which substantially reduces the UI quality, one of the reasons people pay a premium for Apple products, you're not going to have Ogg Vorbis support.
So, while it is possible to buy a DAP that supports Ogg Vorbis, you have to make your hardware purchase based on your codec choice, which really shouldn't be the case.
You suggest that Ogg Vorbis support is only a problem if you're looking at cheap DACs. This clearly isn't the case. If you want to use an iPhone, Apple Touch, an iPod or any other popular DAC, you have two lossy choices - MP3 or AAC.
So, while you do gain some space by using Ogg Vorbis, IMHO it's not worth the limitations in hardware and software choice.
As for desktop usage, conventional hard drive storage is so cheap, that it is really inexpensive to simply rip to FLAC and your choice of lossy format. In fact dBpoweramp can rip a CD to both FLAC and any lossy format of your choosing in one simple step, and it will use the Accuraterip database to confirm the rip was accurate.
Or you can use EAC, which is free, and then use dbpoweramp or another tool to batch convert at a later point. While my i7 makes the process very quick, even a mid-range Core 2 Duo can transcode a large FLAC collection in a few hours, and certainly overnight.
With 1.5 TB drives at $100, hard drive space simply isn't a meaningful concern.
The market for lossy audio formats on private bittorrent trackers shows the strong preference for MP3. A recent statistical analysis at what.cd showed that MP3 was by far the most popular lossy format, accounting for at least 98% of all downloads.
Ogg Vorbis had very few downloads, and Ogg Vorbis uploads were the most likely to have 0 downloads. It's just not a popular sharing format for the reasons I raise above.
That doesn't mean nobody is using it. FLAC has become much more popular as of late, and lossless formats provides the benefit of being able to transcode to any lossy format retaining tags and album art.
I still think downloading, and certainly, riping to FLAC makes the most sense. You then can purchase any DAP of your choice, and know that you'll be able to convert your music to a supported lossy format. Even a relatively old computer can rip to MP3 relatively quickly. Foobar2000 even has a plugin that will do this for you automatically, for DAPs, including the iPod that don't support your format of choice.
BTW, I'm only referring to encoding for personal use. Obviously, when widespread distribution is a concern, you must consider licensing costs, and size becomes a greater issue.
As a matter of practicality, I don't see why FOSS advocates continually argue for Ogg Vorbis and don't talk much about FLAC. It is probably because MP3, and lossy formats in general are considered to be so popular. But, from my experience at what.cd, a private music tracker with over 120,000 members, FLAC is most certainly po
Re:Does MPEG-TS have indexes? (Score:4, Informative)
A DVD is MPEG-PS, not MPEG-TS. Your cable system and satellite feed are TS. Both are built on top of the PES layer.
MPEG-2 is the reason I have no hair left on my head.
Re:Does MPEG-TS have indexes? (Score:3, Informative)
The PTS isn't stored in the GOP header. The GOP header is defined in part 2 of the spec, the PTS is in part 1. So the PTS and the DTS are in the PES header. MPEG frames are typically sent out of order. You'll need to do a lot of decoding to figure out the frame rate from the PTS. The bitrate is just as tricky to determine if you're just looking at one layer. A transport multiplexer needs to know a lot about the video it's multiplexing to be able to maintain the proper bitrate and order the frames correctly, etc. etc.
So basically, without understanding your elementary stream to some degree, you can't do much with it in the system layer. Even something seemingly simple, like remuxing, isn't easy to do without knowing something about the structure of the elementary stream. I'm guessing that this is why Ogg doesn't even try to pretend like you can abstract the codec enough to do something meaningful with data you know nothing about - other than skip it, that is.
I've dealt with proprietary data that was multiplexed in MPEG-2 TS before, and there's not a whole lot you can do with it without knowing what it is.
Re:Well written, and informative, but... (Score:3, Informative)
I guess you didn't RTFA (Don't feel bad -- I only got 80% through before throwing in the towel). OGM's status is thoroughly explained, and the author talks about adding indexes in the next version of OGG, due to concerns about HTTP over satellite.
Re:Well written, and informative, but... (Score:3, Informative)
A previous responder to your earlier post explained that ffmpeg puts a bogus value in the OGG header which causes the entire OGG vid to be parsed.
If that's true, then you're using a broken tool to create your OGG vids. File a bug report or switch tools.