Ask YouTube for Ogg support
fsf.org
fsf.org
I certainly falls into that "good enough" category for encoding audio and video, the same as Divx and mp3. And it appears to stream at rates a few percentage points lower than the prevalent licensed formats.
My little Sansa clip player plays it quite happily and I like that I can stuff more songs onto its little 4GB memory if I reencode everything in Ogg, with really no perceptible different in sound. The few Ogg encoded videos I've seen seem perfectly fine and take up less space and use less bandwidth off of my disk to watch...
I was mystified when Google and Chrome went h264. Seems like lots of expensive licenses for something that's cross platform and well supported with no real expense associated with it.
seriously, why the hate?
It's not a real surprise that Google built in support for h264--they have petabytes of h264 video and sell phones that play h264 with built-in hardware decoding. Oh and it looks better.
VC-1 has hardware support in a number of areas and is included in WMP since at least 10, IIRC. h.264 still is not supported on any version of Windows before 7, and is only available in Flash.
Supporting h.264, with your logic, makes no sense.
This is true. But, if I had to choose between paying $20 extra for a better processor (that can play Theora) or $20 extra for a patent license (to legally play h.264), I would pick the former. At least I can use the better processor when I'm not watching video; the patent license only works for the 10 minutes a year I feel like looking at Youtube on my phone.
It's technically superior and also supported out of the box by 97% of new computers.
Nice statistic. What percentage of Internet users have "new computers", though? (I work at a company with 300,000 employees. We still use Windows XP; two versions behind the latest stable version of Windows!)
You are right that h.264 is technically superior to Theora. The Space Shuttle is technically superior to my bicycle, but due to cost concerns, I have to ride my bike to work rather than fly there on the space shuttle. Sometimes the best solution is not the one you can afford.
(I can't afford an h.264 license. Or rather, I won't afford it. I don't care that much about seeing a cat flushing a toilet on my phone.)
The same h.264 files can be played with Flash, which is ubiquitous on "old" computers like you have at work. Everyone can watch now and when they upgrade they can watch without needing Flash. Ogg doubles storage requirements for the foreseeable future without any gain.
I'm sure somebody has done the math on this.
This makes sense for those collecting the fees because the big players could move the market by themselves if they switch so there's no use squeezing them for money, when you can use them to lure in large numbers of smaller players.
On the other hand the Theora video codec has nothing going for it technically: it's worse than any of its competitors across the board. It was written for the commercial market, but was abandoned after no customers ever bought licenses. There are no independent implementations: there's only a transliteration of the decoder to Java, and a fork of the encoder to not suck quite as pointlessly within the bounds of the spec.
Theora's few proponents are pushing it for purely ideological reasons. Has that ever worked?
My guess is that because there's no support for Digital Restrictions Management. Apple has already widely deployed software and devices that can play restricted h.264, and that's what the media companies that produce the content "want". (Of course, I never watch "media-company content" on Youtube. I doubt anyone whose videos I watch on Youtube would want Restriction Management on their files.)
Incidentally, all of the music I've bought recently has been in FLAC format. Seems like everyone I listen to offers it in addition to mp3s.
(It's just video-producers that think I am going to pay them $2 for a TV show I can't watch on my portable device. Haha, fat chance.)
Kind of shows up their stance of we want to use the best and most widespread format (as does the crappiness of their H.264 encoder compared with the x264 encoder that they could just adopt).
They never made any official announcement, but there were reports of Apple employees claiming that the ever handy bogeyman of patents were preventing them implementing FLAC.
Shortly after they implemented their own ALAC (note that's the exact same name with Free replaced with Apple) which reverse engineering showed to be built with the exact same technology they claimed was under a patent cloud with a few extra bits which were actively avoided by FLAC because of patent worries.
Having experienced that, and been quite disappointed as an Apple fan and owner, I can't take their stance of H.264 seriously.
Apple originally developed ALAC for their AirTunes WiFi remote-speaker system. It supports low-latency streaming, and seeking works a lot better than with FLAC in every player I've used. FLAC's pointlessly-special container format suffers from the same screwy metadata problems as the other ogg formats: Apple wanted it in a standard mov/mp4 container.
http://flac.sourceforge.net/links.html#hardware
I find it surprising that the independently developed FLAC codec would suffer from the same problems as the Ogg container, unless you're talking about the slightly nonstandard FLAC in Ogg approach.
But if Apple really re-implemented a lookalike lossless format because they couldn't figure out any other way to put it in a .mov container then I think we're agreed that their engineering priorities around this issue are all messed up.
FLAC's container format supports arbitrary seekpoints, but it seems many encoders do not add them. Add them and a seek is a constant-time operation.
Though I've never seen a FLAC file with any metadata at all in the wild: it's always in the filename and accompanying text files. I would end up massaging the metadata into the standard mp4 fields when I transcoded to ALAC.
In practice when I've tried seeking in a FLAC file, I usually get a short pause followed by a loud click, and then the timecode is usually wrong or missing entirely. Maybe none of the files had seekpoint data, or the player/decoder implementations I used didn't support them. ALAC always worked perfectly.
http://en.wikipedia.org/wiki/Vorbis#Name
This obviously has nothing to do with companies like google and their licensing decisions, but I do honestly think it's a major reason the format never caught on with the general public.
And no-one, not even the BBC, can guarantee they won't get patent trolled. That's part of the delicious brokenness of patents, you have prove a negative, prove that there are no black swans and while reasonable people will go forward based on probabilities and heuristics, the wider discussion about Theora moved onto politics and business a long time ago, where demanding people prove a negative is a good rhetorical trick even when it applies just as much, if not more, to your own side.
With YouTube and Vimeo adopting h264 and not Ogg, I'd say I have a feeling I know how this is going to end.
Supporting H264 <video> was just a matter of writing some front-end player code (which they already had from their HTML5 demo) and feeding it the same video file they gave the Flash player. Supporting Ogg, on the other hand, would require massive transcoding.
* 720p version for hdtv videos
* 480p version for non hd web viewing
* High bitrate version for iPhone streaming on wifi
* Low bitrate version for iPhone streaming on 3g or edge.Mozilla does not need to distribute H264 support - just use what is already there. A similar library exists for windows.
Yet Microsoft's Windows Media Player 'just uses ffmpeg' to play these formats when you have one of the many DirectShow packages installed, and has since the beginning. Apple's Quicktime does the same when you have Perian installed. Opera uses GStreamer for <video>, and does the same when you have gst-ffmpeg installed.
Google is mostly paying for H.264 decoder licenses because they were already going to have to pay broadcaster-level encoder licenses.
I can see Firefox doing similar on Linux, so if it's just (ironically) the Linux geeks that are desperate for the patented codecs then I wouldn't worry too much about it. For the 60% of Firefox users on XP though, Mozilla aren't going to rely on system codecs that aren't there.
You'd be surprised at the hundreds of millions of XP users with codec packs installed already. For the remainder Mozilla would just need a nice 'codec not found, go here' dialog like they already have for Flash.
As a side note, I'm not sure why you want H.264 to become the de-facto standard, given that it would require you to pay licensing fees just to host your own videos.
I would prefer to see open, unpatented and free video codec used for the majority of web video. I applaud Mozilla for taking a stance. I don't applaud them taking a stance by limiting their users' freedom, instead of directly talking to Google, Vimeo and others and lobbying for the use of more open formats. Surely, a letter from Mozilla "hey guys, we really think you should support Theora too, let's meet and we'll tell you why we think it's very important" would have more effect than random blog articles & what amounts to blackmail?
The alternative is the continued domination of Flash. Is that what they really want? Because that's what they're choosing to get.
I admire their principles but in the end it's the outcome that matters.
There would be no Wordpress equivalent if putting text on the web was taxed.
Ironically, there is VideoPress.
http://people.xiph.org/~greg/video/ytcompare/comparison.html
It appears that Theora could easily replace H.263 as a low-end codec and would be competitive with H.264 as a high-end codec.
(Google is the same; they are just another media company. If you think Google is about "openness", ask yourself why Google can crawl your site, but you can't crawl Google's site.)
In this case Theora is both mediocre and unestablished, which is not a winning combination.
People complain about the extra CPU power it takes to decode Theora, but if I have to choose between paying extra for a more-powerful CPU or a patent license, I would choose the former. At least I can make use of the more-powerful CPU when I'm not watching videos of cats flushing the toilet.
So personally if it's a difference of battery life, I'd choose the one that uses less power and gives me more time.
(And, I have a portable device that plays arbitrary video formats just fine on a rather-big 5" screen for a whole transatlantic flight; 7-8 hours. So the current technology is more than adequate, H.264 or not.)
Even they weren't shitheaded enough to remove their GIF decoder when the encoder was revealed to be patent-encumbered.
You're also completely discounting the cost of H264 licensing right now (estimated by some to be over 5 million dollars a year), and the cost of future licensing once the current license terms expire. You're also discounting the cost that Google pushes off to the rest of the market - like the money other manufacturers of software and hardware pay to support H264. Adobe has to pay for the H264 license Flash uses, and without that license, Youtube wouldn't be able to use H264.
Now, one could argue that since Theora isn't completely equivalent to H264 quality-wise, that Youtube wouldn't be able to provide video at the same bitrates. That's ridiculous. The typical Youtube viewer doesn't even know what a bitrate is and is unlikely to be able to identify encoding artifacts.
One should also consider that Google could easily pay a small team to work on improvements to the Theora encoder for a year or two, like they're doing on Unladen Swallow. The results would pay off on a fairly regular basis, allowing Google to re-encode their Theora videos for improvements in quality and bitrate efficiency. I have no doubt that with a sustained investment of resources, Theora could be highly competitive with H264 - if not superior - for Youtube's uses. Even if they were to dedicate 10 engineers for an entire year to working on Theora, the total costs there would not approach the cost of licensing H264.
If it would be cheaper there would be no reason not to do it. Google built support for Ogg into Chrome, so they aren't scared of the format. They aren't doing it so I'm going to go out on a limb here and say it's not cheaper.
http://people.xiph.org/~greg/video/ytcompare/comparison.html
That comparison, of course, is six months old and things change rapidly in a short span of time.
Think about the consequences of this for just one moment. How much support and developer time is Firefox going to lose if it can't play videos if/when YouTube switches over fully and doesn't use Flash? How much support and developer time is Linux going to lose if there are no browsers for it that can play internet videos, if H.264 becomes the de-facto standard (note that only Chrome works, not Chromium)? If you don't care about that at all, and are happy using IE (or Chrome, these days) on Windows for ever, then by all means move along, there is nothing for you to see here. The rest of us care.
Chromium supports all the codecs your local ffmpeg install supports, if you put symlinks to the libraries in /usr/lib/chromium-browser/. Everyone installs it this way, and it actually supports way more codecs than the official Chrome (Google didn't buy licenses for MPEG2, Xvid, etc.).
Edit: I must be doing something wrong, because I can't get it to work. This might be a distro/version/phase of moon-specific fix?
[1] Ubuntu's default ffmpeg package has all the decoders turned on without being 'nonfree'.