| |||||||||||||
More about the Chrome HTML Video Codec Change (The Chromium Blog)More about the Chrome HTML Video Codec Change (The Chromium Blog)Posted Jan 15, 2011 11:30 UTC (Sat) by kepstin (guest, #72391)Parent article: More about the Chrome HTML Video Codec Change (The Chromium Blog) I've always wondered why more browsers don't do like what Epiphany (with WebkitGTK+) does, and simply not ship any video codecs at all. Instead, use system media libraries WebkitGTK+ uses GStreamer, which means on most Linux distributions itll play WebM and Theora just fine, and if you get Fluendos codecs or the ffmpeg decoder itll play H.264 (and a bunch of other formats besides). Why is this an issue at all?
(Log in to post comments)
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 15, 2011 12:04 UTC (Sat) by fsphil (guest, #44932) [Link]
That would be the nightmare scenario from a web developer point of view, each system having a different set of codecs with a different way of adding new codecs. It would be worse than what we have now.
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 15, 2011 18:11 UTC (Sat) by JEDIDIAH (guest, #14504) [Link]
Nonsense. Before Flash was dominant, this wasn't the case. Widely used non-proprietary standards are a given on any platform. As long as you don't have the sort of nonsense like we had with Apple and Sorenson, you can be pretty confident that well defined standards will be widely available.
On the other hand, casting h264 in stone creates an entry barrier for everyone. It's not just about how there's a licensing quagmire with h264 but the fact that it is a format that pretty much requires specialized hardware acceleration.
Also, Flash is mainly about obscuring access to the underlying file. This is an area where HTML5 doesn't even really help anyways.
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 16, 2011 15:59 UTC (Sun) by AndreE (subscriber, #60148) [Link]
Yes and the way it was before sucked. It sucked for users because they had to install various pluggins for the wide variety of codecs that were used, and it sucked for developers because they could never be sure what codecs users had.
There is a reason we want a standarded HTML and not the crapshoot we had before
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 17, 2011 5:44 UTC (Mon) by JEDIDIAH (guest, #14504) [Link]
No. The only thing that sucked about the way things were done before was all of the proprietary nonsense from the likes of Adobe and Apple. None of that seems set to change since HTML5 doesn't even address the critical issues when it comes to web video anyway.
Publishers want to obfuscate content in a manner that makes it more difficult to deal with with generic tools (as opposed to "special plugins"). Any decent non-crippled video tools would have no problems with dealing with the sort of "chaos" you seem so fearful of.
It's the intentionally crippled and limited platforms that would have the most problems. This is a problem artificially created by the same people that created the earlier mess with exclusive single vendor proprietary codecs and the special plugins needed to deal with them.
This ultimately seems to be primarily about catering to the most restrictive and abusive system vendors in the industry.
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 18, 2011 0:09 UTC (Tue) by AndreE (subscriber, #60148) [Link]
Nice rant, but not really relevant to what I had to say.
HTML5 addresses both the user and developer need to have a standardized video format for the web.
System codecs are NOT the answer because they give no guarantees to the content provider or the system user. There is nothing standardized about system codecs
HTML5 + WebM is the best answer. Of course, if HTML5 becomes split between HTML5/h264 and HTML5/WebM, then yes, we may as well be using system codecs
Bingo! Posted Jan 18, 2011 0:27 UTC (Tue) by khim (subscriber, #9252) [Link] It's the intentionally crippled and limited platforms that would have the most problems. Yup. Things like TV sets, mobile phones, etc. You know, the devices which are actually used to watch video by non-geeks. Where hardware support is paramount because it makes tangible difference on your battery life or your monthly energy bill. This is a problem artificially created by the same people that created the earlier mess with exclusive single vendor proprietary codecs and the special plugins needed to deal with them. Sorry, but no. When you present a "non-crippled" platform which can play and encode HDTV video in realtime using less then one watt of power - we can start talking about "openness" and "pluggable codecs". Till then it's not an option. Because simple fact of life is: today there are more users of web-enabled mobiles then there are users of personal computers. Tomorrow (or, mre likely, in the next 2-3 years) these devices will start showing video - and what they'll support in hardware will be used on the Web.
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 15, 2011 13:17 UTC (Sat) by jku (subscriber, #42379) [Link] Google and and Mozilla have both stated that they don't consider this (only) a technical problem. Ulterior motives are always a possibility but let's take their word for now, these are quotes from the fine article:...we genuinely believe that core web technologies need to be open and community developed to enable the same great innovation that has brought the web to where it is today.Making a stand like that is not possible by just passing the responsibility to someone else.
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 16, 2011 1:15 UTC (Sun) by roc (subscriber, #30627) [Link]
You can't ship Fluendo's or ffmpeg's H.264 codecs in a Linux distribution in the USA or Europe without risking a patent lawsuit.
It's funny to read on "Linux Weekly News" someone arguing that Mozilla and Google should give up the fight against patent-encumbered formats and pass the buck to Linux distros.
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 16, 2011 1:45 UTC (Sun) by tetromino (subscriber, #33846) [Link]
> It's funny to read on "Linux Weekly News" someone arguing that Mozilla and Google should give up the fight against patent-encumbered formats
If you want to avoid using patent-encumbered code, you basically have to avoid using any software written in the past 20 years that is more complicated than "Hello World!". (And even then, if you wrote "Hello World!" in a modern language, your language's standard library almost certainly violates dozens of US patents.)
Attempting to altogether avoid patent-encumbered technology in 2011 is quixotic, and bordering on insane. If you try to do anything interesting, you *will* violate some company's patents. Your choices are not about avoiding patents, but about behaving in a way that lowers your personal risk of ruinous lawsuits.
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 16, 2011 7:00 UTC (Sun) by gmaxwell (subscriber, #30048) [Link]
There is a pretty significant difference between the vague and untested theoretical risk presented by most patents, many of which were registered for purely investor-soothing or defensive purposes by ordinary companies which make ordinary products, and what you see in the codec space: Where the patents are widely and aggressively enforced and collected on, and where the royalty income is the primary or sole income for some of the patent holders.
Patents which are crated with the express intention of encumbering a format are a special case in another regard as well: The claims will usually exactly parallel some mandatory minutia of the format, allowing the patent to be hyper-specific thus making obtaining and enforcing the patent less costly, while removing the risk of invalidation due to prior art without diminishing the potent of the patent for its intended purpose in the slightest.
Furthermore, should a serious patent claim be raised against a browser, for example, then an update can be issued to avoid the issue and thus bound the damage. A patent which reads on a _format_ used for interchange is far more damaging. Moreover, you can choose to avoid software with known patent problems if your sensitivity to risk is great, but it's much harder to pick and choose what formats you work with because you're subjected to the choices other people make.
So sure, patents are problems in many places but I think there are plenty of arguments supporting that the difficulty caused by patents is not uniformly distributed and codes deserve special attention in this area.
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 16, 2011 17:51 UTC (Sun) by Seegras (subscriber, #20463) [Link]
> You can't ship Fluendo's or ffmpeg's H.264 codecs in a Linux
> distribution in the USA or Europe without risking a patent lawsuit.
Actually, software patents are still illegal in Europe. Just because the European Patent Agency is violating the law wholesale does not mean software patents are enforceable.
If the US legalizes extortion in the field of software, so be it; but I'm going to fight against the the same happening in Europe. And in the meantime, I refuse to acknowledge that something as abhorrent as the doings of the EPA even exists.
But of course, in regards of international standards, it's clear you have to go the route of the least common denominator, and if one country decides to allow monopoly rights on a technology, and the designers of that technology encumber it with those monopoly-rights, that pretty well means that this technology is not going to be a standard -- unless that country a) either fixes the law or b) the body decides to get rid of monopoly-rights on said technology. (Well there is c) of course, that what is happening right now: The USA bullies all other countries into adapting its laws).
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 16, 2011 20:42 UTC (Sun) by roc (subscriber, #30627) [Link]
You may not believe software patents are enforceable in Europe, but lots of European companies clearly do since they license H.264 patents and other software patents in Europe.
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 17, 2011 16:32 UTC (Mon) by Los__D (guest, #15263) [Link]
No, that just means that they believe that the risk of them being enforceable is greater than the savings of not licensing.
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 18, 2011 0:33 UTC (Tue) by Wol (guest, #4433) [Link]
Actually, it's probably a case of "if we have to licence them for the USA, we might as well licence them for the world".
They are NOT enforceable in Europe. One simply has to quote the European Patent Treaty to the Judge and it's "end of court case". Or at least, it is if you can persuade the Judge that your stuff falls into the EXplicitly excluded category, which is all software patents.
Problem is, a bit like in the US, the lawyers like to argue and if they can persuade the Judge that "All Software Patents" is a bit vague and woolly, they might get a result ...
Cheers,
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 17, 2011 11:57 UTC (Mon) by rqosa (subscriber, #24136) [Link] > Actually, software patents are still illegal in Europe. The problem is, it's possible to patent "a machine that does something", and anyone shipping a hardware device that does something must have a patent license, even if they're using a software implementation of something. (See here, for example.) So codec patents are still a problem for mobile phones and tablet computers.
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 17, 2011 12:15 UTC (Mon) by thomasvs (guest, #36955) [Link]
Not sure why you are lumping Fluendo codecs in with ffmpeg's h264 codecs.
The Fluendo codecs are licensed and legal. If a distro cannot ship them it's probably because they can't or won't pay the licensing fees. But various distros ship with Fluendo codecs; one prominent example is Dell + Ubuntu + Fluendo codecs.
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 17, 2011 23:14 UTC (Mon) by clump (subscriber, #27801) [Link] But various distros ship with Fluendo codecs; one prominent example is Dell + Ubuntu + Fluendo codecs.Dell's messaging, web site, and offerings are very sorely lacking for Linux on Dell. This is especially true in the US. I wish this weren't so.
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 18, 2011 8:14 UTC (Tue) by DonDiego (subscriber, #24141) [Link]
There is nothing illegal about Fluendo codecs, nor has there ever been. Stop the FUD already!
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 19, 2011 6:55 UTC (Wed) by DonDiego (subscriber, #24141) [Link]
> There is nothing illegal about Fluendo codecs, nor has there ever been. Stop the FUD already!
Haha, how can I blame anybody for being confused, when I cannot even write a single coherent sentence ;-)
I meant that there is nothing illegal about the *FFMPEG* codecs, nor has there ever been.
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 18, 2011 8:22 UTC (Tue) by DonDiego (subscriber, #24141) [Link]
> You can't ship Fluendo's or ffmpeg's H.264 codecs in a Linux distribution in the USA or Europe without risking a patent lawsuit.
Contrary to what is continuously claimed here, there are many distributions that do ship H.264 in Europe and the USA, for example Ubuntu, Debian, Gentoo and many others. I can understand that some distros like Red Hat (and thus Fedora) refrain from doing it, but the claim that nobody does it and/or it is impossible is demonstrably false.
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 18, 2011 8:55 UTC (Tue) by roc (subscriber, #30627) [Link]
The standard Ubuntu distribution does not include H.264 "out of the box".
https://help.ubuntu.com/community/RestrictedFormats
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 17, 2011 2:04 UTC (Mon) by jmorris42 (subscriber, #2203) [Link]
> Instead, use system media libraries...
That doesn't help Google at all. Remember that their browser is just the first component in what will be a complete OS offering called Chrome OS. So they will be the one packaging those system libraries as well. They would have two choices, pay the royalties for H264 support and include it in Chrome OS or don't... and have angry customers who get an inferior Chrome experience on the Google branded operating system vs Chrome on other platforms.
Nope, they are doing the right thing here. Perhaps for the most selfish of reasons, but as a Libertarian it is hard to find fault with that.
More about the Chrome HTML Video Codec Change (The Chromium Blog) Posted Jan 17, 2011 9:38 UTC (Mon) by DonDiego (subscriber, #24141) [Link]
> They would have two choices, pay the royalties for H264 support and include it in Chrome OS or don't...
This is a choice they already made:
http://www.mpegla.com/main/programs/AVC/Pages/Licensees.aspx
Google has previously shipped H.264 in the browser, shipping it in the system libraries (don't they already?) would not be a problem.
|
|||||||||||||