Ogg Format Accusations Refuted 248
Posted
by
kdawson
from the horse's-mouth dept.
from the horse's-mouth dept.
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.
Obligatory (Score:5, Funny)
http://xkcd.com/386/ [xkcd.com]
And don't forget (Score:5, Funny)
"Whenever you want information on the 'net, don't ask a question; just post a wrong answer."
-- Cancer Omega
Re: (Score:2, Funny)
Re: (Score:2)
Well written, and informative, but... (Score:5, Informative)
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:Well written, and informative, but... (Score:5, Informative)
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.
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.
Does MPEG-TS have indexes? (Score:2)
Re:Does MPEG-TS have indexes? (Score:5, Informative)
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.
Re: (Score:3, Informative)
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,
Re:Does MPEG-TS have indexes? (Score:4, Informative)
A DVD is MPEG-PS, not MPEG-TS. Your cable system and satellite feed are TS. Both are built on top of the PES layer.
MPEG-2 is the reason I have no hair left on my head.
Re: (Score:3, Informative)
RTFA. (Score:5, Informative)
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?
Re: (Score:3, Informative)
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.
Re: (Score:3, Informative)
No, Monty is simply lying about this point.
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.
Re: (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:Well written, and informative, but... (Score:4, Informative)
Have you tried it with MPlayer? I just tried it with an OGV [archive.org] from archive.org. Seeking was instantaneous.
Re: (Score:3, Informative)
Yes, I have. I can only conclude that I'm encoding it wrong.
But I seem capable of making streamable/seekable vids in other formats, so why is it so difficult with ffmpeg2theora?
Re: (Score:3, Informative)
A previous responder to your earlier post explained that ffmpeg puts a bogus value in the OGG header which causes the entire OGG vid to be parsed.
If that's true, then you're using a broken tool to create your OGG vids. File a bug report or switch tools.
Re: (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: (Score:2)
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.
Doesn't Ogg have/support anything like th
Motion JPEG (Score:2)
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).
Re: (Score:2)
This was well written?
The authors response in no way enticed the audience to keep reading.
Informative yes... Well written I don't believe so. But his admission to poor documentation is a nice sign of humility you rarely see in today's world
Re:Well written, and informative, but... (Score:5, Insightful)
Re: (Score:2)
Don't feed crap trolls. The crafty ones can get you sometimes but there was no excuse for this.
If it wasn't for your response the moderation system would have made sure I, and thousands of other readers, would never had read the AC's post at all. It has already disappeared off the radar.
But you had to go and open a dialogue. You even quoted the whole thing! No offence man, but WTF were you thinking?
I do agree that it would be nice to ban everybody named "Anonymous Coward" though. I wish we could to a poll
Re: (Score:2)
Oh I dunno, the quip about Xiph panzer divisions was clearly intended as humour. Unless of course he wasn't actually joking about that - do you know something the rest of us don't?
Re:Well written, and informative, but... (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
Where, exactly, is the boundary line between a file format and its documentation/specs?
Re: (Score:2)
A different argument with the same result - it's unusable.
Re: (Score:2)
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.
Re: (Score:2)
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.
Neither of which is really the author's fault. So there you have it.
The goal (Score:5, Insightful)
Re:The goal (Score:4, Interesting)
Re:The goal (Score:5, Insightful)
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.
So, why use OggVorbis over FLAC?
Re: (Score:2, Insightful)
So, why use OggVorbis over FLAC?
Because:
You have a decent (i.e. non-Apple) media player that supports a variety of formats, and Ogg happens to be one of them
[shrug]... That's my reasoning for using Ogg, anyway.
Re: (Score:3, Informative)
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.
Neither is low quality. V2 averages
Re: (Score:2)
Sorry for the spelling errors and such. I wrote my response quickly.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:3, Interesting)
Re: (Score:2)
Oops. That should have read "ogg was not designed specifically for vorbis."
Re: (Score:2)
I didn't realize there was a "the" goal. My goal certainly doesn't have anything to do with patents. (It does care about expense, but that's not a 1:1 relationship.)
Re: (Score:2)
Ogg video (Theora) is most certainly nowhere near H.264 (MP4). Every independent (non-Xiph-run) test has shown that. Xiph's "proof" was comparing against H.263, which is an ancient codec.
Re: (Score:2)
Re: (Score:3, Insightful)
And that's exactly what TFA was refuting. Why is Matroska better?
Ogg format considered not as good as MPEG (Score:3, Insightful)
From the article:
When MPEG-1 started it closely followed H.261 [wikipedia.org]. H.261 was very well written. Back in 1994 when Xiph started, MPEG-1 had already been going 6 years [wikipedia.org].
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.
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: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:3, Informative)
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
Re: (Score:3, Informative)
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.
Re: (Score:3, Informative)
Doesn't count... in America. I've never seen a VCD for sale, except in obscure import shops. It was big in Asia.
Re: (Score:2)
Yes, and clearly the couple billion people in Asia "don't count" compared to your ethnocentrism.
It still doesn't address many real world problems (Score:5, Informative)
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.
Re: (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 i
MPEG-LA bad mouthing? (Score:2, Insightful)
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
Re: (Score:2, Insightful)
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:3, Insightful)
Well that was a load of paranoia. There are clearly technical problems with the format - but according to you any criticism must be funded by the evil MPEG-LA!
In a nutshell (Score:3, Funny)
Mans Rullgard:
"Ogg considered harmful"
Monty Montgomery:
""Ogg considered harmful" considered harmful"
Reminds me of an Albert Einstein quote: (Score:2)
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
Shortcomings addressed (Score:2)
So can we expect to see a working example of bitrate peeling some time soon?
Re:tl;dr (Score:4, Informative)
Summary so far:
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.
Re:tl;dr (Score:5, Informative)
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).
Timestamps, dimensions, aspect ratio, framerate, samplerate, etc. are stored in codec-independant ways in the container.
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.
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: (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
Re:tl;dr (Score:4, Informative)
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."
Re: (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
Re: (Score:3, Informative)
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:
http://videos.videoonwikipedia.org/video/275/cell-phone-engineerguyogv [videoonwikipedia.org]
You can find many more with Skeleton streams at http://videos.videoonwikipedia.org [videoonwikipedia.org] or http://openvideo.dailymotion.com [dailymotion.com] or http://www.archive.org [archive.org] or many other sites. I can only conclude that you are not very knowledgeable about ogg usage in practice.
Re: (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: (Score:2, Informative)
Okay, I'll uninstall libtheora from my Fedora 12 desktop:
# rpm --nodeps -e libtheora-1.1.0-1.fc12.x86_64 libtheora-1.1.0-1.fc12.i686
Totem no longer plays Elephants_Dream.ogg because libtheora is not installed. It outputs a warning:
$ totem Elephants_Dream.ogg
(totem:8219): GStreamer-WARNING **: Failed to load plugin '/usr/lib64/gstreamer-0.10/libgsttheora.so': libtheoraenc.so.1: cannot open shared object file: No such file or directory
Let's try ogginfo now:
$ ogginfo Elephants_Dream.ogg
Processing file "Elephan
Re:tl;dr (Score:5, Informative)
Ah, the gotcha is in the source:
http://svn.xiph.org/trunk/vorbis-tools/ogginfo/ogginfo2.c [xiph.org]
Ogginfo's source includes information on how to process the metadata for various codecs.
So, the grandparent's complaint is still valid. Ogginfo appears to require recompilation for every stream that they want to support inside an ogg container.
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: (Score:3, Informative)
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.
Re:tl;dr (Score:4, Insightful)
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.
Direct Stream Copy (Score:2)
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.
Re: (Score:3, Insightful)
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.
Re: (Score:3, Insightful)
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
Re: (Score:3, Insightful)
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.
Re: (Score:2)
And indeed, the OSI model isn't even used in modern networking. It can be loosely applied to IP networking, but it was meant for the CLNP networking infrastructure.
Re: (Score:2)
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.
RTFA. (Score:2)
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?
Re: (Score:2)
``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
This matches my experience (Score:5, Funny)
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 :-)
Re: (Score:3, Informative)
The article is itself basically a summary of the format. If you don't care enough to read the article, probably all you should be worried about is what your iPod will and won't play.
Re: (Score:2)
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.
Re: (Score:3, Funny)
Oh, it's far worse than that: one of his competitors thinks it's not a good format.
Re:Really? (Score:5, Insightful)
And more importantly, they're wrong, in the eyes of its developer.
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.
Re:Really? (Score:4, Insightful)
He didn't say it was good, he explained why it is good.
Re: (Score:2)
Uh, retard -- he didn't attack the person he attacked the written work.
Probably he didn't read the definition.
Re: (Score:2)
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.
Re: (Score:2)
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 [barelyfocused.net] out there though...wish it was developed on more and would do vi
Re: (Score:3, Funny)
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!
(This comment is known to cause cancer in the state of California.)
Re: (Score:2)
Re: (Score:2)
``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
Re: (Score:3, Informative)
That's great. What container are they going to put it in again?
(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.)