For background on the free software angle on this story please check out Robert O’Callahan’s post on this topic. Also check out Mike Shaver’s shorter background post as well. This post differs from theirs in that I want to talk about network effects, why codecs should be considered a fundamental web technology and what the long-term effects of the choices at this inflection point might look like.
Recently Youtube announced that you could test out an HTML5-enabled version of their site. They said that they were doing this partially based on people’s “number one request” that Youtube do more with HTML5. (They left out the other half of that #1 request – that the implementation be based on open codecs, but more on that later.) Not to be outdone, Vimeo rushed to announce a beta version of their player based on their site that claims HTML5 support as well.
To be clear, this is great news. This is just the latest in a long string of changes for video on the web. We started with a raw “player” delivered by Real Media. Then on to media embedded directly in pages via Windows Media + Quicktime. More recently video on the web has been a a platform play by Flash. And finally to a place where media becomes a first class citizen on the web without a single source provider. These moves by Google and Vimeo (and before either of them, DailyMotion) show that things are changing for the better, and faster than I think anyone could have imagined.
The players from Google and Vimeo do present a pretty serious problem, though. Each of these require a proprietary H.264 codec to be able to view them. These codecs aren’t compatible with the royalty-free web standards that the rest of the web is built on. The fact that they are being so unabashedly hyped along with the new darling of the web – HTML5 – means that most people don’t understand that something very dangerous is taking place behind the scenes.
If you think that this isn’t an issue that’s worth worrying about you need to read the rest of this post. In particular the history of GIF shows us what happens when patented technologies are used on the web and what happens when network effects over-run the natural drive to royalty-free technologies at scale. MP3 pricing gives us a glimpse into the strategy around H.264 licensing and what the landscape might look like 5 years from now, assuming H.264 were baked into the web platform as a requirement. I’ll also talk about other options that might be coming in the near future that most people don’t know about.
The Web Exploded on Royalty-Free
The web has always been based on the assumption of Royalty Free. In fact, participation in a working group at the W3C requires that any parties disclose and make available any essential claims on the technology covered by that working group.
But that’s just a technicality. The truth is in the tests: you can still build a web browser, spider, client, web server, image editor, a JS library, a CSS library, an HTML editor, a web publishing system, commerce system – anything that is based on fundamental web technologies – without asking anyone for permission. This is a fundamental reason why the web has spread everywhere. Because everyone had the chance to add to the mix.
It’s worth saying twice. Anyone can create technology or services on the web and they don’t have to ask anyone for permission to do it. This is why we’ve had billions of dollars of investment and a fundamental shift in the way that western society acts and communicates – all in the course of a very short period of time. The web grew up on Royalty-Free.
Learning from GIF
The web in 1999 was a lot smaller than it is today, so a lot of people don’t remember what happened back when Unisys decided to start to enforce their GIF-related patents. GIF was already widely used on the web as a fundamental web technology. Much like the codecs we’re talking about today it wasn’t in any particular spec but thanks to network effects it was in use basically everywhere.
Unisys was asking some web site owners $5,000-$7,500 to able to use GIFs on their sites. Note that these patents expired about five years ago, so this isn’t an issue today, but it’s still instructive. It’s scary to think of a world where you would have to fork up $5000 just to be able to use images on a web site. Think about all of the opportunity, the weblogs, the search engines (even Google!) and all the other the simple ideas that became major services that would never have been started because of a huge tax being put on being able to use a fundamental web technology. It makes the web as a democratic technology distinctly un-democratic.
We’re looking at the same situation with H.264, except at a far larger scale.
So let’s talk about what makes a fundamental web technology, and how they should be licensed. First, the licensing. I think that Apple said it best:
After careful consideration of the draft patent policy, Apple believes that it is essential to continued interoperability and development of the Web that fundamental W3C standards be available on a royalty-free basis. In line with the W3C’s mission to “lead the Web to its full potential,” Apple supports a W3C patent policy with an immutable commitment to royalty-free licensing for fundamental Web standards. Apple offers this statement in support of its position.
(The post then goes on to talk about an opt-out mechanism for participating members.)
This leads to the obvious question: is the codec a fundamental web technology? The HTML5 working group argued and punted on the issue. Given that the standard is mum on the issue it falls to the actors in the market to determine what’s required to support HTML5. Given the state of online video today this basically boils down to one actor: Google.
Google has a near-monopoly in online video thanks to the ubiquity of Youtube. This means that they are the effective arbiter of codec choices for HTML5 video. If you want Youtube to work, you have to support whatever they are using. (Right now that’s Flash or a native Youtube app for mobile devices, but it’s clearly changing.) Let’s set up a strawman and say that it’s going to be H.264. (I’ll discuss later why I don’t think that this will be a requirement, but let’s say that it is.)
Their choice for H.264 had an immediate effect. It’s a signal to the market that it’s OK to start using H.264 as the main codec for HTML5 video. This is proven out by Vimeo’s HTML5 beta player launch. Vimeo is a secondary player, but were perfectly happy doing what Google did. The effects of that move have spread quickly and you can see it in people’s reactions: John Gruber getting angry at Mozilla as a result of Google’s actions, people on twitter claiming that we don’t support HTML5 at all because of Google’s use of a proprietary codec (Not true! Firefox actually leads in HTML5 support in a huge number of areas.) and Gizmodo’s choice comment: “Luckily, YouTube accounts for a hefty chunk of said architecture, their catalog is rendered in HTML5-friendly h.264 format.“ This is what network effects look like in real time.
So if you think that Google has settled on H.264 as the only codec they will support (unlikely) it would appear that they have set us up to have another GIF-like situation. Note that I think that this will not actually be the case, as I discuss later, but it’s worth thinking about as a framework. So instead let’s talk about what that situation would look like, with MP3 as the model for the H.264 licensing strategy.
Rising Costs and Unpredictable Licensing
So what can we learn about H.264’s licensing strategy as it pertains to pricing? Much like GIF we already have a model to look at that is already near the end of its cycle: MP3. Network effects and goverment-sponsored monopolies make a very powerful combination. But getting the most out of them requires a very specific strategy, one we saw with MP3 and we’re seeing again with H.264.
History is instructive. We know that MP3 was licensed quite liberally early in its lifespan. Before 2002, “no license fee is expected for desktop software mp3 decoders/players that are distributed free-of-charge via the Internet for personal use of end-users”. They changed that after the network effects had already taken their toll. Not only were decoders free for free software, but bulk flat rate licenses were available to large distributors. That’s how widely distributed software picked up with ability to play back MP3-encoded files.
But as the cycle continued and MP3 became a requirement for playback the pricing changed to where we are today. So let’s talk about what it looks 8 years later.
If you look at the public published rates for a couple of the MP3 licensors (and there are more than just two) someone who wanted to use it would be looking at a royalty rate of about $1/downloaded unit. So if you were doing, say, two million downloads a day you would be looking at about $2,000,000 per day just to have permission from those companies to include an MP3 decoder. Could you negotiate a lower rate? Probably. But that gives you a sense of the scale if you’re a small provider in a world where getting started on the web is hard and you don’t have much negotiating power.
People casually say that we should support licensed codecs like MP3, but they haven’t done the research. We have.
Much like MP3, H.264 is currently liberally licensed and also has a license that changes from year to year, depending on market conditions. This means that something that’s free today might not be free tomorrow. Like sending an H.264 file over the Internet.
In fact there are already royalties charged to some people using H.264 for streaming, according to Jan Ozer. Some quotes from that article:
Whenever I speak at industry groups about H.264, and detail the upcoming royalty obligation, some attendees are invariably surprised that using H.264 will generate royalties. Here’s what you need to know about H.264 and royalties, in an except from an article that I wrote for StreamingMedia.com [ed: full article here.]
…
When I spoke with Harkness, he stated that the patent group hadn’t yet decided the license provisions for internet broadcast, or even if there would be a license, though he conceded that it would make little sense for the patent group to forego this revenue. The only thing certain is that the royalty provisions must be announced by January 2010 for royalties that would be payable the following year.
OK. This paragraph hits all of the big points:
- Right now there aren’t any fees for “internet broadcast.”
- But there might be in the future
- The license changes from year to year.
Remember, this is still very early in H.264’s history so the licensing is very friendly, just like it used to be for MP3. The companies who own the IP in these large patent pools aren’t in this for the fun of it – this is what they do. They patent and they enforce and then enjoy the royalties. If they are in a position to charge more, they will. We can expect that if we allow H.264 to become a fundamental web technology that we’ll see license requirements get more onerous and more expensive over time, with little recourse.
Selective Enforcement
One reason why a lot of this isn’t known is because patents can be selectively enforced. And because it’s still early in H.264’s lifespan it’s extremely advantageous to lightly enforce the patents in the patent pool. MP3 and GIF both prove that if you allow liberal licensing early in a technology’s lifespan, network effects create much more value down the road when you can change licenses to capture value created by delivering images and data in those formats. Basically wait for everyone to start using it and then make everyone pay down the road. (Three words: unpredictable business costs.)
The other problem is that the Internet, because of it’s global nature, hides many of these costs. Everyone – and I mean everyone – uses tools from parts of the world where there are no software patents to transcode and edit videos. (One of the world’s largest free software downloads after Firefox? VLC. 111M last time I checked.) This grey area for tools means that these heavily patented formats gain much of the same advantage as free formats – lots of free tools and tons of ad-hoc support from free software people – but with the ability to still enforce and monetize in parts of the world where patents are enforced. It’s actually a brilliant strategy, even though the outcome is that the true costs of patents are hidden from the view of most people.
So What Now?
Remember that my setup for this was that Google’s choice was going to be H.264-only and that their decision would have network effects on the web, setting up another GIF-like situation for the web.
But I, like many others, have reason to believe that H.264 will not be Google’s final choice. There’s good reason to believe this: they are purchasing On2. On2 has technologies that are supposed to be better than H.264. If Google owns the rights to those technologies they are very likely to use them on their properties to promote them and are also likely to license them in a web-friendly (i.e. royalty-free) fashion. Google actually has a decent history of doing this. In particular you can get a sense of this from their post on The meaning of open:
If there are existing standards for handling user data, then we should adhere to them. If a standard doesn’t exist, we should work to create an open one that benefits the entire web, even if a closed standard appears to be better for us (remember — it’s not!). In the meantime we need to do whatever we can to make leaving Google as easy as possible. Google is not the Hotel California — you can check out any time you like and you CAN, in fact, leave!
In this case they were talking about user data, not video formats. But it’s the same set of principles at work. It’s also very hard to imagine Google licensing proprietary codecs as a revenue stream. It just doesn’t align with how they have worked in the past.
So it’s very likely that Google will be using a codec that’s superior to H.264 in terms of bandwidth usage and will also have web-friendly licensing attached to it. I know that at Mozilla we would support that and would very likely incorporate that technology into our browser, much like we did with Theora and Vorbis.
In Summary
So that’s the case for supporting free formats and also describes why we should be avoiding H.264 as a fundamental web standard. We don’t want to set ourselves up with another GIF situation and set up licensing like MP3 where we’ll be dealing with increased costs and restrictions over time. Google is likely to support something other than H.264 on Youtube and we’re likely to end up with something that’s better on a royalty-free basis as a result. And as I mention below, Theora and Vorbis are still excellent alternatives even if they for some reason don’t do as we expect.
Mozilla and Firefox continue to stand with the web on this topic. We don’t think that fundamental web technologies should be encumbered with patents and our actions and messages reflect that. We hope that you will stand with us on this.
A Note About Theora and Vorbis
Many of you might notice that I haven’t talked much about Theora or Vorbis. In fact some of you might read this post as me throwing them under the bus. That couldn’t be further from the truth. What I’ve really been talking about is one part of a larger ecosystem. What the web is really asking for is a codec that is implemented everywhere, that competes well on quality and doesn’t come with GIF-like surprises. Theora and Vorbis fit every part of this bill. You can actually use them on all of the desktop browsers, either via native support or via a Java plugin that actually works pretty well.
On the quality side what we’ve been able to do at Mozilla, with the help of the rest of the Xiph community, is to show that even though Theora is based on older, royalty-free technology, most people can’t really tell the difference between a video encoded with a decent Theora encoder and a video encoded with H.264.
But given the situation with submarine patents it would actually be a good idea for us to have more than one royalty-free codec available for browser vendors, site owners and content publishers. That way if one of them turns out to have issues, you just turn one of them off and continue to use the other one That’s why I think that if Google did offer a new codec that it would make a wonderful addition to the list of codecs we could use on the web. And if they want to use it on Youtube and other Google sites, that’s great. But it’s good to have other options in the wings.
So this means that Theora and Vorbis aren’t going anywhere. There are other reasons to continue to support (and promote!) Theora and Vorbis as well:
- There’s a growing corpus of Theora content on sites like the Internet Archive, Wordpress and Dailymotion, not to mention all the private sites that are out there starting to use it.
- Vorbis is far better quality than MP3 for the same bandwidth and I would expect that Google would use it as the audio codec of choice to match a free video codec.
- Vorbis is actually supported in a large number of hardware devices, often quietly. My phone supports it, for example.
- Theora with Ogg as a container actually is a fantastic live streaming format for HTTP. This is often overlooked. While Apple has had to add a bunch of code and description files trying to get live streaming to work with their proprietary H.264 codec and MPEG containers, we’ve been doing live streaming over HTTP out of the box ever since Theora and Ogg were part of the browser without any changes to standards. This is largely a function of history. Vorbis and Ogg were originally built as a radio streaming format. It’s possible to jump into the middle of a stream and start decoding. (As a side note it will be interesting to see if Google ends up trying to build their own container format. Ogg is simple, and it works.)
So I wouldn’t expect these formats to go anywhere. Instead I would expect to see them implemented everywhere either as backups or to support existing content and streaming.
-
In regard to the royalties for free-to-view Internet streaming and VOD (as opposed to the codecs at either end), MPEG-LA have announce it is to remain free of charge for another 6? years:
http://www.mpegla.com/main/Pages/Media.aspx
That doesn’t address the issues with codec licensing, of course, but it does remove one of the brakes that might have slowed adoption.
-
Two things I see here from this announcement.
First, Mozilla and the folks pushing Theora are going to look like they’ve been crying wolf. A central argument since the push for Theora is “Wait til 2011! Wait til 2011! The prices will skyrocket and you’ll be sued!” Now what? No price increase. Distributors carry on as is, and, as far as a consumer sees, they can still go download Silverlight or Flash for free and have H.264 playback anyway.
Now, that’s obviously a bad thing for the web if H.264 has 6 more years to settle in and then MPEG-LA decides to start charging. But, it also gives people time to *properly* develop a more open codec. Instead of pushing an obsolete codec where the best argument in terms of quality is “Well, it’s good enough for YouTube,” investment can be put into hardware support and improving quality above H.264 in… something. I don’t think it’s Theora. But it won’t be until that point that an open codec is going to get industry backing. Mozilla is dead wrong to try to argue on behalf of video distributors for a codec that they don’t even want to use (folks in the professinal video industry have already factored in the costs of licensing). What’s more, Mozilla is too small and doesn’t have the clout to argue on behalf of an industry that it’s not even in. Google maybe. Apple maybe. Both have expressed a desire to support HTML5 and standards.
In the meantime, until there actually *is* somethign worth using, why doesn’t Mozilla support H.264 AND Theora to give people the choice between the two? If people want high quality and hardware support, use H.264. If you’re obsessed with software freedom primarily, use Theora. The market will decide which is supported more until something better comes along. Or, if you don’t support H.264, just put that 5 million annual licensing fee towards Dirac, hardware support, or start trying to buy up some of the patents surrounding video to open up.
-
Kenneth: You mostly missed what the royalty announcement was about. They’ve chosen not to enforce royalties on *the encoded streams*, ie, a *new* royalty. Royalties for everything else are still in effect. In short ‘for now, we won’t be raising prices and tripple-dipping’. They’ve announced that they’ve graciously chosen not to commit gory public suicide partly because it would put the entire industry out of business instantly, and that’s not good for revenues.
So… What are we supposed to be excited about? This doesn’t undermine anything that Mozilla has been saying. All this means is that in the next six years they won’t be demanding every web browser not only pay for the right to ship the software, but also include a new slot where you put in a quarter to go straight to MPEG for every video you view. Oh, and they’re still allowed to change their minds if they think they’re not making enough. Work once, paid forever.
-
Just to confirm what Kenneth says about the professional video industry… We have an interest in Web streaming but our main products are video servers delivering VOD in hotels etc. – this market traditionally used MPEG-2 (and paid MPEG-LA for that), and is now in the process of completely shifting to H.264 (and accepts paying MPEG-LA likewise). The clients are sub-$100 set-top boxes and can seamlessly decode 15Mb/sec 1080p. Nothing without hardware support flies in that business.
Because of this, and the ever-increasing convergence of the “3 screens”, content owners are going to favour a single codec to save encoding and storage costs and gain economies of scale by combining technologies (e.g. one video server for all three). Quite apart from the fact that H.264is just a better codec, particularly for the higher resolutions we’re moving into.
I do see the ethical problem Mozilla has here, but I suspect the forces now arrayed in favour of H.264 (and against Flash and Theora) are probably now too hard to resist. My suggestion would be to support Theora natively and allow access to H.264 codecs in the platform, giving users the choice that Kenneth suggests. Given the open source nature of the beast, can Mozilla even prevent that happening if they wanted to?
-
Paul: right… but your point has nothing to do with the web. No one ever said h264 was ‘evil’ or shouldn’t be used. Also no one ever said that it shouldn’t be used on the web. What we’ve said and always said is that it can’t and shouldn’t ever be the mandated (or defacto) baseline. It would be the only part of the baseline that would have royalties and encumberence associated with even the most minimal possible support. The. Only. Part. Massive fail awaits that route.
As for the chicken/egg problem of hardware support, several big commercial groups are already scrambling to get over it, partly because full Theora support in hardware is so much simpler than full h264 support. It’s a tiny fraction of the complexity. You practically get that many transistors for free in the today’s average cardboard cereal box. Can’t say more– NDAs. But that’s OK, it will be reality or not soon enough.
-
Does anyone have any more information about the status of On2’s codec work since their purchase by Google — or is that a state secret?
It’s been nearly six months.
Some coverage on the web, such as this…
…is quite dismissive, but other commentary makes an open-sourced On2 (VP something) codec from Google sound like the most likely stalemate breaker.
-
I have a different take on this as regards Html 5 video. First, I don’t believe it’s the business of any standards body or browser maker to specify or limit what video codec should be used. Granted the Html 5 video recommendations don’t mention a codec and that’s great. But Firefox is taking an unusual stand in all this.
Html 5 is more than just video and I think people are getting the wrong impression about Html 5 because all they see/hear is video, which is too bad, because it’s the least important part of Html 5.
Html 5 video – what’ so great about it? As a publisher I can tell you what I see looming over our heads. Since the video player is not the same in every browser you can expect different performance by different browsers/players on different operating systems. For example videos that play fine on MAC Safari (in their Html 5 video player) don’t work the same on PC Safari. The same video played in Chrome behaves differently and of course Firefox not at all. So we’re making a lot of progress?
What Flash gives us is an abstraction from all this. We are assured that if a video played in a certain browser and OS, it would play perfectly on any browser and OS (at least the platforms we care about).
The inconsistency in performance between browser players and the lack of support of H.264 by Firefox is a huge nightmare for us. Already we have 4 versions for every video uploaded (to suit different bandwidths and devices) and are planning a total of 6-7. Now, not only will we require double that number (because of Ogg-Theora) for each video uploaded but we’ll have to deal with the inconsistencies across browser players to boot.
Given a choice between all the extra encoding, disk space and inconsistencies in video quality (between H.264 and Theora) and the inconsistencies across browser players and the support nightmare that that will cause…
We’ve done extentive test between the various Html 5 video players and codecs. You can it here.
-
So what’s the next step for Mozilla and Theora? It’s clear that the current strategy has received so many setbacks that it doesn’t stand much hope of succeeding. The long uphill battle seems to have only gotten longer and more strewn with boulders.
Will Mozilla spend more money to lobby browser makers Apple and Microsoft to include Theora in their browsers? Will Mozilla lobby hardware makers to include Theora decoding on their chips? Will Mozilla move forward with both of these strategies using a codec like Dirac? Will Mozilla hold off for Google to (possibly) join the fight with VP7/8 and support them in the browser maker/hardware lobbying effort?
It seems like a given that consumers aren’t going to see the costs of H.264 until 2016. OSS advocates have until that time to come up with something not only competitive with H.264, but competitive with H.264’s successor(s).
I really support the idea of open codecs, very much. But, with all respect to the Xiph developers, I need something at the absolute peak of quality and public support (to ensure that, practically speaking, it’s still around) if I’m going to entrust my personal video to it for the next several decades.
-
Shiv,
It’s very early in the game, but Mozilla is trying to help solve the very thing that annoys you. One video codec to always work anywhere any platform any browser. For one thing, Flash doesn’t work here but Firefox does (There’s more of us 64 bit Linux folks than there are Macs! :-) Apple is trying harder to kill flash than Mozilla and are really the only browser vendor pushing h264 right now. For as long as this is all fragmented, all video pages will be like your comparison page with several paragraphs of ‘what you need to install depending on your platform before you begin’.
That said, the comparison page is really nice. The Ogg looks a ton better than the h264 version, which is also nice to see! One thing I couldn’t help but notice: the Theora stream is actually 2,800 kbps, considerably less than the 4,000kbps of the h264 example. And it’s still obviously better looking. *sweet*. [But I suspect this actually means your h264 encoder is just low quality or possibly broken; this clip should have been a total piece of cake for both h264 and Theora.]
Kenneth:
“It’s clear that the current strategy has received so many setbacks that it doesn’t stand much hope of succeeding.”
Huh? Chrome, Firefox, Opera support Theora. The Silverlight support announced last week mostly adds IE to that list [managed plugin, thus clickless installation. very clever of Microsoft in an indirect way-- it allows them to embrace the Ogg from a distance].
The lone holdout then is Apple/Safari, and we at least have a workaround for Apple’s politics (Apple is an MPEG member after all) with XiphQT. Looks like the Open forces are winning from here. So only the Macheads suffer while Jobs rants about his prized ‘user [lack of] experience’.
No one knows what Google is going to do. They’re as good at avoiding leaks as Apple wishes it was. We’ll probably have no inkling until it’s announced. If Google does announce an open VP7/8, I don’t see how it could be anything other than good news in the long term. We’ll just have to wait and see.
It does hint pretty strongly that Google’s not as bullish on h264 as it might seem from YouTube of right-this-minute. They may see h264 as nothing more than a stopgap; after all, they keep all the original video submissions and can transcode the whole lot to a new format en-masse on a whim. They also completely control a mobile platform and control what appears in hardware support on that platform. This feels like vertical integration in a formative stage, and giving a huge chunk of that revenue away to MPEG is something that just isn’t going to happen. They have no reason to do it, so why would they?
-
Right, but not that many people are actually *using* Theora. And, at least for my company, it’s an unacceptable use of space to have our videos transcoded in both Ogg and H.264 and, since we have to have everything in one format, H.264 wins the day since it can be piped through Flash. Not to mention that we have the requirement that our video also be able to stream to iPhone users.
Silverlight support is a major impressive thing, I’ll certainly grant you that. And Google’s development in the mobile space could well lead to better hardware support. But support outside of the browser space is sorely lacking. Specifically, set top boxes, professional video workflows and the like. It seems like there needs to be a related high quality, competitive file size lossless format in order to get professional support. I suppose that is Dirac, in the grand scheme.
I may well be admitting my ignorance by asking, but… any ideas on when the Theora encoder will achieve even greater quality/efficiency than 1.1 (perhaps, efficient HD), and/or Dirac support in Ogg?
-
Theora 1.1 was Thusnelda, Theora 1.2 (Ptalarbvorm) is well underway. The pace of improvement has actually picked up, which surprises me a bit. It will continue to work in all Theora decoders. I don’t think 1.2 has any tentative release date as yet.
As for internal workflows… none of these codecs make sense as intermediate interchange. They’re all last-mile delivery. And it’s obvious Theora has an uphill battle and small userbase today. I am surprised at how quickly it seems to be picking up though. Much more rapid than Vorbis uptake was back in the day (it better be).
Dirac is already in Ogg, though its development is being done by a group not part of Xiph. I can’t speak to its roadmap with as much certainty. It is a much newer codebase and behind Theora in maturity and usability as of right now. Dave Schleef thinks he has a good grip on the ‘go’ button now, we’ll probably see if that’s true or not shortly :-)
-
yup agreed
-
Ken Pardue’s position summarized:
“We need to stream to iPhones so we have to use the codec that (MPEG patent owner) Apple tells us to.”
I’m not saying that’s a “bad” thing, but it does kind of put a different spin on things when stated clearly and really underlines why Ken should be supporting Theora even if he needs to supply H.264 in the short term.
Note that supporting iPhones means you can’t even use the CABAC feature of H.264 which isn’t supported in the highly touted “widespread hardware support” you find in iPods and iPhones. If you wanted to use this feature you’d need two different encodes, one for older, smaller devices. This however is for Ken a total deal breaker (at least that’s what rules Theora out for him). Shame really, disk space prices are plummeting, patent fees are going up for the next 20 years.
-
Safari on the iphone is very limited video codec wise. It can’t play H.263, or MPEG-1 (with the exception of Layer 3 audio) or plenty of other video formats that have less of a patent thicket than H.264/MPEG-4. I wonder how well it plays video from Wikipedia with the Cortado java converter?
http://www.apple.com/iphone/how-to/index.html#help.song-video-or-other-items-wont-play
-
Well, it’s more than “I support iPhone because Apple tells me so.” The H.264 files are higher quality for a given bitrate, easier to provide one video as a fallback (sorry, but the Cortado Java applet isn’t an option), etc. Disk space prices are falling, but not falling fast enough for us, a very small company, to serve our 35GB of videos in two formats to a limited set of customers.
That said, I’ve already built a simple tool to take and display videos uploadedZ in Theora (or another codec) if we ever go that route. I can have our videos re-encoded and in place long before that 20-year frame for hiked up royalties. However, being philosophically “free” just isn’t as appealing of an argument for us, or our customers, yet. There’s more to cost than moneytary value.
But yeah, I’d gladly and enthusiastically switch to a codec given that it met our needs and could be easily served to our customers regardless of their platform.
-
@Kenneth Pardue: Well, it’s more than “I support iPhone because Apple tells me so.” The H.264 files are higher quality for a given bitrate
For small-screen video — e.g., on the iPhone — that simply isn’t true. As many tests have shown, Theora is better than H.264 in that use. H.264 is better at full HD, sure.
-
“Theora predates these patents and could not infringe.” What is the publication date for Theora? Based on this, http://lists.xiph.org/pipermail/theora-dev/2004-June/001112.html the publication date is June 2004, which is after the filing date on the 6,950,469 patent.
(Posted here because the other article does not allow comments.)
-
Pingback from Software Freedom | BitBot Software on February 24, 2010 at 6:13 am
-
Pingback from efliv.com - Canvasing Social Games on February 28, 2010 at 12:56 pm
-
@Joshua Cogliati you have to look at when VP3 came into existence (May 2000) which does predate the patent
‹ Previous · 1 · 2 · 3
Become a Friend of Gnome!
Watch as I Grow
interesting stuff
- Streaming Media - Ogg, MPEG LA, and Submarine Patents March 9, 2010
- Opera Core Concerns - Everything you need to know about HTML5 video and audio March 4, 2010
- PdaNet -- USB Tether/Bluetooth DUN for Android March 2, 2010
- html5media - Project Hosting on Google Code March 1, 2010
- OGMRip - Welcome to the OGMRip website February 26, 2010
137 comments
Comments feed for this article
Trackback link: http://www.0xdeadbeef.com/weblog/2010/01/html5-video-and-h-264-what-history-tells-us-and-why-were-standing-with-the-web/trackback/