Forgot your password?
typodupeerror
Media Software News

Ogg Format Accusations Refuted 248

Posted by kdawson
from the horse's-mouth dept.
SergeyKurdakov sends in a followup to our discussion a couple of months ago on purported shortcomings to the Ogg format. The inventor of the format, Monty "xiphmont" Montgomery of the Xiph Foundation, now refutes those objections in detail, with the introduction: "Earnest falsehoods left unchallenged risk being accepted as fact." The refutation has another advantage besides authoritativeness: it's far better written than the attack.
This discussion has been archived. No new comments can be posted.

Ogg Format Accusations Refuted

Comments Filter:
  • Obligatory (Score:5, Funny)

    by Anonymous Coward on Tuesday April 27, 2010 @05:23PM (#32004906)
    • by Anonymous Coward on Tuesday April 27, 2010 @05:46PM (#32005140)

      "Whenever you want information on the 'net, don't ask a question; just post a wrong answer."

      -- Cancer Omega

    • Re: (Score:2, Funny)

      by noidentity (188756)
      That is so fitting, especially because this rebuttal quotes the original with numbered lines! I can't stop laughing.
  • by Dragoniz3r (992309) on Tuesday April 27, 2010 @05:42PM (#32005096)
    ... the last time we discussed this, didn't the consensus eventually become that ogg isn't a fun container to work with, despite the fact that the guy who wrote the rant about it was a moron for wanting to trim headers that contribute fractions of percents to the overall size of files? I know I personally have worked with ogg, and it was a pain in the ass, mostly because (as the author of the format admits) the documentation blows.
    • by imsabbel (611519) on Tuesday April 27, 2010 @05:47PM (#32005144)

      Yeah.
      Also, for some reason there seems to exist no player in the world that can skip or jump in a video inside an OGM container without severe slowdowns and pauses even on an Core i7. Something that does simply not happen for avi, mp4, mkv or even mov (which is more or less mp4).

      • by BikeHelmet (1437881) on Tuesday April 27, 2010 @05:57PM (#32005258) Journal

        I've noticed the same thing. MP4, MKV, AVI, etc. are instant, but ogv (ogm according to GSpot) has multi-second delays when seeking to specific parts of the video.

        I must be doing something wrong... and yet it's the same for every media player I try.

        • by EMN13 (11493) on Tuesday April 27, 2010 @06:16PM (#32005434) Homepage

          As the article notes, .ogm isn't actually a normal ogg container, so the author isn't disputing issues with ogm (he calls it an ugly windows specific hack). And in any case, if you use a codec set to use few keyframes, you'll get poor seek performance in *any* container format - it's quite likely the issues you saw had everything to do with the encoding choices made and little with the (deprecated) ogm container.

          • by evilviper (135110) on Tuesday April 27, 2010 @06:56PM (#32005766) Journal

            And in any case, if you use a codec set to use few keyframes, you'll get poor seek performance in *any* container format - it's quite likely the issues you saw had everything to do with the encoding choices made and little with the (deprecated) ogm container.

            Not at all. Every other format listed as having good seek performance has an INDEX. Ogg/Ogm does not. Lacking an index generally results in broken frames when seeking as well.

            The are a couple efforts to get Ogg files indexed, but Xiph.org remains utterly indifferent, so you can expect it to remain an unsupported bastard step child like OGM, which is also only unofficial because Xiph can't be bothered with other people's needs.

            • I don't have problem seeking DVD dumps and as far as I know, MPEG-TS does not have indexes -- it is a pure stream. In fact, you can seek in an MPEG-TS stream even if it is partially corrupted or incomplete.
              • by NoMaster (142776) on Tuesday April 27, 2010 @08:35PM (#32006920) Homepage Journal

                That's because MPEG Transport Streams have an easily-accessible Presentation Time Stamp (PTS) in each GOP header, and it's reasonably easy to calculate the increment between PTSs (which will vary with framerate). The simplistic explanation is that the GOP header has the bit rate* & framerate; you can calculate the PTS increment either from the framerate or examining adjacent blocks, you then check the current PTS, calculate the desired PTS from that, and can then jump to the appropriate part of the file to find the PTS you're after.

                (That's assuming you're working with a TS file, where the player can examine the first & last block to determine file length. With streaming, you're restricted to working with what's in the buffer (& hopefully your app knows how long the buffer is, since it allocated it!))

                Ogg, AFAIK, doesn't have that info in the block header - IIRC it relies on the bitstream having presentation timing stored in it (i.e. none, in the case of most audio formats), which means you have to decode the block to find it. It was done that way to allow for variable framerates to be stored without having to build a huge index. MKV is a bit better in this respect, but it's a remarkably fragile container.

                * It falls down a bit sometimes, particularly where the bitrate in the block header is set to max (15Mbps), or where you're using VBR. With the latter the calculation will usually get you in the ballpark; with both cases, some splitters/decoders calculate the bitrate themselves while playing, store it, and use that for seeking.

                • Re: (Score:3, Informative)

                  by Wumpus (9548)

                  The PTS isn't stored in the GOP header. The GOP header is defined in part 2 of the spec, the PTS is in part 1. So the PTS and the DTS are in the PES header. MPEG frames are typically sent out of order. You'll need to do a lot of decoding to figure out the frame rate from the PTS. The bitrate is just as tricky to determine if you're just looking at one layer. A transport multiplexer needs to know a lot about the video it's multiplexing to be able to maintain the proper bitrate and order the frames correctly,

              • by Wumpus (9548) <IAmWumpus@COLAgmail.com minus caffeine> on Wednesday April 28, 2010 @12:00AM (#32008912)

                A DVD is MPEG-PS, not MPEG-TS. Your cable system and satellite feed are TS. Both are built on top of the PES layer.

                MPEG-2 is the reason I have no hair left on my head.

            • Re: (Score:3, Informative)

              by Jesus_666 (702802)
              Except that TFA mentions they're likely to put an index in the next revision of Ogg.
            • RTFA. (Score:5, Informative)

              by SanityInAnarchy (655584) <ninja@slaphack.com> on Tuesday April 27, 2010 @10:44PM (#32008230) Journal

              From TFA:

              An index is only marginally useful in Ogg for the complexity added; it adds no new functionality and seldom improves performance noticeably. Why add extra complexity if it gets you nothing?

              You can do seeking without an index:

              A binary search is discussed in the spec for ease of comprehension; implementation documents suggest an interpolated bisection search. So far, this is the same as Matroska and NUT.

              The only difference being, Matroska implementers tend to be lazy about implementing the indexless seeking properly, and people tend to use indexes, thus propagating this myth even more.

              The Vorbis source distribution includes an example program called 'seeking_example' that does a stress-test of 5000 seeks of different kinds within an Ogg file. Testing here with SVN r17178, 5000 seeks within a 10GB Ogg file constructed by concatenating 22 short Ogg videos of varying bitrates together results in 17459 actual seek system calls. This yields a result of just under 3.5 real seeks per Ogg seek request when doing exact positioning within an Ogg file. Most actual seeking within an Ogg file would be more appropriately implemented by scrubbing with a single physical seek.

              And there you go. I don't know WTF is wrong with your players, but really, how can a total of four seeks bring your system to a crawl?

            • Re: (Score:3, Informative)

              by Daengbo (523424)

              I guess you didn't RTFA (Don't feel bad -- I only got 80% through before throwing in the towel). OGM's status is thoroughly explained, and the author talks about adding indexes in the next version of OGG, due to concerns about HTTP over satellite.

          • Re: (Score:3, Interesting)

            by BikeHelmet (1437881)

            And in any case, if you use a codec set to use few keyframes, you'll get poor seek performance in *any* container format - it's quite likely the issues you saw had everything to do with the encoding choices made and little with the (deprecated) ogm container.

            That's quite possible. I'm just having trouble finding settings that let it be seekable, without torpedoing the quality.

            Tons of keyframes does work, but the bitrate required goes up quite a bit.

        • by Hatta (162192) on Tuesday April 27, 2010 @06:52PM (#32005746) Journal

          Have you tried it with MPlayer? I just tried it with an OGV [archive.org] from archive.org. Seeking was instantaneous.

          • Re: (Score:3, Informative)

            by BikeHelmet (1437881)

            Yes, I have. I can only conclude that I'm encoding it wrong.

            But I seem capable of making streamable/seekable vids in other formats, so why is it so difficult with ffmpeg2theora?

            • Re: (Score:3, Informative)

              by Dan Ost (415913)

              A previous responder to your earlier post explained that ffmpeg puts a bogus value in the OGG header which causes the entire OGG vid to be parsed.

              If that's true, then you're using a broken tool to create your OGG vids. File a bug report or switch tools.

      • Re: (Score:3, Interesting)

        by poetmatt (793785)

        uh, OGM is not ogg. So of course you cant' help but not have problems with it. It's a horrible attempt at getting WMV to work in ogg, basically. Try OGG instead of OGM and what do you know! skipping and jumping works wonderfully!

        Helps to read the article because then you'd actually know that.

      • by Twinbee (767046)

        Is this a problem with Ogg, or the media players implementations? Could this even theoretically be fixed with Ogg in its current state?

        Afaik, usually, codecs have something called 'key frames' where the lower the step for each key frame, the quicker it is for the user to seek to any particular part of the video. The extreme case would be to have each frame as a key frame. This should allow instant random access of the video, but the resulting filesize will be bigger.

        Doesn't Ogg have/support anything like th

        • The extreme case would be to have each frame as a key frame. This should allow instant random access of the video, but the resulting filesize will be bigger.

          I know of a few AVI codecs like that: motion JPEG, the motion-JPEG-like DV, and Huffyuv (which could be considered the PNG of video).

    • by Slotty (562298)

      This was well written?

      The authors response in no way enticed the audience to keep reading.

      Informative yes... Well written I don't believe so. But his admission to poor documentation is a nice sign of humility you rarely see in today's world

  • The goal (Score:5, Insightful)

    by DaMattster (977781) on Tuesday April 27, 2010 @06:06PM (#32005344)
    Funny, I thought the goal was to get away from a patent encumbered format. Does Ogg work? Is it reasonably close to MP3/4? I believe the answer is yes to both. Now is Ogg as efficient as MP3/4, I cannot really comment because I am not that technically versed. If a standard HTML5 Video is adopted, it should and must be patent unencumbered. Rather than this nitpciking, I would love to see that same energy poured into improving Ogg. Like any design, Ogg can be improved upon to reach the same robustness of MP3/4.
    • Re:The goal (Score:4, Interesting)

      by kiwieater (1799016) on Tuesday April 27, 2010 @06:58PM (#32005796)
      I've always found Ogg/Vorbis to be superior to MP3. Using semi-good gear(electrostatic headphones, for the geeky folk), I find Ogg at q6(average of ~192kbps) to be nearer to CD quality than an MP3 at any bitrate - it's transparent in 95%+ of tracks.. Some music isn't transparent on either format regardless of bitrate, but Ogg has always tended to give better quality for a given filesize. All in my experience...
      • Re:The goal (Score:5, Insightful)

        by jasonwc (939262) on Tuesday April 27, 2010 @07:35PM (#32006186)

        The problem with this argument is that it somewhat misses the point. MP3 is "good enough" for the vast majority of users at LAME V0/V2. I would venture a guess that 95-99% of persons couldn't ABX at V0 in perfect conditions (expensive amp, DAC, and high-end headphones), yet if we're talking about the use of a DAP and earbuds, it is quite clear qualtiy isn't relevant.

        MP3's primary advantage is its effective standardization and universal support in all hardware and software. This single advantage far outweighs any benefit Ogg Vorbis can provide. An MP3 can be played on any DAP, on any operating system (with the right codecs), and all music software. It's therefore the preferred lossy sharing format. On the large music trackers, Vorbis makes up fewer than 1% of lossy downloads by file size and # of downloads. MP3 is the clear preference.

        The fact is that, while Ogg Vorbis, may be better than MP3 quality-wise at V0 or 320 CBR, this is not the main point of lossy audio. If your primary concern is quality and archival, you shouldn't use any lossy format. You should use FLAC - it is open source and has superior error detection features (MD5/CRC for each frame, use with Accuraterip to verify any disk).

        I use FLAC on my desktop and only download EAC rips with 100% logs, or try to, at least. This ensures that my downloads are "perfect rips", and the encoding process has not reduced quality at all. With a single click, I can verify my FLACs against the Accuraterip database to ensure they are perfect.

        No lossy format provides this benefit. If I want to put the music on my iPod, I can convert it quickly with my Core i7 (45 seconds an album). I can convert my entire collectoin in several hours.

        So, why use OggVorbis over FLAC?

        • Re: (Score:2, Insightful)

          by AtlantaSteve (965777)

          So, why use OggVorbis over FLAC?

          Because:

          • You may not need absolute-100%-CD-quality, but you're still more demanding than the majority of users
          • You have a decent (i.e. non-Apple) media player that supports a variety of formats, and Ogg happens to be one of them

          • You don't see the point of wasting space with a FLAC that's half the size of a ripped WAV, when you could just use an Ogg file that's less than ten-percent the size of a ripped WAV

          [shrug]... That's my reasoning for using Ogg, anyway.

      • by Yaur (1069446)
        Vorbis is better than MP3 and Ogg was more or less designed to contain Vorbis so it does it isn't surprising that it works well together where it fails is trying to use it as general purpose container format.
        • by caseih (160668)

          Can't blame you for not reading the article, since it was dry. But if you would read the article you'd know that you're wrong. ogg was not designed specifically for ogg vorbis. It was designed as a generic container for all sorts of streams, right from the beginning. Before you post next time, please consider whether what you are saying is actual fact or just something you made up based on what you thought you knew.

          • Re: (Score:3, Interesting)

            by Yaur (1069446)
            My opinion is based on implementing software around OGG and I stand by it. That the original developer says something different 10 years after the fact is interesting but not definitive.
          • by caseih (160668)

            Oops. That should have read "ogg was not designed specifically for vorbis."

    • by Blakey Rat (99501)

      I didn't realize there was a "the" goal. My goal certainly doesn't have anything to do with patents. (It does care about expense, but that's not a 1:1 relationship.)

    • by diamondsw (685967)

      Ogg video (Theora) is most certainly nowhere near H.264 (MP4). Every independent (non-Xiph-run) test has shown that. Xiph's "proof" was comparing against H.263, which is an ancient codec.

      • by arose (644256)
        You are referring to a specific test, comparison was both against H.263 (not ancient, just off the bleeding edge, but that's beside the point) and H.264 as they are used on youtube. The point wasn't to show that Theora can achieve better compression then H.264 (monty quite clearly admits the opposite), but to refute a specific claim by a Google representative (this is clearly spelled out on the test page). Said representative hasn't bothered to defend his statements. Now please define "nowhere near" and we
  • by kegon (766647) on Tuesday April 27, 2010 @06:34PM (#32005600)

    From the article:

    When Xiph started out in the early ninties, MPEG was hardly dominant.

    When MPEG-1 started it closely followed H.261 [wikipedia.org]. H.261 was very well written. Back in 1994 when Xiph started, MPEG-1 had already been going 6 years [wikipedia.org].

    Ogg is full of strange fields and difficult to read structures. The author of the criticism is right to question it, especially when Ogg used similar fields but changed the names. There was never any need to change terminologies. H.261 and MPEG-1 were well written standards but not freely available and included patented technologies. The "not freely available" means that you have to buy it, not that it's secret.

    If Xiph wanted to produce a free standard for video coding they could easily have adopted the same terminologies and similar structures, defining their own versions of them and recommending unpatented technologies. Instead they chose their weird terminology and rushed to come out with something different without spending the time to work out how difficult it would be for users to implement and what quality it would give. H.261 and MPEG were backed up by masses of research by companies and universities of which much was freely available in journals and conference proceedings.

    The idea that "MPEG was hardly dominant" is the thought of someone who either didn't do his homework at the time or a revisionist. VCD (created 1993) was massively popular in the second half of the nineties, or doesn't that count ?

    From the summary:

    it's far better written than the attack.

    I wish it had been. If you want to refute a rant, pick some illustrative points and clearly answer them. Don't pick apart the text, all of it, sentence by sentence. Fancy colouring and highlighting don't make it better written.

    • by Haeleth (414428) on Tuesday April 27, 2010 @07:38PM (#32006224) Journal

      VCD (created 1993) was massively popular in the second half of the nineties

      Really? I don't think I ever saw a single VCD on a store shelf. I recall they existed, and I think I even watched one once, but basically they were a brief fad that completely failed to make a measurable dent in the VHS market and rapidly disappeared without a trace. That's not what I'd call "massively popular".

      If you want to refute a rant, pick some illustrative points and clearly answer them.

      That is exactly the wrong thing to do. If you don't answer every point, then your opponents will simply pick out the points you omitted and claim that your failure to refute them proves that they are valid.

      Fancy colouring and highlighting don't make it better written.

      Who said they did? What makes it better-written is the higher quality of the prose. The supporting references and the real-world measurements help, too.

      • VCD is still popular in international markets. VCD just never made it here in the States.
      • VCD (created 1993) was massively popular in the second half of the nineties

        Really? I don't think I ever saw a single VCD on a store shelf.

        Your experiences don't really define the popularity of a format. It never took off in North America but they were very popular in Asia, with more than half of Chinese homes containing a VCD player at one point.

        • by Johnno74 (252399)

          Yeah, I've still got some VCDs at home which appeared to be legit licensed versions of hollywood movies that I brought in Singapore and Hong Kong in the mid 90s. They were sold everywhere. I doubt if they were bootlegs, I brought most of them in reputable looking music and video stores at the airport, not some shady stall in a market.

      • Re: (Score:3, Informative)

        by NoMaster (142776)

        Really? I don't think I ever saw a single VCD on a store shelf. I recall they existed, and I think I even watched one once, but basically they were a brief fad that completely failed to make a measurable dent in the VHS market and rapidly disappeared without a trace. That's not what I'd call "massively popular".

        It may not have been popular in the US (it certainly wasn't obvious here in Australia) - but just about every Chinese home in Australia I went to (in the course of my job) from the mid-90's onwards h

      • Re: (Score:3, Informative)

        by diamondsw (685967)

        Really? I don't think I ever saw a single VCD on a store shelf. I recall they existed, and I think I even watched one once, but basically they were a brief fad that completely failed to make a measurable dent in the VHS market and rapidly disappeared without a trace. That's not what I'd call "massively popular".

        Just because *you* never saw them doesn't mean they weren't successful. Head to Asia - they still sell them by the truckload aside DVD and Blu-Ray, and displaced VHS over 15 years ago. I bought a few dozen a couple months back because they were cheap and easy to copy to the computer. Then I remembered just how awful MPEG-1 looked.

    • Re: (Score:3, Informative)

      by Toonol (1057698)
      The idea that "MPEG was hardly dominant" is the thought of someone who either didn't do his homework at the time or a revisionist. VCD (created 1993) was massively popular in the second half of the nineties, or doesn't that count ?

      Doesn't count... in America. I've never seen a VCD for sale, except in obscure import shops. It was big in Asia.
      • by diamondsw (685967)

        Yes, and clearly the couple billion people in Asia "don't count" compared to your ethnocentrism.

  • by pslam (97660) on Tuesday April 27, 2010 @06:34PM (#32005606) Homepage Journal

    My rant with Ogg is not so much the minute details of the format itself but that it works badly in a few common real world cases:

    • Resizing metadata. It's stored at the beginning, so resizing the metadata requires moving the majority of the file around (or rewriting it).
    • Metadata growing across a page boundary (64KB). Not unlikely if you're storing anything substantial such as album art. I know, that's slightly abusing it, but it's convenient to go there and it's common practice. The trouble is this affects the page numbering, requiring every page in the stream to be renumbered, and then every page including its contents to have its CRC recalculated. Very expensive.
    • No index. Seriously, why can't we have an index? It doesn't have to be at the beginning of stream - the end is fine too. Which leads me to...
    • Random access video across a high latency link. Think that's uncommon? What about cell phones playing a web-hosted video, where 1000ms+ is the norm? Or even laptops with a 3G access dongle? An index (even a small one) mitigates the issue, even if placed at the end of stream.
    • Mandatory per-page CRC forces low-latency streaming to use single packet per page. Demux cannot continue before an entire page is received, which increases latency by the number of packets in a page (minus 1). Per-packet or even no CRC would be more appropriate.

    I know it's all been said before, but these are pretty common cases and Ogg isn't great when you have to deal with them. Everything else is nit-picking. I'm not a fan of the minute details of the format either, to be honest, but the above are real world examples of where it falls a little short. I should add that none of these issues make it unusable in any of those situations: just annoying.

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      * Mandatory per-page CRC forces low-latency streaming to use single packet per page. Demux cannot continue before an entire page is received, which increases latency by the number of packets in a page (minus 1). Per-packet or even no CRC would be more appropriate.

      I don't know anything about Ogg, but you're forced to single "bigger unit per codec packet" for very low latency with all most all containers, CRC or not. What forces you is either length coding (either coding of the whole bigger unit size or the i

  • by bit01 (644603)

    Just how much money is MPEG-LA making on their patent pool? How much are they spending on bad mouthing OGG to preserve/increase their income?

    Treat any criticism of proprietary product competitors with a very large grain of salt.

    Particularly against free competitors since it's legally safer as they often don't have the legal resources to fight half-truths and innuendo.

    Good to see Monty's refutation.

    ---

    Anonymous company communication is unethical and can and should be highly illegal. Company legal structures

    • Re: (Score:2, Insightful)

      by Blazewardog (1339197)
      People aren't arguing to use mp4 over ogg (at least most aren't). They are arguing to use Matroska instead. Matroska is also a patent free container that is more flexible, can hold any stream, and is apparently much nicer to work with.
    • by Jesus_666 (702802)
      Actually, the criticism came from someone who contributes to another open source container format. It was just one OSS developer trying to bad-mouth a competing project - and getting shot down.
    • Just how much money is MPEG-LA making on their patent pool? How much are they spending on bad mouthing OGG to preserve/increase their income? Treat any criticism of proprietary product competitors with a very large grain of salt. Particularly against free competitors since it's legally safer as they often don't have the legal resources to fight half-truths and innuendo.

      Good advice in general, but in this case, I think it verges on paranoia. The bulk of consumers not only don't care, they aren't even aware of the issue. Most software vendors don't particularly care either, as few of them are in the codec business, and MPEG-LA's licensing fees are not exorbitant. The calculation that likely licensees are probably making is that the proprietary solution is well-documented, well-tested, and easy to integrate (and already integrated in most cases), and Ogg is none of these thi

    • Re: (Score:3, Insightful)

      by diamondsw (685967)

      Well that was a load of paranoia. There are clearly technical problems with the format - but according to you any criticism must be funded by the evil MPEG-LA!

  • by iris-n (1276146) on Tuesday April 27, 2010 @07:18PM (#32006010)

    Mans Rullgard:

    "Ogg considered harmful"

    Monty Montgomery:

    ""Ogg considered harmful" considered harmful"

  • From a letter about the theory of general relativity to Hermann Weyl, from 1916-11-23. Here is my amateurish translation:

    “While the theory has many enemy [sic] for the time being, I take comfort in the following circumstance: the otherwise determined mean thinking strength of the supporters outmatches that of the opponents by a tremendous amount.”
    (“Wenn die Theorie einstweilen noch viel [sic] Gegner hat, so tröstet mich der folgende Umstand: die anderweitig ermitte mittlere Denkst

  • So can we expect to see a working example of bitrate peeling some time soon?

The economy depends about as much on economists as the weather does on weather forecasters. -- Jean-Paul Kauffmann

Working...