This whole thing is really about bad blood between Xiph and the mplayer folks. Once, long ago, I made disparaging remarks about a particular mplayer developer's extensive collection of ass hats, and they declared war. This stopped being about facts or reason years ago. Here's the last blog thread that got completely hijacked by the anti-Ogg container wingnuts. It's a hell of a read:
So, rehashing this yet again: The Anti-Ogg bullet points [Not going to bother with complete sentences, because I've wasted too much typing on this recently]:
1) A few of the mplayer/x264 hackers are right pissed that Ogg and Theora are getting all this attention when x264 is so obviously superior. That simply cannot stand. Since only America has patents and there are no computers there anyway, nobody should have to worry about them. Stick it to The Man! (How very ironic, Xiph being considered 'The Man' by folks contributing to an h264 encoder).
2) Xiph should immediately drop Ogg for [insert container here], breaking millions of hardware decoders and hundreds of millions of software decoders:
a) the [patented] mp4/MOV container is one suggestion they actually make seriously. Never mind adding 'willful infringement' to breaking the entire installed software/hardware base, this choice would totally redeem Xiph in their eyes. The benefit: by their own figures, it would reduce container overhead from.7% to.3%.
(Except that number is wrong. I found later that DonDiego screwed up his mp4 overhead figures at the link above; I had simply assumed he got his container numbers right. The mp4 file in his example has almost identical container overhead to the Ogg, a shade under 1%. His demultiplexed mpeg audio and video had framing in them, so it made it appear the mp4 container overhead was much smaller when he subtracted their file sizes.)
b) OK, mp4 is patented and no better, fine, Xiph should have just used Matroska from the beginning. Despite the fact that Ogg and Vorbis predated it by about five years (also mkv's not been able to interleave until just recently, which == no streaming). This is not to say you can't put Theora and Vorbis in Matroska. It's even a good idea! I've come to like MKV. But for streaming, Ogg is still much easier to deal with. Ogg was designed to stream, mkv was not.
c) OK, so, mp4 and Matroska are right out for streaming, Xiph should use Nut, which is the system they designed. Nut came ten years after Ogg was already widespread. And looks almost exactly like Ogg. Which is not to say there aren't things about it I like that improved on the Ogg approach. Eg, the packet length encoding is better. It has a conditional checksum coverage feature I had never considered, etc. At some point we'll make those changes when that wouldn't mean completely abandoning any chance we have at adoption just to save a fraction of a percent and add... no new features.
d) but.. but.. even FLV is better! OK, at this point I can't even entertain the arguement.
3) OK, maybe not adopt another container, but Xiph should immediately improve/change Ogg for, breaking millions of hardware decoders and hundreds of millions of software decoders for a 'better' implementation that won't actually give users any features they don't have now. FOSS need _tools_, not us wasting time overoptimizing something they couldn't care less about.
3) 64 bit timestamp! OMG, waste! Wait, mov/mp4 uses 64 bit stamps... Also, plenty of things in Ogg use a full byte instead of one bit because the container assumes octet alignment. Alignment makes it much faster/easier to deal with (you don't need a bitpacker to read pages, and you don't have to repack packet data to embed it into the page). Remember, all the completely unacceptable waste adds up to about.4% of the bitstream [except those numbers were wrong and it wasn't that much anyway].
4) [Someone actually accused me of this one verbatim!] Xiph is cramming Ogg down our throats so they can control us!...using an open, documented, published, unencumbered container format on which Xiph reserves no rights or control.
OK, this is getting long...
Here's a bombshell in all caps: OGG COULD BE IMPROVED. Gasp! It sure as Hell could be. Or rather, could have been and will be in the future at some point. I'm a little surprised that no one saw fit to suggest improvements until now. It's been documented and used for twelve years. It seems odd to wait that long to suddenly alert the world that it's suddenly the worst thing ever created. Despite the fact that no one else really seems to have any problem with it.
But that said, most of the argument against Ogg really does consist of "I would not have designed it that way" and "how dare you not take my advice". The simple fact is there are a couple places where they're right-- and a whole bunch more where they're suggesting changes that improve nothing. It's also too late to change anything (for now) for completely negligable benefits that no user would notice or care about in the slightest. When could improvements happen? Possibly at the next major new codec rollout, when the whole world would want to upgrade anyway (eg, if and when Ghost sees release).
But yeah, that's not acceptable or sensible and we're totally out of control Nazi design pigs for not immediately apologizing to MPEG and retracting all our software. We suck!
You're right, in that Ogg could be improved to make it suck a lot less. Here's my list, which I'm sure is the same as everyone else's list:
Make CRC either not mandatory or attached to individual packets. Optional 8/16 bit (truncated) CRC. A single byte CRC per packet would do its job fine. For any stream less reliable, there's bigger problems to tackle. The CRC requirement alone is big latency issue.
Use 'UTF-8' style fields. The lacing values look stupid when packets are large (video). E.g, 0x40 can be ju
What the fuck are you talking about? There is absolutely no "latency" harm caused by the CRC, at least not on any hardware actually able to decode the formats much less encode. If performing the CRC on decode is so burdensome, you can stop checking it once you obtain sync and only check it if you obviously lose sync.
There may be, for example, 64KB pages, containing many packets. None of the packets can be decoded until the entire 64KB page is received and its CRC checked. This may sound small, but for 32-
There may be, for example, 64KB pages, containing many packets. None of the packets can be decoded until the entire 64KB page is received and its CRC checked. This may sound small, but for 32-64kbit stream, that's 10 seconds of latency right there. Alternatively, you can have 1 page per packet, but on 32-64kbit streams you end up with about 5-10% overhead from the container. It is a REAL problem.
So picture it:
You have a widget with knobs on it. Stuff goes into it, and other stuff comes out depending on how
Documentation is like sex: when it is good, it is very, very good; and
when it is bad, it is better than nothing.
-- Dick Brandon
Ah, and now slashdot... (Score:5, Insightful)
This whole thing is really about bad blood between Xiph and the mplayer folks. Once, long ago, I made disparaging remarks about a particular mplayer developer's extensive collection of ass hats, and they declared war. This stopped being about facts or reason years ago. Here's the last blog thread that got completely hijacked by the anti-Ogg container wingnuts. It's a hell of a read:
http://blog.gingertech.net/2010/02/20/googles-challenges-of-freeing-vp8/ [gingertech.net]
So, rehashing this yet again: The Anti-Ogg bullet points [Not going to bother with complete sentences, because I've wasted too much typing on this recently]:
1) A few of the mplayer/x264 hackers are right pissed that Ogg and Theora are getting all this attention when x264 is so obviously superior. That simply cannot stand. Since only America has patents and there are no computers there anyway, nobody should have to worry about them. Stick it to The Man! (How very ironic, Xiph being considered 'The Man' by folks contributing to an h264 encoder).
2) Xiph should immediately drop Ogg for [insert container here], breaking millions of hardware decoders and hundreds of millions of software decoders:
a) the [patented] mp4/MOV container is one suggestion they actually make seriously. Never mind adding 'willful infringement' to breaking the entire installed software/hardware base, this choice would totally redeem Xiph in their eyes. The benefit: by their own figures, it would reduce container overhead from .7% to .3%.
(Except that number is wrong. I found later that DonDiego screwed up his mp4 overhead figures at the link above; I had simply assumed he got his container numbers right. The mp4 file in his example has almost identical container overhead to the Ogg, a shade under 1%. His demultiplexed mpeg audio and video had framing in them, so it made it appear the mp4 container overhead was much smaller when he subtracted their file sizes.)
b) OK, mp4 is patented and no better, fine, Xiph should have just used Matroska from the beginning. Despite the fact that Ogg and Vorbis predated it by about five years (also mkv's not been able to interleave until just recently, which == no streaming). This is not to say you can't put Theora and Vorbis in Matroska. It's even a good idea! I've come to like MKV. But for streaming, Ogg is still much easier to deal with. Ogg was designed to stream, mkv was not.
c) OK, so, mp4 and Matroska are right out for streaming, Xiph should use Nut, which is the system they designed. Nut came ten years after Ogg was already widespread. And looks almost exactly like Ogg. Which is not to say there aren't things about it I like that improved on the Ogg approach. Eg, the packet length encoding is better. It has a conditional checksum coverage feature I had never considered, etc. At some point we'll make those changes when that wouldn't mean completely abandoning any chance we have at adoption just to save a fraction of a percent and add... no new features.
d) but.. but.. even FLV is better! OK, at this point I can't even entertain the arguement.
3) OK, maybe not adopt another container, but Xiph should immediately improve/change Ogg for, breaking millions of hardware decoders and hundreds of millions of software decoders for a 'better' implementation that won't actually give users any features they don't have now. FOSS need _tools_, not us wasting time overoptimizing something they couldn't care less about.
3) 64 bit timestamp! OMG, waste! Wait, mov/mp4 uses 64 bit stamps... Also, plenty of things in Ogg use a full byte instead of one bit because the container assumes octet alignment. Alignment makes it much faster/easier to deal with (you don't need a bitpacker to read pages, and you don't have to repack packet data to embed it into the page). Remember, all the completely unacceptable waste adds up to about .4% of the bitstream [except those numbers were wrong and it wasn't that much anyway].
4) [Someone actually accused me of this one verbatim!] Xiph is cramming Ogg down our throats so they can control us! ...using an open, documented, published, unencumbered container format on which Xiph reserves no rights or control.
OK, this is getting long...
Here's a bombshell in all caps: OGG COULD BE IMPROVED. Gasp! It sure as Hell could be. Or rather, could have been and will be in the future at some point. I'm a little surprised that no one saw fit to suggest improvements until now. It's been documented and used for twelve years. It seems odd to wait that long to suddenly alert the world that it's suddenly the worst thing ever created. Despite the fact that no one else really seems to have any problem with it.
But that said, most of the argument against Ogg really does consist of "I would not have designed it that way" and "how dare you not take my advice". The simple fact is there are a couple places where they're right-- and a whole bunch more where they're suggesting changes that improve nothing. It's also too late to change anything (for now) for completely negligable benefits that no user would notice or care about in the slightest. When could improvements happen? Possibly at the next major new codec rollout, when the whole world would want to upgrade anyway (eg, if and when Ghost sees release).
But yeah, that's not acceptable or sensible and we're totally out of control Nazi design pigs for not immediately apologizing to MPEG and retracting all our software. We suck!
Re: (Score:1)
You're right, in that Ogg could be improved to make it suck a lot less. Here's my list, which I'm sure is the same as everyone else's list:
Re: (Score:2, Interesting)
What the fuck are you talking about? There is absolutely no "latency" harm caused by the CRC, at least not on any hardware actually able to decode the formats much less encode. If performing the CRC on decode is so burdensome, you can stop checking it once you obtain sync and only check it if you obviously lose sync.
There may be, for example, 64KB pages, containing many packets. None of the packets can be decoded until the entire 64KB page is received and its CRC checked. This may sound small, but for 32-
Re: (Score:2)
There may be, for example, 64KB pages, containing many packets. None of the packets can be decoded until the entire 64KB page is received and its CRC checked. This may sound small, but for 32-64kbit stream, that's 10 seconds of latency right there. Alternatively, you can have 1 page per packet, but on 32-64kbit streams you end up with about 5-10% overhead from the container. It is a REAL problem.
So picture it:
You have a widget with knobs on it. Stuff goes into it, and other stuff comes out depending on how