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 Locke2005 (849178) on Wednesday March 03, 2010 @03:49PM (#31349392)
    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 Dragoniz3r (992309) on Wednesday March 03, 2010 @04: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 @04: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.

  • by cheesybagel (670288) on Wednesday March 03, 2010 @04:19PM (#31349800)
    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) and accesses the files in a more direct fashion, bypassing the standard OS APIs. It is also likely your programs use different OS media APIs. Windows has like two different APIs: VfW, DirectShow. There are also some apps that use the Quicktime API.

  • Re:Just complaining (Score:4, Informative)

    by Wildfire Darkstar (208356) on Wednesday March 03, 2010 @04:21PM (#31349834)

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

    When challenged, [Ogg campaigners] will occasionally assume an apologetic tone, explaining how Ogg was only ever designed for simple audio-only streams (ignoring it is as bad for these as for anything), and this is no doubt true. Why then, I ask again, do they continue to tout Ogg as the one-size-fits-all solution they already admitted it is not?

  • by r_benchley (658776) on Wednesday March 03, 2010 @04:27PM (#31349936)
    I use Handbrake http://handbrake.fr/ [handbrake.fr] for encoding. Handbrake will let you chose from MP4 or MKV for container, H.264 or Theora for video and MP3, AAC or Vorbis for audio.
  • by Steve Max (1235710) on Wednesday March 03, 2010 @04: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.

  • by Jah-Wren Ryel (80510) on Wednesday March 03, 2010 @04: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 Yokaze (70883) on Wednesday March 03, 2010 @04: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.

  • by 0xABADC0DA (867955) on Wednesday March 03, 2010 @04: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 Anonymous Coward on Wednesday March 03, 2010 @05:34PM (#31350770)

    The reason that the page header data is repeated is because Ogg is a streaming file format. You can write it out live in real time, and decoders can decode it as you write it... you can arbitrarily chop it in the middle and or truncated off the end and still get something demuxable. You don't have to seek back and rewrite headers when you're done writing, and you don't have to seek to the end to read footers when you're done reading. Other formats (e.g. MKV) don't handle truncation, incremental writing, and streaming as well (or without putting them into a mode that makes their behaviour and overhead more similar to Ogg.

    This means that some header data must be repeated frequently. The version number is 8 bits so that highly simplistic code can implement a version check with simple character level logic and without implementing a fancy format-specific bit unpacker. Yes, it costs a little efficiency, but if you really can't tolerate 7 BITS of additional overhead per greater than 500k bits (0.001%) then you have no business using _any_ multimedia transport format.

  • by Svartalf (2997) on Wednesday March 03, 2010 @10:37PM (#31353776) Homepage

    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.

  • by adolf (21054) <flodadolf@gmail.com> on Thursday March 04, 2010 @02:39AM (#31355118) Journal

    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 supporting all of the features of PNG. But to say that it supported PNG before IE, when IE supported PNG before Firefox could even have begun to exist, is a little anachronistic.

  • by metamatic (202216) on Thursday March 04, 2010 @03:44PM (#31361588) Homepage Journal

    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.

Reference the NULL within NULL, it is the gateway to all wizardry.

Working...