The Ambiguity of "Open" and VP8 Vs. H.264
An anonymous reader writes "With all the talk about WebM and H.264, how the move might be a step backwards for openness, and Google's intention to add 'plugins' for IE9 and Safari to support WebM, this article attempts to clear misconceptions about the VP8 and H.264 codecs and how browsers render video. Firefox, Opera and Google rely on their own media frameworks to decode video, whereas IE9 and Safari will hand over video processing to the operating system (Windows Media Player or QuickTime), the need for the web to establish a baseline codec for encoding videos, and how the Flash player is proprietary, but implementation and usage remain royalty free."
Please make it easier to report/flag spammer accounts. That is all.
vos nescitis quicquam, nec cogitatis quia expedit nobis ut unus moriatur homo pro populo et non tota gens pereat.
H.264s development was open? I mean really that is just a bit of a reach.
So I disagree with everything in this but one thing.
The correct way to implement video is to used the OS provided framework. Support EVERYTHING the OS can support as far as formats goes. It really is the the correct and most flexible way to do things. While I support the idea of WebM it will cause no end to problems if Apple, RIM, Nokia, and Palm/HP do not support it.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Doesn't matter what Google chooses to support in Chrome as they are still going to have to support H.264 for Youtube streaming unless they feel like making the battery life of all current and soon to be released Android phones abysmal when playing Youtube videos.
"Firefox, Opera and Chrome" Since it appears that sentence was directed at browsers.
HTC EVO 4G LTE w/ CM 10.2 | NookColor w/ CM 10.2 | Samsung Epic 4G w/ CM 10.1
This seems more like an attempt to introduce ambiguity, than to clear it up. The definitions of open and closed in this situation are clear, and pretending that the browser codec situation is particularly confusing is mostly FUD. H.264 is closed. VP8 is open.
You may disagree with the stances of the browser makers (I think all media playback should be handed off to the parent os)... but the definitions of the terms are clear.
The only thing that concerns me about the web video format is that it needs to be unencumbered by royalties or other licensing. If I want to make a video, encode it, sell it, make ads off of a website, get 100 or 100,000 visitors, I should damn well be able to do that without having to pay a dime to anyone for the ability to make my own god damn videos--unless I optionally choose.
By using h.264, you pretty much guarantee that *someone* *somewhere* is paying for it. Could you imagine if say, the "David After Dentist" kid had to pay tons and tons of royalties to the MPAA for a video they created simply because they used the h.264 container format? To even conceive such a thing is such bullshit that this should absolutely be a non-issue.
Though this will never happen, the US government should claim eminent domain on all patents involving the h.264 technology, and then dare the large companies to make a move. After all, we're the ones with the guns.
Well I learned something new. Perhaps "liberated" would be a better term since the software, like Seamonkey, Songbird, OpenOffice.org, have been liberated from the clutches of single companies (i.e. Microsoft).
Google also has a WebP standard based on VP8, to replace GIFs/JPEGs, but it seems like it's reached a deadend. So WebM is the container.
--- VP8 is the video
--- Vorbis is the audio
Versus h.264:
--- MPEG4 AVC for video
--- plus some audio codec, like MP3 or AAC or HE-AAC
MPEG4/h264 vs. VP8 comparison (h264 slightly better - specially on low bitrate connections):
- http://compression.ru/video/codec_comparison/h264_2010/vp8_vs_h264.html
HE-AACplus vs. Vorbis (HE-AAC wins):
- http://listening-tests.hydrogenaudio.org/sebastian/mf-48-1/results.htm
JPEG vs. WebP (WebP wins):
- http://englishhard.com/2010/10/01/real-world-analysis-of-googles-webp-versus-jpg/
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
It's frustrating that only the OS-provided solutions (Safari and IE) are doing this right by handing it off to the OS. The notion that your browser needs to reimplement everything, including video rendering, is what leads to the bloatware we have today. The whole point of having an OS is to have a common framework and API layer that all applications hosted on it can access. Instead, Firefox, Chrome and Opera are all re-developing their own video rendering, for each platform they exist on, AND each one needs to write its own video-card accelerator layers for each platform it exists on.
I'm out of my mind right now, but feel free to leave a message.....
http://antimatter15.com.nyud.net/wp/2011/01/the-ambiguity-of-open-and-vp8-vs-h-264/
Open as in Goatse.
What does this one sentence mean?
"Firefox, Opera and Google rely on their own media frameworks to decode video, whereas IE9 and Safari will hand over video processing to the operating system (Windows Media Player or QuickTime), the need for the web to establish a baseline codec for encoding videos, and how the Flash player is proprietary, but implementation and usage remain royalty free"
in all respects.
.....
something that is 'reasonably open as per defined standard bodies' but, is subject to the ownership of any private party which can at any point end that state of openness at whim through their ownership of underlying patents, is NOT OPEN. it is a state of 'dubiously open' or 'haphazardly open', or 'illusory open', or 'open for now' or 'open depending on the whim of the patent owner'
open means open. and dont be mistaken and think that there is difference in between ownership and openness concepts - in the world of software, they are directly linked - today's open can be tomorrow's closed when you wake up.
Read radical news here
There are open standards, and open source, and they are not the same. The IETF, for example (subject to yesterdays Birthday Article) deals with open standards. Linux, by contrast, is open source.
An open standard means that no one party controls the generation of the standard, and that the standard is openly available. Generally, open standards are developed by SDOs (Standards Defining Organizations, such as the IETF or the W3C). As a general rule "anyone" can participate in their creation (but this may require that you or your company be a member of some organization or have some other qualifications). Many open standards have patent encumbrances. Typically, SDOs seek RAND (Reasonable and NonDiscriminatory) licensing terms; some even require a particular patent licensing policy as a condition for participation. The IETF, however, requires disclosure and seeks, but does not strictly require, RAND terms. While an open standard may have some code associated with it, typically the entire point of an open standard is to allow you to go off and write your own code, generally under whatever code license you want. This is how the Internet was developed.
Open source means that the source is licensed by GPL or BSD> or some similar licensing. Now, generally open source means that the code is available, but in practice many open source projects are more or less closed to outside participation, and they frequently do not provide documentation sufficient to replicate what they are doing.
The QtWebkit based browsers and KHTML also hands it off the OS (through Phonon and/or GStreamer).
So the Right Thing is to force everyone to buy an OS from Microsoft or Apple? Do you know there are some crazy people developing free operating systems? And even using them! How dare they ask for a royalty free baseline codec for encoding video for the web?
You're missing what the GP said - no-one's suggesting forcing anyone to buy an OS, the suggestion is to hand off video playback to the OS. In this case, the right thing to do would be to release it to a video decoding layer for Linux and then call it from Firefox/Chrome.
Cheers,
Ian
Spawning up some WMP or Quicktime in the browser sounds like fun..not.
So basically what you're saying is that having one supported format that web developers can rely on being supported, regardless of platform, is a bad thing?
For years Slashdot seems to have yearned for a wider adoption of Vorbis and Theora. Theora didn't quite cut it, so Google replaced it with VP8, and has thrown its weight (and its patent portfolio) behind Vorbis as well. But since it's Google, now Slashdot seems to support a royalty and patent encumbered h264 instead of pining for WebM (which is VP8 + Vorbis wrapped into a Matroska container) to win, for which there's a non-exclusive, perpetual, royalty free license on everything, including fucking _ASIC designs_. WTF people? Do you have no principles?
Thing is to force everyone to buy an OS from Microsoft or Apple
You really need to go back to school and learn how to read.
A good point here - Google has a lot of "green" initiatives (reduced-power computing, huge solar cell farms on their roof, etc.)
This approach is NOT a "green" approach - a "green" approach is one that makes use of the large amount of hardware acceleration infrastructure now deployed for the existing standard codecs.
WebM/VP8 will force a non-accelerated CPU-only rendering path on ALL existing hardware. This eats power compared to hardware acceleration. (Look at how well most Android devices handle H.264 thanks to hardware accelerated decoding.)
Google is being hypocritical and inconsistent here. Great summary at http://daringfireball.net/2011/01/simple_questions - Key here is, HTML5 was supposed to at least partially break Adobe's stranglehold on the web by moving some content away from Flash. Google just killed any hope of that - They talk about supporting open codecs, but they still bundle Adobe Flash (which includes H.264 support) with Chrome?
As a result of this mess, content providers are starting to shy away from HTML5 and stick with what "just works" (for the most part) - SmugMug was starting to consider HTML5, but Google's latest decision has them moving back to Flash.
retrorocket.o not found, launch anyway?
Are Apple/Microsoft doing the right thing because it's the "right thing", or because they fear an independent web browser with builtin Video support, might make their OSes obsolete? (i.e. Don't install either OS X or Windows- just install Seamonkey, or Opera, or a spinoff of those like Splashtop, and you're done. The browser does everything.)
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
Ah, but can't write such a thing and release it under the gpl... And that's my problem with adopting h.264 as the standard. We wouldn't be able to have general-purpose Free OS anymore ;)
exp(i*pi)+1=0
In this case, the right thing to do would be to release it to a video decoding layer for Linux
Which would end up supporting only MPEG-1, Theora, and VP8 given the patent policies of many GNU/Linux distributors. And for each operating system, how should the browser direct the user to find and install appropriate codecs? Do video decoding layers for Linux even support codecs installed by one user for that user as opposed to codecs installed by root for all users? Most of the tutorials I found were for .deb installation on Ubuntu, which is always system-wide.
Clearly, as I do not understand what are you talking about, could you please point it out? Bear with me, I'm still learning the English language.
exp(i*pi)+1=0
Three words: Cross Platform Uniformity
The user doesn't care that his OS is doing something stupid/wrong, he just wants the app to work. It's an inherent problem with cross platform anything, and the reason toolkits like Qt have to exist.
concept of ownership was challenged. mod to oblivion. dey comin for ya. hide your patents, hide yo codecz ...
Read radical news here
Ok I'll come clean I havent RTFA, but it strikes me weird that a 15 year old is going to grasp all sides commercial and technological nuances of a very complex issue.
Anyone else feel the same way?
Yeah I'd totally hit some of that hot piece of ass Apple is flaunting in Main road.
Oh wait I got confused. They are utilising an upgraded processor in their upcoming iPhone refresh.
This isn't really about desktop browsers. It's all about mobility. Not a coincidence that Google announced this right when Apple announced that iPhone was coming to Verizon (Android's biggest US sales generator).
Simply put, Safari in iOS doesn't allow plugins and relies on the HTML5 Video tag to play H.264 video (which is supported natively by frameworks in iOS and MacOS). Until Android 2.2, it was the same thing in Android. Now Android supports Flash, and Google also built their own special version of Flash into desktop Chrome. So this is pretty much just a naked attempt to kill the HTML5 video tag and by extension harm iOS and help Android.
On the desktop, Chrome exists mainly to keep Microsoft reasonably honest. On Android, it's everything. Google wants to do everything it can to blunt iOS and boost Android - and trying to break iOS's video experience may be a dirty trick but all's fair in OS wars. If it were just about boosting WebM then Google would start pushing WebM, helping with video acceleration efforts, helping to produce authoring tools, and such while not changing a thing about their already built H.264 support. But they are actively removing H.264 support from the browser.
Don't be evil, my ass. Apple may not be the paragon of Free Software that most Slashdot readers want them to be, but they are supporting a standards-based tag that uses a popular, documented video standard that is prevalent in multiple media forms and well-supported by browsers and tools.
When the Chromium dev build with H.264 support removed is pushed to my computer is when I remove Chrome from my computer. Microsoft and Apple are doing the right thing here for once - at least Firefox's stance is political in nature. Google's is just about trying to kill iPhones. When Apple changes the default search engine in iOS and Safari to Bing, this'll be why they did it.
-- Josh Turiel
"2. Do not eat iPod Shuffle."
Um, x264 is released under the GPL, and I've seen it included in recent Linux distributions.
Bottom line is the Microsoft/Apple alliance is trying to keep video proprietary and Google, the outsider, is saying "Screw it, we are backing an open alternative". Deal with it.
This approach is NOT a "green" approach - a "green" approach is one that makes use of the large amount of hardware acceleration infrastructure now deployed for the existing standard codecs.
For some reason this argument sounds eerily similar to "but think of the children!"
Do video decoding layers for Linux even support codecs installed by one user for that user as opposed to codecs installed by root for all users?
Why does it matter? It "just works".
When you install Ubuntu, you don't get AVC because it's patented. Instead, to watch an AVC video in Totem for the first time, you have to connect to the Internet,* open Software Center, authenticate with sudo privileges, install gstreamer-plugins-ugly, and then affirm that you don't live in a country with AVC patents. You have to have someone with sudo access present for this.
* Should be obvious, but there's actually a feature request for being able to queue up packages in Software Center for installation the next time Update Manager runs.
Why are you lying?
FFMPeg is GPL
x264 is also GPL
Do I need to go on and list a few more, or is two enough to snub your ignorance?
"His name was James Damore."
Maybe I'm ignorant. Maybe I'm just dumb. But I can't, for the life of me, understand why it is so difficult for Apple and Microsoft just to ship libtheora with their Operating Systems and stop bothering everbody. Seriously, it's licensed BSD for god-sakes. And as far as hardware decoding goes, most computers (By computers, I mean anything with a microprocessor in it. Your iPhone, your Desktop, your Laptop, and your Calculator.) have the processing power to handle Theora in software, if they are capable of using Flash already. Furthermore, if it is really that big of a deal, that a company needs a hardware decoder, the company that wants it the worst will pay to finish up the decoder project. This would mean that people would have to upgrade their devices, but can you really tell me that people who own iPhones don't upgrade them regularly to keep up with Apple's latest shiny new toy? Lastly, their is the argument of quality, but that has already proven to be crap. See here Theora may not be the fastest, but it's not really any worse or better than anything else we can use in terms of quality. As such, the only really difference is that H264 is closed and patented, and Theora isn't. And if we're are completely honest with ourselves, submarine patents are a non-issue. Remember, the patent system is so screwed up, that there is a patent on a stick. (Trust me, google it. It's there, in all it's patent glory.) So although patent trolls could cause problems, it's not like that's anything new and it would be dealt with, just like with the hardware decoding.
So, in conclusion, I don't know why people keep arguing. I didn't know it was that hard for a multi-billion dollar company to link in one more library. It's not like any other codec will do any better. Theora just has the advantage of being open by nature, and not encumbered by patents. So I wish we could just move on, and use Theora.
(In the interest of disclosure, I am very pro theora and am a long time Linux user. As such, any solution involving patents is revolting, and flash is disgusting in terms of support and distribution.)
That is the reason why Google decided to no longer support H.264 in Chrome. Not supporting WebM and Theora in IE and Safari is very similar to any other monopolistic approach in business. As far as I know, the HTML5 tag is , not . So, Google is playing the same game as Microsoft and Apple removing H.264 from Chrome.
Achille Talon
Hop!
H.264 is open standards, not open source. There IS a difference. H.264 is, in no way, open source.
Considering Chrome-the-browser is part of Google's push towards a Chrome-OS, one could argue that Chrome *is* handing it off to the OS... itself. Chrome ultimately needs to be more self-reliant than most pieces of software out there.
Also, while an OS is there to have a common framework, that only works on single-OS applications. If you have a cross OS application, you either need to implement standardized frameworks with hooks into the host OS, or you need expensive divergent development paths.
The ______ Agenda
The grid the blogger shows has "standardized" and "development history" columns. These are both completely irrelevant to the discussion at this point. The bitstream of both formats is frozen and available to everyone NOW, so they should be judged as-is. This leave only the implementation and distribution columns, where the only codecs that are fully green are Theora and WebM. And there lies the reason Google wants WebM. It's as simple as that. .gif image disaster and what had to be done.
You can switch to WebM today and stick with it forever. Or you can go H.264 today and then switch to H.265 when they jack up the royalties before the patents expire and THEN switch to the new patented codec and repeat. Google paid $130M to free the web, and all people want to do is bitch about it. Seems we've forgotten the
This will all change when YouTube turns off Flash - HTML5 and WebM are already there.
Maybe I'm ignorant. Maybe I'm just dumb. But I can't, for the life of me, understand why it is so difficult for Apple and Microsoft just to ship libtheora with their Operating Systems and stop bothering everbody.
H.264 is a theatrical production standard, a broadcast, a cable and sattelite distribution standard. H.264 is supported by every HDTV set, video game console and set top box on the planet.
H.264 is deeply entrenched in medical, industrial and military applications. The corporate intra-net is H.264.
H.264 supports content protection.
"Google wants to do everything it can to blunt iOS and boost Android - and trying to break iOS's video experience may be a dirty trick but all's fair in OS wars."
Everything it can to blunt iOS? Then would you care to explain Google Maps for iPhone, Google Voice for iPhone, Google Latitude for iPhone, Google Goggles for iPhone...?
If Google wanted to try to kill HTML5 video, it would have been easier and more effective just to drop support for H.264, full stop. Instead, they spent $133 million to buy On2, then went to all the effort of continuing to improve the VP8 encoder, creating the WebM open source project, and building support for it (critically, among hardware developers). And the result of all that is that Apple and Microsoft can now foil Google's dastardly plans simply by including WebM in their products. HTML video would be saved and WebM would be the baseline. Hurrah!
Why are you lying?
FFMPeg is GPL
x264 is also GPL
Do I need to go on and list a few more, or is two enough to snub your ignorance?
He's not lying, he's just over-simplfying.
So far, software patents have not been legally applied to source code because source code has been clearly defined as "speech" as it is a means for people to express ideas.
So it is legal to write and distribute source code.
But, in most countries with software patents, it is illegal to actually use a binary built from that source code.
Its just the compiling it yourself or downloading it from a country without software patents makes it pretty much impossible to get caught.
When information is power, privacy is freedom.
Breaking that lock is very important. It means a lot. It's a must. H.264 will survive. VP8 will be a cost effective alternative. Nothing keeps it from being incorporated into hardware.
Google won't lock us in with their alternative. When you have no choice you will be locked. when you have a choice it is hard to lock. But the alternative must be viable and gain enough market penetration to make a difference (and the pre-existing lock can't be so entrenched that no one can compete with it).
You can lead a man with reason but you can't make him think.
MPEG-LA could cut this whole thing off at the knees and ensure WebM is relegated to an also-ran by making a H.264 basic profile available in a completely royalty-free way... Obviously there are a lot of profiles in H.264, but pick a baseline one for the video and audio portions and make it entirely freely available for anyone to implement without signing any agreements/etc. From a purely cut-throat business position: If I were one of the major members of MPEG-LA, I'd certainly take this seriously and do anything I could to ensure there is no need for WebM to exist. Basically make myself the path of least resistance.
Now people like Apple/Microsoft are still going to pay the license fee to implement all the profiles but for projects like Firefox it would give them a way to implement a video standard that was developed through an open process, is an ISO standard, and enjoys widespread hardware acceleration support. It would also give anyone targetting browsers an easy way to do so because everything that exports or records video does so in H.264 or supports transferring to H.264. Selecting the "web standard profile 1.0" would be all that one needed to do to ensure compatibility.
It's not like this isn't what will happen anyway: what linux users haven't installed ffmpeg or VLC with included H.264 support? Honestly, all this would do is legitimize the status quo. H.264 isn't going way: iPhones/iPads alone mean video is going to be produced in H.264 (mindshare can be as important as marketshare). Add in Windows and Mac native support and you are looking at what - 80% of all web users? 90%?
I hate this political bullshit that gets in the way of just standardizing on what everyone is already doing anyway.
P.S. I don't see what is bad about handing off video/audio rendering to the OS frameworks. Frankly, if Firefox or Chrome can't render a given codec, they should fall back to that mode anyway. I may be doing things for my internal intranet or my own personal use that have nothing to do with this browser maker pissing contest so just get out of my way and let my OS render anything it knows how to render.
Natural != (nontoxic || beneficial)
I think the whole argument is really over peanuts. I care little about the technical merits of either side. Personally, my eyes cannot distinguish between good H.264 and WebM. They both look equally as good. So one might be marginally faster or even marginally better? I would rather go for the patent unencumbered technology because I don't want to be threatened with a royalty lawsuit for maybe making some money off of a video I shot. I want to completely own the videos that I shoot. It comes down to a legal argument versus a technical one. It is all well and good if there are ISO standards surrounding H.264 but if using it brings lawsuit storm clouds overhead, no thanks! Everyone here is trying to make a technical argument when the article is looking at legal issues.
But why on earth should video playback, of all things, be made part of the OS?
This is how Windows and OSX try to do it, and it's stupid. The integrated players (WMP and QuickTime) are pretty awful, and even if they werent, there privileged position in the OS just causes problems anyway. I use VLC on every platform and certainly dont want or need these inferior players. Firefox IIRC bundles ffmpeg internally, which seems like a fairly reasonable way to do things. Of course it would be nice if Firefox would figure out how to detect and use the up-to-date copy of ffmpeg on the system already, instead of insisting on maintaining its own, but there are obviously quite a few obstacles to doing that in a sane, cross-platform way, so their solution works fine for me. The last thing I would want to see would be for them to copy IE and Safari by using WMV/Quicktime.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
There seems to be some confusion as the limits of the standard vs the limits the patents held, or believed to be held(and how many were tested in court instead of settled?) by members of MPEG-LA for H.264 and others.
No open standard can do what you say it can until the patents expire, no matter how open they are, unless they can PROVE IN COURT that the patent does not do what the patents in question restrict apply to them. That's why software patents are so harmful, they cannot be worked around in a technical manner. NO amount of clever will let you base your business on doing what is patented. No amount of clever will let you do it for free either, because the patent holder MUST either
1) sue you
2) collect royalties from you
3) get a contract from you that defends its patent
I can't find examples of a 3) being applicable to open source/open ideas initiatives right now, although small "the library of Kerhampton, middle of nowhere" can use the software without license for perpetuity has happened.
Another post by someone who doesn't know what proprietary means. From the Oxford English Dictionary
H.264 are a collection of standards that utilise the Intellectual Property of the Members of Mpeg LA. This property or ownership controlled legally through license makes the format and encoders/decoders undeniably proprietary.
VP8 is based on Intellectual Property with following license (see below), this makes it non proprietary or common ownership (like the atmosphere).
While we are at it "open standard" both h.264 and VP8 have freely available, accessible technical documentation, this is all that is required to be an open standard. As regards standards bodies like ISO/ITU et al. HTML wasn't passed through one of those for 9 years and xHTML (widely used) still hasn't been, were/are they not open standards...
Well, there are problems with VP8, in that more of the specification needs to be fixed and not tied to specific code, there are bugs to iron out, etc.
But the "openness" that some people are worried about is the matter of royalties which make H.264 unsuitable for FOSS, legally speaking. In an ideal world, anyone could write whatever code they want without patents and such getting in the way and then we wouldn't have all these problems, but this world is not so ideal in that respect.
Then again, as the article points out, different people are worried about different problems. There are things that are not a problem for me that might be a problem for you. And so we either find ways to cooperate or just agree to disagree, in that one might really be the best for me but not the best for you.
/sigh. Even ./ gets it wrong.
The major issue is licensing, not that the 264 standard is publically (open) available. VP8, FFMPEG, 264 is loosely "open source" in that the code is available.
However, one one of the aforementioned examples require you to pay an arbitrary (and possibly fluctuating) cost to a group of companies if you were going to use it for commercial purposes. Furthermore, W3C *requires* that all baseline standard HTML needs to be patent free.
This should automatically disqualify 264, but I guess having two of richest tech companies (one of which has a closed ecosystem that cannot support any other tech unless they choose to) behind it gives it weight.
Key here is, HTML5 was supposed to at least partially break Adobe's stranglehold on the web by moving some content away from Flash. Google just killed any hope of that - They talk about supporting open codecs, but they still bundle Adobe Flash (which includes H.264 support) with Chrome?
Why does the solution have to the problem have to be H.264? Why can't it be WebM? Why did Google kill that hope. Apple hold patents/ Microsoft hold patents why can't they offer support to WebM? Why should the Restrictive License/Patent Encumbered Codec become the standard?
Flash has won the web because its crossplatform and codec agnostic. Why would settling on a now solution be better when better formats are available. WebM2 or H.264+. I Loath Flash, but if the alternative is the web locked into a legacy restrictive licensed/patent encumbered codec. I'll take it.
What the @#$ is with that? Xiph.Org's Theora Specification is easily the nicest codec standards document I've ever seen. It's completely, informative, and easy to write from. It's _far_ nicer than the hideously complex and expensive H.264 documentation.
Thanks. Yes, I was simplifying it on purpose, to prove a point: slashdotters don't really understand the issue. I guess that makes me a troll ;)
exp(i*pi)+1=0
Over 20 hardware manufacturers are working on WebM hardware implementations, including Broadcom and Qualcomm, the two biggest chipset makers for mobile devices. When H.264 was standardized, all computer implementations were done in software as well. The hardware acceleration came later. Three years ago, HD-DVD and BluRay war was still undecided, and smartphones that played streaming video all but non-existent. Who knows how much inroads WebM could make in the next three years.
SmugMug was starting to consider HTML5, but Google's latest decision has them moving back to Flash.
Firefox and Opera don't support H.264 either, and they have much greater market share than Google. So if this announcement changes anyone's plans, they obviously hadn't thought them through very well to begin with. Either you support two formats for the next several years until everything is sorted out, or you exclude a large portion of your audience. This is a draft standard we are talking about. You should expect early adopter issues.
So, can you use x264, ffmpeg or whatever other implementation of the h.264 "open standard" without having to pay any royalties? Can you distribute binaries of that software in countries were software patents are valid?
exp(i*pi)+1=0
Can you share ffmpeg or x264 binaries in the US without asking mpeg-la for a licence? Remember that your ignorance won't help you from being accountable for your breaking of the law ;) and if you start doing some money from your work and refuse to pay up, you'll be sued to oblivion.
exp(i*pi)+1=0
Come on, it's only trolling if you are wrong! Creating honey pots for people that don't understand the issue to prove their ignorance helps getting them educated ;)
exp(i*pi)+1=0
You'll find out that these are being distributed from France and Switzerland, not from the US. The reason is that while you can put your code under the GPL, the software cannot be distributed when patents prohibit you from doing so. That's 7 of the GPL.
No, they are forcing you to pay a licence to be able to use a basic infrastructure. And they are preventing any Free alternative OS in the countries were the mpeg-la patents are valid. Maybe someone else will sell you an OS properly licensed (say Red Hat or Canonical), but that won't allow you to share it (i.e. it won't be Free).
Trust me, I'm not one of those floss over-zealots, but they first came for the video tag but I didn't watch any videos online, then...
exp(i*pi)+1=0
There is simply no sword of damocles. MPEG-LA has stated it will increase royalty payments, if at all, by no more than 10% every 5 years. Google currently pays $6.5 million to license h.264. In five years, that could rise to a SHOCKING $7.15 million. Five years after that, Google could be looking at license fees of $7.865 million!!! In other words... it's just silly to argue that Google, is worried it might find itself paying (in 10 years) licensing fees of less than .00005% its current market cap.
No. You can tell people to use WebM and install the codec to view the content to.
Firefox, Chrome and Opera could even ask if you want to download it if it wasn't already installed upon the first run or whatever. Though I assume that should really have been the media players task.
Open standard : I can read up the standard, and I can do my own clean room implementation. I don't need to go through hoop and loop with any 3rd party.
Non Open : no matter how much I read the spec/standard, no matter how much the implementation is fully clean room, I cannot implement that standard without jumping thru hoop and loop and paying money under certain condition to somebody. H.264 is not open. Has never been. It ain#t a question that you pay some basic money to get a copy of the spec, it is a question that no matter how clean room your implementation is, somebody can dictate how it is used. You cannot for example give your own H.264 implementation for free to decode and encode !
Furthermore a standard which cannot be read and accessed if you take the time to go to your governement library to read it, is not a standard. Here around evry standard dign of that name can be gotten for free. It might not be easy, it might not be convenient, you might have to ask 10 intern to spend a month making photocopy, but it can be had fopr free. I standard which can only be sold at the behest of some royalty agreement is not an open standard.
An open standard has NO barrier of entry whatsoever , expect having your own expert and your own material to implement it
Case in point the ISO standard 9001 can be implemented by anybody, can be read by anybody. WEhat cost money is the certification process by an accredited entity.
Know your rights: H.264, patent licensing, and you
That is another really good FAQ on this issue. In short: understand the difference between "open" and "free" before going into a discussion on this topic.
First, you say it's just linking a library, and then you refer to rolling silicon for hardware decoding. I suspect you understand some of the issues then. Why does a company want to roll silicon? To Save $10k in licensing fees? I think not.
That's because those standards aren't patent-encumbered. I mean, duh!
The thing is, VP8 is patent encumbered too. Almost certainly it's infringing on some MPEG-LA group patents, we just don't know which ones yet. Start using it and you'll find out.
That's why Google refuses to indemnify (say that Google is liable for lawsuits for the use of) companies that make use of VP8.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I can write a C++ compiler and sell it without paying anyone a dime. Could I do the same with a H.264 encoder?
Since VP-8 most likely violates some MPEG patents, you can't do that with VP8 either - at least not long term. It just *appears* to be free...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
This is the problem with x264. If x264 becomes the de facto standard, two guys in a garage will never be able to develop their own browser that competes with all the current market leaders
Any browser writer could implement the video tag in such a way they fall back to system supported codecs. Then they need not pay anyone even though on all platforms you would support h.264 playback.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Leaving all "open standards versus open source" debate aside, it is interesting that these discussions usually bring so much emotions on the surface. Also topic of TFA indicates need for flame.
Well, there is simple deal - Google Chrome and Mozilla Firefox has nice market share. They are planning to push V8. It is their decision. It is their strategy. Will work it or not - it is not a subject here. Somehow lot of people feel offended by such competition in first place. Why? Does it suddenly cancel all movies, clips available in H.264? No. Can it kill H.264? With Firefox taking H.264 decoding from Windows - hardly. So what's the problem then?
I see good reasoning in existence of video formats free from patent and royalty shackles. Not everything on video in Internet is entertainment. Not everything has to be compatible with your latest iPhone. But I don't deny H.264 has a solid market share and place in electronic entertainment.
user@ubuntubox:~$ stfu This server is going down for shutdown NOW!
It's frustrating that only the OS-provided solutions (Safari and IE) are doing this right by handing it off to the OS.
IE9 doesn't really do that. Yes, it uses the system media framework to play HTML5 video but it only allows video playback with two, and only two, video codecs: H.264 and VP8 (i.e. WebM's video codec). No other video codec will be used even if it is installed on the system.
WebM/VP8 will force a non-accelerated CPU-only rendering path on ALL existing hardware. This eats power compared to hardware acceleration. (Look at how well most Android devices handle H.264 thanks to hardware accelerated decoding.)
My phone has a general purpose DSP which can be used to accelerate different video codecs. Accelerated WebM can be had on my phone with a software upgrade. Theora already has software available:
http://www.schleef.org/blog/2009/11/11/theora-on-ti-c64x-dsp-and-omap3/
Pretty trivial really. In many cases the capability for hardware acceleration of WebM is already there in existing devices. No hardware upgrade required.
It's frustrating that only the OS-provided solutions (Safari and IE) are doing this right by handing it off to the OS.
Unless you use different computers with different OSes, yet still expect streaming video to work the same. In fact I would argue strongly that adding video rendering into the OS is bloat, not the other way around. Video rendering is clearly a user-space application, and shouldn't be tied to the OS. Do you really want to go back to the days of 'IE only' sites?
No
AccountKiller
Until someone can quote a specific patent or the MPEG-LA actually acts on its threats, this is simply FUD.
History tells us patent threats around video are a very real minefield. You cannot dismiss the issue as mere FUD; certainly vendors you are asking to spend a lot of money and time to encode in VP8 cannot.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The point of TFA was that having browsers delegate to the OS is actually bad for web standards, because it means all the browsers will implement a dozen different codecs, and then web site authors will have dozens to choose from, and they will all choose different ones. Then we'll need to install *all* of them in order to browse the full web. That leads to lack of standardisation. If there is two or (preferably) one codec incorporated into all browsers, that gives us a de facto standard.
Also think about what you are saying: "It's frustrating that only the OS-provided solutions (Safari and IE) are doing this right by handing it off to the OS." How can a non-OS-specific browser hand off video decoding to the OS? This would immediately render it non-portable.
Sure, Firefox could delegate to the Windows video decoder on Windows, the Mac video decoder on Mac, the Gstreamer framework on Linux, etc. But it's still not portable, it merely runs on three platforms. How can you port Firefox Mobile to the next device?
Sure, they are GPL, but the GP said "given the patent policies of many GNU/Linux distributors". He wasn't referring to licenses. Patents. Patent-encumbered GPL code is not considered "free software" and can't be included in many distros, including Debian and (with key exceptions) Ubuntu.
The version of FFmpeg included with Debian/Ubuntu, for example, has been specifically modified to remove H.264 support.
That is a terrible article and you should feel ashamed for using it.
No it's not, HTML is designed to be an open standard that enables anyone to create content on the internet that can be read by any device or software that is designed to interpret the HTML tags. HTML version 5 is no different. Please leave your Adobe hate at the door when defining what is a standard.
Now I'll address why Gruber is full of it.
Relevance?
Simple fact is, Google does not need to pay per-install for flash due to it's free to distribute licensing agreement. H.264 does not have a similar agreement. So this is a strawman at best, Flash and h.264 have little in common in terms of licensing.
If you think it's fair that Apple does not have to support VP8 by default in Safari, why is it unfair that Chrome does not support H.264 by default in Chrome?
Another Strawman because Gruber does not understand how licensing works. The manufacturer pays per device for a H.264 license. Google does not license H.264 in Android.
YouTube also uses VP8. It is Google's goal to drop H.264 completely. I know Gruber lives in Fantasy World but in the real world chang-overs like this do not happen overnight. You cant simply cut over from System A to System B withuot some time to acclimatise users to System B (this is why Facebook hasn't foisted the new interface on everyone just yet).
Why does YouTube use H.264, well if you haven't figured that one out you're retarded, because there was no other decent alternative, this is not the case anymore.
He's asking two questions, not entirely intelligently either.
1. What Netflix, Amazon, Vimeo or anyone else does is not Googles responsibility.
2. Google didn't ban H.264, they just removed it from the default configuration. Chrome can still use H.264, it's just not installed by default. Gruber should have been smart enough to realise this is a non issue thanks to Chrome Extensions. Google just wants to stop paying for H.264. This is question disingenuous and hypocritical of Gruber, first he derides Google's decision to include Flash by default and not as a separate plugin then he derides Google for not including H.264 by default when it can and will be available via a plugin.
Who calls this a legitimate grievance, gripe or complaint?
This is nothing but a filler comment to make it look like Gruber has a point, which he does not. You really need to read what Gruber writes rather then assume he is correct. But I'll answer, I'm happy because it's a giant step towards being able to host videos from
Calling someone a "hater" only means you can not rationally rebut their argument.
WebM/VP8 will force a non-accelerated CPU-only rendering path on ALL existing hardware
So what? Tomorrow this will change. The future of the open Internet is of somewhat more consequence than battery usage over the next thirty six months, especially considering we are talking about a HTML tag for which support isn't yet widely deployed in the first place.
If battery usage is such a consideration, just stick with "evil empire" codecs like H.264 and pseudo standards like Flash in the interim. As has been mentioned elsewhere, all the DRM people apparently need to stick with something like Flash indefinitely, so there is nothing stopping paid video distributors like NetFlix from sticking with H.264.
It is the H.264 uber alles movement that is the enemy of the Internet as we know it. On a limited basis in proprietary sandboxes, it is just fine.
Key here is, HTML5 was supposed to at least partially break Adobe's stranglehold on the web by moving some content away from Flash
And put it in the hands of a far more pernicious "evil empire" than Adobe has ever hoped or pretended to be? H.264 is evil. What patents does Adobe claim on Flash? Adobe allows other implementations on a royalty free basis. Do they have any basis to do otherwise? Last, but certainly not least, Adobe doesn't come close to the audacity of requiring royalties on all Flash distributed content. If they did, Flash would be dead in the water.
Do you think any web advertiser in the world would pay royalties for Flash ads, for example. Hardly - they would switch to a royalty free alternative (as simple as static images) overnight.
So what? The GPL is nearly meaningless so far as third party patent encumbered software is concerned. No one can legally use x264 without paying patent royalties. Depending on MPEG-LA's licensing whims x264 might not be legal to distribute tomorrow in any case, at least in binary form.
grandparent is brainwashed.
How about now? How about now? How about now? ...
I think it's time for wavelet base DIRAC codec as the open standard for web video, it's a open & royalty-free implementation.
Apple and Microsoft aren't handing it over to the OS. They are handing it over to THEIR OWN OS.
Firefox can't do that. Google can't do that (unless you're running on Android).
No two operating systems handles this the same. Some don't even have a legal way of playing h.264 (in countries where software patents are valid). You can't hand it over to the OS and still have working video on every platform under these conditions.
(Ok, Apple could theoretically be handing it over to Windows when running Safari on Windows, but since they force you to install Quicktime anyway, I bet they use Quicktime to play h.264, rather than handing it over to the OS).
...it's a step towards IE9.
The last time someone tried insisting on an open standard, we got the alternative to .doc - which is used by an overwhelming majority of almost no-one.
The whole open/ closed debate is all very nice, but folks are already using H.264 - so it's not 'what shall we insist that people use', more a case of 'how do we support what people are already using'. GIF isn't open, and no-one has stopped using it - ditto JPEG. It's odd, you'd think the alternatives would at least learn *something* from MS - establish dominance, create standards. Things don't usually work the other way round.
I though dirac should be the choice for default codec on HTML 5, since it open & royalty-free.
I know the quality is not as good as h.264 or vp8 right now; however, more people join the development will bring it to a quality codec faster.
No you can't contribute code to H.264 any more than you can to WebM. VP8 is now a standard and you can no longer enhance it any further. If you're talking about the encoders and decoders. The answer is still the same, VP8 and H.264 are equally open in that there are open implementation of both which you can contribute to. In the case of H.264, the x264 project is far better than the closed ASICs and code bases anyway, so why would you want to work on those? x264 is probably the highest quality video encoder available today. (Don't tell Jason I said that)
H.264 is an open codec, anyone can implement it whenever they want. However to use it or ship it will cost money. By the time which the MPEG-LA actually starts charging for it, I'd be surprised if most of the patents of interest weren't ready to expire. But, there is certainly concern over whether use of the codec will be free. Since I have copies of the spec and the drafts are freely available and accurate (though not always complete), I consider the codec to be open. Unlike the VP8 codec, the specs are actually written well enough that you can pretty much implement a standard compliant implementation from the spec itself. I'm sure VP8 will get better over time, but last time I read the spec, it depended heavily on the code.
WebM doesn't meet the spec as far as open development is concerned either. You can implement it and you can even contribute to the reference codec, but, you won't be making changes to the spec any time soon.
The argument is complement wrong sided, let's forget one sided. The issue shouldn't be WebM against H.264, but it should be users against the browser companies.
The standard for the video tag should require that all browser vendors provide documentation on how to extend their browsers to support more decoders. The browser vendor shouldn't be allow to force you to use one codec or another. They can however choose which codecs to support by default.
Google and Opera should be reprimanded and boycotted by the users who should be outraged that they haven't released SDKs for extending their browsers to support more codecs as plugins.
Let's face it, WebM and H.264 are both superb codecs. Well, they're basically the same codec, just implemented a little differently. VC-1 should be included in that as well.
But point being they're both great codecs but compared to tomorrow's codecs and what we have learned since they were implemented, they're shit. H.265 has set a goal for decreasing the bit consumption by 50% for equal quality. WebM's successor will attempt to achieve the same to remain competitive.
What will the debate be later when there's a new generation of codecs? Will we still argue WebM vs. H.264 or will we allow the users to install new codecs that support higher quality video on lower bandwidth?
Opera can fix their problem pretty easily. They only need to compile the GStreamer codec wrapper and add code to build a pipeline instead of using a static pipeline. It's really quite simple to achieve in GStreamer.
Google can do the same with ffmpeg.
This would allow both browsers to support all system supported codecs from day one. So, we're all arguing over whether one inept browser vendor is better than the other hated browser vendor because some idiots chose not to use the multimedia libraries they chose properly.
So, quite your wah wah wah. If Microsoft and Apple want to pay the decoder licenses for H.264, let them and if the video provider chooses to do the same, then let them. On the other hand, if Google wants to provide WebM plugins for all browser and provide authoring/publishing/streaming software, let them. Then when the new stuff comes around, whoever publishes a codec for it can distribute it for all browsers as well.
Yes you do have the right, but it's been decided to infringe on that right for the public good by implementing "patents".
Except that compression is maths and software should never be patented, so the rights involved have already been broken.
PS you may not have the right to use h.264, but then that means you should not be FORCED to use h.264. Which makes WebM the right choice.
So only about 6billion possible problems since the patent pool group only constitute a miniscule fraction of the world population, any of which may have a patent that h.264 violates.
I don't see much of a reduction there, kiddo.
And, if this person goes in to the patent pool by invitation, then the slice for each person has to reduce or the cost of licensing has to increase. Guess that means you STILL pay for even more patents with h.264 than you do with WebM.
From where? That would mean I'd have to keep an up-to-date list of all the places to get the WebM codec for all the various platforms that my visitors might be using, if one even exists. I don't mind other codecs being supported through whatever framework is available to the user - but there should always be at least one common codec that can be relied upon being present, regardless of platform.
So suddenly, there's no problem killing battery life. On the other h264 threads there was a lot of complaining that WebM was a non-starter on the grounds that it would have to be software decoded and that decode would kill battery life on mobile kit.
Mobile kit that has video cameras built in and would need to encode to h.264 that you say can be done in software and therefore the patents not a problem...
It's frustrating that only the OS-provided solutions (Safari and IE) are doing this right by handing it off to the OS. The notion that your browser needs to reimplement everything, including video rendering, is what leads to the bloatware we have today. The whole point of having an OS is to have a common framework and API layer that all applications hosted on it can access. Instead, Firefox, Chrome and Opera are all re-developing their own video rendering, for each platform they exist on, AND each one needs to write its own video-card accelerator layers for each platform it exists on.
We had that, it was called "embed" and "object". It didn't work.
I don't think it stands up to any of the FOSS definitions of "open".
I assume by "it" you refer to a document specifying the H.264 video encoding standard.
By the FSF's definition of Free Software and the OSI's definition of an Open Source license, I'm guessing the document isn't "free" or "open". And if you like free software, that's not a problem.
The reason is: what it means for software to be free is that you are free to run, modify and redistribute it, as well as redistribute your modified versions.
Let's say I apply this to RFC 793 (the old TCP one): I distribute a document claiming to be the TCP standard, but I have changed so it's all wrong (say, I swapped the ports fields with the sequence number). Then people go and implement my false TCP "standard". Then shit breaks. Not good.
You really want the standard documents to be fixed once the standard has been ratified by the relevant organization(s) and/or people(s). It seems to be more friendly to the bazaar-style development practiced in large part by developers of free software if the standard document is freely redistributable, but not modifiable.
(On the other hand, maybe putting a crypto signature on one document and letting people change it without keeping the signature is fine, if you can make people look for the signature...)
I'm not sure the FSF have a definition of "Open Standard". As a first approximation, I can propose: a standard for a (class of) piece of software is "Free" (or "Freedom Respecting") if it is possible to create a piece of software implementing it which is free software.
(I won't even guess as to a definition of "Open Platform". That's besides the point for this discussion anyways.)
No, actually, it is the other way around: there is no inherent right
How have you found out? I would like to know what inherent rights there are, but socialists, libertarians and geolibertarians all disagree. Who's right, and how do we know? If we prove our result, which axioms do we use? How do we know those axioms are the right ones?
Translated: I think it's all a matter of opinion. There are no objective moral truths (only factual ones). If you disagree, please prove one :-)
In this case, the right thing to do would be to release it to a video decoding layer for Linux
I think it's called mplayer :)
Why do we care about the policy choices of some Linux distros? You will always find policy choices that outlaw things.
Because all your installed base are belong to these distros. If well over 80 percent of desktop PCs running Linux are running either Fedora, CentOS, Debian, or Ubuntu, then of course these distros' policies will determine how companies deal with GNU/Linux as a whole.
There are GPL H.264 encoders and decoders.
Just because the copyright in a work is licensed under the GNU General Public License doesn't mean the United States patents on the method that the work implements are necessarily licensed compatibly with the GPL.
So you've mentioned another package that does the same thing and has the same patent problems. Please allow me to rephrase my other post:
When you install Ubuntu, you don't get AVC because it's patented. Instead, to watch an AVC video in Totem for the first time, you have to connect to the Internet, authenticate with sudo privileges, install gstreamer0.10-ffmpeg, and then affirm that you don't live in a country with AVC patents. You have to have someone with sudo access present for this.
From where?
I said you could.
I don't see why the browser or media player integrated in the browser shouldn't be able to figure it out and inform the user by itself though.
That would mean I'd have to keep an up-to-date list of all the places to get the WebM codec for all the various platforms that my visitors might be using
Not once it was widespread.
but there should always be at least one common codec that can be relied upon being present
H.264 is (or well, not with the stupid browsers picking their own format and not using whatever is installed in the OS), and WebM could be to if people decided to.
(I was earlier thinking about saying it could be distributed with the browser but that would be like Apple does with iTunes and Quicktime and all sorts of crap and I don't think people want to download it time and time again even though they already have it installed. So .. Better have the browser help them out if it's not there already. It's very simple to do and your webpage don't have to do shit if the browser inform your user either at start that it need to fetch a new video codec used for HTML video or upon loading your page with WebM content.)
I'm writing this without having any information about it, so you can flame at will. ...) have to pay royalties when they encode in H264?
Do the content providers (youtube, vimeo,
If yes I can understand Google that owns youtube that they want to support a different format. Imagine, every day, 12 years of video is uploaded to youtube. How much would this cost in royalties?
If that were the case I think no video site could survive without charging for the view and H264 supporters are wishing for a grey future web.
My two cents
It Is Time to Standardize a Royalty-Free Video Codec http://www.robglidden.com/2011/01/time-to-standardize-a-royalty-free-video-codec/ Rob Glidden on January 18, 2011