Are they pretty much teh same as software patents?
Back in 2010, champions of a free web were ecstatic over Google's plan to seed the internet with a patent-free video. VP8 was going to crush the patent-heavy H.264, now celebrating its 10th birthday. Or so we were told. In May of 2010, Google open-sourced VP8, the video compression codec component to the audio-visual WebM format …
Are they pretty much teh same as software patents?
Yes, and thus should never have been granted. Codecs especially are just maths! Even more so than something like Word.
What's the difference between a patent on a physical process and one on a software process, other than the medium?
What's the difference between a patent on a physical process and one on a software process, other than the medium?
A physical process requires the invention of physical devices to solve a physical problem.
A software process is solved using math.
The difference is actually made in patent law in most countries.
Most patent laws explicitly exclude patenting mathematical equations (though not necessarily their application). Because any algorithm can be expressed in lambda calculus, it could be (and has been) argued that algorithms should not be patentable. Their application (as e.g. as codec) could be under various laws.
So, as Mr. Slant would say: "This is an interesting case."
With degree of interest being defined as proportional to the amount of money it brings to lawyers.
"What's the difference between a patent on a physical process and one on a software process, other than the medium?"
The difference is crucial. A hardware implementation covers just that implementation (with some wiggle room). But in software that function is achieved by copyright on the source. Software which is running somewhere is converted into a specific implementation by the compiler. So, to make a software patent work (ie, to be more than copyright) ALL those implementations of the software's function have to be covered and in doing so one inevitably has to grant the right to any implementation anywhere using any method - because the method the compiler actually chooses may not bear a close relation to that expressed in the source code.
This is much, much broader than hardware patents and in fact amounts to patenting an idea regardless of how someone somewhere goes about making that idea a reality.
If you want a good example of how physical patents should work, James Pickard patented a crank in 1780 as a mechanism for converting linear motion to rotary motion - ie for using a piston to turn a wheel (so allowing steam engines to drive many more types of machine).
Because it was a physical patent, it was only on that particular technique for converting linear motion to rotary, so when Pickard refused to license it to Watt, Watt used a sun-and-planet mechanism instead, which was not under the patent.
If it had been a software patent, it would have been "method for converting linear motion to rotary motion" and picking a different method would not have been enough.
... the point is that if you do a clean-room implementation and you don't come up with the same approach, then a patent shouldn't stop you. But software patents do.
Watt knew a thing about patents himself - he patented everything he could, including the sun-and-planet gear. He was the model for the modern patent-driven industry - using expensive litigation to drive rivals out of business, even paying 'spies' to take assistant positions with rival manufacturers so they could check for any Watt-patented technology being used secretly. He maintained strict secrecy at his own workshop, fearful that others may steal his ideas, and refrained from publishing anything patentable until the patent was granted.
Pickard actually wanted to cross-license: He'd let Watt use his crank design, in return for Watt permitting him to use Watt's patent on the external condenser. Watt refused: The crank was a small thing, the condenser a revolutionary advance, so he considered this an unfair exchange and set to work finding an alternative to the crank instead.
There's a common view among historians that Watt's patents held back advancement for some years: He refused to conduct any research on high-pressure steam as he believed it to be too dangerous (Early high-pressure engines had a tendency to explode), but he also refused to license his essential patents to any company that was willing to conduct this highly dangerous research for fear they might be able to perfect the technology (after killing a few apprentice engineers) and so create an engine more compact and efficient than his own. It was only after Watt's patents started to expire - most importantly the external condenser patent - that others were able to start experimenting with the high-pressure steam that would make rail travel practical.
If you do a cleanroom implementation, and come up with the same idea, a patent should stop you. The whole point of a patent is that it's a monopoly right. Infringement does not require copying.
It's always been possible to get a patent on a method.. It's actually quite hard to draw a clear line to exclude software, considering that in our modern world, most inventions are likely to at least involve software.
I don't think it was so much MPEG-LA's presence that allowed H.264 to win but more the idea that Google was simply late to the party. By the time VP8 came out, h.264 support was baked into too much hardware for Google to shake the tree. It's hard to beat H.264 when phone, vidcam, and other small hardware makers use chips with the codec baked in. This time, however, Google has a chance to disrupt H.265 before it can gain momentum: with VP9. Consider why MPEG-LA couldn't get a patent pool for VP8 rolling. While there are patents for them, Google probably owns the key ones since they got them along with On2. And Google's a big enough company that they would be willing to (1) take the fight to court and (2) challenge MPEG-LA's patents with its own, starting a patent war. And since Google isn't using the patents as a way to make money, any patent nullification would be neutral to Google if not beneficial (if an MPEG-LA patent is nullified).
Broadcom already has H.265 silicon in production. Where can I buy Google chips?
I think you should go read the article again and see in which camp the hardware makers sit. Then you can answer yourself.
Yes, and recall that Google was getting nVidia (who has their own SoCs—the Tegra line) among others in their ear. with VP8. It only fell through because, like I said, H.264 was already ubiquitous. Broadcom may be churning out H.265 chips (IIRC they're part of MPEG-LA). I will admit that Apple would be behind H.265 and can roll their own SoCs, and its iPhones still have weight, but there are plenty of others. What if Google counters Broadcom by getting other chip makers to bake VP9 into THEIR chips? We've heard little from Qualcomm (makes the Snapdragon line). Same with nVidia and the Tegras. Then there are the Chinese: wildcards in this fight. Patents I think would mean less to them than ubiquity.
Google bought a hardware codec outfit from finland and have been giving hardware "source code" for encoders and decoders to manufacturers for free for a long time now. Basically all the big names in hardware are involved, including broadcom. And since Android is the big thing they want to support Google's got a fairly big carrot to weild:
That's all for VP8, since VP9 hasn't been finalised yet, but they've made several changes to the proposed VP9 spec "at the request of our hardware partners" so it looks like it's all go for the next round.
The thing that you--and the article author--is missing is that H.264 succeess was not due to ubiquitousness on the Web, but to its pervasive use throughout the entire content industry, including consumer media-delivery electronics.
This is the reason why VP9 will also fail against H.265: as long as Google keeps on directing its efforts at the "Web delivery" side, they will miss the introduction and proliferation of H.265 throughout the content creation pipeline. This includes direct hardware support for the codec on every aspect of production, such as cameras, film-editing devices, etc. Why would anybody even consider re-encoding their product for the Web when the major and popular browsers already support the native encoding of your content?
That has happened many times before. The JPEG format became popular on the Web because it was a standard for digital photography that existed prior to its inclusion on web pages. It was only natural to include support for it in web browsers and enable a myriad images at once, rather than force everyone to re-process all their photos just to put them up on a web page.
As long as content is produced off-Web first, non-Web-specific codecs will permeate the industy and the Web will have to adapt to support them. Enterprises like Apple and Microsoft understand this. This is why QuickTime and AVI were always intended to be content industry standards, not plain PC codecs. Google's VP9 is not being proposed as a new standard for the film industry as a whole, but as a Web media solution. As such, it'll remain a niche player, if it remains at all.
@Charles 9. Agreed. Employ game theory on this one and it is clear why the market moved as it did. The point is codec support doesn't need to be exclusive. You can support multiple codecs on a single device. However iOS devices were built to support H.264 in hardware and discourage use of anything other than hardware based video decoding. This was one of the key technology standards battlegrounds and saw it as essential to the iOS experience. Apple were much more on a knife edge on this one than many people realise and it could be argued widespread H.264 support was essential to the success of iOS as a platform.
I'm sure Steve Jobs understood this and I believe it was one of the key, for the most part under the radar, tactical battles Apple was engaged in from 2007 onwards. It is IMO a less publicised, but potentially more important reason why Apple were so down on Flash than the oft quoted headline reason of security. Flash had of course became, over time, mainly used as a means to ensure cross platform video decoding on PC's. But on PC's you don't care if decoding is being done in software and a lot of power is used doing it. Flash, if it were supported by Apple devices, could, of course, have supported hardware decoding of H.264video as well, but then users would also have expected it to work with all the video codecs it works with on a PC. That would have meant the user would never have been aware if a video was software decoded and draining the battery 5 times faster than the same video encoded as H.264 would have done.
Google I think also understood this and I believe, conveniently consonant with the policy of supporting open standards, they saw WebM was as a means to split the market and, potentially, leave Apple stranded on an Island with many websites not support the only video codec iOS devices properly support (you have apps which offer software decoding of video, but the experience isn't integrated with the Core OS). There can be little doubt if H.264 hadn't stuck it would have been very damaging to Apple.
In the end, as Web-M was late to the party, the market only really had a choice between A) support H.264 and provide for every important device in terms of market share, or B) support both Web-M and H.264 and provide for every possible device. There was no real option C) to provide for Web-M only because, in the event, given the success of iOS (and the resolute stance against Flash), even if it wasn't the majority of the market, it was clearly becoming a significant high value chunk of the market.
Given the choices A) and B) most content providers then reasoned they only really needed to support A). I mean if you think about YouTube and the sheer quantity of video stored there, imagine the cost now for Google of maintaining Web-M encoded versions of the video (especially given only a tiny fraction of what is stored is actually viewed more than a few times). They surely must have implemented dynamic transcoding of video from H.264 to WebM at the time a device requests it and the vast majority of video must surely be stored H.264 encoded. I would like to know if they have publicly admitted what the ratio of stored video formats are. I think it likely they would decline to answer that question, but perhaps someone on here knows.
at Google IO this year there were a couple of - very impressive - VP9 demos. The advances in the codec (the math and the application of math) were, in the demos at least, quite significant and compared to where H.265 is today it was easy for them to make some bold statements... but when pressed on silicon adoption for mobile chipsets (for instance) the vague hand-waving began (my favorite was "it shouldn't be needed because the codec is so much more efficient") but the upshot was that no-one has committed to hardware decode in a SoC package yet... and while I'm not aware of an H.265 implementation in a SoC yet yet you have to assume given the track record of H.264 if a silicon vendor was going to take a bet on two fairly similar technologies they're going to make their initial focus the MPEG-LA aligned one ... and to be honest, as a content provider I'd prefer to see one clear winner (just as I'd like to see MPEG-DASH tidy up this mess of adaptive bitrate solutions)
What DZ-Jays said...
In short, it's got nothing to do with the web or mobile. H.264 was never in any danger from VP8 (WebM is a wrapper for VP8) because it is the standard at point of creation from consumer device right up to pro. Apple know this and it is why it was never a concern for them or Microsoft. It's why Final Cut Pro X is a potential disaster for Apple (interest has increased in it again of late). If the F/LOSS movement and/or Google wish to change the landscape on the web, they must be looking to change the way content is created. There is more to world than the web...
That's part of the ubiquity that gave H.264 the crown previously (and this ubiquity was spurred by the support of H.264 in the current-generatiobn optical discs). However, for H.265, no such consumer hardware exists yet, so Google still has a chance to get its foot in the door. As for the professionals, IIRC, they don't encode until they have to, to maximize the quality of their sources. And since they tend to use server farms to do the encoding, that encoding is likely done in software, which can change gears pretty easily.
Even if it means paying the royalties to MPEG-LA? Google offers VP9 with no royalties, and when the quantities rise, so does the cost in royalties. AND Google has the muscle to support the VP codecs in court (note how MPEG-LA couldn't take Google to court over VP8).
@SimB Very true, re use of H.264 throughout the industry and I'm well aware of the content production and delivery pipeline technologies (my job is directing Digital TV integration projects). I'm not sure what you are saying contradicts anything I have written however. There are plenty of examples of predominant pro formats differing from consumer formats. MP3 being one.
The risk for Apple remained that WebM would gain traction and would be used for the Web, especially if MPEG LA imposed onerous license terms, which they were all set to do if it wasn't for the need to stave off the threat from Web-M - so Google did the industry a favour in that regard.
It's interesting that if you buy a consumer video camera, still to this day (or at least the last time I checked which was about 2 years ago) use of the technology for business will be forbidden by the license terms and that is because use of H.264 is cost free only for consumer use. Of course this is totally f**king stupid and the chance of me getting sued for using my (now ageing) consumer Cannon HF100 is slim at best. However in theory, if not in any practical reality, were I to use it for business (which was it's original intended use), MPEG LA could come after me for license fees.
The Chinese tried to counter H.264 (AVC) licensing with their own "AVS", which was basically a clone (what a surprise), and it fell on its arse. Earlier, Microsoft had tried the same thing with their own "VC-1" (also almost a clone) which fell on its arse. VP8 did too, as the article says. I therefore predict that VC-2, AVS2 and VP9 will all fall on their arses.
Looks like the way forward is HEVC-DASH for mobile and thus for everything else.
Actually Microsoft succeeded with VC1 - it is part of the Blu Ray standard. And H.264 is largely a clone of that technology - hence why Microsoft are in the patent pool for H264....
Two big bullies trump one big bully.
..."shot across the bowl"? Better than one across the bowel I guess...
Saw that too, eh?
Sorry, but it was the only thing I could make sense of in this whole article.
A perfectly predictable result.
If Google had been Microsoft, then when they acquired YouTube they would have started dropping support for H.264 in favour of WebM - not across the board, but selectively, gently and quietly, until enough of the clients it didn't control implemented WebM well enough. Then they could just drop H.264 completely since virtually everything that could view YouTube could use WebM to do so.
Unfortunately they were too concerned with scraping the pennies from every last corner under the sofa by giving consumers what was convenient for them at the time, and dropped the ball.
"too concerned with scraping the pennies"
I like how Google can't win with you no matter what they do. From my perspective they went with what was best for the user - something they are embarrassingly good at on a lot of fronts. I'm not too sure you managed to argue that that's a bad way to do business.
@Andy Fletcher: I think you're missing the point made by grammarpolice. The way I read it is that if Google had been more underhand in breaking the grip of H.264 and worried less about marginal current income then we would have had a better chance of video content not being encumbered with patented codecs, i.e. "best for the user."
There are no good guys and bad guys when it comes to major corporations, rather the interests of certain coportations occasionally coalesce around something good for the majority of users and on those occasions we should put our weight behind them.
April 2010: Steve Jobs threatened that a patent pool was going after Ogg Theora.
May 2010: MPEG-LA threatened that a patent pool was going after WebM.
~8 months of nothing
Feb 2011: MPEG-LA asked (pleaded?) companies to contribute to their WebM patent pool.
~2 years of nothing
March 2013: Google signs agreement.
That's a whole lot of silence from MPEG-LA, which leads me to suspect that they had trouble finding companies willing or able to contribute patents. Perhaps they'd finally found some, or perhaps Google just gave them some cash to stop FUDdying the waters.
And if H.264 has "won", and H.265 "should be propelled to a rapid takeover", why would Google bother to make a deal with MPEG-LA? Perhaps, just perhaps, the future is not set in stone.
Regardless of the MPEG-LA license, Nokia have refused to license their technology in the VP codecs, so VP8/9 are as dead as a DoDo....
Google's action kept free to use so job well done to stop Microsoft and Apple using MPEG LA to keep out the competition.
And seeing as how Google is working on VP9 it hardly looks like they've given up. H264 may have won this round but where is H265? Google now has both YouTube and Android to encourage the adoption of VP9.
" Google now has both YouTube and Android to encourage the adoption of VP9."
Google had them 3 years ago for the H.264 vs VP8 show down. It chose not to use its position. If anything the H.264 accelerators in all those android phones and tablets probably makes it harder to move away.
As you say, H264 in hardware was what tipped the scales then.
As the resolution of phones continues to increase the need for more efficient codecs increases as well. As long as H265 isn't widely available in hardware there is a chance for alternative. What succeeds will be down to the availability of silicon and licensing terms. It's perfectly possible that Google will continue to use VP9 to ensure favourable licensing conditions rather than say providing a reference implementation via Motorola: going head to head against Broadcom might not worry them too much but Qualcomm would be a different matter.
As YouTube's business model depends on the fastest performance possible I think we can expect Google to try everything that works. It already has an excellent basis for delivering the optimum performance to each device and has started flexing its muscles against Microsoft in how YouTube's content can be consumed.
All Digital Broadcast is MPEG2 and much HD is MPEG4. Some countries use only MPEG4 even for SD. TVs, PVRs, Setboxes can't use SW codecs economically. They use dedicated HW. Hence TVs, Setboxes etc with MPEG2 only can't upgrade via Firmware to MPEG4 and boxes & TVs that do MPEG4 & MPEG2 and HD can't have VP8 added by Firmware.
BD players use HW based codecs too, MPEG2 (for DVDs) and MPEG4
The "Appliance", tablet, phone and gadget markets dwarf PC/Laptops. ARM based gadgets use SoC HW in the ARM CPU for Codec and Graphics. No SW/Firmware codecs. So VP8 was dooomed from the start due to only being used for Internet and lack of built in HW support.
2K HD Broadcast will use H.265
This was not decided by the "Internet" or MPEG LA, but Gadget, Chipmakers and Broadcasters.
Something to keep in mind in all those "Privacy is dead, yadda yadda" doomsayers.
Does anyone doubt a Google codec would come with built in reporting back to the Chocolate factory?
Thumbs up not for software patents but for co-operation and not reaching for the lawyers, as several of MPEG LA's members have done.
BTW Did anyone else think the LA was just a reference to them being based in LA?
Why? Why do you doubt? Why wouldn't Google further extend their information harvest to the codec level, if given the chance?
You can download the source yourself from e.g. here: http://packages.debian.org/source/wheezy/libvpx
and then study it yourself to see if there is any function "report_back_to_the_Chocolate_factory_heehee()".
What exactly is your complaint?
Feel that Google has been mis-treated? It's a $50Bn/year company.
Locks in patents? Well has anyone asked you personally for a contribution?
Can't post/download stuff on Youtube because it's copyright and the holder keeps issuing DCMA notices? What's BitTorrent mostly used for?
Just to be clear I believe software patents are (and let me make this extra clear for the slow ones out there) STUPID. I'd prefer they did not exist at all.
However I don't trust Google one bit. They're in it for the bucks and they don't take prisoners. this seems a slightly better use for S/W patents than most tit for tat suing that has gone on.
I do believe people who do creative things should be fairly and directly rewarded. but 70's years on creative works because Disney wanted to protect The Rat (not TM) is just taking the p**s.
So please, what is your problem?
I know I should have something more substantial to contribute other than disappointment, but every time I see "MPEG LA" I think of a giant mechanical owl.
"My mind is sharper, my intellect superior. You won't be making any videos without paying me, raccoon."
Can you imagine the tantrum Microsoft would have started had they done that. They would have gone crying to every single government, complaining that nasty Google were using their leverage to push a free and open codec over their closed stuff...
And the governments would have listened. Because business money is at risk.
Barry, you do know that MS is only a small part of MPEG-LA.
And the thing with this "free" stuff, people are to fucking dumb to see the big picture. Let's take you ideal world.
Say you are a company selling sat-nav. google come along, give away free ones and kill of the sat-nav makers.
They come along and push free desktop OS's, they kill of the paid for software companies.
They come along and give free mobile clients and kill off paid for ones.
They come along and give free office suites and kill off paid for ones.
What a wonder utopia?
But wait, then they can push ads as much as they want...they can "upgrade" the free products to paid for one....
and what's to stop them? There is no one to stop them, they own the entire markets. Congrats you replaced several dominant players with a single one.
Always be careful what you wish for.
And a serious question. Why can a company in the software world give stuff away to break the competition, yet if the likes of Tesco's decided to sell everything at cost price ro lower for a year, the country would be up in arms!
Quotes from the article:
"MPEG LA doesn't create technology standards like MPEG 2 or H.264, but it does charge for them."
"MPEG LA is not a standards body, so it does not create specifications."
"MPEG LA is owned by 10 companies including Cisco, Sony, General Electric and Google..."
"LA stands for license authority"
"The group was formed in 1997 by eight companies that wanted to turn the then-new MPEG 2 standard into a viable business by charging others to use it."
Net result: the lawyers (rather than engineers or inventors) within these big companies are the ones benefiting,. The consumer ends up paying for using "standards".
And what gov reg is made for. No lawyers. No ever moving goals and feature creep. No argument about who owns what. Just processes that work.
And it doesn't preclude R&D nor presenting whatever the next advancement is.
it'll all be over in a few years and we'll be able to use cranks to convert linear to rotary motion as and when we please. remember gifs?
and make a few VP8/VP9 chips and let them loose in a phone or other device then I can see the standards gaining leverage very quickly.