Forgot your password?
typodupeerror
Media Bug

Technical Objections To the Ogg Container Format 370

Posted by timothy
from the do-these-objections-matter-on-modern-hardware? dept.
E1ven 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."
This discussion has been archived. No new comments can be posted.

Technical Objections To the Ogg Container Format

Comments Filter:
  • by godrik (1287354) on Wednesday March 03, 2010 @02:28PM (#31349144)

    I don't see any comment and the website is already down. gg /.

    • by heneon (570292) on Wednesday March 03, 2010 @02:32PM (#31349192)
      In related news, I know technical shortcomings in hosting an article on hardwarebug.org...
      • by sopssa (1498795) * <sopssa@email.com> on Wednesday March 03, 2010 @02:35PM (#31349222) Journal

        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).

        • by XanC (644172)

          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.

          • by Lunix Nutcase (1092239) on Wednesday March 03, 2010 @02:45PM (#31349338)

            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)

              by aflag (941367)
              However, do you disagree? Why? I hope it's not because of this world you talk about.
            • by drooling-dog (189103) on Wednesday March 03, 2010 @03:37PM (#31350044)

              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.

              • by hairyfeet (841228) <.bassbeast1968. .at. .gmail.com.> on Wednesday March 03, 2010 @05:31PM (#31351472) Journal

                I would say it is more because they work than any adverts. Take H264 as an example. Even on the lowest cost machines I build there is hardware acceleration out of the box for H26x, WMV 7-9, DivX, and MPEG 2 (and usually 4). This makes those formats much nicer to use, their playback much smoother, and the overall hardware more responsive because the CPU isn't bogged down with playback. In short it works.

                The average Joe really doesn't give a shit about "free as in freedom" all he gives a shit about is does it work and is it easy. That is why MP3 stomped Vorbis and FLAC, because it was easy (most of the files they downloaded/ripped were MP3 and every device supported it) and it worked (MP3 playback gave longer battery life over WMV, can't say about Vorbis as I've honestly never come across a Vorbis player) so they were happy little campers. As for website builders, if site A has H264 and gives me a great experience on my netbook/cell phone/etc and your site uses Theora and runs like shit? Well I'm not likely to return to your site now, am I?

                The problem with the OGG formats is the classic "chicken or the egg" problem. Nearly no support in hardware, doesn't work as well as established formats (thanks to hardware acceleration) and the average Joe really doesn't care whether a format has patents up the wazoo or not as long as it works for him, which considering like the other 90% he is probably using Windows or a cell phone/PMP with H264 acceleration it does. Sadly while I hoped that Theora might be the fabled "flash killer" I'm predicting it will be just like Vorbis, a niche format that almost nobody ever uses. Everywhere I go I see "H264 support" on 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.

                • Re: (Score:3, Interesting)

                  by horza (87255)

                  "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)

                    by moonbender (547943)

                    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.

                • by Risen888 (306092) on Wednesday March 03, 2010 @07:45PM (#31352926)

                  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.

            • by interval1066 (668936) on Wednesday March 03, 2010 @03:39PM (#31350082) Homepage Journal

              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.

            • by jedidiah (1196) on Wednesday March 03, 2010 @04:29PM (#31350682) Homepage

              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.

          • by maxume (22995) on Wednesday March 03, 2010 @02:46PM (#31349350)

            And then over here in actuality (rather than the conversation), there is Youtube. And Netflix. And Hulu. And so on.

            • by arose (644256)
              I think it's quite clear that he was talking in terms of standardization, not in what content providers would consider using.
              • Re: (Score:2, Insightful)

                by maxume (22995)

                In which case the standard will be impotent (because it will be completely divorced from practice).

                • by Draek (916851)

                  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)

                  by Korin43 (881732)
                  As opposed to a standard that you can't standardize on (because only Google can afford the licensing fees). They're pushing back when the fees start, but that doesn't change the fact that small businesses and individual people would have to be insane to start a website using H.264.
          • Re: (Score:3, Informative)

            by Locke2005 (849178)
            Unfortunately, it can enter the conversation. Standards should be free, open, and unencumbered to allow for rapid adoption. That doesn't mean they always are. For example, Microsoft, simply because of it's size, can drive a non-open standard into widespread adoption (this isn't always a bad thing.)
            • by sopssa (1498795) *

              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.

          • by egamma (572162) <egamma.gmail@com> on Wednesday March 03, 2010 @02:51PM (#31349414)

            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.

            • by vadim_t (324782) on Wednesday March 03, 2010 @03:24PM (#31349886) Homepage

              Says who? XanC?

              Add me to that list

              Any format (and its software requirements) can succeed as long as the users will put up with it.

              It can, yes. But there's a difference between what can be done, and what should be done.

              And of course, there's Adobe Flash.

              Actually, as of recently the Flash spec is available without restrictions, and there's gnash, a GNU implementation.

              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?

              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)

              Companies can make excellent closed-source products. Communities can make excellent open-source products.

              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.

              • by sopssa (1498795) * <sopssa@email.com> on Wednesday March 03, 2010 @03:33PM (#31349998) Journal

                And of course, there's Adobe Flash.

                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.

                • by Draek (916851)

                  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

                • by vadim_t (324782) on Wednesday March 03, 2010 @04:00PM (#31350326) Homepage

                  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.

                  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.

                  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.

                  People are short sighted. I think long term.

                  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 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 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 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 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.

                  I use Linux on servers for the same reason.

                  But fundamentalism and closed mindset in the end is just stupid.

                  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.

              • "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)

            by drtsystems (775462)

            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

            • by Khyber (864651)

              "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.

        • by Draek (916851)

          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

          • 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.

        • by Steve Max (1235710) on Wednesday March 03, 2010 @03:29PM (#31349958) Journal

          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)

            by metamatic (202216)

            AFAIK, MKV is also patent-free, and it's the standard container for torrents^Wprivate-encoded HD video.

            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.

    • by noidentity (188756) on Wednesday March 03, 2010 @02:34PM (#31349204)

      I don't see any comment and the website is already down. gg /.

      Yes, but what format is the website in? I'm thinking something involving ashes.

    • by Jurily (900488) <jurily&gmail,com> on Wednesday March 03, 2010 @02:34PM (#31349212)

      Wasn't us. We don't read the articles before posting.

    • by Nemyst (1383049) on Wednesday March 03, 2010 @02:35PM (#31349232) Homepage
      Must be a hardware bug.
  • by Ltap (1572175) on Wednesday March 03, 2010 @02:29PM (#31349150) Homepage
    No matter how bad it is, it's still better than AVI. I personally use Matroska, it has all of the ideological benefits (free, non-encumbered, open-source) over stuff like MP4.
    • Re: (Score:2, Funny)

      by Anonymous Coward

      You forgot the lack of general support. Definite win on the ideological front.

      • Re: (Score:3, Insightful)

        by sopssa (1498795) *

        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.

        • by Shimdaddy (898354)
          I'm not sure about the XBox360, but the excellent ps3 media server [google.com] will happily transcode matroska files for smooth playing on your ps3.
          • Re: (Score:3, Insightful)

            by sopssa (1498795) *

            Of course, I use that too. But that's exactly the point - it doesn't support it, so you have to transcode.

        • by c_g_hills (110430)
          Untrue. Matroska is now officially supported by the DivX Plus HD profile which is used by a variety of devices.
        • by Jah-Wren Ryel (80510) on Wednesday March 03, 2010 @03:33PM (#31350004)

          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.

        • by Khyber (864651)

          "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.

    • by rwa2 (4391) *

      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: (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

  • Just complaining (Score:4, Insightful)

    by Evets (629327) * on Wednesday March 03, 2010 @02:30PM (#31349174) Homepage Journal

    "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)

      by TheRaven64 (641858) on Wednesday March 03, 2010 @02:45PM (#31349342) Journal
      Wow, did you copy that criticism of TFA from the last section, where he says:

      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:

      • Being too different is bad. We live in a world where multimedia files come in many varieties, and a decent media player will need to handle the majority of them. Fortunately, most multimedia file formats share some basic traits, and they can easily be processed in the same general framework, the specifics being taken care of at the input stage. A format deviating too far from the standard model becomes problematic.
      • Ogg is bad. When every angle of examination reveals serious flaws, bad is the only fitting description.

      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)

      by sopssa (1498795) *

      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)

      by Aladrin (926209)

      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)

      by evilviper (135110)

      "I would have done it diffferently" does not mean that the format is bad.

      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...

      • by arose (644256)
        Since people keep bringing up Matroska as a well designed coded we could see what they say about Ogg [matroska.org]:

        It's less a matter of better/worse, and more a matter of different. This is a little complex but we will try ad explain.

        and

        Will Matroska be streamable? Yes, but low bitrate streaming like streaming Vorbis, will always be better in Ogg. This is because their design is for different purposes.

        Are we to believe that they have no clue about container formats?

        • Re: (Score:3, Interesting)

          by evilviper (135110)

          Are we to believe that they have no clue about container formats?

          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

  • by Anonymous Coward on Wednesday March 03, 2010 @02:48PM (#31349382)

    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)

      by sylvandb (308927)

      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).

      • by 0xABADC0DA (867955) on Wednesday March 03, 2010 @03:53PM (#31350244)

        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.

    • by Josef Meixner (1020161) on Wednesday March 03, 2010 @03:25PM (#31349894) Homepage

      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.

      • by Yokaze (70883) on Wednesday March 03, 2010 @03:49PM (#31350208)

        > 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.

      • 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

    • 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.

      Actually, it shows the opposite to me. You have the current version,

    • by logicnazi (169418)

      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

  • by theheadlessrabbit (1022587) on Wednesday March 03, 2010 @02:53PM (#31349448) Homepage Journal

    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?

    • by Dragoniz3r (992309) on Wednesday March 03, 2010 @03:11PM (#31349674)
      Because, in general, you don't only want a video stream. You want to be able to bundle multiple streams together (usually of different types, eg an audio stream and a video stream). Vorbis, for example, is audio. Theora would be video. Ogg (the container) exists to bundle them together into a single file, so you can have a movie and sound with it.
    • by Anonymous Coward on Wednesday March 03, 2010 @03:11PM (#31349678)

      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)

      by reacocard (1043858)

      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)

      by cheesybagel (670288)
      Code reusability. You can use an MPEG-4, MPEG-2, or MPEG video codec with the same MP3 audio codec. The integration parts of the code can be reused as well. Forward compatibility: you can easily make a library so programs can use the same API to decode a variety of codecs. This means a program can support file formats which did not exist when it was written.

      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

    • by MobyDisk (75490)

      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

      • 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

    • by ink (4325)

      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

    • by jhfry (829244)

      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

    • 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.

    • 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.

  • In the long run (Score:5, Interesting)

    by istartedi (132515) on Wednesday March 03, 2010 @03:44PM (#31350154) Journal

    "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.

  • by Hurricane78 (562437) <deleted@slashd o t .org> on Wednesday March 03, 2010 @04:36PM (#31350796)

    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.

  • by azmodean+1 (1328653) on Wednesday March 03, 2010 @04:57PM (#31351056)

    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.

    • by pslam (97660) on Wednesday March 03, 2010 @06:19PM (#31352096) Homepage Journal

      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.

  • by xiphmont (80732) on Wednesday March 03, 2010 @05:21PM (#31351360) Homepage

    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

  • by pslam (97660) on Wednesday March 03, 2010 @05:48PM (#31351708) Homepage Journal

    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.

  • by KonoWatakushi (910213) on Wednesday March 03, 2010 @05:56PM (#31351826)

    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.

Those who do not understand Unix are condemned to reinvent it, poorly. - Henry Spencer, University of Toronto Unix hack

Working...