Ogg, Vorbis, and Theora have complete specs. They have been correctly clean room implemented from the specs by other parties. The specs are not perfect, but, as you say— patches accepted. ;) Unfortunately, ffmpeg doesn't care about the specs (see, for example, the link I provided about non-conformance for Theora). So my thinking is if you don't care to trouble yourself enough to follow the specs then at least use the darn reference code.<p>Unfortunately it's a little hard for me to follow MRU's complaints there. For example, I do not understand:<blockquote>The Ogg mapping for Speex states only that “the granulepos is the number of the last sample encoded in that packet.” There is not even an explanation of which packet this refers to.</blockquote><p>Because the speex specification is abundantly clear to me:<blockquote>The third and subsequent packets each contain one or more (number found in header) Speex frames. These are identified with packetno starting from 2 and the granulepos is the number of the last sample encoded in that packet.</blockquote><p>The complaint that oggdemuxing requires codec specific logic for interpreting timestamps is valid in so far as it really is an additional piece of complexity that has to be dealt with although codec specific logic isn't unheard of in other containers.<p>It was the result of a design the favored that having another 50 or so lines of code rather than taking another couple bytes per page for a distinct presentation timestamp and coding order marker, or mandating a single scheme which would have likely been done wrong. (In particular— the scheme used for Theora *can't* be used for Dirac because Dirac frames have a different coding and presentation ordering. Had a single granpos to timestamp scheme been fixed in stone, dirac in ogg would never have worked or would have required another layer of shim-framing).<p>It's perfectly valid to conclude that you would have made a different set of engineering trade-offs: The Ogg container was designed to be streamable, syncable at any point, — many of the comparisons made to mkv center around the consequences of building a streaming container; and the same people then complain elsewhere that mkv isn't a streaming container! <p>Ogg's initial target was compressed audio, and the ratio of bytes to coding units are very small for audio so minimizing overhead is very important.<p>Basically different people have different requirements. Under different requirements different engineering trade-offs must be made. <p>I don't consider this to be the stuff of holy-wars, and I don't think it's a good use of my time writing long rebuttals to people who simple are thinking about different requirements, or people who've worked themselves up over a silly misunderstanding. (I.e. like folks complaining that Ogg has high overhead when they're only placing one packet per page which can, in the pessimal case increase overhead by 177x)<p>There are some cases (not in Ogg, but in Vorbis and Theora) where it would have been nice to do something different but entire area surrounding the obviously better way appeared to simply have too many patent problems at the time the formats were finalized. I understand that FFmpeg's developers don't give a crap about what laws they or their users may or may not be violating, so the goals are simply different. Please appreciate that other people have different goals and those goals impose different constraints. <p>Unfortunately we have these great big multimedia frameworks which make innumerable assumptions about how files and formats work. When the assumptions are consistent with reality the code is tight and clean (there are whole video formats ffmpeg supports with something like 100 lines of code), but when the assumptions are not met it doesn't go well. The gstreamer community deals with this by fixing their assumptions, but for some reason it seems that folks from the ffmpeg camp resort to emotional rants about "horrible design". This is nothing unique to Ogg or Xiph or whatever, it even crops up from time to time with the mpeg codecs (although less often, I'd guess because thats most of what ffmpeg does). For example, Theora and H.264 both allow you to specify that the displayed area is an offsetable cropping rectangle out of the coded video. This can be used to perform lossless cropping and it also allows a transcoded cropped video to be subject to less loss by keeping the DCT block edges aligned. FFmpeg ignores the offset, violating the theora spec and breaking files found in the wild. I filed a bug and got "<i><a href="https://roundup.ffmpeg.org/roundup/ffmpeg/issue1041">the real bug is that the theora devels are copy and pasting every idiocy from the h.264 spec</a></i>" in response (which was not only rude, but didn't really make any sense). I did start to make on a patch myself but when I got up to about two hundred lines changed I gave up— yet offset support in other applications is usually just a three or four line patch. <p>I can certainly appreciate the "send a patch", but it's not a realistic request when I can more easily advise people to use different tools that don't have the problems, then spend my time improving those tools. It allows me to avoid extensive dealing with the FFmpeg development community which I've found to be rather hostile in most of interactions I've had, etc.<p>I don't think FFmpeg is poorly written software or anything like that. But historically Ogg support has not appeared to be much of a priority there, there are known existing unfixed problems. I don't know why I'd expect it to be— the entire purpose for the existence of Xiph is trying <a href="http://xiph.org/about/">to reduce and eliminate multimedia format royalties</s>, so why would I expect FFmpeg folks to care? Some FFmpeg developers spend non-trivial time spreading FUD about efforts to create formats which don't require royalties (Just look in this thread). There just simply is no rational reason for me to recommend that anyone use FFmpeg for anything to do with Ogg, and I have no idea why that would surprise or offend you.