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."
already slashdotted ? (Score:4, Interesting)
I don't see any comment and the website is already down. gg /.
Re:already slashdotted ? (Score:5, Funny)
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).
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.
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: (Score:2, Interesting)
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.
Comment removed (Score:5, Insightful)
Re: (Score:3, Interesting)
"That is why MP3 stomped Vorbis and FLAC, because it was easy"
Because it was first, and gained momentum. At the end of the day, MP3 gained popularity because of pirates and they aren't exactly known for caring about patents. Those that were ripping from their personal collection often chose FLAC or Vorbis. A codec is just a codec, there is nothing more 'easy' about any one of them.
"can't say about Vorbis as I've honestly never come across a Vorbis player"
Any Samsung player, but then if Vorbis became popular
Re: (Score:3, Interesting)
You care about the average Joe because he seemingly gets to decide which codec is hardware accelerated and which codec is used by major web sites. Even if you (or I) find his choice unacceptable.
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: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.
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: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: (Score:2)
Re: (Score:2, Insightful)
In which case the standard will be impotent (because it will be completely divorced from practice).
Re: (Score:2)
The same was said of HTML itself when Microsoft decided to 'fork' it with IE. Sure it took a long time for the dust to settle and Microsoft to accept defeat and finally implement the actual standard, but if we even took on Microsoft itself I doubt we'd fare any worse against the much smaller Google and Apple.
Just keep patents off the official standard. Sooner or later they'll learn the idiocy of patented standards, and its best we don't have to fork it over when they do, specially given the W3C is now the o
Re: (Score:3, Interesting)
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: (Score:3, Informative)
Netscape Navigator had useful support for PNG starting in November, 1997 [vias.org] with version 4.04. This beat even the existence of Firefox 1.0 by seven entire years [wikipedia.org].
This was even several months [wikipedia.org] before Netscape released the source code for their browser, which was the event that made Firefox possible in the first place.
Even Microsoft had the beginning of useful PNG support in Internet Explorer starting with version 4.0, released in September of 1997 [wikipedia.org].
Now, sure: As I recall, Firefox was way before IE in fully suppo
Re: (Score:3, Informative)
Re: (Score:2)
This is especially true with the battle over HTML5 Video. Technically H.264 is a lot better format than Theora, especially on web because you can stream a lot better quality on slower bitrate. This is why YouTube uses H.264 even with the HTML5 Video tag testing and why all Microsoft, Google and Apple support it. Maybe Google pulls some new great open video codec format still as they bought a company developing such, but until that H.264 will win over Theora too just on technical merits.
Re: (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
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.
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: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: (Score:2)
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.
That's because Adobe is the one footing the bill for MPEG's patent licenses. If it were *them*, the actual users and webmasters, the bitchfest would be simply epic (well, mostly from webmasters, users would just torrent a pirated version from TPB or something).
And if anything is "fundamentalist" in this discussion, is the idea that performance trumps everything else, regardless of circumstances. You'd think all those arguing for h.264 due to its performance would be using IBM mainframes to post on Slashdot
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: (Score:2)
"Buy from $company" isn't a standard. "Get a license from $company" can be, and often is. In many cases, patents are to be licensed on a RAND (Reasonable And Non-Discriminatory licensing) basis, which really isn't better than a patent troll for free software, but works very well in the commercial and proprietary world.
As far as your car and CPU are concerned, unless they're over 20 years old they've probably got some patents that apply to some features, and so you can't just make your own legally witho
Re: (Score:2, Interesting)
This argument is what will kill HTML5 and ensure a new era of the reign of flash, silverlight, etc. The choices are not h264 or theora. Its h.264 through an open html5 spec, or h264 through silverlight and flash. All major operating systems have support for h264 built in as it is (not to mention all the portable devices with hardware acceleration for it, including now many netbooks). The whole debate is stupid, firefox needs to just use the operating system's built in codecs to play h264. Problem solved
Re: (Score:2)
"This argument is what will kill HTML5 and ensure a new era of the reign of flash,"
Not as long as one of the top hackers in the world continues to prove that Adobe is one of the biggest security threats to the web.
Re: (Score:2)
Talk about missing his point.
Re: (Score:2)
The patent-free, open source and free are very rarely any good selling points.
Really? guess somebody should tell game devs that, then, and make them pony up the cash for AAC instead of using Ogg Vorbis for their engines.
When you want to ensure your product reaches the biggest amount of people, the best thing to do is to pick a patent and royalty-free standard as the base, and *then* work around the technical details, because nothing alienates hobbyists more than a third-party going around suing your customers for unpaid royalties. For a game engine such things are important, but for
Re: (Score:2)
Thanks for bringing that up, I recently picked up the PS3 version of the recent Ghostbusters game and what do I see when I start the game? A Xiph copyright notice. It's the only one I've seen it in, however. Lots of Bink video notices though.
Re: (Score:3, Informative)
If you'd drop the "casual" from the statement, it'd also be fairly accurate.
I do know that in the large the casual/indie space are using OGG as the format- it's more to avoid the per-unit royalties that the "superior" formats charge, but if it were as all bad as the article author makes it out to be I can assure you that they'd not be using it.
Re:already slashdotted ? (Score:5, Informative)
However, it's not unique to OGG. AFAIK, MKV is also patent-free, and it's the standard container for torrents^Wprivate-encoded HD video. And it's a much better container anyway.
Re: (Score:3, Informative)
Which is fucking stupid when you think about it. All those MKV files contain MPEG-2, MPEG-4 or h264 video, and usually AAC or MP3 audio. Given that you're using those patent-encumbered codecs, you may as well use the standard patent-encumbered container, MPEG-4. All you do by using MKV instead is annoy people who would like to play the video on their AppleTV, PS3, Mac, PSP, iPod, phone, etc.
Re:already slashdotted ? (Score:4, Funny)
Yes, but what format is the website in? I'm thinking something involving ashes.
Re:already slashdotted ? (Score:5, Funny)
Wasn't us. We don't read the articles before posting.
Re:already slashdotted ? (Score:5, Funny)
There's articles? Since when?!
Re: (Score:2)
Wasn't us. We don't read the articles before posting.
Or after posting.
Re:already slashdotted ? (Score:5, Informative)
Re:already slashdotted ? (Score:4, Interesting)
Still better than AVI (Score:4, Insightful)
Re: (Score:2, Funny)
You forgot the lack of general support. Definite win on the ideological front.
Re: (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.
Re: (Score:2)
Re: (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: (Score:2)
Re: (Score:2)
That's good to hear, but it still doesn't work with PS3, 360 or other devices I have :-)
Re: (Score:2)
http://hubpages.com/hub/How-To-Play-MKV-Files-On-Playstation-3 [hubpages.com]
Really, googling "Play MKV on PS3" isn't that hard - it just removes the container format and puts it all back into native VOB.
Re: (Score:2)
You're missing the point. I know how to convert them to play on PS3, but that still doesn't make PS3 support Matroska.
Re:Still better than AVI (Score:4, Informative)
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..
However, matroska support is pretty much standard in any but the most proprietary set-top boxes. For example - WDTV, TiVX, Popcorn Hour - basically anything that uses any recent Sigma Designs chipset. Similarly iRiver supports matroska on their newest portable media players and Archos's latest android based pmp also supports matroska.
JVC and Phillips have currently shipping blu-ray players that play matroska. Panasonic has announced their next generation of TVs and blu-ray players will do matroska, and the specs for NEC's next gen of video decoder chipsets (which compete with Sigma Designs) say they will include matroska support.
Re: (Score:2)
"Matroska in general is great and a lot better than Ogg or others, but it doesn't work on any device besides PC"
My AIWA DVD player can read MKV containers as long as the codec used for encoding is FourCC compatible.
Re: (Score:2)
I'd like to use Matroska more, I like the DVD-like features such as alternate audio tracks and switchable subtitles. Have any recommendations for encoders that can include these features? VLC appears to work pretty well on the player side.
Re:Still better than AVI (Score:4, Informative)
Re: (Score:3, Interesting)
The great thing about Matroska is that it supports (or at least can support) absolutely everything.
The main drawback of Matroska is that it supports (or at least can support) absolutely everything.
Matroska is a great container format, but unless you have a program like mplayer or vlc you can't guarantee that a Matroska file is going to be playable on your system. You can't reasonably expect browser maker to standardise on Matroska if it will mean having to include 30+ different codecs in their software, whi
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: (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.
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:Just complaining (Score:5, Interesting)
More commonly, the Ogg proponents will respond with hand-waving arguments best summarised as Ogg isn’t bad, it’s just different. My reply to this assertion is twofold:
And he's right. Unless the technical details of Ogg are not as he represented them, the format is stupid. I've not looked at Ogg in detail, but I have written multimedia apps and his complaints are right on the mark. Even if most of them are untrue, the point about timestamps would have been a show stopper. There is absolutely no excuse for not encoding timestamps as rationals in a fixed format in the container. Without that, you are just inviting synchronisation problems between audio and video CODEC formats that aren't explicitly designed to work together.
Which may, of course, be intentional. Vorbis and Theora are designed to work together. But if you have a Theora video stream with MP3 or AAC audio, what happens? An H.264 video stream with Vorbis? Obviously the solution is to just use Xiph formats in the Xiph container. And that's fine. I don't have a problem with Ogg as a container for Xiph formats (other than the latency issues he mentions), but claiming that it is a general purpose format is misleading.
Ogg is like XML. It defines just enough to let you define something useful, but it's not useful by itself.
Re: (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
Re: (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: (Score:3, Interesting)
Every open source multimedia developer outside of Xiph.org, who has had to do anything with Ogg, will tell you that Ogg is a flaming pile of crap. This notably includes Moritz Bunkus, the author of Ogmtools. Quotes of such are easy to find.
For a real challenge, just try to find ANYONE saying Ogg is a well-deigned and well thought-out container format...
Re: (Score:3)
and
Are we to believe that they have no clue about container formats?
Re: (Score:3, Interesting)
YES! From the same link:
Ogg was designed to stream audio, specifically Vorbis. Ogg was not designed to handle video, or any other type of audio.
Ogg is so tightly coupled to Vorbis, and has only the minimal features required for streaming. It's shortcomings become clear when you try to do ANYTHING ELSE. Even just playing a local file, you find seeking horrible, no way to do a accurate progress-bar, etc, etc.
And when you try to stick anything
Re:Just complaining (Score:4, Informative)
Haven't read the article, because it's slashdoted, but I assume it's about the fact that the Ogg container was initially designed as a transport stream format for audio.
The article goes considerably beyond that, arguing that the container is flawed even as an audio format. Here's the money quote (emphasis mine):
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: (Score:2, Interesting)
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).
No, the flaw is yours. The 1 bit merely says "this is not the original version" and anyone that only knows the original version just stops there. Anyone that knows the 2nd version has enough smarts to look at the 2nd version bit (or field).
Re:Flawed reasoning... (Score:4, Informative)
No, the flaw is yours. The 1 bit merely says "this is not the original version" and anyone that only knows the original version just stops there. Anyone that knows the 2nd version has enough smarts to look at the 2nd version bit (or field).
In which case once there is a second version you have the exact same packet format as the current ogg, except for an extra mask, test, and one fewer flag bit. So the only gain at all is if you assume there will never be another version, and if there is even one more version then you've caused a pipeline stall for no reason. Which is stupid.
This goes along with the criticism of the checksum field as 'wasted space', but it is probably put there so you can reliably find the page header if doing a random seek. Which if you can do, then you don't need a time index because you can do a binary search to find any time index with only a tiny bit of extra seeks.
I haven't looked at these formats in depth, but it sure sounds like this guy is clueless.
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:Flawed reasoning... (Score:4, Informative)
> I don't see any reason, why the version would have to change in the middle of a file in any case.
It is probably not due to the fact, that the version might change in the middle of the file, but in case, you only have a part of the file.
This makes it more robust, and better suitable for streaming: You can simply start sending from an arbitrary position, and the parser should
be able to recover at some point.
Re: (Score:2)
I would assume that redundant page level data as fundamental as the encoding version would be most helpful when streaming, especially streaming live. I can't be bothered to read the article, but it sounds like the critic isn't taking into account all of the reasonable use cases. Not everybody downloads a file and plays it from beginning to end and not everybody can start from the beginning. If the stream started yesterday and I want to start watching it today, there had better not be any indispensable da
Re: (Score:2)
Actually, it shows the opposite to me. You have the current version,
Re: (Score:3)
No, that's not true. Version 2 can simply define a new bit to indicate whether it's version 2 or later.
The real problem with this optimization is it's effect on later versions.
Say one eventually moves to version 12 and each version along the way defines it's own flag. That mean's you've used 12 bits and some very nasty decoding logic to indicate you are a version 12 format when you could have just reserved that one byte and used a case statement.
I mean the annoyance and difficulties created by using a nex
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:what is the point, exactly. (Score:5, Informative)
Re:what is the point, exactly. (Score:4, Informative)
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?
The point of containers is to make the contained media modular. This way, you can assemble a multimedia ("many media"... whodathunkit) file from several individual pieces of media, each with codecs that may or may not be on speaking terms, into a cohesive file that i played as a unit.
If you define a format that has a video track and two channels of audio, you might think, hey, that's great, and play stuff on your computer. But what if you want a 5.1 audio track? Make another format, one for stereo and one for 5.1. Second audio program, like an alternate language? More formats: one for stereo + stereo SAP, one for 5.1 main + stereo SAP, one for 5.1 both; up to 5 formats now. Subtitles or closed captioning? More formats: up to 20 now. A different audio codec? Even assuming the SAP tracks and main use the same codec (they might not; depends on where you got the SAP track from), add 20 formats per audio codec. Multiple video codecs? The number of formats can grow exponentially. And we haven't even gotten to things like multiple camera angles and sideband info like text commentary, HTML links to things discussed in the show, or TV listings.
Or you can define a container and then, in each of those cases, only need to define a new component to be put into the container, and you're done. Containers make things much simpler and easier to implement.
Re: (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
Re: (Score:3, Informative)
Of course this is mostly true for player software. Editing software sometimes wants to do more low level bit twiddling (e.g. to minimize recompression
Re: (Score:2)
There are a lot of benefits to containers. I'm sure I can't name them all.
These container formats contain multiple types of data streams. Ex: audio, video, multi-language subtitles, etc. If you don't have a container format, then the software must guess at what streams are in the file. Would a file with H264 video + MP3 audio have a different extension from H264 + AAC? What if I add subtitles, does that need another extension? The container file solves this.
Because there are multiple streams, the soft
Re: (Score:2)
Lastly -- what app doesn't work with MJPEG .AVI files???? That's like the absolute baseline most commonly, easily-supported format.
Sony Vegas 7a does not have mjpeg out of the box. The audio track opens, but no video (I will be upgrading to 9 pending the completion of one more video job. I only invest into this hobby what I make from it)
I eventually got it to work thanks to ffdshow, but it was a year before I stumbled upon that solution.
I think I understand the purpose of container formats now.
To use a non-car analogy: it's like having multiple separate channels coming at you simultaneously. if one is not recognized by the system, th
Re: (Score:2)
Think about an HTML file. It can contain embedded objects and/or alternative tags, or newer tags, all of which your browser may or may not work with. Containers are important because they provide the meta information that players need to orchestrate the various streams embedded in them. Some containers were built for instant streaming in mind (FLV). Some were simple data partitions (AVI). Some are jack-of-all-trades that do everything (MKV). Some are so simple that the user has to provide information
Re: (Score:2)
A container format is a necessary evil. There is much more to any media file than just the content. Potentially in any media file there may be metadata, timing information, synchronization information, subtitles, multiple language audio streams, multiple video streams, 3d video streams, surround sound information, interactive content, etc.
A good container format is one that allows all of those things in a way that developers supporting that container format can utilize in a standard predictable way.
If you
Re: (Score:2)
If all you have is a single video stream then you don't really need a container. However, once you start adding in audio tracks, subtitles, and interactive features (e.g. menus), you need some way to combine these streams together in a manner which minimizes the need for buffering and/or random access (seeking) during normal playback. Container formats also supply the format identification, tags/metadata, and indexing/seeking support which raw formats typically lack.
Re: (Score:2)
You do make a good point about the name, though. A name like: filename.pcm.dv.avi, or filename.mp3.mjpg.avi would reveal a lot more information. Too bad that scheme isn't more widely used.
slashdotted (Score:2)
Here's the coral mirror:
http://hardwarebug.org.nyud.net/2010/03/03/ogg-objections/ [nyud.net]
In the long run (Score:5, Interesting)
"In the long run, all file formats become programming languages."
From this I draw a number of conclusions, the first being that when designing a format you need to bring a "language sensibility" to it. If you don't, it's only a question of *when*, not if, your format will become a poorly designed language. OK, "language" may not be the right word. I'd also accept, "byte code" or "executable file", but it's the same idea. JMHO.
A better free container, IMO: Matroska. (Score:4, Interesting)
Besides it being EBML (a binary and efficient kind of XML), I’ve yet to see a feature that it can’t do. Even a complete 3D TV series with multiple perspectives, languages, subtitles, additional content, hull cover... streamed over the net in one file? No problem.
Also, it’s already the format of choice for HD video and multichannel audio format rips on the net.
A competitor would be nice. Unfortunately, OGG can’t hold a candle to it. But if they manage to catch up, they will be very welcome.
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:Overly-large analysis of article (Score:5, Interesting)
I'll do some analysis for you:
Generalities/codec mapping
The complaint is that there's no up-front header declaring all the streams contained. This is actually absurd - in theory you need to scan the entire file in case someone's just concatenated a video file with an audio file. This was, also absurdly, one of the aims of the Ogg container spec: concatenation. It's awesome to ask implementations to do this.
Overhead
One of Ogg's aims was to try to be less than 1% of the total stream space. It does achieve that, but the 'lacing values' end up looking pretty stupid for anything with large packets. It's like the article says: you end up with long strings of '255' summing up to 32-64KB packets, and hey just for extra complexity's sake, you'll have to split them across multiple not-quite-64KB pages. And then figure out where in that mess you're supposed to stick a timestamp: and here's a hint, you first page in that sequence has timestamp 0xffffffff which is nice if you randomly seeked to that place to find a position. God, what a mess that is to implement.
Then there's decode CPU overhead: the above basically means you end up copying the bitstream, which is a significant few percent overhead when you're talking about video.
Latency
You didn't understand his point. The latency is inherent in Ogg due to the large pages (not packets) required to reduce its size overhead, and in the position of the CRC (at the front of the page rather than the end). Reducing the page size makes the page headers start taking significant percentages of size if it's a low bit rate stream, e.g internet audio.
Random Access
Try pre-caching a 2GB video file. Or try pre-caching a 2GB video stream coming off the internet where the other end of the pipe is the other side of the world. Random access in these two realistic cases (if you'll admit that) requires a look up table, and it's precisely why many containers DO.
Complexity
The lacing values crossing pages, packets crossing pages, position of CRC, position of timestamp between packets/pages especially when cross-page, timestamps between logical streams (elementary streams), and other oddities/idiocies all ADD UP to make it a bloody mess to deal with. You end up just making copies of packets out of the stream, which is inefficient. In fact, that's exactly what the official Xiph codecs do: they make ugly copies. On real world MP3 players (and I've worked on some) that accounts for about 10% of your battery play time right there. I kid you not.
What this guy is expressing is what everyone who's worked on the Ogg container format itself has found out: it's just BAD at EVERYTHING. It needs replacing with something that doesn't suck, and there are free/open alternatives around. Maybe Vorbis 2 should switch container.
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
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.
NUT open container format (Score:3, Interesting)
NUT is another alternative, which is open, simple, and well designed. Along with Matroska, it is also capable of containing Ogg Theora and Vorbis streams, so there is really is no good reason to use the Ogg container anymore. The author of the article is correct--the Ogg container is an awful format.
The main complaints about Matroska are two-fold. One, the EMBL encoding is overly complicated. It requires a considerable amount of code to parse, and also imposes an unnecessary degree of overhead. The second is a much more serious problem: a Matroska file can only contain one timebase. Thus, in order to mux streams with different timebases, approximation is required. To accurately represent the converted timebases, it is necessary to use a much finer granularity, and then you also lose the exact timestamps.
The NUT specification and code is available from svn://svn.mplayerhq.hu/nut, and the (de)muxers are included in MPlayer/FFmpeg, VLC, and probably elsewhere.
Re: (Score:2)
Sure you could... but would those 10 meet the needs of developers, content creators, and everyone else to whom the container does matter.
Most container formats are limiting on the users of the format... and they must be to ensure that someone can develop for them, if there weren't rules, then it wouldn't be a specification. The best format is the one that imposes the right limitations while remaining very flexible for future technologies and uses.
While there are a multitude of container formats, few have m
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.
Re: (Score:3, Interesting)
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 allow you to start/stop downloading from different points in time and QuickTime is one of those formats that uses this feature.
He is trying too hard make an issue out of it. Read this:
In a large file (sizes upwards of 10 GB are common), 50 seeks might be required to find the correct position.
A typical hard drive has an average seek time of roughly 10 ms, giving a total time for the seek operation of around 500 ms, an annoyingly long time.
Now being a binary search, each seek halves the size of the search domain. The minimum size a harddrive can read is 512 bytes, so there will be no further seeks after we find a search domain less than that.
So 50 seeks is only needed with a filesize of 512 * 2^50 = 576460 terabytes.
For a 10 GB file you would need no more than half that many seeks (25). Take into account that most filesystems do not distribute the file at random over the whole harddrive
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.
Re:Technical Objections by Armchair Engineer? (Score:5, Interesting)
Your objective is to Armchair engineers? Ok, well I'm not an armchair engineer. I've written my own Ogg/Vorbis decoder from scratch in the past (here [mooo.com]). I've worked on codecs for about 10 years. I'm a fan of Vorbis and Theora, but Ogg needs to die a horrible death.
Ogg was by far the most bug-inducing part of the code. It's just AWFUL. It's ill-designed. It's incredibly complicated. It's inherently inefficient (copy sometimes required).
In short, it's the worst container format I've used in any serious application, and I've used pretty much all the common ones.
The irony of what you're saying, is that actually Ogg is what you'd end up with if an armchair engineer designed an audio codec container from scratch.
Re: (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