Ogg Format Accusations Refuted 248
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.
Re:Well written, and informative, but... (Score:5, Interesting)
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).
Re:Well written, and informative, but... (Score:5, Interesting)
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.
Re:tl;dr (Score:5, Interesting)
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:
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.
Re:tl;dr (Score:2, Interesting)
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 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.
Re:tl;dr (Score:4, Interesting)
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.
Re:Well written, and informative, but... (Score:3, Interesting)
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.
Re:Well written, and informative, but... (Score:4, Interesting)
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.
Re:The goal (Score:4, Interesting)
Re:tl;dr (Score:2, Interesting)
>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 the codec.
Only in the sense that you can find frame boundaries, not in the sense that you can do anything useful with them whatsoever. And indeed, the only thing you can do is drop and ignore pages for streams with codecs you don't recognize.
>and the data is possibly useless without the codec anyway, but that's true of every container.
Dead wrong. As a trivial example, remuxing.
And didn't you just say that you can parse streams without knowing about the codec?
>In practice, the granule position mapping does in fact exist in the stream metadata within the Skeleton header
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.
>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.
I'm not really sure what he's talking about here, but ogg certainly doesn't allow you to do like other containers do and store the unmangled timestamp.
Re:Well written, and informative, but... (Score:3, Interesting)
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.
Re:tl;dr (Score:3, Interesting)
It looks like it's depending on the information from each codec though. What happens if you don't have one of the codecs installed?
Re:Ogg format considered not as good as MPEG (Score:5, Interesting)
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".
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.
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.
Re:It still doesn't address many real world proble (Score:2, Interesting)
* 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.
Re:The goal (Score:3, Interesting)
Re:Ogg format considered not as good as MPEG (Score:2, Interesting)
> I'm guessing that he didn't use the same names in his design partly because that would be inviting a patent infringement lawsuit. It would be trivial to convince a judge (let alone a jury) to bring down the legal hammer because the two specs use the same terminology.
It wouldn't happen, you can't patent terminology. You might be able to copyright names, if they are specific enough.
MPEG is commonly thought of as "patent encumbered" but the patents only refer to some specific components. These components are not necessary for implementing a codec but if you do use these valuable methods then you get better results. Think of it like the patents that apply to glyph hinting for TrueType fonts: We still have lib FreeType and use TTF in Linux.