Slashdot Mirror
Concrete Comparisons of Theora Vs. Mpeg-4
icknay writes "With the upcoming Firefox 3.5 and HTML5 video, there's natural interest in Theora vs. Mpeg-4, but without much evidence either way. Here's clips encoded at various rates to provide concrete comparison between Theora and Mpeg-4. Theora performs decently, but requires more bandwidth than Mpeg-4 (although this is a 1.1alpha release of Theora and Theora has a much better license than Mpeg-4). The quality comparisons are very subjective, but you can try the clips yourself and see how it breaks down. There was an earlier discussion about this, but it lacked much concrete evidence. (Disclosure: it's my page.)"
I sort of knew Theora was a bit behind than Mpeg-4, but I didn't realize by how much. The Theora clip that has a 60% higher bitrate than the Mpeg-4 still looks fuzzier to my eyes (especially the moving grass).
Subjective measures are really the best way to evaluate video quality. There are (objective) quantitative measures such as PSNR, but they don't really tell you what the impact of video compression does for the eye. Video quality evaluations mostly involve showing clips (like these) to a large amount of people and asking them which they liked better. There is a lot to consider in terms of how the video responds to packet loss, jitter, etc.
The important line from the article: "Theora uses 1600kbps, or about 60% more bandwidth than Mpeg-4 to reach about the same quality."
Also useful to get some scale: "The uncompressed clip is 349 megabytes, while the 1600kbps Theora clip is 2 megabytes -- Theora may lag Mpeg-4 at this time, but it still yields great compression."
and "Theora is significantly better than Mpeg-2. Mpeg-2 required about 2400 kbps to hit the subjective quality level above, 50% higher than Theora's bandwidth."
Some things I would have liked to have seen: 250kbps, 500kbps, 2mbps, 8mbps videos, with subjective quality difference (rather than same subjective quality at different bitrates). Theora is apparently very good at lower bitrates, and not everybody has an awesome broadband connection, so they may be forced to watch lower-bitrate streams. Does the HTML5 video tag support selecting streams based upon available bandwidth?
"but the average computer user isn't going to spend months learning how to use a CLI and then hours compiling packages so that they can encode videos with Theora"
HUH?
There are plenty of visual apps to do this, no need for cli and whatnot....
NO SIG
gnome-terminal is better than windows command prompt.
P.S. Ogg Vorbis never toppled MP3 from the throne. However, the existence of Vorbis may have exerted some downward pressure on the licensing fees for the paid codecs.
But it didn't. In actuality, the license costs for licensing MP3 has actually increased since the time that Vorbis was being initially designed in some cases by almost 25%.
The license is the single most important thing. It determines whether or not you can use the software at all, or for your specific purpose, whatever that is.
When we're talking about establishing a standard for the Web, which everybody is expected to be a) able and b) allowed to use, there is nothing more important than the license.
Firefox? Chrome? Blender?
Apache? An argument can be made for Firefox vs IE too. Yeh open source sucks so much that Apple built OS X from it.
Except for the Apache webserver, I'm stumped.
Not coincidentally, most IT shops never consider Linux for anything outside of webserving.
The reference implementation of Theora, like that of Vorbis is under a BSD-style license to help it gain wider adoption, so your point is valid even for propietary browser makers such as Opera.
No problem is insoluble in all conceivable circumstances.
There are three things that this test doesn't consider:
For real life examples, that also include sound see "YouTube / Ogg/Theora comparison" and "Another online-video comparison".
There's a hidden treasure in Python 3.x: __prepare__()
The license means that every product that includes an encoder or decoder for MPEG-4 (including AVC / H.264) needs to pay the MPEG-LA a small free for every version they sell (or give away). This is incompatible with Free Software. Imagine that FireFox included an MPEG-4 implementation. The Mozilla Corporation makes enough money that they could afford to pay the maximum annual fee for this license, but what happens after you download it? If you give a copy of FireFox to someone else, then you need to pay the license fee (except you can't, because the MPEG-LA doesn't offer licenses except in large quantities). Maybe Moz. Corp. could pay that license too, but what happens in a few years time when they decide to stop? Suddenly, no one can redistribute any copies or derived works of FireFox. The root problem is that it is not possible to get a license for MPEG-4 that permits the kind of arbitrary redistribution that Free Software entails. Although the license fees are capped, they are capped annually, so each year you need to pay again or you no longer have a license to distribute code implementing the patents.
This is why Theora is better as a standard format. Anyone can implement it, at no cost and with no restrictions. H.264 is better quality, and so makes sense as an optional format for HTML 5 to support, but requiring it would mean that it would be impossible for the second-most-popular web browser to be HTML compliant. Of course, in an ideal world, the W3C, Mozilla Corporation, Google, or some other interested party would just buy the H.264 patents outright and let them lapse, but somehow I don't think that's very likely.
I am TheRaven on Soylent News
I hope you realize that Firefox was initiated by Mozilla, or did they finish the full frontal lobotomy after your first post?
Apache, lighthttpd, vsftpd, squid
Linux , bsd, darwin kernels
mythtv
vim/emacs/nano
mysql/PostgreSQL
GCC/llvm
IranAir Flight 655 never forget!
Chrome falls into the "proprietary or whatever" category because it's made by Google. Basically, open source projects that weren't initiated by a commercial vendor suck.
The rendering engine used by Chrome and Safari (webkit) wasn't made by any company. In fact, its origins are KHTML. the rendering engine used by KDE.
Nobody.
Yes!
This is why stuff like that gets separated from everything else and marked something like "non-Free" or "non-U.S. users only." Check it, you'll see.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
People providing decoders have to pay the license fee.
"Royalties to be paid by end product manufacturers for an encoder, a decoder or both (âoeunitâ) begin at US $0.20 per unit after the first 100,000 units each year. There are no royalties on the first 100,000 units each year. Above 5 million units per year, the royalty is US $0.10 per unit."
This causes issues for free software especially with the gpl because there is a clause which says you cannot restrict the distribution of the code but by having to pay a license fee this is a restriction.
Because in its current incarnation it is more of an archive format than a web video format. E.g. it cares more about quality than bitrate. The amount of CPU power required to view DIRAC is just too high. So it is a great source format but it wouldn't work well for streaming
Wow, I just had to comment on this. The article itself is of course nice and intriguing (and the video-clip chosen is an excellent clip to give the codec a hard-time. The grass, and medium-mask net in the background, wow.)
The problem with the article is that it really compares pears with apples, and is not too specific about what pears and what apples. The main problem here is that is uses different suites for conversion, in one hand ffmpeg with some probably well-tuned defaults for x264 (-vpre hq), and on the other hand ffmpeg2theora, that may be tuned for different defaults and different coding-settings. Especially, there are two parameters not covered by the article that may have a huge impact. Multipass-encoding, and keyframe-density.
Multipass-encoding is a technique where you let the encoder skim the content several times, gatherings statistics on progressive levels. Multipass encoding has huge benefits, and can sometimes cut the mbit/quality in half, or more.
Keyframes are special frames in the video-stream where the content can be synced. Between those frames only progressive frames happen, so you can't skip to those frames. Keyframes usually take up a lot more space than the frames in between so you want as few as possible of those, but if you make them too few, you will be limiting seeking severly, and for live content, the zap-time will increase.
Then there's the issues of whether different processing filters were used between the sets, and of course exactly WHICH versions of the codecs were used. "June-something" isn't really a good spec.
To make it a bit more equal comparison, and also with known versions, I tried redoing it myself, using a gstreamer-pipeline and the same source-material used in the article. The pipelines used were:
gst-launch-0.10 filesrc location=soccer_4cif.y4m ! decodebin ! x264enc bitrate=1000 ! avimux ! filesink location=soccer_4cif.y4m.avi
gst-launch-0.10 filesrc location=soccer_4cif.y4m ! decodebin ! theoraenc bitrate=1000 ! oggmux ! filesink location=soccer_4cif.y4m.ogv
Unfortunately, I don't have much time, or hosting space to share the encoded results, but trust me, it was NOT in favor of x264 with these settings. On the bright side, you can try it out for yourself, and fiddle with different settings, all versions are directly from updated Ubuntu Jaunty repositories, as of today. Just install gst-tools, and all gst-plugins even from multiverse.
Happy encoding!
Yeh open source sucks so much that Apple built OS X from it.
Unix was proprietary, and built by AT&T. Unix.
Nextstep used parts of FreeBSD and NetBSD, sure, but that was just the cheap path to Unix.
If you accept the GP's premis, his point is still valid.
Nice try though, kthxbye.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller