Open letter to Google: free VP8, and use it on YouTube
fsf.org
fsf.org
What's there for Google?
- Google, Apple and Microsoft can afford the license and the fee is peanuts to them. Most likely Flash will be history no matter what codec wins. - If Mozilla decides to stick with it's values and stay free (is anything else even an option?) while the web goes h.264, I'd say a significant part of people will migrate to other browsers. And come on who's going to migrate to IE and Safari isn't that popular on PC, so that's even better for Google and it's Chrome. How could a bigger browser market share be bad? One downside though would be that some smart people who would be really valuable employees and have strong personal values might get pissed off and not join Google.
- "You owe it to the public" "if you care about free software". No matter how much it sucks, the only entities Google owes something is it's creditors and share holders. Sometimes same things benefit both the public and the share holders which is just super, but isn't it a bit naive to ask a publicly listed company not to take advantage of the situation just because it would be nice? Again though there's the possible loss of love, of which effect on the business as a whole I'm not competent to evaluate.
- Mobile hardware support is important and it's going to get even more important in years to come. I might be talking out of my ass here, but isn't the world full of hardware support for h.264? If that hardware support is something really generic like doing ICT really fast and can be applied to VP8 then this might not be that important.
People act as though the H.264 video tag is a foregone conclusion, but it really isn't - it's still a long way from being viable. Web technologies have never been about what developers want or what sites use but rather what browsers implement, and today ~88% of web-browser marketshare doesn't support the H.264 video tag (58% IE, 28% Firefox, 2% Opera). This is worse than Ogg Theora where ~68% aren't supported, while Flash is unavailable on less than 1% of browsers. Of course, this may change if Microsoft decide one way or another.
Although mobile devices are going to be increasingly relevent in the coming years, it's still a rounding error and users regularly update their handsets, which means the current H.264 support isn't a particularly strong argument in its favour. I suspect that mobile devices will converge towards whatever is done by desktop browsers, as has been the historical trend.
If this model turned out to be profitable, it would be a good precedent for subsequent codecs seeking universal adoption while still paying for investment.
With few users and a paid barrier to entry, few hardware vendors took the leap. No hardware support means fewer people bothered to encode to Vorbis... and the spiral to the bottom continued.
If you're trying to use the network effect to your advantage, you do exactly what the MPEG-LA has done: the first couple of years are free, then everyone pays. The only want to combat that is to do the same.
Still, I'll amend my above plan to include some period of royalty-free hardware. The real trouble is device manufacturers not wanting both On2 and H.264 hardware (it's unfortunate that MPEG-LA won't just step up to the plate with perpetual royalty-free software and make the whole issue moot)
[1] http://lists.xiph.org/pipermail/vorbis-dev/2002-September/00...
---
novas0x2a: i feel vaguely insane. did xiph ever (2002 timeframe, perhaps?) charge for a vorbis encoder or decoder? I had a pretty distinct memory of that, but going back and researching it, I can't find any sign of it. Did anyone ever charge for an encoder or decoder impl?
xiphmont: I've taken on works for hire in the past. That was not as part of Xiph. There was also a work for hire the company renegged on, and we opened that as the original Tremor. But I also wrote a decoder with Neuros and wrote an encoder for Mercora.
novas0x2a: I think I remember reading about tremor before it was open, and that's where my misconception comes from. thanks :)
From their site: (http://www.on2.com/index.php?599)
And with no patent-pool royalty hassles, VP8 licensing terms are flexible and affordable to ensure maximum ROI potential.
It's quite likely that any number of H.264 or other random patents apply just as well to VP8, especially given the USPTO's penchant for handing out patents that cover even the most basic of ideas. This is Apple's stated reason for refusing to implement Theora. In this vein, it should also be noted that there's no guarantee that licensing H.264 actually covers you for every patent.
I'd assume that if someone would be foolish enough to sue a h264 licensee, MPEG-LA (or it's members) would be quick to counter-sue them to oblivion.
There's a reason why patent owners just join the pool when they discover they're eligible for a nice easy income stream.
Equally, it's why productless patent trolls are so dangerous: since they don't make any products, such patent portfolios are useless as deterrence against them.
OTOH, I'm sure Google has thought about this problem and done some due diligence.
They're probably moving in that direction anyway and will release the codec as an open standard. It is also likely Adobe will support it in Flash to maintain maximum compatibility. The real question is whether Apple will bite...
And this is not related to open source but rather open web. The internet has been successful because of open technologies, meaning technologies that can be freely implemented and worked with by anyone without asking for permission from someone.
Regardless of what direction Google is moving in giving them some developer feedback doesn't hurt and Flash supporting the codec would be a good thing as well (The more support the better).
Not quite true. They have the following from what I've seen:
1) fmt=6 FLV with ffmpeg ~350kbps (legacy)
2) fmt=18 H.264 Baseline ~500kbps, now with x264 (iPhone support + current default)
3) fmt=22 720p H.264 High with x264, ~2.2mbps
4) fmt=somethingorother 1080p H.264 High with x264, ~4.5mbps
Note that options 3) and 4) don't exist for the vast majority of videos, and thus likely don't cost much disk space. Option 1) is being phased out. Their primary default is 2), a single format that works in Flash, on iPods, on iPhones, and on many mobile devices. They could have saved 30-50% on bandwidth by offering an H.264 High stream for PC viewers, but they didn't because it would have required they keep around a separate stream.
Any argument that Youtube should keep around a separate format for some Purpose X has to confront the fact that Google has thrown away staggering quantities of bandwidth explicitly to avoid offering a separate format.
All the On2 stuff just has the one, especially since they only ever released new incompatible codecs instead of improving their older products. Funnily enough that applies just as much to Theora (née VP3), which right now is a only an open standard in theory, not IETF-level reality. There's a few forks of the original On2 code and a transliteration of the decoder to Java for applets (Cortado). I guess people have been working on writing a new DSP decoder, but the whole thing feels like an even worse recapitulation of the ODF lie.
format 35: mp4/h264/aac, 480p@main format 34: flv/h264/aac, 360p@main format 5: flv/svq3/mp3, 400x226
format 36: 3gp/mpeg-4 asp/aac, 320x240 format 17: 3gp/mpeg-4 asp/aac, 176x144 format 13: 3gp/mpeg-4 asp/amr, 176x144
http://web.mit.edu/xiphmont/Public/theora/demo7.html
Check out the last graph on the page: when measured using PSNR, Theora tweaked to the max is roughly 50% worse than x264's default settings.
This now applies somewhat to Theora as well (in current SVN); they ported over a similar optimization to x264's Variance Adaptive Quantization, which dramatically increases SSIM but lowers PSNR.
Regardless of what video codec you use, the rate-distortion greatly depends on the encoder software and how you use it. When you use MEncoder's x264-compression for example you can tell it to do multi-pass encoding, more accurate motion estimation, use less keyframes, more frames for pixel prediction, ... . Many people don't even use multipass encoding when they convert their videos.
Update: Here's an interesting website about work on the theora encoder http://web.mit.edu/xiphmont/Public/theora/demo8.html
I'm all for Theora, but the (admittedly limited) anecdotal evidence that I have is that it isn't quite competitive with h.264 (with a good encoder like x264) at higher rez 720p and 1080p). I might be mistaken on that, though.
The encoder still has a good bit of room to improve; it still lacks proper pixel-domain RD optimization and could use some psychovisual improvements as well. It is primarily crippled by the ancient VP3 specification though. In theory it may eventually be able to eke ahead of Xvid, as while Xvid was a very good MPEG-4 ASP encoder, it never had any significant psy optimizations, so even though Theora as a video format is probably slightly worse, the encoder should be able to surpass Xvid with psy optimizations in some cases.
The primary problem for adoption (not for quality) is its lack of features. For many many use-cases, one needs fine-grained control over various parameters, such as the buffer size, the maximum bitrate, the latency, and so forth. The encoder is currently very inflexible, and with no alternative encoding libraries, this leaves very little choice for many applications. For practical purposes, it only has one speed mode: "slow as hell", which makes it basically impossible to stream anything above SD.