This one was accidentally deleted from the submission queue when it was first submitted some time ago, so I decided to keep it around for a slow news day (such as this one – dear lord, it’s quiet). FFmpeg developer Mans penned down a number of crucial problems with the Ogg container format.
The problems with the format centre around a few basic principles: generality, overhead, latency, random access, and timestamps.
The problem with generality is, well, that there isn’t any. Ogg is supposed to be a general-purpose container format, meaning that “encoded data of any type can be encapsulated with a minimum of effort”. According to Mans, Ogg doesn’t fit this description.
“For every format one wishes to use with Ogg, a complex mapping must first be defined,” Mans explains, “This mapping defines how to identify a codec, how to extract setup data, and even how timestamps are to be interpreted. All this is done differently for every codec. To correctly parse an Ogg stream, every such mapping ever defined must be known.”
Sadly, there is no single place to go and get these codec mappings from, leading to problems. “It is simply impossible to obtain a exhaustive list of defined mappings, which makes the task of creating a complete implementation somewhat daunting,” Mans explains. He also presents Matroska as a much better example of a general purpose container format.
Ogg also has overhead problems, Mans argues. After providing a detailed explanation of the concept, he concludes: “We thus see that in an Ogg file, the packet size fields alone contribute an overhead of 1/255 or approximately 0.4%. This is a hard lower bound on the overhead, not attainable even in theory. In reality the overhead tends to be closer to 1%. Contrast this with the ISO MP4 file format, which can easily achieve an overhead of less than 0.05% with a 1 Mbps elementary stream.”
Latency-wise, it all gets very technical again:
Latency in an Ogg-based system is introduced at both the sender and the receiver. Since the page header depends on the entire contents of the page (packet sizes and checksum), a full page of packets must be buffered by the sender before a single bit can be transmitted. This sets a lower bound for the sending latency at the duration of a page.On the receiving side, playback cannot commence until packets from all elementary streams are available. Hence, with two streams (audio and video) interleaved at the page level, playback is delayed by at least one page duration (two if checksums are verified).
This problem could technically be solved, but in doing so, you’d hit the overhead problem again. “Minimum latency is clearly achieved by minimising the page duration, which in turn implies sending only one packet per page,” Mans explains, “This is where the size of the page header becomes important. The header for a single-packet page is 27 + packet_size/255 bytes in size. For a 1 Mbps video stream at 25 fps this gives an overhead of approximately 1%. With a typical audio packet size of 400 bytes, the overhead becomes a staggering 7%. The average overhead for a multiplex of these two streams is 1.4%.”
Other formats, like ISO MPEG-PS and Microsoft’s ASF, have far less overhead, and Mans suggests bringing Ogg in line with those.
Random access is also a problem with Ogg. Random access allows direct seeking at any position in the file; quite important for a general purpose container format. The method with which Ogg provides random access is crude, according to Mans, a problem which gets worse on slower media like optical disks or over the network.
Another important aspect of video files is that the audio and video streams must run in sync, or else it starts to get annoying really fast. “By the time Ogg was invented, solutions to this problem were long since explored and well-understood,” Mans writes, “The key to proper synchronisation lies in tagging elementary stream packets with timestamps, packets carrying the same timestamp intended for simultaneous presentation. The concept is as simple as it seems, so it is astonishing to see the amount of complexity with which the Ogg designers managed to imbue it.”
Mans concludes that Ogg is simply a bad format – patent free or no. “[Being patent-free] still does not alter the fact that Ogg is a bad format,” Mans claims, “Being free from patents does not magically make Ogg a good choice as file format. If all the standard formats are indeed covered by patents, the only proper solution is to design a new, good format which is not, this time hopefully avoiding the old mistakes.”
Why not use Matroska instead of Ogg? As far as I can tell, Matroska avoids all the problems with Ogg, and is still open. If their are problems with Matroska, it should be relatively easy to develop a new format that fixes the problems.
I think a lot of people don’t seem to realize that Ogg is a container format and Theora and Vorbis are not bound to it at all.
Container formats are much simpler to develop, and much easier to avoid patents with than audio or video codecs like Vorbis and Theora.
Somebody should write patches for Firefox, Chrome, and common open source audio/video editors (if they don’t already) to support Matroska. If Ogg really is that bad, being optimistic, I can imagine Matroska or another format basically replacing Ogg within ~6 months.
The question is not so much as “Matroska is better than Ogg”, but rather a question of “Ogg and Matroska have different design goals, which is better for video on the web”?
Ogg was designed primarily as a streaming format. The primary feature of a streaming format is that one can pick up the stream “mid-stream”, if you will, and still make sense of it. A streaming format therefore necessarily has repeated information, and is not competitive when used as a file format instead.
http://en.wikipedia.org/wiki/Ogg
Ogg Theora is efficient enough at streaming so that it can even support live streaming … such as you would require in a videophone application, for example. When used in a live streaming context, one must compress the stream using a single-pass compression, and the results of this can often be disappointing. Many Ogg-Theora video files which are NOT intended to be streamed is un-necessarily degraded because the encoding was still (mistakenly) constrained to a single-pass process. You can get far better results in a static file if you use two-pass encoding.
The Matroska open format supports Theora and Vorbis codecs.
http://en.wikipedia.org/wiki/Theora
If one runs the Handbrake program, for example, it allows one to transcode from any input to Theora and/or Vorbis within a .mkv (Matroska) file format. So Matroska is already a demonstrated alternative to Ogg as a file format.
http://en.wikipedia.org/wiki/Matroska
The real question boils down to this: in the context of video for the web, presumably when wrapped within HTML5 video tags, do we want a streaming format (Ogg) or a file format (Matroska)?
I would suggest that there are use cases for both. Only Ogg can meet both situations.
AFAIK the HTML5 player embedded in Firefox at this time is capable of playing Ogg format only.
Edited 2010-03-18 01:21 UTC
MKV is intended for streaming: http://en.wikipedia.org/wiki/Matroska
OK, Matroska is better than Ogg as a file storage format, so the question boils down to this: is it as good as Ogg as a streaming format?
If so, then Matroska would seem to be the most sensible option, without any doubt.
PS: the points raised in the original article about the difficulty of “mapping” are moot, because lets face it Ogg is only ever going to be used for Xiph codecs, and that mapping has already been done.
Yes, that is a comparison that I would also like to see.
I think though, from all that I’ve read and experienced as just a user of both containers, that it would probably be easier to improve streaming support in Matroska, should it prove significantly worse, than to address the deficiencies in Ogg at the moment (bringing it up to par with Mkv feature wise and technical flexibility/robustness)
Assumption is the mother of all screw-ups. Assume nothing. Theora et al are here today – but something else will be here tomorrow. Ogg should not be advocated any more. End of story. Please look at the bigger picture.
That’s the one part I didn’t understand about the article. Ogg and the Xiph codec formats it is intended to use will largely come together.
The Matroska devs don’t appear to think so:
from: http://www.matroska.org/technical/guides/faq/index.html
Yes, this is more or less what I thought. Ogg designed for streaming, Matroska designed for storage as a video file. The thing I hadn’t realised is that both formats can be pressed into service for doing either role.
OK, so it still begs the question … which is better for use over the web? Considering how easy it now is to make either format, and the fact that they will be within a few percent as far as bandwidth/filesize goes, it surely would come down to how difficult or easy is serving each one?
OK, so it still begs the question … which is better for use over the web? Considering how easy it now is to make either format, and the fact that they will be within a few percent as far as bandwidth/filesize goes, it surely would come down to how difficult or easy is serving each one?
I am in no way an expert at all in these things so I may be talking completely out of my arse here, but from what I’ve gathered OGG is better for streaming lower-quality content and Matroska would be better for high-end content. On server side though, gathering from the article, OGG poses some synchronization, latency and overhead issues. Multiply that with hundreds or thousands of users and it’s probably easier on server side to go for Matroska or some other format.
Now, someone correct me if I am indeed mistaken.
Note that for “low bitrate” streaming they specifically compare it with Vorbis — audio streaming. DVD quality video (youtube “HQ” mode) and above (youtube “HD” mode) is no longer “low bitrate”.
Yes, I agree about using MKV for Theora. In fact Mann does point out the merits of Matroska in the Generality point.
And as discussed in the article, I have also experienced issues with seeking in OGM taking a long time (in the order of seconds).
In addition, Matroska supports many other useful features such as file linking and ordered chapters, whereby different parts of different files can be linked together, to be played as one continuous file, or skipped to as chapters, from the same file(s).
Edited 2010-03-18 02:12 UTC
The article in places is too technical to matter only to people who write encoders and decoders.
To the rest of us, the following information is more understandable and i did not see them addressed.
In the overhead section:
How much extra file size and bandwidth does the overhead consume compared to h.264 for example and can this overhead be reduced.
in the latency section:
Because of the latency, how long will a stream have to buffer before it starts playing? A bit of numbers on streaming bitrate, available bandwidth and buffering times would have been appreciated
in the random access section:
is ogg seakable? if yes, how much does it take on average to seek and rebuffer before play starts again
H.264 is not a container. It would be a question of Ogg, MKV, various types of MPEG containers, etc..
Latency: agreed. While I can see what he means, what would be typical actual times, or theoretical differences in times, compared to something like MPEG-TS?
Seekable: seeking is highly dependent on how long it takes to get the data you can, make sense of it, and ask for different data. I didn’t quite catch what formula was used to figure out how many levels of searching may be required. IE, log-1 (base 2, 10GB Ogg data) = 10 comes from….what, exactly? How does that translate to smaller files?
Anyway, in case it was the binary search bit that caught you off, a typical binary search will go like so:
Is what I’m looking for to the left of this spot?
Yes: search left.
No: search right.
Each time, halving the amount of the file it searches, until it reaches a small enough section that it has found the location you are searching for.
Now, an index sent to the client upon beginning the stream would allow something like that to occur in memory (guaranteed to be very fast). An index on the server would allow it to also occur in memory. With no index at all, you as a client become limited by ping times, and the server becomes limited by storage device latency. HOWEVER, if the file is wholly or in-memory at either end, searching will be quick, and if parts that you are searching over are in memory, that part will be quick.
Edited 2010-03-18 01:31 UTC
seemed like total osnews material, figured you didn’t take it cause it was a topic that has been beaten to death.
Any of the people here discussing the container formats actually read the damn article? Not just skim it, but read it? Almost all of the questions people above have asked were addressed in the article, and a few things people said he didn’t cover he most certainly did.
So far as Matroska, he did mention it, but he has not posted any detailed analysis of the format yet either. He indicated it’s better, but not whether it’s better than any other particular container format. He only mentioned it in relation to it also being an free/open standard and hence invalidates the claim that we “need OGG because it’s the only patent-free container format.” (Matroska might be covered by an unknown patent, but then so might OGG; nobody’s brought up one for either yet, though.)
Container formats for compressed data are unlikely to be covered by a patent as there is nothing all that innovative about them really, there is copious prior art, including but not limited to the zip format.
Patents are more likely to cover codecs.
The Theora codec (which Ogg or matroska might contain) is itself patented, there is nothing “unknown” about that. Theora is based on On2’s VP3 codec. Xiph.org have obtained the required permission to develop Theora, and to distribute it royalty-free as open source software.
This makes it unlikely that there are any other “unkown” patents that apply to Theora out there. Firstly, On2 should not have been able to patent VP3 if there was a valid earlier patent that covered the same technology, and secondly, any later patent on the same technology would be trumped by On2’s older patent.
Finally, the companies that are trying so hard to promote h264 and FUD against Theora have repeatedly mentioned this possibility about imaginary “unkown” patents that might be out there that might apply to Theora. This is telegraphing their wish that there was such a claim, clearly the h264 companies would support such a claim. Proabably with hard cash up front, just so there would actually be a patent claim against Theora.
As the parent post notes: nobody’s brought up one yet, though.
This is a very strong indication that nobody holds such a patent, just as should be the case if the USPTO were doing their job when they awarded the patents for VP3 to On2.
Edited 2010-03-18 06:35 UTC
Doesn’t matter, because we can’t change it. Hixie made sure that the spec says that if <video> encounters an unknown format, it *does not* fall back. That means, that unless they’re using JavaScript to check this, if a new video format comes along and a site _doesn’t_ provide an OGG version, then Firefox 3.5/3.6 will not fallback to Flash, if provided.
Hixie has made sure that there can only be one winner, and no new formats are allowed. It’s H.264 or Theora/Vorbis. I hate that. Browsers didn’t support PNG to begin with and now it’s universal. Hixie has crippled the browsers because he wants this video war to be fought and to force people to provide OGG (a noble idea, but with the problem that it’s now 10x tougher for Diarc or any other free format to now get a foothold).
* * *
Secondly, I don’t care about the format. Even if it’s flawed, it still plays fine in my browser. What matters, more than a sucky format (HTML is a sucky format compared to PDF) is the tools to work with the format; and those suck even more. OGG is horrible to work with. The software is out of date, buggy and obtuse—having no clean integration with existing workflows. Video editors (the people, not the software) use QuickTime / Apple QMaster and so forth to do batch and distributed compression; the OGG QuickTime bundle is a year out of date, barely provides any options and craps out all the time.
The lack of good, simple tools for working with OGG will seal its fate. The quality argument is irrelevant, YouTube didn’t get where it is based on quality.
In reality, the OGG container format is really no better than the original FLV flash video container format. Both suck in their own ways. It doesn’t matter how good the engine (codec) is, if the car has flat tyres, a thrashed gearbox** and no suspension, it’ll run like a dog.
** Transmission in American speak.
luckily dogs are good runners.
And don’t forget that tyre == tire in amerispeak.
Yeah, I did have that one, but then I though it was a little *too* obvious 😉 Then again I once had an argument with an American who would not believe that “dreamt” was the past participle of “dream” and is in fact interchangeable with “dreamed”.
That irks me… in my kids school they are slowly but surely eliminating the alternative, hard endings with “ed.”
I still use “t” where ever I am able. It’s happening with other endings as well. The evolution of language, I guess.
I am not a video editor, yet my system supports three up-to-date video editing tools for Ogg Theora.
(1) LiVES
http://en.wikipedia.org/wiki/LiVES
(This is supposed to work on MacOSX, but it doesn’t look easy to install)
(2) FireOgg
http://firefogg.org/
(Will run anywhere that can run Firefox)
(3)Kdenlive
http://en.wikipedia.org/wiki/Kdenlive
http://kdenlive.org/
Here you go, a Mac port:
http://kdenlive.org/user-manual/downloading-and-installing-kdenlive…
http://kdenlive.org/features/video-editing-made-easy
http://kdenlive.org/about-kdenlive/audio-and-video-formats
BTW, if you are supposed to be a Video editor, and I am not, how come my machine has far better support for video editing than yours?
Here is a screenshot gallery I took from an Ogg video movie trailer at 480p, transcoded from .mov by fireogg. The entire .mov file was 147 MBytes, the .ogv file was 106 Mbytes, the quality is indistinguishable. It took me only a couple of minutes to download the fireogg extension and convert the video (three clicks).
http://ourlan.homelinux.net/qdig/?Qwd=./Theora_480p&Qiv=name&Qis=M
Isn’t it time you thought about moving to a platform that could run software that better supports your Video editing needs?
Edited 2010-03-18 11:15 UTC
Here is a screenshot gallery I took from an Ogg video movie trailer at 480p, transcoded from .mov by fireogg. The entire .mov file was 147 MBytes, the .ogv file was 106 Mbytes, the quality is indistinguishable. It took me only a couple of minutes to download the fireogg extension and convert the video (three clicks).
http://ourlan.homelinux.net/qdig/?Qwd=./Theora_480p&Qiv=name&Qis=M
Since it only shows the output, not the input, we cannot compare the quality. Just because you say it’s “indistinguishable” doesn’t really prove much.
http://ourlan.homelinux.net/qdig/?Qwd=./Mov_480p&Qiv=name&Qis=M
Sorry, but the reaction time of my finger on the “S” key (for screenshot) is such that I cannot get the exact same frames. Hopefully some of them are close enough to illustrate the point.
Remember also, the Theora .ogv file is only 72% of the size of the .mov file.
Edited 2010-03-18 11:50 UTC
BTW, you can try it for yourself, if you like, and you have firefox.
Firstly, get and install firefogg:
http://firefogg.org/
Then get a decent video clip.
In firefox, select “Tools” then “Make Ogg Video” (a new Firefox window will open). Click on select file, then select your input file.
I left the default pre-set for Theora Web Video. Click on “Basic quality and resolution control”. I selected maximum quality (10) and two-pass encoding.
Then I clicked on “Save Ogg”. Pretty simple, hey, if even I can do it.
It doesn’t seem at all like a difficult format to me.
Edited 2010-03-18 12:28 UTC
What has any of that got to do with EDITING video? Video conversion to a delivery format is about the final step of any workflow in a video editor. It is insignificant and trivial. The intermediate file format/codec used as for editing will inevitably require some kind of conversion – even if it is a similar format to the final target delivery format. Because editing a compressed and optimised video is absolute torture!! You don’t, it would seem, know what video editing really means.
I’m not a video editor, but I do know one.
Try using OGG in QuickTime, Apple QMaster, Adobe After Effects and FCP. Methinks you don’t know what a workflow is if you seriously suggest using a Firefox extension to output video. OGG will never catch on because it is not appealing to the types of people who edit videos for a living and certainly don’t have time to waste with needless extra steps outside of their normal workflow using tools that can’t work directly from the source material.
I wouldn’t suggest that your platform is poor for editing purposes, it just has poor support for the final output format. Currently, for example, your platform cannot make decent output in a form suitable for delivery to Firefox users via HTML5. That userbase is significant in many places, it is 50% of users in Germany.
If you would like to support that userbase, here are some of your choices:
(a) Use an extra encoding step after video editing via a tool such as Firefogg that is supported on your platform, or
(b) Use a Theora-capable editing tool that is supported on your platform (perhaps via porting, kdenlive is a possibility here) , or
(c) Use a Theora-capable tool that isn’t supported on your platform (perhaps via Virtualization, kdenlive or LiVES under Virtualbox are a possibilities here) , or
(d) Start an open source effort to update Theora for Quicktime, possibly on Google Code or Sourceforge, or
(e) Change your platform (because you will be waiting forever before your platform vendor helps you).
I would venture to suggest that simply bemoaning that the available tools for Theora aren’t adequate, when they clearly and demonstrably are because other amateurs (me for example) can easily produce such videos, isn’t really a sensible attitude.
Edited 2010-03-19 00:53 UTC
I found another one:
http://mirovideoconverter.com/
I found out about it reading this:
http://videoonwikipedia.org/index.html
which lead here:
http://videoonwikipedia.org/howto.html
Why would anyone participate?
More here:
http://openvideoalliance.org/
Sounds cool to me.
PS: It also might be possible to convince this organisation:
http://corp.kaltura.com/
to start a project to update the Theora Quicktime plugin.
Edited 2010-03-19 11:50 UTC
FLV would work. Please note Kroc was talking about practical people who are not on a crusade. Those people will most likely also want to support IE and can not use HTML5 at all.
Interesting I always assumed that video editors would work similarly to photographers. I know quite a few photographers who do not use the same tool for the RAW conversion and the image manipulation, I’d even say it’s quite common as people tend to use a RAW converter which gives them the best results and then use an image manipulation program (e.g. photoshop) for further touches.
As a side note, I find it interesting how, if an open source program can’t use a format it’s always the fault of the program, however if a commercial program can’t use an open format it’s the fault of the format
I almost included that in my post, but I thought it’d come across as whiny. But it’s a good point. When people whine about Linux, a frequent complaint is that “DVD’s, MP3’s and common video formats don’t work.” And yet when Apple’s tools don’t support a format… that’s the format author’s fault? Huh? How’s that work out?
The next time someone complains about not being able to legally play a DVD on Linux in the US, can I count on Krok to pipe up with a hearty “And that’s the DVD Forums’ damned fault!”?
I don’t know that I agree with his reasoning, but I do agree with his conclusion. It’s not the format author’s fault that Apple’s professional editing tools don’t support Ogg as a container. That’s not a weakness in the Ogg format, it’s a weakness in Apple’s tools. And it’s Apple’s problem to fix – at least, if Apple’s customers start demanding the ability to work with Ogg video.
I though Kroc was a Mac user? This would seem to fit the bill if so. Even so much as having a version of iMovie bundled with new Macs.
Linux is NOT a platform with a SINGLE semi-professional quality video editor worth any beans. I with Eugenia would comment on this thread, as her blog documents all of this.
I beg to differ on that… there is one editor that for some reason, seems more well known to Windows users than Linux users: Blender VSE.
It is very powerful.
However on the issue of using Theora as an editing format, yeah I agree that it’s not meant for an intermediate format. Just like photo editors don’t actually edit pictures in jpeg. (nor would people who do multiple edits would want to save in jpeg each time)
Exactly so. No one would suggest that one should use Theora as the editing format … it is a lossy format, after all. Nevertheless, given that it is actually now a very competitive compressed video format, Theora should clearly be an option for an output format of any video editing suite.
Any graphics program that couldn’t save in .jpg or .png, say, would unquestionably be seen as a deficient, less feature-rich program. What is it about Mac users that they somehow can’t seem to accept that their video editing suite of programs are likewise deficient if they cannot output to Theora?
cycoj said:
Is it a weird type of “digital snobbery” or something? What am I missing here?
Edited 2010-03-19 09:12 UTC
Subjective. I think you need to realise that no one edits video in “OGG/Theora” format. It is NOT an intermediate format.
I fail to see how lacking support of OGG and Theora is actually any kind of issue. This all boils down to your one person crusade to be proven correct. You have decided to advocate Theora, and well, you are like a broken record. It is extremely boring.