Technical Objections To the Ogg Container Format 370
A user writes "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."
Still better than AVI (Score:4, Insightful)
Just complaining (Score:4, Insightful)
"I would have done it diffferently" does not mean that the format is bad. None of these "flaws" render the format unusable. Maybe it doesn't perform as well as another format, maybe it isn't designed the way you would like, but it's implemented, it's available, and it's in use.
Re:already slashdotted ? (Score:4, Insightful)
But there was a lot of interesting points though (I read it before it got slashdotted) and it went to technical points too. But what Ogg support, along others, basically comes down to:
The third reaction bypasses all technical analysis: Ogg is patent-free, a claim I am not qualified to directly discuss. Assuming it is true, it still does not alter the fact that Ogg is a bad format. Being free from patents does not magically make Ogg a good choice as file format.
This is so true, not only with Ogg or file formats, but also Linux and open source software too. The patent-free, open source and free are very rarely any good selling points. What it can actually do is. I can only hope more open source developers would get this - you can't sell the idea outside /. people for it being open and free, it also has to be better (or even on the same level).
Re:Still better than AVI (Score:3, Insightful)
Exactly this. Matroska in general is great and a lot better than Ogg or others, but it doesn't work on any device besides PC - not on 360, not on PS3, not in mobile phones.. CoreCodec should really try to push general support in other devices for it.
Not a selling point (Score:3, Insightful)
It's not a selling point, it's a starting point. It's a sine qua non. For an application like video on the Web, nothing non-free can even enter the conversation.
The Biggest Technical Objection (Score:1, Insightful)
Is that the ogg container format doesn't play itself.
Re:Not a selling point (Score:4, Insightful)
Apparently the rest of the world disagrees considering the widespread nature of flash video that has always used proprietary audio and video codecs.
Re:Not a selling point (Score:5, Insightful)
And then over here in actuality (rather than the conversation), there is Youtube. And Netflix. And Hulu. And so on.
Re:Just complaining (Score:3, Insightful)
Uh, wtf? Just because none of the flaws make it completely unusable doesn't mean it's not bad. If it has serious flaws, it is. As the writer states, it's a complete mess for app developers and lacks some required features that other formats have.
I can implement, make available and use a format I made in a few hours without thinking about it. Maybe it misses features for seeking because I didn't think about adding timestamps, and probably only usable audio format is WAV. But in your words it doesn't make my container bad and anyone criticizing it would be just complaining.
Flawed reasoning... (Score:3, Insightful)
There's at least one obvious flaw in his reasoning. He talks about removing the 8-bit version field in the header and replacing that with a 1-bit portion of the flags field to distinguish it from a hypothetical future version. That only works if one assumes there will only *ever* be two versions (v1 and v2). Such a basic failing of analysis is a pretty good indicator that he hasn't thought it all through as completely as he thinks he has.
Re:Not a selling point (Score:5, Insightful)
It's not a selling point, it's a starting point. It's a sine qua non. For an application like video on the Web, nothing non-free can even enter the conversation.
Says who? XanC? Any format (and its software requirements) can succeed as long as the users will put up with it.
RealPlayer did very well for many years (say 1995-2000).
Apple Quicktime is used on many sites.
And of course, there's Adobe Flash.
To simply say that "nothing non-free can even enter the conversation" is ridiculous. Are your clothes free or open source? Your car? Your house? Your shampoo, your radio, your computer's processor, your keyboard?
Companies can make excellent closed-source products. Communities can make excellent open-source products.
what is the point, exactly. (Score:5, Insightful)
I'm not an expert in video or audio production, I just dabble in it as a hobby. but one thing I often wonder is, what is the point of these container formats?
I've got a miniDV camera, and a canon point and shoot that thanks to chdk can record good-enough video. Both give me ".AVI" files, even though one is miniDV, while the other is Mjpeg. Mjpeg files don't work in my editor, while miniDV does. but I didn't know this at first, all I knew was that I have a bunch of .AVI files sitting in my hard drive, some work, some don't. I dont care about file extensions, I care about having files that work. I care about codecs. If they were named "filename.minidv" and "filename.mjpg" that information would be useful to me. What good is a container format when only half of the files within that container will play on my system?
I'm not trying to knock the idea of container formats, if they exist, their must be some beneficial reason for them. Could someone please enlighten me on what that reason is?
Re:Just complaining (Score:3, Insightful)
Actually, they never said 'unusable'. They said 'ill-suited'. And it is, if their technical objections are all correct.
It sounds like Ogg tried to be too much and as with any over-generalization, the specifics suffer for it.
That doesn't mean it should't be used, it just means it's not optimal.
Re:Not a selling point (Score:2, Insightful)
In which case the standard will be impotent (because it will be completely divorced from practice).
Re:what is the point, exactly. (Score:2, Insightful)
But its not just one codec that's involved, it's multiple. A typical video file will have at least two, one for video, one for audio. If you have alternate audio streams or subtitles, you need a codec for each of those as well. The purpose of a container is to let you take all these streams in their individual codecs and put them together in one file for easy playback. I'll grant you that it's not optimal to have some files with a given extension playable and some not, but with such a multitude of codecs in a single file it's just not possible to condense all that information down to a single file extension.
Re:Still better than AVI (Score:3, Insightful)
Of course, I use that too. But that's exactly the point - it doesn't support it, so you have to transcode.
Re:Not a selling point (Score:4, Insightful)
Add me to that list
It can, yes. But there's a difference between what can be done, and what should be done.
Actually, as of recently the Flash spec is available without restrictions, and there's gnash, a GNU implementation.
No, but I think they should be, it'd be better if they were, and that it's a goal well worth fighting for.
Especially since we're talking about standards here, and I don't see how something with one possible implementation can be a standard. A standard is a published spec anybody can implement. "Buy from $company" isn't a standard.
Actually, I think you used quite horrible examples as well. Let's see:
Clothes: the "spec" is open. Anybody can make their own pants if they wish to, and nobody is going to come ask for license money.
Car: Also open and well documented.
House: Built according to code
Shampoo: has a very loose open spec
Radio: How to receive FM signals is well documented and not restricted AFAIK
CPU: some (though not all) are open, with complete specs and source available
Keyboard: Either PS/2 or USB, is made to fulfill an open specification.
Every single thing you picked as an example complies with an open standard, can be made by anybody without needing to pay for a license, and is interoperable (any car from any manufacturer works and is legal to drive, so long it complies with the relevant standards for instance)
It's not about the quality. It's about a principle. I reject a closed "standard" for web video on principle, no matter how well implemented.
Re:Flawed reasoning... (Score:5, Insightful)
It is not in the header, the 8-bit version field is in every single page. As according to the post a page is mostly 64K due to a strange length encoding, you send the version very, very often. I don't see any reason, why the version would have to change in the middle of a file in any case. And honestly, would you write a decoder taking that into account, if the probability of stumbling onto such a file was currently 0 (due to there being only one version) and very, very low in the future? That means it just adds to the size of the file.
The second reason is even simpler, you only need one bit to tell the current format from the future formats. As there hopefully will be a good reason for a future version the page header will probably be different, so I can add a version field there when I at least found one reason why I need it, no? That way I need one bit now and can still have different versions later.
Re:Not a selling point (Score:4, Insightful)
Actually, as of recently the Flash spec is available without restrictions
But Flash still uses H.264 too. I don't see too many people, either normal web users, webmasters or those making Flash applets complaining.
It's good you reject closed-source products by principles, I wish I would too. But the reality is, people just want the best performing tool for the job and frankly the older I get the more I think so too. I had these fundamentalist ideas in late teen years, but then I faced the real world. Now I pick the right tool for the job, be it open source or closed. I use Windows on desktop because I game and think the experience is better, while still giving me freedom to mess around with the system. I use Linux on servers because they perform a lot better and command line usage with servers is a lot better, and in that case and scriptability Windows doesn't come even close. But fundamentalism and closed mindset in the end is just stupid.
Re:Not a selling point (Score:4, Insightful)
Mindshare has more to do with advertising and promotion than raw technical superiority. Proprietary, patent-protected technologies tend to florish simply because companies are more willing to invest in promoting them if they'll reap all of the benefits when they sell. If anyone and her brother could legally make and sell Gucci-branded handbags, then there would be no incentive for Gucci to spend $millions on advertising and you'd likely never hear about them.
Re:Not a selling point (Score:4, Insightful)
Apparently the rest of the world disagrees considering the widespread nature of flash video that has always used proprietary audio and video codecs.
And that will be fine so long as Adobe is always around to maintain and develop Flash, and people are always willing to use it. Personally, I can't see being married to one av format simply because it works, world opinion be damned, but it is what everyone uses. Until HTML 5 gets wider adoption, perhaps. Frankly, if I were Adoba I'd be getting out of the "Chief bottle washer and Flash maintainer" business myself, I hope for their sake they've poured money into something new that they've kept the wraps on, as I would hate to have as large a percentage of my business as they have based on 15 year old technology. I'd do that then just before I trotted the new stuff out let Flash wander out into the open source pasture.
Which doesn't answer the question ... (Score:2, Insightful)
... of what format *should* be used in its place.
It is all very well claiming one format is not particularly good, but overall rather pointless if you don't argue an alternative.
So the question any .ogg user will have (since they probably chose this slightly obscure format over the more 'normal' .mp3 alternative due to the reputation of being better to listen to from an audiophile POV) is what to use instead? FLAC is fine if you have the space, but sometimes you want to compromise in order to save storage space...
Re:Still better than AVI (Score:5, Insightful)
I get what you're saying, but how is this different for Matroska than any other container format?
Re:Not a selling point (Score:4, Insightful)
For now. Just wait until they decide to start charging for the license, then there will be plenty to complain about, but it'll be hard to avoid paying up, since it will be so widely used.
People are short sighted. I think long term.
I had these ideas in late teen years, but then I faced the real world. I worked with proprietary stuff enough to figure out that indeed I don't like it, so I got a job where I work exclusively with Open Source and release my code under the GPL. It's really awesome, you should try it.
I use Linux on the desktop because that's what works best for me -- though for me "works" nearly implies "comes with source". Even if it works now, some day it'll do something I don't want it to, or not do something I want it to. That's why I require the source upfront, then I don't have that issue.
I use Linux on servers for the same reason.
It's not fundamentalism, it's long term thinking. I don't like exchanging short term convenience for lock-in, licensing payments and major limitations later.
And as the time passes, OSS software improves so things keep getting better. Maybe you should give it another try.
Re:Ogg is a nice format (Score:5, Insightful)
I can't say anything about video, but for audio all my CD collection is converted to Ogg instead of MP3, you can't even spot the difference in quality, thou the filesize is smaller. BTW, my MP3 player supports Ogg playing as well.
Audio quality and compression efficiency are controlled by the codec, not the container format. The article is critiquing the latter.
Technical Objections by Armchair Engineer? (Score:2, Insightful)
His complaints:
On top of this we have the 27-byte page header which, although paling in comparison to the packet size encoding, is still much larger than necessary.
Ok, it's a container format, nobody cares about an extra 27 bytes when you can buy TB of storage for virtually nothing. And if you're complaining because it needs to go in the intertubes, gz compression on the server does a very good job of extracting and compressing plain non-random text like page headers but again, MBits are cheap and unless you're living in the US they are plenty.
The version field could be disposed of, a single-bit marker being adequate to separate this first version from hypothetical future versions. One of the unused positions in the flags field could be used for this purpose
It's kind of important to keep track of versions. If your player can't play the next version or an older version it should be able to detect that so it doesn't try-and-fail. It might also want to suggest what version of the player is required.
A 64-bit granule_position is completely overkill. 32 bits would be more than enough for the vast majority of use cases. In extreme cases, a one-bit flag could be used to signal an extended timestamp field.
That's what they said about our memory too back in the early 90's. 32-bit addressing is enough, nobody will ever have more than 4G of RAM. Again, these open formats tend to be scalable across time because they need to fulfill a certain mission. Look at ZFS, they have 128-bit addressing but nobody (currently) needs that amount of storage.
32-bit elementary stream number? Are they anticipating files with four billion elementary streams? An eight-bit field, if not smaller, would seem more appropriate here.
Why not, how many languages are there around the world? If you need to bring out a media file with subtitles and audio-tracks for each language, braille instructions and who knows what else for open access to certain media, you might want to use more than 256 streams.
The 32-bit page_sequence_number is inexplicable. The intent is to allow detection of page loss due to transmission errors. ISO MPEG-TS uses a 4-bit counter per 188-byte packet for this purpose, and that format is used where packet loss actually happens, unlike any use of Ogg to date.
Well, maybe the makers intended Ogg to be used eventually to replace MPEG (c)(patented) and used across links with much higher transmission errors. Sometimes my MPEG-encoded stream I get from my DTV provider has enough errors to stall and cause artifacts. When NASA wants to use Ogg for a non-repeatable stream from outer space, they should be able to. Again, overhead is a small cost to pay these days.
A mandatory 32-bit checksum is nothing but a waste of space when using a reliable storage/transmission medium. Again, a flag could be used to signal the presence of an optional checksum field
Ah, well, what is reliable these days? Ever used a large array of hard drives? Ever used a freakin' dial-up connection? As the makers of ZFS, Google and a few others recently have shown hard drive and memory reliability is not as good as we take for granted. Silent data corruption is a major cause of data loss these days.
With the changes suggested above, the page header would shrink from 27 bytes to 12 bytes in size.
Whoop-dee-doo, you made it half the size but you sacrificed reliability, error correction and future-proofness.
Latency
You show that the overhead is anywhere from 1% to 7%. That might not be the requirements for latency-sensitive applications but then you would again sacrifice other features. That is always a balance between speed and reliability but for most applications it doesn't really matter if the movie needs to be buffered 5ms longer.
Random access
You've got somewhat of a point there, maybe somebody will find a solution for that. The issues around indexing however is that seeking within a stream is possible. HTTP servers
Re:Not a selling point (Score:4, Insightful)
The rest of the world has always constantly complained about how buggy and slow Flash is. Even the HONEST "boosters" have freely admit to this problem. This is a problem that exists primarily because of the very proprietary nature of Flash. Although this does demonstrate how patents alone aren't such a barrier. EVERYONE has better video implementations than Adobe. This even includes multiple Linux video players.
There are $200 general purpose PCs that make great little HTPC machines except for one little detail: Adobe's a sandbagger.
This comes from letting crass corporations have the keys to the kingdom.
Re:Still better than AVI (Score:3, Insightful)
I can see this problem going from MPEG2 to MP4 for an iPhone. So this is hardly a Matroska only problem.
Consumer video devices, especially video devices, tend to have a very limited range of what they can handle. It's just a side effect of the tech being relatively immature.
Overly-large analysis of article (Score:4, Insightful)
Quite a bit of the analysis seems to be reasonable on the surface, but something about the way it was presented set me off in a geek-rant that I put in the comments. Since I'm having trouble posting that comment on the site, here it is.
Many of the points sound reasonable, but the argument is strongly undermined by the fact that it offers not a single apples-to-apples comparison between ogg and any other container format in the article. On a section-by-section basis:
Generalities/codec mapping:
Article complains about how there is no global mapping, but does not assert that other containers have one.
Overhead:
The breakdown of where space is wasted is informative and mostly reasonable, but some of them seem to be a reach, such as the checksum being unneeded, and the suggestion of implementing the functionality in optional fields seems like a bad idea to me in general, since it will make the header variable-length, which is something to strongly avoid in my experience. Finally, when the article does "compare" ogg to mp4, it compares some rather hand-wavey numbers for ogg to a different scenario for mp4.
Latency:
The article fires off a bunch of numbers here, but then offers no comparison to the alternatives. In fact it don't even provide an explanation of how other formats avoid this latency in theory, much less in practice, and instead of showing how bad the latency is, it uses it as a platform to show that a naive reaction to the issue will cause bad header overhead.
Random Access:
In this section it lists quite a few worst-case numbers for disk accesses (why isn't it being pre-cached by the filesystem?) and then ends with no comparison to alternatives at all.
Complexity:
Once again it has a bunch of statements of problems the author has with the format, but no comparisons to "good" formats, in addition this section is particularly weak, with statements like, "implementation is annoying", and "ambiguity is bad".
Final Words:
"We have shown" is a rather specific claim to make, which the article has not remotely achieved. This pretty much sums up the whole article, which is titled "Ogg objections", but then tries in the text to bill itself as a rigorous analysis of ogg, which it is not.
If the author had matched the tone of the article to the title, this would be reasonable, but he only hurts his position when he throws around phrases like, "True generality is evidently not to be found with the Ogg format.", "The Ogg format is clearly not a good choice for a low-latency application.", and "We have shown the Ogg format to be a dubious choice in just about every situation.". He has demonstrated NONE of the above claims, and by making them the article has rendered me skeptical of the rest of its claims.
Re:Not a selling point (Score:5, Insightful)
PNG gained support for three reasons.
1. It's non-lossy, unlike JPG.
2. It's does 24-bit color with 8-bit alpha transparency, unlike GIF which does 8-bit color with indexed transparency (one color is replaced with transparent).
3. Unisys patent trolled companies/people who made image editors that could output GIF.
Re:Technical Objections by Armchair Engineer? (Score:5, Insightful)
I forgot to mention that one can do much better than a naive binary search. Read the first and the last of the file to calculate the average block size. Calculate the approximately place your target will be. Jump there and repeat. Once you are very close to your target, read a larger block of data which will get your target by a very large probability.
This would get your target with not many more seeks than reading an index.
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 unacc
Comment removed (Score:5, Insightful)
Ogg needs to die so Vorbis and Theora can live. (Score:5, Insightful)
I sadly have to agree, and I've voiced the same objections for a long time. It really is like he tells it: it's just bad at everything it was intended to achieve. It's a source of bugs, it's horrendously complicated to support, and it's horrendously inefficient at anything but audio (and even then, not so good).
It seems to me, most of what went wrong was trying to support concatenation of Ogg streams. This is a nice idea, but actually quite a rare case. It's also incredibly naive for the specification document to request that Ogg implementation detect this. What, I'm supposed to scan the entire file in case that happens? No. I'll just not be compliant to that, thank you very much.
I even wrote my own Ogg/Vorbis decoder from scratch [mooo.com] a while back (and dabble every now and then), and found Ogg to be a never-cooling, never-extinguishing steaming pile of hippo crap left over from consuming a dog. It just made everything so difficult to do. Seeking a stream involves divide-and-conquer - not necessarily a bad thing, but when you have huge streams the number of seeks can be bad. Not to mention if your stream has an endpoint the other side of the Atlantic Ocean. Why oh why did they pick timestamps being at the END of a page and indicating the output byte count produced by the END of that page? That little detail alone probably cost me days of debug.
I almost gave up at one point and went to a container format of my own which would have worked much better. Header: 'CONTAINER v1'. Packet: 'MAGIC', 4 byte Length, 4 byte Output pos. Job done. The sad fact is, that's easier than Ogg, smaller than Ogg (unless you're talking really low bit rate), and does entirely the job of Ogg without the complexity.
I'm probably going to add a Matroska container to my codec just to see how easy they are to produce. The spec looks fantastic, but the devil's always in the details - although seeing the praise on various (engineer) forums, it looks like the way to go.
So, Ogg, please die. We need you to get out of the way.
Re:Technical Objections by Armchair Engineer? (Score:3, Insightful)
I wonder who's the armchair engineer here...
Ok, it's a container format, nobody cares about an extra 27 bytes when you can buy TB of storage for virtually nothing.
It's extra 27 bytes per page, not per total file. "Tb of storage" reference is irrelevant, since we're talking about streaming here.
And if you're complaining because it needs to go in the intertubes, gz compression on the server does a very good job of extracting and compressing plain non-random text like page headers
Are you seriously proposing live streaming the entire an audio or video stream (presumably produced by a compressing, lossy codec) through gzip?...
Or did you suggest just running gzip on the headers? In the latter case, you do realize that the overhead will likely be larger than header size?
It's kind of important to keep track of versions. If your player can't play the next version or an older version it should be able to detect that so it doesn't try-and-fail. It might also want to suggest what version of the player is required.
TFA doesn't say that it's not important. It says that there are more space-efficient ways of doing so, especially when there is only a single container version so far in practice (so we may just as well optimize for this case).
That's what they said about our memory too back in the early 90's. 32-bit addressing is enough, nobody will ever have more than 4G of RAM. Again, these open formats tend to be scalable across time because they need to fulfill a certain mission. Look at ZFS, they have 128-bit addressing but nobody (currently) needs that amount of storage.
Again, TFA does say that, for those extremely rare cases where 64-bit positions would be needed, a more efficient variable-length encoding could be devised, so that the common case is smaller (e.g. 31 bits lower + 1 bit flag + optional 32 bits upper).
Why not, how many languages are there around the world? If you need to bring out a media file with subtitles and audio-tracks for each language, braille instructions and who knows what else for open access to certain media, you might want to use more than 256 streams.
I can actually agree on the reasoning here, but again, there are more efficient ways to encode a number of "usually less than 16, very unlikely but still possibly hundreds".
Well, maybe the makers intended Ogg to be used eventually to replace MPEG (c)(patented) and used across links with much higher transmission errors. Sometimes my MPEG-encoded stream I get from my DTV provider has enough errors to stall and cause artifacts. When NASA wants to use Ogg for a non-repeatable stream from outer space, they should be able to. Again, overhead is a small cost to pay these days.
If they "maybe intended" it for some hypothetical applications, making it a mandatory feature that is useless in 99% of all practical applications both today and in foreseeable future is kinda useless. In any case, error detection is much better handled at lower level, on the transmission protocol.
Ah, well, what is reliable these days? Ever used a large array of hard drives? Ever used a freakin' dial-up connection? As the makers of ZFS, Google and a few others recently have shown hard drive and memory reliability is not as good as we take for granted. Silent data corruption is a major cause of data loss these days.
You need to start with a solid reference for your final claim. Even if provided, though, this doesn't change the fact that a container format for streaming data is not the best place to do error checking, since it imposes this burden on all users, regardless of any error checking already present on lower levels (which may, and, in fact, almost always is enough for the practical application at hand).
Whoop-dee-doo, you made it half the size bu
Re:Not a selling point (Score:5, Insightful)
MP3 playback gave longer battery life over WMV, can't say about Vorbis as I've honestly never come across a Vorbis player...
The problem with the OGG formats is the classic "chicken or the egg" problem. Nearly no support in hardware...
I don't think there even IS a single device with hardware Theora support, is there? OGG being "free as in freedom" really isn't gonna matter much if nobody supports it, and I haven't seen hardware manufacturers rushing to add it to their bullet point lists.
You lose all credibility with nonsense like this. My Sansa Fuze plays ogg (flac too, but anyone who puts flac files on a 4gb flash device is taking it a little far). My dear departed iAudio X5 played ogg and flac. A fucking shitload [newegg.com] of audio players play ogg. Go ahead, ask me why.
"Why, Risen?"
I'll tell you why. Because it's patent-free, unencumbered, and an easy bulletlist item to put on a device. No, maybe they "don't give a shit about freedom," but they do give a shit about easy.
Re:Not a selling point (Score:3, Insightful)
but OGG is here, OGG is now, and OGG is part of the spec.. until a bunch of whiners decided they didn't want FREE competition. Ogg may not be great, but it's "good enough". There are many "standards" web browsers support that haven't been used on modern pages for ages.
The article completely misses the point that Ogg would be just fine for the little snips from my iPod Nano, or from my little hand recorder, or for my SCA how-to videos. The day is coming when people will have to PAY to host all these popular video and audio formats on their own sites. With the new IP rules coming ISPs will be forced to lock out anybody that doesn't pay first.. there's no "fair use" for patents. Meaning you will be forced to pay a large fee, or host ALL your material thru Apple or Google (and force your visitors to watch THEIR ads) who will have a choke-hold on everything interesting on the Internet.
Re:Not a selling point (Score:1, Insightful)
"That is why MP3 stomped Vorbis and FLAC"
No. MP3 stomped vorbis because it came first and had inertia. It stomped FLAC (Not that they are direct competitors), for the same reason, and due to the much smaller file size, which was important when portable players had 64MB of storage. The primary reason MP3 succeeded was that it was first, and therefore had the majority of the market. The reason it "just worked" is because it had the majority of the market and devices targeted it.
Re:Not a selling point (Score:2, Insightful)
Um, no. Being proprietary does not inherently make one slow or buggy, and being open-source does not make anyone faster or less buggy. If you believe so, I have a bridge to sell you.
Flash is "slow" if for any reason, because it is cross platform and tries to do a lot of things, including gaming, RIAs, and video, etc, and is immensely ambitious (trying to run on any number of phones as well as desktops), and yes has an aging code base. These are not problems inherent to proprietary software.
You may say that a rewrite from scratch might help, but then you'd also need an economic incentive to cause people to invest the time and effort to do so, and you'd also be opening all sorts of intellectual property issues, plus what about the tools necessary to support workflows, etc. Merely complaining about the status quo, without suggestions, is not a good solution.