Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Where he's been ever since. Microsoft's evil layer, just under Steve Balmer's bedroom, chained to a chair, just waiting for this correction to be posted so that he could post the XKCD cartoon. Imagine the willpower it takes to sit for weeks refreshing slashdot just waiting for that first post. If only he could escape to use his powers for good.

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

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

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.

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.

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.

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,

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?

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.

While the fields in Ogm are based on Window's VfW, they can be created and parsed on any platform quite easily. I've NEVER used Ogm one Windows, I've ALWAYS used it under Unix systems. Ogmtools can be used to generate such files, and MPlayer (which works on damn near every platform, from Linux, Windows, and OSX to VMS and OS/2) will play them out of the box, with no additional dependencies.

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.

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!

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.

Certainly better written than Rullgard's hatchet-job. Maybe I'm just used to reading technical documentation (RFCs and the like), but I really dislike reading the flippant opinions of some hack with an axe to grind. Much prefer reading the technicalities of the topic and making up my own mind.

It's a different kind of flaw, though. Rullgard was arguing that Ogg is inherently technically flawed. Arguing that it's technically fine but unusable due to a lack of documentation is a different argument.

Yeah, but the fixes are different. If it's a technically sound format with bad documentation, the fix is to write better documentation. But if the format itself has significant technical shortcomings, just documenting it better isn't a fix.

Even if you're right (and we'll probably just have to agree to disagree on that) he still replied as if it was a literal statement, which is at best extremely irritating.

BTW, my dismissal of his opinion is mostly:1) because the blurb says it was well-written when I believe it clearly is not. I expected it at least to be entertaining.2) I really don't give a flying rat's ass about the OGG format.

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.

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

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.

Your points are good ones. However, you and other make reference to "low bitrate MP3s". Isn't that somewhat besides the point? If you're going to compare Ogg Vorbis q6 or q8 to MP3, you should compare to the best and most widely available codec and encoding options.

By far, the most popular MP3 encoder is LAME, and the preferred format is V0 or V2. V0 generally has the most downloads on the popular private bittorrent trackers, but V2 is the choice of "scene" release groups.

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.

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.

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

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.

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

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.

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

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.

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.

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.

* 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

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.

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

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

Many of the complaints levied against Ogg were not about its technical merits, but about its inadequate documentation -- a feature Matroska shares. Other complaints were about features of Ogg (such as mappings) which nearly every other container format has as well.... I've only gotten about a quarter of the way through, so far.

Nearly every other container format+codec has exactly two bits that are codec dependent: an identifier (e.g. 'XVID' or "V_MPEG4/ISO/AVC" or a number) and binary private data/codec-specific init data/whatever you want to call it. Some codecs in some containers additionally define one bitstream, if the codec has multiple possible (h.264).

Ogg is not like that at all. The only thing it stores in a codec-independant manner is framing. Every other piece of information you might expect a container to have is stored in a codec-dependant manner. Even metadata!

I have no fucking clue why the creator does not see this as the problem that it is for everyone that tries to work with ogg.

What possible use could you have for obtaining time stamps within a video stream that you cannot decode? As far as I'm concerned, a container format should provide enough information to determine two things:

A CODEC identifier (magic/FOURCC)

The physical length of each frame's data so that decoders that don't understand a particular CODEC can skip it.

Although there might be advantages of having other data encoded in a consistent fashion for people writing debug tools, when it comes to general software, as long as the CODEC software provides a standard set of accessor functions that return the data in a consistent way across all CODECs, it is by no means a requirement that they be stored in the same way, and in terms of the format's long-term flexibility, it is advantageous to allow the data to be stored in a codec-specific fashion.

A better question is: why should the demuxer care about whether or not you can decode a given codec?

There has been absolutely nothing new with regards to codec timestamps since MPEG-1 introduced the concept of out-of-order coding and B frames. ogg was developed nearly a decade after that. Thus, there is and was no reason whatsoever to make timestamps codec-dependant.

And you're ignoring the problem that with ogg you have to hunt down and read the spec of every single codec that you want to implement demuxing

And you're ignoring the problem that with ogg you have to hunt down and read the spec of every single codec that you want to implement demuxing support for, and that it is impossible to have, say, a generic lightweight file analyzer that tells you duration, codecs used, metadata, samplerate, framerate, etc.

From the article:

"This is commonly asserted by detractors, but a combination of false and missing the point.

Ogg transport is based entirely on the page structure primitive, described accurately above. There are no other structures in the container transport itself. Higher level structures are built out of pages, not built into them. All Ogg streams conform to this page structure and all Ogg streams are parseable and demuxable without knowing anything about the codec. "Drop the needle" anywhere in an Ogg stream and start demuxing; you get the codec data out without knowing anything about the codec. You possibly won't know what exactly to do with that data without the codec mapping and the data is possibly useless without the codec anyway, but that's true of every container.

To avoid being accused of sidestepping the issue, I posit that the actual [if unstated] objection is that the Ogg container does not fully specify the granule position in the transport specification. Beyond a few requirements, a codec mapping defines the granule position spec for that codec's streams, not the Ogg spec. In theory, this would mean that without codec knowledge or some other place to find the granule position definition, a decoder missing the codec for a given stream would not be able to determine the timestamp on the stream that it is not capable of decoding anyway. In practice, the granule position mapping does in fact exist in the stream metadata within the Skeleton header[7] (as it would be in Matroska or NUT). Additionally, the Ogg design allows implementations to ignore the pretty design theory and just do things the way other containers do by building granule position calculation into the mux implementation.

There's specific considered reasons for the granulepos design which take some space to explain accurately. Because Mr. Rullgard also wrote a lengthy diatribe against Ogg timestamping[8], I'll leave the explanation for there and link to it here when my response to the other article is live."

>Ogg transport is based entirely on the page structure primitive, described accurately above. There are no other structures in the container transport itself. Higher level structures are built out of pages, not built into them.

And my argument is that a container should provide more than just framing. Hell, many codecs provide framing themselves and don't need container framing.

>All Ogg streams conform to this page structure and all Ogg streams are parseable and demuxable without knowing anything about

Too bad that in practice, I've seen a skeleton header maybe once. And anything optional is guaranteed to be missing in many cases. Thus to demux a new codec you still have to find the codec spec, find the ogg mapping, write the granule demangler, write a parser for the codec headers, etc. instead of adding a single entry to a table like you would for sane containers.

I think this speaks to your own inexperience more than anything else. Here's an ogg video with a Skeleton stream:

As far as I'm concerned, a container format should provide enough information to determine two things:

Basically, what you just wrote is "there shouldn't be containers."

Is that really your position? I certainly can understand it. It has that quality to it that any hack can go ahead and start coding to handle it immediately, which is great. But checking with reality, we seem to have so many container formats because ID/LEN is just not enough for purposes.

No, that's not at all what I wrote. The fundamental purpose of a container is to consolidate multiple pieces of information into a single file. Without containers, you would need one file for your audio data and a separate one for your video data. You should not need to understand the video data to play the audio data; it is sufficient to know its length. And *that* is what I wrote.

ID and LENGTH is not a "container" by any definition that I have ever heard of or used in practice.

What you are describing is a common ordinary linked list.

None of the containers that I am aware of require you to understand the video data in order to play the audio data, so what the heck are you actually getting on about? That "containers" should be ordinary linked lists?

In reality, thats not fit for purpose. That media file contains at least two stream, and while each stream can be treatable as independent, they can also be treatable as semi-dependent. There exists information that is shared between streams. For example, metadata.

If I am not required to decode the video stream, then you can't put the shared metadata in the video stream. If I am not required to decode the audio stream, then you can't put the shared metadata in the audio stream. So what then?

And thus, the media container is born. Linked lists just don't cut it. These formats are more than linked lists for a real (and I gave only one of them) reason.

What possible use could you have for obtaining time stamps within a video stream that you cannot decode?

Right, so much for Ogg.

This kind of answer, which amounts to "You shouldn't want to do that", is an absolutely certain indicator of a product that doesn't solve the problem that poeople actually have and never will, because when the inadequacies of the solution are pointed out, users are told they should have a different problem.

Every time I have ever been told by anyone anything like that it has been a sure indication that they have simply failed to understand the domain I am working in.

I want to prepend my ignorance in this area, however one thing that occrs to me in your complaint is that isnt this really how the OSI model works? The higher level (container) has the info it needs to pass its payload along to the next level. http, being a payload in the data of IP, and so on. Now I cannot speak to if this makes sense in the contact of media storage, but parsing deep into the media itself would seem to be out of scope of a container, and then end up being a crutch that could break later fo

I wouldn't assume because the OSI model works that way means its the right model for a video container format.

And, given the plethora of systems out there that have had to add functionality to introspect higher layers while routing lower layers, I wouldn't even assume the OSI model is actually the right one for networking, either.

An interesting observation, but when you have significant amounts of common data that are useful to be exposed - timestamps, dimensions, aspect ratio, framerate, samplerate were mentioned - then these should be stored in a standardized format and location. No need to make 7 layers when two will do the job every bit as well.

Mapping is a term I coined for the process of formally documenting how a codec will be placed into a container. Every container involves details beyond 'plop raw compressed frames into the container and you're done.' Some details include specifying codec magic (eg, the "FOURCC" in AVI, the 'Magic' in Ogg), choosing an appropriate timebase (or how to convert to the container's timebase), how one indicates keyframes/sync points, how this data is submitted to the container, and so on. Mappings also allow a given codec to take targeted advantage of the features offered by a particular container. One example is mp3 in Matroska, where the mapping specifies that the mp3 header is to be treated as duplicated/compressed data. Mappings need only be specified once and they're done.

By definition, mapping must be done for any codec into any container, even if the mapping is relatively trivial. This is true of MP4/MOV, Matroska, Ogg, NUT, AVI, and every other container. Some containers, like Ogg and Matroska[5], explicitly describe and document mapping, as well as the codec mappings themselves. Other containers document mappings but have no explicit name for it. A few remainders like AVI neither institutionalize the process of mapping, nor reliably document how codec data is contained, leading to an 'anything goes' situation of widespread ambiguity and compatibility conflicts[6].

In short, every container has codec mappings whether they are explicit or implicit or even well-formed. The Ogg project has a name for the process. It is disingenuous to claim that Ogg is inferior to some other container that requires these same decisions, but has no name for the process, or worse, no process at all.

So I have to ask: Have you done significant work with both OGG and other formats?

``Ogg is not like that at all. The only thing it stores in a codec-independant manner is framing. Every other piece of information you might expect a container to have is stored in a codec-dependant manner. Even metadata!''

Ok, so you are saying that there are things that you can do which, with Ogg, require you to understand the codec, whereas other containers allow you to do these things without having to understand the codec. Correct?

Could you or someone else provide (or link to) some examples of things yo

The best way to get documentation out of a project is trash talk it until a developer gets into such a frothy rage he explains it in a manner "even an idiot could understand." Used to do this all the time in the early years of Linux, worked like a charm:-)

Summary: certain uses require certain tradeoffs. Ogg tries to balance many different uses, and mostly succeeds. The original rant often cherry-picked which container formats it would compare Ogg against in a given context. Even so, Ogg often ends up comparing favorably to that container under real world conditions. The other FOSS Swiss Army Knife of container formats, Matroska, often does things the same way or comes out with similar performance in the end.

It's a cogent flame of his critics, but it also exposes what are plainly design differences-- and his critic's non-nuanced eye. You have to appreciate someone that can split hairs so finely when taking a set of arguments apart. I like thinkers.

I think the original comment was implying that Monty's reply contained ad hominem attacks. It sort of did (pointing out that the person complaining had contributed to a competing design, thus at least implying a conflict of interest), but not in a fallacious way.

man...must say though...I had a good laugh when I saw the line: "...wholesale dismantling..."

I only wish there would be more Flash media players that supported it (I know there's a haxe-based Ogg Vorbis decoder [barelyfocused.net] out there though...wish it was developed on more and would do vi

You're wrong, but instead of pointing out why, I'll just note that my teeth and hairstyle are better than yours, and that my opinion is the opinion of a proven winner. Only disagreeable people would disagree with me!

Luckily, the number of non-geeks who care about media container formats, beyond the level of "will it play/won't it play", is approximately zero, so any failure to style your communications for the layman is largely unimportant...

``it's like the local computer geek spouting about the technical reasons his N64 is better then a SEGA - no one is going to give a shit and the other nerds have already made up their minds, so he won't do anything to sway them.''

You are likely correct, but I still think it is useful to provide good argumentation based on technical facts. After all, opinions can vary, but facts stay the same. Some of us like to make choices based on technical merits rather than opinions. I often base my arguments on technica

(Less snarky version: VP8 is a codec. Ogg (& MKV, & AVI, & etc) are container formats that hold data encoded with various codecs. The situation is muddied somewhat with MPEG, as the various versions encompass both a codec and a container. DivX too, but the DivX container is nothing more than a bastardised.AVI container containing video encoded with the DivX codec.)