Slashdot Mirror
Firefox 33 Integrates Cisco's OpenH264
NotInHere (3654617) writes As promised, version 33 of the Firefox browser will fetch the OpenH264 module from Cisco, which enables Firefox to decode and encode H.264 video, for both the <video> tag and WebRTC, which has a codec war on this matter. The module won't be a traditional NPAPI plugin, but a so-called Gecko Media Plugin (GMP), Mozilla's answer to the disliked Pepper API. Firefox had no cross-platform support for H.264 before.
Note that only the particular copy of the implementation built and blessed by Cisco is licensed to use the h.264 patents.
But with access to the source code, it's easily possible to verify that the binary supplied corresponds to the source.
That's how we know that TrueCrypt has no "binary" backdoors - we just try different combinations of compiling, noting the differences, until we find the one that Cisco used. If we never find the exact combination, the differences between a "known good" compile of the original source and the final binary make the amount of code to blind-check almost negligible in comparison.
It's when people DON'T provide source that you should be suspicious, or when you can't get close to their source providing their binary.
I always wanted a backdoor in my browser.
They've already destroyed FF and changed it from a browser with its own identity into Chrome's obsessed former friend who mimics her every move and style and is planning to kill her and assume her identity some day.
Honestly, there's nothing left to call Firefox now. If I want a browser like Chrome, I'll run Chrome. If I want a browser like Firefox, then I have to use an old one or a fork.
Stop punching your users in the face, and give them back the control they had over their browser.
The source is open: you can read it, you can compile it and compare binaries, etc.
In fact, it is BSD licensed.
But that only covers the copyright. The patent is not opened (nor owned by Cisco), and seem to prevent derivative works.
Cisco paid the fees to use the patent in this one application, and open-sourced it to the world. Seems like a great solution, security-wise, and clever legally.
And, it becomes just more BSD code when the patent expires in... what, a decade? Or if the new Supreme Court ruling is found to invalidate the patent.
Your ad here. Ask me how!
(reads summary)
Hum, Interesting...firefox 33 integrates, mumble, mumble...wait, something's not right with this picture.
(Scrolls back a few lines on the RSS feed)
Firefox 31 Released
Aha! I knew it. Latest version is 31! Must be a typo...
(One angry RTFA later)
Oh, hang on...They are referring to the yet unreleased, possibly future version of Firefox. With no indication whatsoever of that fact in the summary, even though a (stable?) version of Firefox was just recently released, as highlighted on this very same website less than 24 hours ago.
Would it have killed anyone to point this out somewhere? You know, for those of us at home who don't keep up with Firefox's versioning madness?
Mozilla capitulating on the tag has serious implications for web standards. By including patent-encumbered code in the browser they take the rug from under those in the www foundation that argue for free web standards. Yes, some websites wanted to use H.264 for video encoding, but Mozilla shouldn't have abetted them.
Cisco heard your concerns and has responded: Development and maintenance will be overseen by a board from industry and the open source community.
Your ad here. Ask me how!
That's why I know I'm safe. I use OS X, which is a closed-source OS. And since it's closed, the government doesn't have access to it.
I love the smell of bad logic in the morning.
Get free satoshi (Bitcoin) and Dogecoins
But with access to the source code, it's easily possible to verify that the binary supplied corresponds to the source.
Is it that easy? My understanding was that you'd at least have to have identical versions of the compilation tools to have any hope of coming close to a bit-for-bit match on the binary.
systemd is Roko's Basilisk.
Seems like a problem with a simple solution: Cisco needs to publish their build procedure.
So, this is a software only patent... so it's not legal in Europe (or is it). Some Linux distro might consider integrating this code directly, and compile it instead of letting FF grab a blob from Cisco. Maybe distribute it in a special repository, that users would activate where it legal... Notice VideoLAN for example does play HEVC (aka H.264), and does not licence anything...
And, it becomes just more BSD code when the patent expires in... what, a decade?
A decade from now, most major web video streams will be in H.265 (HEVC), and H.266 will be the Next Big Thing(tm). By the time the patents on one codec have run out, bandwidth constraints cause providers of non-free media to switch to a new freshly patented codec. Users end up stuck on a treadmill, from H.261 to MPEG-1 to MPEG-2 to H.263 family (Sorenson Spark, DivX, Xvid) to H.264 (AVC) and so on.
So, at least on Linux this 'thing' doesn't come packaged with the browser in a package. Instead browser DOWNLOADS this crap from the net. ActiveX, anyone?
Very-very-very disappointing. Looks like Mozilla have forgotten what their mission was behind all those gay-rights fights.
Yes, some websites wanted to use H.264 for video encoding, but Mozilla shouldn't have abetted them.
H.264 is here.
HEVC not far down the road.
The geek sees everything in terms of the "open" web.
But there is more to digital video than video distribution through the web.
Which is why the mainstream commercial codecs dominate here.
Why hardware and software support for these codecs are baked into the smartphone, tablet, PC, graphics card, HDTV, video game console, Blu-ray player. The prosumer HD camcorder, medical and industrial video systems and so on, endlessly.
No. In fact it's absurdly difficult to reliably create reproducible builds. Debian has been working on this since at least 2009 (afaict) and has been plowing through issues but you still can't get an identical Kernel as the .deb. Heck, it was 8 weeks just for the Tor browser.
It's not just the compilation tools, it's the entire build environment that needs to be homogenized. All kinds of components will insert uname/hostname and paths into the binary, filesystems list the contents of a directory in undefined order, timestamps and permissions are embedded into tarballs and documentation, different locale produces other weirdness.
tl;dr: it's much harder than just installing an identical version of clang and hitting make.
[ And, as an aside, this goes back decades. The infrastructure around builds was never designed with reproducibility as a design goal. We are basically retrofitting this new requirement on decades of legacy code that never even considered that we would want such a thing ... ]
Not only will it be your choice to accept the binary, but Mozilla also shares those concerns. Hence why they're sandboxing the CDM plugins to limit their access and ability to do anything except what they advertise. We'll have the choice to trust Mozilla's work, disable it, or partake in an effort to confirm that it's as legit as we want, so I honestly fail to see any major issue here.
Why the fuck would they bother, when they can just do that to all of the backbone routers you use?
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
how about "-1 whoosh"?
Climate Progress - Hell and High Water
... all software is implemented on hardware. Even the instructions you send to your processor get translated into other software (microcode) which is what actually gets executed.
Hardware acceleration still runs software.
H.264 isn't 'amazing' because of the hardware acceleration built into everything, its extremely convenient. If OGG was built into everything, we'd be using that instead because thats what would allow us to have long battery life and lower heat dissipation.
H.264 isn't software anyway, its a collection of algorithms and protocols. There are multiple software implementations of H.264, of which cisco's is only one.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager