Slashdot Mirror
Ogg Format Accusations Refuted
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.
http://xkcd.com/386/
tilder.
Is there, you know, a summary or something so I don't have to wade through that long fricking rant in order to actually learn anything interesting about the Ogg format? Inadequate summaries aside - if this is the extent of the creator's ability to communicate about issues surrounding the format, no wonder it's suffering.
You mean the creator of a file format thinks that his file format is good? This certainly is newsworthy!
... 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.
he goes "and that's why the Ogg format is awesome...bitch!" and deliberately drops the microphone a-la Chris Rock. The ogg format critic...dat muddafugga just got served, yo.
The refutation has another advantage besides authoritativeness: it's far better written than the attack.
coughcoughADHOMINEM
If you're going to make commentary about an argument, try not to use a logical fallacy when doing so...
Please help metamoderate.
"Whenever you want information on the 'net, don't ask a question; just post a wrong answer."
-- Cancer Omega
He goes through every bloody line and shows how ill-formed just about everything his detractor had to say about Ogg.
Very thorough.
You mean all Political Parties Try to do this. Don't let your personal favor to an other political party make you think that you are not getting brainwashed too.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
1: ok.
2: what does that have to do with this topic?
3: I have been complaining about html5 for the better part of 2 years.
4: I've had to shelve a few xhtml2 projects I had started when I heard the spec was being cancelled. I have reason to complain.
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.
Earnest falsehoods left unchallenged risk being accepted as fact
And emphatic denials risk a stronger belief in the denied thing.
Ask me about repetitive DNA
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 :-)
I've got a lot of respect for a lot of OSS programmers, however they seem to fail to know how to respond on a non technical level. 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.
If you mod me down, I will become more powerful than you can imagine....
From the article:
When MPEG-1 started it closely followed H.261. H.261 was very well written. Back in 1994 when Xiph started, MPEG-1 had already been going 6 years.
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:
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.
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:
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.
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 require accountability.
dunno how it's offtopic....
anyways...here's what I learned (unlike Comedy Central)....Ogg isn't ".OGM" (a now-defunct bastard child/fork), it's got features that Matroska has and more, it's got error-detection...MP4 can't do live....etc.
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 out there though...wish it was developed on more and would do video as well)
Mans Rullgard:
"Ogg considered harmful"
Monty Montgomery:
""Ogg considered harmful" considered harmful"
entropy happens
Indexing and seeking over low-latency connections is discussed in this piece. He specifically cedes this point and I *think* transOgg may address it.
Would you like to clarify this? A packet is split into segments, and a page encapsulates one or more segments. You seem to be confusing packets and pages, as it is normally one or more pages per packet, not the other way around.
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.
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ärke der Anhänger übertrifft diejenige der Gegner um ein Gewaltiges!”)
(I dug this one out myself. The letters are available online. And: Yes, I added the “[sic]”. :)
Any sufficiently advanced intelligence is indistinguishable from stupidity.
I hadn't considered a packet being split into multiple segments, because that would make even less sense for low-latency streaming. The case I'm thinking of is:
However, there's still just 1 CRC per page. This means that the demux must wait until all 4 packets are entirely received (the entire page) before it is allowed to pass the contents on to the decoder layer.
If CRC were not mandatory, or you ignored it, then the demux could pass each packet along as it's received instead of waiting for the link to receive all of them.
On the sender's side, the CRC being before the data also means you need to buffer up the entire page before it can be transmitted. However, there's bigger problems here, such as the lacing values not being available until the size of each packet is known. There's no decent solution to that, other than moving the packet size fields to being placed between packets. That has its own problems and advantages.
None of this is an issue if you restrict to 1 packet per page, and I guess you could just ignore the CRC, but it is something about the design that doesn't help.
I just recently heard about the VP8 codec which Google plans to open up and allow its use royalty free. I have even heard that it might be opened up as early as next month. This should render the whole OGG vs. MPEG obsolete.
Where were you when that initial smear piece was posted on slashdot?
It is restricted to one packet per page, with packets being broken up among multiple pages if they're too large. A packet should be something like a single frame of video, or a single line of subtitle text, or whatever a codec is using as a discrete packet of information. Buffering should not be an issue.
* 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 individual packet sizes), or the encoding of the "bigger unit" timing information. At least ogg does appear to support moderately low latency for that single packet case.
Can you suggest another format which does zero (container) latency better while still being low overhead? I can think of some things which are about half the overhead compared to ogg in the single packet case, but they retain the high (several percent) overhead even when you don't care about very low overhead.
So can we expect to see a working example of bitrate peeling some time soon?
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
Sure. But when one party uses it 15% of the time and the other party uses it 99% of the time, there is a big difference.
"Marx would say that a sufficiently large quantitative difference is qualitative. One of his few useful insights". - Ashby
Wait, I think I'm wrong, you can have multiple packets per page. Still, pages are not supposed to contain large amounts of data unless it's a single large packet.
From TFA:
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?
Don't thank God, thank a doctor!
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?
Don't thank God, thank a doctor!
You can have an index:
http://blog.pearce.org.nz/2010/01/indexing-keyframes-in-ogg-videos-for.html
You're welcome.
Your skipping problems may have to do with how your source material was encoded.
After reading your post, I KVM-switched to my WinXP PC, found a .ogm file, started MPlayer, used right-arrow, up-arrow, left-arrow, and down-arrow, and got instant skipping, with subtitles properly synced.
Then, I KVM-switched to a Linux laptop, found a (different) .ogm file, started MPlayer, used right-arrow, up-arrow, left-arrow, and down-arrow, and got instant skipping, with subtitles properly synced.
*shrug*
"Works for me."
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).
What possible use could you have for obtaining time stamps within a video stream that you cannot decode?
I believe VirtualDub calls it Direct Stream Copy. The user can transcode an AVI file's video and not touch the audio except to keep it in sync, or vice versa.
The article specifically addresses random access across high latency. Search for "latency", or just read the article.
Geesh. I only implemented ogg for a little embedded device and even I know this.
Ogg pages store a "granulepos", which is a 64 bit composite number for representing the end time of the last frame completed by the end of the page. Ogg's only promises are "granulepos can be mapped to a time" and "granulepos monotonically increases". The codec is what does the time mapping for you. There are basically two schemes in use: Vorbis, flac, and speex just use a sample number. Theora uses a variable shift to split the granulepos into "frame number of the last keyframe" and "frames since the last keyframe".
To seek you ask the codec to codecs to map the time you want into a "granulepos" then you use a bisection search to find the page with the largest value which is smaller than the time you want. You begin decoding there. Even with no more intelligence than that and simply relying on the codecs to tell you the timing you'll never need to decode more than an excess of 64kbytes of compressed data to get your timing. If that isn't enough for you, you look inside the codec data to back calculate the time for every frame from the "granulepos" then only decode the right ones but to me that seems like a lot of extra work for a very small cpu savings. You can make this even simpler by simply not worrying about sample accurate seeking at all.
My guess is that the grandparent poster was simply trying to decode one of those broken Ogg files that FFMPEG writes. These files gave me quite some heartburn in my development: Because the ffmpeg developers hate ogg so much they made their software write ogg files that are maliciously constructed! They contain "0xFFFFFF...." for _ALL_ granuelpos values. This is a special value that says that no frame finishes on this page, so normally you look forwards or backwards a little further to find the time. But since an ffmpeg produced stream never has anything but -1 you end up seeking, then reading to the beginning or end of the file! I had to put in special case detection of the broken ffmpeg output in our product to avoid this problem.
As far as I agree with, you're offtopic.
People aren't arguing about Vorbis the CODEC, but about Ogg the container.
It talks about high latency. It doesn't solve it.
XKCD is plenty funny from time to time, and like every other comic out there, some strips are better than others. If you don't get the jokes, or you don't think they're funny, that's a reflection on your view-of/capacity-for humor, not XKCD. As for the drawing... it's minimal, because the point is rarely in the quality of the drawing. And it's only fair to point out that if everything you accept as funny must also be drawn to some arbitrary standard, you're going to miss a whole lot of funny things. I expect you don't tolerate South Park well, either, eh? Given the quality of the drawing, which is somewhere between hilariously abysmal and straight-up awful. It's still funny as heck from time to time.
XKCD is one of the few comics I visit regularly. But then again, my sense of humor wasn't shot off in the war.
I've fallen off your lawn, and I can't get up.
Xine works marvellously too.
VLC seeks instantaneously, but displays corrupted frame just after the seek.
Which are the players with multi-seconds pauses ?
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]